devel June 2013

devel@lists.fedoraproject.org

224 participants
259 discussions

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 17 Jan '22

17 Jan '22

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

Expanding the list of "Hardened Packages"
by Dhiru Kholia 22 Jul '14

22 Jul '14

Hi, This proposal was originally at https://fedorahosted.org/fesco/ticket/1104 (mitr asked me to move the discussion to fedora-devel to get more attention and feedback) ... http://fedoraproject.org/wiki/Hardened_Packages page mentions that "FESCo requires some packages to use PIE and relro hardening by default." It would be great if this list could be expanded to include even more packages which are at comparatively more risk of being exploited (locally or remotely). Such packages will typically include various system daemons, network daemons and network enabled applications. Lot of network daemons are already using PIE and RELRO (e.g. httpd, MariaDB). So a natural question is why packages in same "network daemons" class like PostgreSQL, Dovecot and MongoDB aren't being hardened? Some of the ways to implement this proposal are, 1. Hardening flags should be turned on (by default) for all packages which are at comparatively more risk of being exploited or which meet some well-defined criteria (suggestions welcome). "Packaging Guidelines" say that "Other packages may enable the flags at the maintainer's discretion." Thinking from a security perspective, I find "Hardening flags can only be disabled for other packages at the maintainer's discretion provided enough justification is given to FESCo" to be more appropriate. 2. An alternate approach is to come up with an expanded list of packages which should be hardened. Any feedback is welcome! -- Dhiru

39 140

Strange ssh / openldap linking problem
by Richard W.M. Jones 21 Mar '14

21 Mar '14

I'm not sure whether or not this is a bug, but it sure looks strange. $ rpm -qf /usr/bin/ssh openssh-clients-6.1p1-6.fc18.x86_64 $ ldd /usr/bin/ssh|grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fad274fc000) /usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link which passes through a -devel package. /usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18 /usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18 /usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18 To cut a long story short, I fixed this by uninstalling openldap-devel and reinstalling it. Now there is no -devel package in the chain: $ ldd /usr/bin/ssh | grep ldap libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fe8caf69000) /lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0 I'd like to understand how the original situation happened, because it broke a supermin-built appliance (RHBZ#954185). I assume ldconfig must have something to do with it. There is nothing unusual in the %scripts of openldap (it just runs ldconfig as you'd expect), nor is there any special openssh/openldap config file in /etc/ld.so.conf.d. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

3 7

Q: webfonts:
by Alec Leamas 06 Dec '13

06 Dec '13

Hi! I'm trying to package a web application with bundled fonts. These fonts are used by the web clients (browsers), and just served from the Fedora webapp. The case is similar to javascript .js files. Trying to package the webfonts as dependencies I have run into problem together with my reviewer. Basically, we don't know what to do. Some questions: - Where should webfonts be stored? A specific dir would be good, since some fonts exists in both a webfont and desktop variant with the same filenames. - How shoulld webapps get access to the system webfont? Is the apache config file approach used for ..js files, where the webapp gets access to specific system paths, usable also here? - Given that the primary concern about fonts seems to be licensing, is it really meaningful to unbundle them? This is the short story. The somewhat longer: https://fedorahosted.org/fpc/ticket/277 Any help, out there? --alec

10 30

Moving xine-lib and dependent apps to RPM Fusion Free for F17?
by Kevin Kofler 24 Oct '13

24 Oct '13

Hi, the current xine-lib maintainer speaking. :-) The Xine project: http://www.xine-project.org/home has recently released a new major version, version 1.2.0. Unfortunately, among the list of changes: http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/vi… there are these new "features": * Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms, this makes use of libavutil even outside the FFmpeg decoding plugin, but avoid duplication of algorithms between different plugins. * Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed. * FFmpeg is now required as an external dependency; if you want to build xine-lib from source, please download a copy of FFmpeg from their SVN server. which basically mean that xine-lib now has a global, non-optional dependency on FFmpeg's libavutil library. So there are 4 possible ways forward: (a) Stick with 1.1.x forever. I don't think that's a good idea in the long run, upstream won't be providing security fixes for the old branch forever. (b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't think libavutil, as opposed to libavcodec, is actually patent-encumbered, though that'd also have to be checked.) The issue there is that FFmpeg upstream obviously doesn't support this. It would need some more black packaging magic of the kind already done in xine-lib, and more legal auditing. I don't think I want to investigate going down that road. (c) Bundle parts or all of libavutil with xine-lib. Yuck!!! (d) Move the whole thing (back) to RPM Fusion (where it originally was, before we started needing xine-lib for Amarok and Phonon, which both no longer use it). It would go to the Free section, of course. My proposal is to go with (d). The following packages currently depend on xine-lib: * gxine * (k9copy – already in RPM Fusion, not affected) * kaffeine (my package, the reason why I maintain xine-lib in the first place) * oxine * xine-plugin * xine-ui These packages would have to move to RPM Fusion along with xine-lib. In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git repository, so it will likely have to move to RPM Fusion sooner or later anyway. This means the affected packages are basically *xine*. So my plan is to retire (for my packages, resp. have the respective maintainer retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the respective maintainer get) them into RPM Fusion Free instead. (I'd take care of xine-lib and kaffeine myself, I hope the maintainers of the other packages will take care of them.) Comments? Objections? Kevin Kofler

4 15

anaconda / initial-setup / gnome-initial-setup: can we do this better?
by Adam Williamson 15 Oct '13

15 Oct '13

So I'm writing a blog post on this topic ATM, and that really kinda brought home how messy this design is at present. Quick refresher for anyone who hasn't looked at it much yet: in F19, anaconda can create user accounts, and 'firstboot' has been replaced with two alternative tools, 'initial-setup' which is used in any graphical install other than a GNOME install and just replicates anaconda's 'root password', 'user creation' and 'date/time' spokes, and gnome-initial-setup, which is used in GNOME installs and is its own whole thing that can also do user creation. I mapped out all the potential paths through this maze, and got this - 16(!!!) paths: anaconda: root pw, no user - g-i-s: admin user i-s: admin user i-s: regular user console: root anaconda: root pw, regular user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: regular user + root anaconda: root pw, admin user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: admin user + root anaconda: no root pw, admin user - g-i-s: user mode i-s: edit root pw or user i-s: leave intact console: admin user + root Note the paths marked "i-s: edit root pw or user" are pretty messy and open ended in themselves - initial-setup always runs if installed, no matter what you set in anaconda, and at least theoretically lets you change the settings you picked in anaconda. This is...kinda nuts, and a QA nightmare. Can we maybe take a step back and look if there's a more sensible way to design this, ideally with the GNOME and anaconda teams working together? If we imagined initial-setup didn't exist and we only had the anaconda/g-i-s case, the proliferation of trees at least looks rather better, because g-i-s can't set the root password or change what anaconda did; if you create a user account during anaconda, g-i-s runs only after you log in with that user account and just lets you configure various settings for that user account, it doesn't let you create other user accounts (this is what I've labelled as 'g-i-s: user mode' in the tree). So the anaconda/g-i-s paths are broadly sane already. It's the anaconda/i-s paths that are really complicating things. Still, it might help to just take a step back and decide if we really need all this flexibility. We could, for instance, simply force user creation during anaconda, dump initial-setup entirely, and use only gnome-initial-setup's "user mode" (desktops other than GNOME could implement something like this "user mode" if they wanted to, or not). That would be a hell of a lot simpler to code, test, support and explain, with the minor(?) drawback that you couldn't install without a user account and then create it on first boot any more. Xkcd Law tells us that someone will not be happy about this: https://xkcd.com/1172/ but still, it seems to be worth considering. Alternatively, we could make i-s behave a lot more like g-i-s: it could dump its 'root password' and 'date/time' spokes, and only run at all, and only to allow user creation, if you didn't create a user during anaconda. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

14 37

bodhi client question
by Joachim Backes 03 Oct '13

03 Oct '13

Dear bodhi/koji specialists, perhaps, this is a dumb question: sometimes after having filed a BZ, I get some email like ----------------------------------------------------------- Package xxxxx-4.1.0.0-4.beta1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xxxxx-4.1.0.0-4.beta1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9971/xxxxx-4.1.0.0-4.be… ------------------------------------------------------------ *My question:* if xxxxx consists of a lot of packages, and I'm only needing some few of them (libreoffice is a good example), how then can I automatically download only those packages installed on my site? The usage of "bodhi -D xxxxx....." will download *all* and not only the locally installed pkgs. Kind regards Joachim Backes -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.4-302.fc19.x86_64 Joachim Backes <joachim.backes(a)rhrk.uni-kl.de> https://www-user.rhrk.uni-kl.de/~backes

8 11

Self Introduction
by Peter Hanecak 19 Aug '13

19 Aug '13

Hello, I've been asked by Luya Tshimbalanga <luya(a)fedoraproject.org> to maintain the gimp-separate+ package for official Fedora project so that it can be included in Design Suite Livemedia. Having read some introductory information, I would now like to introduce myself with few short facts: - I'm using Linux (at start Red Hat, later Fedora) since roughly 1997. - To ease the maintenance of my systems, I'm creating RPM packages "just for myself" since 1998 - this one seems to be the oldest one: http://hany.sk/~hany/RPM/doors1/jserv-doc-0.9.11-2.i386.html - I'm supporter of Free and Open Source Software and small-scale contributor, more recently broadening it with participation in Open Data initiatives. - Now, Luya's invite finally pushed me to come closer to the Fedora project. - I'm earning a living by doing software development and related consulting work. - I'm married with two children. I'm looking forward for future cooperation. And I would also like to thank in advance to all which will help me to get through initial stages of first package submission (https://bugzilla.redhat.com/show_bug.cgi?id=913289). Sincerely Peter -- Peter Hanecak <hany(a)hany.sk> http://hany.sk/~hany/ GnuPG: http://hany.sk/~hany/gpg/E4C349E3.txt

2 3

FYI: F20 Feature: Migrate to Bluez5
by Bastien Nocera 14 Aug '13

14 Aug '13

Heya, In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices. Bluez5 uses a D-Bus API that's not compatible with Bluez4[1] and as such, management applications and a number of libraries and daemons will need to be ported. For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages. Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers. Cheers [1]: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ and http://lwn.net/Articles/531133/

10 14

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel June 2013