Re: Orphaning dnsmasq
On 25/08/11 15:24, Paul Wouters wrote: > Here the issue is: > > 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still > configures and starts dnsmasq (at least on F14 using virt-manager) > (eg I have a /28 bridges to eth1 with static IPs, I don't want it) > > The biggest problem for me is wanting to run a DNSSEC aware resolver, and the > libvirtd/dnsmasq is preventing me from doing a simple "yum install > unbound|bind" > by stealing port 53. Especially on my laptop with libvirtd I think you've got something odd going on I'm using a bridged setup with libvirt and although I do have a dnsmasq running it is for the private network defined in libvirt (which I'm not using) and it is only listing on that private network's address. So when I list networks I just have the default one: virsh # net-list Name State Autostart - default active yes and it is defined over a private address range: virsh # net-dumpxml default default 6229892b-486a-4c48-961a-20298d585e47 and that is what lsof shows dnsmasq as listening on: dnsmasq 2229 nobody6u IPv4 23692 0t0 TCP 192.168.122.1:domain (LISTEN) Though like I say, I don't actually use that as I have br0 setup as a bridge to my ethernet card and use bridged networking with that instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 30/08/11 14:23, Bruno Wolff III wrote: > I'll need to test it. Right now I use explicit modprobe commands in > rc.local, which isn't good for packages. I looked at modprobe.conf > documentation and it doesn't seem like it uses those files to determine > what to load, only what to do if it is loaded. So it may be that udev > is really the correct place to do things. Or modules-load.d if you want to force load a module. tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On 07/09/11 16:52, Nathaniel McCallum wrote: > "gcc -m32 -o foo foo.c" gives me: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file > or directory > > If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package > into the right place and run the command above again I get: Installing the 32 bit glibc-devel package would probably have worked better. > Am I doing something wrong? Or is this a packaging bug? I can't think of > any reason why I shouldn't be able to compile at least a basic C program > with no deps as 32bit on 64bit. Well you can, but you do need things like glibc-devel.i686 to do it... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Delinquent mirror process
On 19/09/11 16:06, Matthew Booth wrote: > I've noticed that mirror.bytemark.co.uk hasn't been updated since 8th > September: > > http://mirror.bytemark.co.uk/fedora/linux/updates/15/x86_64/repodata/ > > However, it's still being handed out by our mirror list. It seems to me > they should be, at least temporarily, dropped as an official mirror. Is > there a process for doing that? > > Also, is there a way to contact them to ask if they've permanently > dropped Fedora, or if this is just a blip? Their mirror site suggests > only Bytemark customers should contact them. I'm a customer so I pinged a tweet at them pointing them at your message. I'm sure they wouldn't have objected to the upstream for the mirror contacting them though. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 04/10/11 14:54, Paul Howarth wrote: > I ran into a similar problem last month. I foolishly set up a bind mount > for a local filesystem, with the new mountpoint living on top of an NFS > filesystem, and set it up in fstab to mount on boot in an F-16 VM. When > I next rebooted, the attempted bind mount happened very early in the > boot process (long before the network was up) and failed, resulting in a > boot failure at an even earlier point that the usual single-user mode, > where all the volume groups hadn't even been scanned and devices added > in /dev, which was tricky to fix until I figured out what had happened > and removed the bind mount entry from fstab. I have a similar problem with some bind mounts over the root filesystem where systemd mounts them while the rootfs is still ro and hence they all wind up as ro until I remount them. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 05/10/11 08:51, Michal Schmidt wrote: > On 10/05/2011 12:18 AM, Lennart Poettering wrote: >> On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote: >>> I have a similar problem with some bind mounts over the root filesystem >>> where systemd mounts them while the rootfs is still ro and hence they >>> all wind up as ro until I remount them. >> >> Is there a bugzilla about this? > > Looks like https://bugzilla.redhat.com/show_bug.cgi?id=718464 Indeed - the stupidity that is NFSv4 is my reason for having the bind mounts in question as well... I was just in the middle of setting up in a test case in a VM and raising a bug but now I guess I don't need to ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and mounting filesystems
On 04/10/11 23:28, Lennart Poettering wrote: > On Wed, 05.10.11 00:18, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote: >> >>> I have a similar problem with some bind mounts over the root filesystem >>> where systemd mounts them while the rootfs is still ro and hence they >>> all wind up as ro until I remount them. >> >> Is there a bugzilla about this? >> >> This is an interesting issue to think about. I wonder what the right fix >> should be though: delay all bind mounts after the / remount? Well I guess the optimal solution is to work out which binds are over the root filesystem and delay those, or indeed in general to delay bind mounts until their source filesystem is mounted. That may be somewhat hard to do though ;-) > Hmm, if you change /etc/fstab and explicitly specify "rw" as option of > the bind mount, does that fix the issue? I have been, and no, it doesn't (until you do a mount -o remount on the filesystem, at which point it is applied). Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: API change: bump mapnik to 2.0 in rawhide?
On 17/10/11 20:02, Alex Lancaster wrote: > Looking at the changelog, it isn't obvious whether this > introduces any ABI/API changes or not, hence this e-mail. I just asked Dane on IRC and he confirms that they are not compatible so the soname needs to be bumped. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 19/10/11 21:48, Richard Shaw wrote: > On Wed, Oct 19, 2011 at 3:26 PM, Lennart Poettering > wrote: >> You should manage acess control of device nodes from udev rules. That's >> the only reasonably safe way to handle these things. And this should not >> be mentioned at all in systemd unit files. > > Well, that's a bit beyond me at this point. I'm not sure that anyone > using MythTV from RPM Fusion is even choosing to run mythbackend as > anyone other than root. Perhaps for the time being I won't give them a > choice. Count me as one person that does... The systemd unit I'm using at the moment (with F15) is: [Unit] Description=MythTV Backend [Service] Environment=MYTHCONFDIR=/etc/mythtv Environment=HOME=/etc/mythtv ExecStartPre=/usr/bin/setfacl -m u:mythtv:rwx -R /dev/dvb ExecStart=/usr/bin/mythbackend --user mythtv --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythbackend.pid ExecStopPost=/usr/bin/setfacl -x u:mythtv -R /dev/dvb PIDFile=/var/run/mythbackend.pid Restart=on-failure [Install] WantedBy=multi-user.target Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 19/10/11 22:27, Kay Sievers wrote: > On Wed, Oct 19, 2011 at 23:20, Richard Shaw wrote: > >> Ok based on Tom's file I came up with the following. I know Lennart, >> you don't like setting ACL's from Systemd, but unless someone want's >> to help me write udev rules that will run before the start of >> mythbackend and after it's stopped, this is all I have: > > Yeah, that looks very wrong. > > Like mentioned earlier in this thread, just put the user into the > audio/video system group and forget about any permissions management. My unit was based on a translation of the old init scripts but yes, it looks like you're right that all of the devices they modify the ACLs on are in either the audio or video groups. I'll try changing my units when the box isn't in use... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 19/10/11 22:34, Tom Hughes wrote: > On 19/10/11 22:27, Kay Sievers wrote: > >> Like mentioned earlier in this thread, just put the user into the >> audio/video system group and forget about any permissions management. > > My unit was based on a translation of the old init scripts but yes, it > looks like you're right that all of the devices they modify the ACLs on > are in either the audio or video groups. > > I'll try changing my units when the box isn't in use... I've tried this now and it all seems to work. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 21/10/11 17:44, Toshio Kuratomi wrote: > On top of that, if I've been following the thread right, the previous rpm > ran as a mythbackend user -- so it's only people who customized away from > that to a root user that will have this migration issue, correct? No - the current RPMs have the ability to run as non-root (if you set a variable in the sysconfig file) but run as root by default. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On 26/10/11 12:45, Kevin Kofler wrote: > Maybe we could do what some sites like kde-apps.org do and default to URLs > which include BOTH the ID and the packagename-version list, but have Bodhi > only actually use the ID and ignore the packagename-version entirely. > > See e.g.: > http://kde-apps.org/content/show.php/Apper?content=84745 > http://kde-apps.org/content/show.php/KPackageKit?content=84745 > http://kde-apps.org/content/show.php/Pink_Pony?content=84745 > http://kde-apps.org/content/show.php?content=84745 > (The first link is what the site produces by default, the second is what it > used to produce before the package got renamed, the third is to prove you > can write in anything and it will be ignored and the fourth is the > equivalent of Bodhi's current ID-based URLs, which also works.) > But I'd put the ID first so it's easier to rip off the ignored stuff from > the link if a short URL is needed. Many CMS systems and the like work in that way. It's also what things like stackoverflow do, for example: http://stackoverflow.com/questions/7901782/war-does-not-start-on-tomcat5-on-redhat-enterprise-server where only the question number really matters - you can change the text which follows to anything. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Having been a Fedora (and RedHat before that) user for more years then I care to think about I have decided that it must be high time for me to contribute my first package. So I have opened a review request for libgxps with the aim of getting support for XPS files into evince. The review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=751568 Now all I need is a sponsor and some reviews... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: World IPv6 Day Problems
On 08/06/11 16:20, Trever L. Adams wrote: > libvirtd VMs cannot have outside accessible IPv6 addresses > autoconfigured. I mentioned the problem, at least as far as I was able > to find it at https://bugzilla.redhat.com/show_bug.cgi?id=514749 Works fine for my VMs with bridged networking - they see the radvd on the network and configure an address. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: World IPv6 Day Problems
On 08/06/11 16:42, Trever L. Adams wrote: > Would you care to share some documentation of some kind? > > >TheCommons > > > > > > > > > > > > That didn't automatically add any of the ipv6 addresses. As I said, no > radvd. If I read the bug reports correctly, it is supposed to be automagic. Ah that's a virtual bridge between your VMs. I'm bridging my VMs to br0 which is a bridge that includes the host's ethernet interface so that the guests have direct access to the local LAN and can see the radvd that is running on our gateway router. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 09:12, Richard W.M. Jones wrote: > On Fri, Jun 10, 2011 at 09:03:16AM +0200, tim.laurid...@gmail.com wrote: > >> - Running Windows application in a windows guest, runs very smooth, no >> delay in updating the GUI. > > You should try new versions. I've never had a problem with delays > updating the GUI, even in old versions. With SPICE support, access > over the network beats everything. Spice is cool, I just wish there was an agent/drivers for 64 bit Windows guests... Not that I have any real problem with a Windows guest and VNC graphics but it would be very nice to have working cut and paste. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 16:12, Michael Cronenworth wrote: > Richard W.M. Jones wrote: > >> They are available, but I think you have to build them yourself from >> source. All the information is here: > > 2. Make guest additions dead simple to install. Having to compile them > with a Windows DDK is not dead simple. Actually building the driver (once I'd downloaded the 620Mb DDK) was quite easy. I'm still scratching my head over how to actually install it though ;-) That was only the graphics driver anyway - what I really want is the agent for the clipboard protocol. To be fair you can download both the drivers and the agent in prebuilt form at http://spice-space.org/download.html but only for 32 bit Windows at the moment. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On 10/06/11 16:54, Michael Cronenworth wrote: > Tom Hughes on 06/10/2011 10:25 AM wrote: >> Actually building the driver (once I'd downloaded the 620Mb DDK) was >> quite easy. I'm still scratching my head over how to actually install it >> though ;-) >> >> That was only the graphics driver anyway - what I really want is the >> agent for the clipboard protocol. >> >> To be fair you can download both the drivers and the agent in prebuilt >> form at http://spice-space.org/download.html but only for 32 bit Windows >> at the moment. > > I'm not sure why you're using this argument as a positive thing. In VB > (or any third-party VM software) installing the guest additions for > 32-bit /and/ 64-bit OSes is as easy and clicking "Install" and > rebooting. No driver downloads. No config file editing. Until > libvirt/qemu/kvm/spice provide a similar solution there is no comparison. I wasn't trying to suggest that the current situation is perfect, just that it isn't always as bad as the DDK thing sounded. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: find obsolete configs
On 23/06/11 14:08, Kevin Fenzi wrote: > /etc/inittab is an odd case due to the switchover to systemd, and in > fact should probibly be removed or replaced with a placeholder at some > point. It is - on my F15 boxes it looks like this: # inittab is no longer used when using systemd. # # ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM. # # Ctrl-Alt-Delete is handled by /etc/systemd/system/ctrl-alt-del.target # # systemd uses 'targets' instead of runlevels. By default, there are two main targets: # # multi-user.target: analogous to runlevel 3 # graphical.target: analogous to runlevel 5 # # To set a default target, run: # # ln -s /lib/systemd/system/.target /etc/systemd/system/default.target # Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something wrong with atlas-3.8.3-18.fc14.src.rpm
On 05/07/11 13:42, Neal Becker wrote: > 0. F15 x86_64 > 1. yumdownloader --source atlas > 2. rpmbuild -D 'enable_native_atlas 1' atlas.spec > error: line 75: Bad Requireflags: qualifiers: Requires(posttans): > chkconfig > > How can it be that my system fails rpmbuild but fedora build is OK? Because the Fedora build was done with an older version of rpmbuild that didn't complain about the unrecognised qualifier on the Requires. That complaint is a recent addition to rpmbuild. No doubt it was meant to be Requires(posttrans) with an r. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 10:19, Paul F. Johnson wrote: > It seems that after yesterdays (5th July) mammoth rawhide update, that > the cups daemon has vanished from /etc/init.d - any idea if this is just > an oversight? I would guess (given that Lennart used it as his example in his recent article) that it has been converted to be a native systemd service. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 10:25, Paul F. Johnson wrote: >> I would guess (given that Lennart used it as his example in his recent >> article) that it has been converted to be a native systemd service. > > Ah. > > Looks like I may need to bz it as unless I run /usr/sbin/cupsd -F from a > terminal, the service isn't starting. s-c-services and s-c-printer isn't > showing anything. Well first of all I'd check it's enabled as I believe policy is that the enabled/disabled state of a service is not carried over when it migrates from svsvinit to systemd. So a "systemctl enable cups.service" might be the best thing to try first - certainly my rawhide VM seems to have had it disabled. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cups service gone walkabouts?
On 06/07/11 13:27, Tim Waugh wrote: > On Wed, 2011-07-06 at 11:32 +, "Jóhann B. Guðmundsson" wrote: >> I thought with Lennart patch/setup on his blog the only case you need to >> enable cups is if you are going to be running centralized printer server >> which in that case the admin himself would enabled it hence we would not >> have to have it enabled by default... > > Yes, you're quite right, my mistake. Except that the cups package only seems to have the service unit and not the socket or path units so socket activation won't work at the moment. I had assumed that was deliberate, but maybe not? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On 08/07/11 17:02, Petrus de Calguarium wrote: > I ran the script, output: > > Checking hardware requirements [ OK ] > Checking for SMBIOS type 41 support[FAILED] > Checking for SMBIOS type 9 support [ OK ] > Checking for PCI Interrupt Routing support [ OK ] > > The instructions say: > > "If the output of the script is [ OK ] and any of the following checks > is [ OK ], your hardware is supported by biosdevname". > > So, what's wrong? Did you upgrade this machine from an earlier version of Fedora? If so then I suspect the old names will stick because you will have udev persistent naming rules for them. Check /etc/udev/rules.d/70-persistent-net.rules and I bet you have rules that are forcing the ethX names. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
On 10/11/11 13:38, Simo Sorce wrote:
> On Thu, 2011-11-10 at 19:07 +0800, Mathieu Bridon wrote:
>
>> Yes, in case of such a fast-forward then rebasing gives the same result
>> as merging.
>
> No, you are dead wrong here. Merging does *join* the history of 2
> branches in git, and the top commit has multiple ancestors.
Not if it is a fast forward merge, unless you force it. Here's what the
manual says:
--ff, --no-ff
Do not generate a merge commit if the merge resolved as a
fast-forward, only update the branch pointer. This is the default
behavior of git-merge.
With --no-ff Generate a merge commit even if the merge resolved as
a fast-forward.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Systemd unit file executed as non-root user, WAS: Systemd unit file: Can/Should ExecStart and ExecStop run a script?
On 17/11/11 22:09, Richard Shaw wrote: > On Thu, Nov 17, 2011 at 3:56 PM, Richard Shaw wrote: >> On Thu, Nov 17, 2011 at 3:41 PM, Jeffrey Ollie wrote: >>> On Thu, Nov 17, 2011 at 3:34 PM, Richard Shaw wrote: >>>> Ok, reviving this conversation! >>>> >>>> I ran into the issue that user "mythtv" can not create the file >>>> "/var/run/mythbackend.pid". I see other services that have their pid >>>> file owned by their own user... >>> >>> systemd doesn't really need a PID file to manage the service, can >>> mythtv be told not to create it? If it insists on creating it see if >>> you can move it to a subdirectory of /run (like /run/mythtv) that is >>> owned by mythtv. >> >> Well PIDFile is recommended when using type forking. One option would >> be to drop the "--daemon" option and move to type "simple". > > I tried this and it appears to work. The other option is to create a file in /etc/tmpfiles.d that defines the /var/run/mythtv (or /run/mythtv) directory so that you can then write the PID file to it. >>>> Also, user "mythtv" can't write to the log file in /var/log/mythtv/ >>> >>> Change the ownership of /var/log/mythtv. > > I added "install -d -o mythtv -g mythtv /var/log/mythtv" to %post for > the backend package. Is there a better way to do this? Yes! Create it in the %install section if the spec file and then add it to the files list. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora clean up process seems to be seriously broken...
On 22/11/11 17:53, Michael Schwendt wrote: > Uh, come on, ... package submitters waiting on the NEEDSPONSOR list > could _really_ work a little bit more actively on persuading potential > sponsors of their packaging skills. Instead, some wait silently for > months without doing any package review themselves. As somebody who is in exactly that situation all I can say is that if doing informal reviews is an essential prerequisite to getting sponsored then the wiki could be a lot clearer. Currently it reads more like it's just one thing that may help. Tom (who is off to look for something to review) -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Detecting Postgres version during build
On 07/03/12 10:22, Gianluca Sforna wrote: I am not sure this is going to work (at least in the present case): the package includes some SQL code along with a shared object that pgsql server runs to provide the chemical functions. AFAICT setting this up is completely server side (see http://code.google.com/p/rdkit/wiki/BuildingTheCartridge for details) and unless we have both 8.x and 9.x in any EL or Fedora branch you just want to pick and install the one that is provided by the package. It might be worth looking at how something like the postgis package handles this, as it also contains a Postgres extension. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Detecting Postgres version during build
On 07/03/12 10:45, Gianluca Sforna wrote: On Wed, Mar 7, 2012 at 11:32 AM, Tom Hughes wrote: It might be worth looking at how something like the postgis package handles this, as it also contains a Postgres extension. Yeah. useful: http://pkgs.fedoraproject.org/gitweb/?p=postgis.git;a=blob;f=postgis.spec;h=53c558366da23ea5afdec41331b3ed40b0138c72;hb=HEAD It seems it uses an approach similar to what Rich suggested to check version. It also seems to build for/against a single postgresql version, adding an explicit require for the same version (not sure how you can end up with a mismatch tough, maybe on upgrades?) Postgis does include 3GL functions that are installed into postgres so will be fairly closely tied to the postgres version it was compiled against anyway. If what you're dealing with is pure SQL then it may be less closely tied to a specific version that postgis is. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: qmake needed by fedora-review?
On 08/07/15 20:02, Dave Johansen wrote: I'm trying to run fedora-review. Do I have something setup incorrectly? Or am I doing something wrong? It keeps running into issue with not finding qmake, but isn't everything supossed to be done in mock? The build is done in mock, but that spec is using qmake in macro definitions in the spec file and fedora-review is presumably examining the spec locally before invoking mock. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 builds not getting tagged as update candidate?
On 15/07/15 21:11, Jonathan Underwood wrote:
I am finding I can't push updates for F23:
$ fedpkg update
/usr/lib/python2.7/site-packages/fedpkg/cli.py:169:
DeprecationWarning: Commands._hash_file is deprecated and will be
removed eventually.
Please use Commands.lookasidecache.hash_file instead.
hash = self.cmd._hash_file('bodhi.template', 'sha1')
Creating a new update for python-importmagic-0.1.3-3.fc23
python-importmagic-0.1.3-3.fc23 not tagged as an update candidate
Yet in koji, I see that build listed as f23-candidate:
https://koji.fedoraproject.org/koji/taskinfo?taskID=10370284
Some unintended fall out from the branching process?
It's normal - updates are only turned on some time after branching so
initially you don't need to create updates.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Boost updated to 1.58.0 in rawhide and f23
On 22/07/15 14:54, Jonathan Wakely wrote: mapnik-0:2.2.1-0.4.20150127git0639d54.fc23.src nodejs-mapnik-vector-tile-0:0.6.2-6.fc23.src I did these for both branches when you announced it at the weekend. nodejs-mapnik-0:1.4.17-7.fc23.src This one is proving more interesting... It builds fine for F23 but fails some tests on F24 although it still builds fine with the old boost. As best I can tell it's down to boost::spirit::karma but that hasn't actually changed in the new boost, and in any case the new boost works in F23. I'm kind of stumped at the moment. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Boost updated to 1.58.0 in rawhide and f23
On 23/07/15 22:33, Josh Stone wrote: On 07/22/2015 07:50 AM, Jonathan Wakely wrote: On 22/07/15 15:30 +0100, Tom Hughes wrote: On 22/07/15 14:54, Jonathan Wakely wrote: mapnik-0:2.2.1-0.4.20150127git0639d54.fc23.src nodejs-mapnik-vector-tile-0:0.6.2-6.fc23.src I did these for both branches when you announced it at the weekend. Great, thanks. nodejs-mapnik-0:1.4.17-7.fc23.src This one is proving more interesting... It builds fine for F23 but fails some tests on F24 although it still builds fine with the old boost. As best I can tell it's down to boost::spirit::karma but that hasn't actually changed in the new boost, and in any case the new boost works in F23. I'm kind of stumped at the moment. I'll look into it and see if I can figure it out. It's good that the F23 build is OK, as that's obviously the one with more time pressure. Beware! I was just looking into dyninst, which also succeeded on F23 but failed on F24. But looking at the root.log for F23 reveals it still had 1.57! f23-boost: http://koji.fedoraproject.org/koji/buildinfo?buildID=671537 f24-boost: http://koji.fedoraproject.org/koji/buildinfo?buildID=670925 nodejs-mapnik on f23-boost also had boost 1.57: http://koji.fedoraproject.org/koji/buildinfo?buildID=669822 Now that I have rebuilt everything again both builds of nodejs-mapnik are failing, so at least there is some consistency... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Updates not getting pushed?
I have updates for both F21 and F22 that were requested for testing on the 22nd and still haven't been pushed, but I also can't change them because trying to do so says: "Unable to add or remove builds from an update that is currently being pushed to the testing repository" It's been saying that for at least 24 hours. Have they got stuck somehow? or is there a general problem with pushing updates? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Updates not getting pushed?
On 26/07/15 15:59, Michael Schwendt wrote: On Sun, 26 Jul 2015 15:49:35 +0100, Tom Hughes wrote: I have updates for both F21 and F22 that were requested for testing on the 22nd and still haven't been pushed, but I also can't change them because trying to do so says: "Unable to add or remove builds from an update that is currently being pushed to the testing repository" It's been saying that for at least 24 hours. Have they got stuck somehow? or is there a general problem with pushing updates? https://lists.fedoraproject.org/pipermail/devel/2015-July/212700.html Thanks - not sure how I missed that... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GDAL 2.0 soname bump
On 27/07/15 14:34, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jul 27, 2015 at 03:04:18PM +0200, Dan Horák wrote: On Sat, 25 Jul 2015 12:39:00 +0200 Volker Fröhlich wrote: https://copr.fedoraproject.org/coprs/volter/gdal-2.0/builds/ I therefore plan to put 2.0 into Rawhide and F23 this weekend. are you going to do the rebuilds for the dependent packages or should the maintainers do them themselves? I rebuilt python-Fiona. I'm just doing nodejs-srs and will do mapnik afterwards (which will need doing in the boost side tag as well...). Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] FTBFS Packages in rawhide (2015-07-27)
On 27/07/15 15:23, Peter Robinson wrote: From dealing with this for arch bringups I know there are quite a few, but likely in the high teens/low 20s in number, of packages that use execstack. Not sure what feature it provides as I've never been bothered enough to look into it but it's generally used at build time not install time which means it won't be picked up by repoquery. It allows the "requires executable stack" flag in an ELF image to be tweaked. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 21/08/15 08:46, Till Hofmann wrote: On 08/21/2015 09:00 AM, Ralf Corsepius wrote: Anywas, this time bodhi offered me a "push to testing" and "push to stable" (!) button (Note: "push to stable") I used "pushed to testing" to re-push it. I just tested "push to stable" on an unpushed update: Despite the name, it pushes to testing: https://bodhi.fedoraproject.org/updates/parcimonie.sh-0-0.4.20150804gitc009937.fc22 At least you have a button to push to stable. I've just been notified of three updates that I can push and none are showing any buttons. Given how completely and utterly broken this apparently is, should somebody be thinking about rolling back until it can be fixed? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ncurses update to 6.0
On 04/08/15 11:33, Miroslav Lichvar wrote: The ncurses upstream has released a first 6.0 version few months ago. The default ABI version has changed to 6, which enables some extensions to allow more colors, mouse wheel, etc. The ABI version 5 is still supported and can be selected with a configure option. We should switch to the new ABI, but we will probably want to provide the old ABI 5 libs even when all Fedora ncurses applications are rebuilt with the new ABI to not break 3rd party packages. Dependency on libncurses.so.5 or libtinfo.so.5 is pretty common. As for updating the ncurses package, my current plan is to build the libs in both ABIs (so there are four builds total with the wide and narrow versions), use the ncurses-libs subpackage for the new ABI 6 libs and create a new subpackage for ABI 5 libs. What would be a good name of the subpackage? ncurses-libs5, ncurses5-libs, compat-ncurses5, or something else? According to http://www.gnu.org/software/ncurses/ the new ABI should include symbol versioning, which would hopefully avoid the need for a repeat of this pain in the future, but as far as I can see none of the symbols in the current F23 build are versioned? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: can't submit updates for f22?
On 25/08/15 05:38, Kaleb KEITHLEY wrote: I must have missed some announcement? Yes. The bodhi 2 announcement that told you to update python-fedora to version 0.5.5-1. I'll grant you it didn't exactly make it clear that the specified version was only in the testing repos and not in the main updates repos ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: how to set/unset env variables in spec file
On 08/09/15 12:15, Jan Chaloupka wrote: I am assuming all scripts you are referring to are sourced and run in %build section. Can you be more specific which commands are you running? %build section is interpreted as a bash script so source and unset should work. Without the concrete example it is hard to guess what is going wrong. The example is actually in his first thread from a few hours ago. Of course starting a second thread after only two hours probably wasn't the best plan. In any case I suspect the answer is that he needs to export the variables as the original thread he implied that he normally uses zsh and if he's used to having zsh with ALL_EXPORT set then he may not have realised that other shells may require things to be explicitly exported. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No autocomplete for new package in bodhi 2.0?
On 13/09/15 19:02, Kevin Fenzi wrote: On Sat, 12 Sep 2015 16:15:24 -0700 Dave Johansen wrote: I just finished the review for cppformat ( https://bugzilla.redhat.com/show_bug.cgi?id=1216279 ) and went to submit the updates. I noticed that bodhi 2.0 won't autocomplete the names of updates. I believe that would happen before the update to 2.0. Is this a known issue? I didn't find it when looking through the list at https://github.com/fedora-infra/bodhi/issues Not fully sure what you mean here... If you are submitting a new update you should be able to enter the name of the package in the "Packages" area, select the package name and then hit return and it should populate candidate builds and related bugs. Normally you're right, but if the package has only just been created then it doesn't work. I assume bodhi catches up eventually but there is definitely a delay when a new package is created during which bodhi won't find it and you have to enter the build name instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] RFC mass bug reporting: checksec failures
On 16/09/15 18:19, Jason L Tibbitts III wrote: Of course, several packages I comaintain are on the list (mainly due to Partial RELRO) and I have zero idea how to fix them. I read about what RELRO means from the blog post but that doesn't tell me what I actually need to do to make the errors go away, or even how to see what's causing them. The key thing to get full RELO rather than partial seems to be linking with "-z now" but the way that happens with rpmbuild appears to be extremely fragile... Basically if you use %configure and the package uses libtool then ltmain.sh will get edited with sed to add this to the compiler flags: -specs=/usr/lib/rpm/redhat/redhat-hardened-ld In turn that specs file adds "-z now" to the linker flags. So if you're building a package that doesn't use autoconf, or does but doesn't use libtool, then it likely won't happen and you will only get partial RELRO. What I'm not sure about is why it's done like that rather than editing LDFLAGS as is done for the -zrelro that gets you partial RELRO. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 02/10/15 15:22, Matthew Miller wrote: On Fri, Oct 02, 2015 at 02:19:19PM +0200, Ralf Corsepius wrote: only for projects where upstream is fully active and cares about the security vulnerabilities in the bundled copies of software well. Correct. That's one of the criteria, FPC is trying to consider when granting bundling exceptions. Openly said, these are the easy cases, we often grant bundling exceptions. The problematic ones are those cases, when it's obvious upstream lacks experience and/or technical skills to understand "unbundling" /"bundling" and resources to take care about "upstreams of their bundled sources. These often are smaller projects - in many cases - one-man shows. Ralf, right now the documented list of reasons FPC might allow exceptions don't give this impression. The closest I see is "Active upstream Security Team", but that has a number of qualifications linked by capital-letters and bold, like "the upstream project is actively working on unbundling" and also notes "this rationale may not be sufficient in and of itself" and that this exception is likely to be temporary. Well I have personal experience of FPC refusing a bundling exception even when the upstream of the bundled source is essentially dead and hence not in any position to respond to anything so I don't really buy it either. I'm actually very much in favour of not allowing bundling in general and mostly wish we would keep the current policy. That said I do realise it is becoming more and more of a problem and what I was originally seeing mostly in javascript code while dealing with node modules is not spreading more into C++ code and the like. Currently the situation is such, and the (perceived) difficulty of getting exceptions such that I avoid even reviewing things where it looks likely to be an issue never mind actually packaging them myself. Recently I even saw a case of a header only C++ library bundling another C++ head library which raises slightly metaphysical questions since dependants of a header only library need to be rebuilt when it changes anyway if they are to pickup security fixes. Strictly speaking that's even true of a more traditional library if the security fix happens to be in a header, but I wonder how well we pick up such things and propagate them? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction / Contributing a package to Fedora
On 29/07/14 15:45, Derek Pressnall wrote: For the Source0 URL, since this project is hosted on Github, the URL that leads to the tar.gz file doesn't contain the tar file name (it is "https://github.com/derekp7/snebu/tarball/master";, which ends up creating the tar.gz file name on the fly through HTTP header / javascript magic). I will address this by attaching an exported copy of the tar.gz file as a binary asset to the Github progject release. No need to do that - we have a guideline on how to handle GitHub: https://fedoraproject.org/wiki/Packaging:SourceURL#Github Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Finding all the source packages that include a copy of valgrind.h
On 14/09/14 10:30, Mark Wielaard wrote: On Sat, 2014-09-13 at 05:44 +0200, Ralf Corsepius wrote: It also would seem reasonable to me to file a ticket to FPC, such that FPC can try to examine this case. I have to apologize for not knowing how to file a ticket to FPC. Where would I do that? I did file a tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1141461 Specific packages that I identified to contain a private copy of valgrind.h have a bug filed that blocks that tracker bug. The FPC trac is at https://fedorahosted.org/fpc/ Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Minifying a javascript library
On 05/03/15 15:08, Jonathan Underwood wrote: I am trying to package up the java script library web-socket-js in order to unbundle it from xpra (currently under review). The javascript packaging guidelines[1] require that "If a JavaScript library typically is shipped as minified or compiled code, it must be compiled or minified as part of the RPM build process." I am not at all familiar with java script - what is the recommended tool for minifying .js files? Well the idea normally is to use whatever upstream uses, just that you should do it yourself in the spec file rather than use the minimised version from upstream. That may not be possible if the minimiser upstream is using is not, or maybe even cannot be, packaged for Fedora. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libdwarf build failure with hardened builds
Does anybody have any clue what's going on here: https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log It's an update to libdwarf, but the actual cause appears to be that it doesn't like the new hardened build options. It's a glibc symbol that it seems to be complaing about though: /usr/bin/ld: dwgetopt.o: relocation R_386_GOTOFF against undefined symbol `optopt@@GLIBC_2.0' can not be used when making a shared object The dwgetopt.o file appears to have been been correctly build with the hardening flags: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -I. -I. -I./../libdwarf -DCONFPREFIX=/usr/local/lib -c ./dwgetopt.c Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libproj soname bump
It appears the soname of libproj was changed in rawhide yesterday, so any dependencies will need to be rebuilt. I'm taking care of mapnik now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Harden_all_packages_with_position-independent_code + guile modules
On 12/03/15 14:41, Adam Jackson wrote: On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote: However I can add my recent story: After hardening perl, loading a DSO by perl failed. I believe the reason was the DSO had an undefined symbol which was not defined in any SO_NEEDed libraries. But because the symbol was never used at run-time, before hardening the executable, run-time linking passed. But after hardening, the -znow feature caused resolving all symbols at link time, including the missing symbol, so dlopen(3) failed. We may want to revisit this, honestly. The actual proposal was just to build executables as PIE, right? Forcing -z now is a bit more than maybe was expected. On top of which there seems, despite a number of questions posted here since the change went live, very little assistance from the proposal owners with fixing packages that have been broken by it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Harden_all_packages_with_position-independent_code + guile modules
On 12/03/15 17:14, Till Maas wrote: On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote: On top of which there seems, despite a number of questions posted here since the change went live, very little assistance from the proposal owners with fixing packages that have been broken by it. I do not see much value in repeating responses if others have already figured something out. So to workaround build failures because of it for individual packages is to disable the flags for the respective package. This allows to build a package for now so the actual problem can be analysed without disturbing updates for the package. Well I haven't figured out how to fix libdwarf (see message this morning) nor do I have any idea what I should do next to try and figure it out. So unless I ignore the "rawhide first" rule it seems I can't update that for F22 until the mass rebuild which might apparently fix it in rawhide. Alternatively I can disable hardened builds, but I assumed that needed permission from somebody... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Harden_all_packages_with_position-independent_code + guile modules
On 12/03/15 17:48, Till Maas wrote: On Thu, Mar 12, 2015 at 05:26:43PM +, Tom Hughes wrote: Well I haven't figured out how to fix libdwarf (see message this morning) nor do I have any idea what I should do next to try and figure it out. So unless I ignore the "rawhide first" rule it seems I can't update that for F22 until the mass rebuild which might apparently fix it in rawhide. Alternatively I can disable hardened builds, but I assumed that needed permission from somebody... Sorry that this was not clear. You can go ahead and disable the check for now. According to my memory it is in general permitted to adjust the build flags if there are important reasons for this. It would be great if you can try to include the PIE build flags if only the "-z now" build flag is causing problems. Btw. why are you setting the CFLAGS manually before running %configure? %configure should already take care of them. I think the CFLAGS things was inherited from the previous owner of the package. I've removed it now, and disabled the hardened build for now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
An everyday tale of dnf
So this morning I cloned an up to date rawhide VM and attempted to convert it to F22 by using "dnf distro-sync" on it. Obviously that is a fairly advanced use case but I think one tale of what happened at the end of that process will highlight why I often find myself shouting WTF at dnf when going beyond basic install/update of packages. There were other issues along the way before I got to this point... Having eventually completed the distro-sync I wanted to check for any orphans that needed sorting out. Google told me dnf-plugins-extras was that I needed to replace package-cleanup, so I installed it, only to find that every use of dnf now reported: fedora22 [~] % sudo dnf upgrade Failed to synchronize cache for repo '_local' from 'file:///var/lib/dnf/plugins/local': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried, disabling. After shouting WTF yet again I determined that dnf-plugins-extras includes python-dnf-plugins-extras-local which apparently tries to use a non-existent local directory as a hidden extra repo. Fine whatever, we don't need that, so lets remove it: fedora22 [~] % sudo dnf erase python-dnf-plugins-extras-local Dependencies resolved. PackageArchVersion Repository Size Removing: dnf-plugins-extras noarch 0.0.6-2.fc22 @System0 python-beautifulsoup4 noarch 4.3.2-3.fc21 @System 605 k python-dnf-plugins-extras noarch 0.0.6-2.fc22 @System0 python-dnf-plugins-extras-debugnoarch 0.0.6-2.fc22 @System 26 k python-dnf-plugins-extras-localnoarch 0.0.6-2.fc22 @System 11 k python-dnf-plugins-extras-orphans noarch 0.0.6-2.fc22 @System 9.3 k python-dnf-plugins-extras-repoclosure noarch 0.0.6-2.fc22 @System 9.4 k python-dnf-plugins-extras-repographnoarch 0.0.6-2.fc22 @System 9.5 k python-dnf-plugins-extras-repomanage noarch 0.0.6-2.fc22 @System 12 k python-dnf-plugins-extras-snapper noarch 0.0.6-2.fc22 @System 4.4 k python-dnf-plugins-extras-tracer noarch 0.0.6-2.fc22 @System 7.7 k python-html5libnoarch 1:0.999-5.fc21 @System 1.2 M python-psutil x86_64 2.1.3-1.fc22 @System 518 k snapperx86_64 0.2.5-2.fc22 @System 1.0 M snapper-libs x86_64 0.2.5-2.fc22 @System 846 k tracer noarch 0.5.8-1.fc22 @System 272 k Transaction Summary Remove 16 Packages Installed size: 4.5 M Is this ok [y/N]: y WTF! Oh, of course, removing that removes dnf-plugins-extras and then everything else counts as auto installed and gets removed. After ceasing banging my head on the desk I let it go ahead and then add back python-dnf-plugins-extras-orphans to get the plugin I actually wanted. So now I run "dnf orphans" at last and am a little surprised to get 589 lines of output: fedora22 [~] % sudo dnf orphans CharLS-devel-1.0-8.fc22.x86_64 ... zsh-5.0.7-6.fc22.x86_64 But those are F22 packages I hear you say! Indeed they are, and list confirms that they do exist in configured repositories: fedora22 [~] % sudo dnf list --showduplicates zsh Using metadata from Wed Apr 8 11:02:28 2015 (0:53:45 hours old) Installed Packages zsh.x86_64 5.0.7-6.fc22@System Available Packages zsh.x86_64 5.0.7-6.fc22@System zsh.x86_64 5.0.7-6.fc22 fedora-base WTF! Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: An everyday tale of dnf
On 08/04/15 15:26, Lubomir Rintel wrote: Hi Tom, On Wed, 2015-04-08 at 12:14 +0100, Tom Hughes wrote: WTF! Err, I already did report them: https://bugzilla.redhat.com/show_bug.cgi?id=1209862 https://bugzilla.redhat.com/show_bug.cgi?id=1209864 I was simply trying to provide input to the ongoing discussion about how surprising it can often be to users used to yum. It was also born of a certain amount of frustration at the end of a long morning doing battle with dnf where many of the things that I had to workaround are things which I know have already been stated to be deliberate design choices and which I therefore didn't feel were worth reporting. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 09/04/15 10:30, Radek Holy wrote: On Wed, Apr 08, 2015 at 08:22:53 -0400, Radek Holy wrote: AFAIK, YUM's --skip-broken does two things: 1) it selects another version of the requested package if the most suitable cannot be installed 2) it skips the requested package if none of its versions can be installed (2) was intentionally not supported in DNF so far but we have been repeatedly receiving bug reports complaining that this "feature" is missing. We have finally received a use case for it and thus we are considering an implementation as a plugin. Doesn't 2 apply if no package list is given for dnf update? Hm, well, in case of upgrade some version of the given package is already installed so literally no (because the already installed version can be installed :-) ). But let's say that we both are correct because upgrade is kind of special in this case. We can think about changing the upgrade command to be consistent with the install command if there is a demand to do that but so far I'm fine with the current situation. I think that in case of upgrade, it's more common to ask to upgrade as much as you can while in case of install, users/scripts prefer to install everything or fail otherwise. Moreover I think that the change could annoy a lot of users. Sounds reasonable, but include distro-sync in the upgrade case please... That was one of the issues I ran into the other day, where I did something like "dnf distro-sync b*" and if failed because one of the installed packages which matched the wildcard didn't exist in any repo. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf replacing yum and dnf-yum
On 09/04/15 11:10, Tom Hughes wrote: On 09/04/15 10:30, Radek Holy wrote: On Wed, Apr 08, 2015 at 08:22:53 -0400, Radek Holy wrote: AFAIK, YUM's --skip-broken does two things: 1) it selects another version of the requested package if the most suitable cannot be installed 2) it skips the requested package if none of its versions can be installed (2) was intentionally not supported in DNF so far but we have been repeatedly receiving bug reports complaining that this "feature" is missing. We have finally received a use case for it and thus we are considering an implementation as a plugin. Doesn't 2 apply if no package list is given for dnf update? Hm, well, in case of upgrade some version of the given package is already installed so literally no (because the already installed version can be installed :-) ). But let's say that we both are correct because upgrade is kind of special in this case. We can think about changing the upgrade command to be consistent with the install command if there is a demand to do that but so far I'm fine with the current situation. I think that in case of upgrade, it's more common to ask to upgrade as much as you can while in case of install, users/scripts prefer to install everything or fail otherwise. Moreover I think that the change could annoy a lot of users. Sounds reasonable, but include distro-sync in the upgrade case please... That was one of the issues I ran into the other day, where I did something like "dnf distro-sync b*" and if failed because one of the installed packages which matched the wildcard didn't exist in any repo. Hmm. Think I misread a bit what you were talking about, but my request still stands ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ARM build error
I'm getting build errors on ARM relating to a memcpy symbol in glibc: https://kojipkgs.fedoraproject.org/work/tasks/9842/9659842/build.log The actual error is: make: Entering directory '/builddir/build/BUILD/node-sqlite3-9ec57d18b7a19c4a091d0ae76bde5c0916aa3d1b/build' CXX(target) Release/obj.target/node_sqlite3/src/database.o CXX(target) Release/obj.target/node_sqlite3/src/node_sqlite3.o CXX(target) Release/obj.target/node_sqlite3/src/statement.o SOLINK_MODULE(target) Release/obj.target/node_sqlite3.node /usr/bin/ld: Release/obj.target/node_sqlite3.node: No symbol version section for versioned symbol `memcpy@GLIBC_2.2.5' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status node_sqlite3.target.mk:120: recipe for target 'Release/obj.target/node_sqlite3.node' failed On x86 I would expect it to be using memcpy@GLIBC_2.14 in a new program but I'm not sure if ARM has the same symbol versions, or if it does why this would be trying to use the old one? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ping6 and other tool6 awkwardness
On 12/05/15 08:56, Nikos Mavrogiannopoulos wrote: While working for an updated ipcalc to support ipv6 transparently, I figured we have more tools which are not IPv6-ready and awkwardly provide an additional tool with a -6 suffix, supposedly for separate IPv6 support. That looks like a relic of the past, we still drag. IPv6 support should be transparent in programs (fortunately we don't have ssh6). Any objection to fill bugs to merge the following tools with their ipv4 equivalent? Isn't that an issue for the upstream of each tool? It's hardly something that can be addressed at the Fedora level. The relevant upstreams seem to be: ping, tracepath - https://github.com/iputils/iputils traceroute - http://traceroute.sourceforge.net geoiplookup - http://www.maxmind.com/app/c Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: ping6 and other tool6 awkwardness
On 12/05/15 09:07, Tom Hughes wrote: Isn't that an issue for the upstream of each tool? It's hardly something that can be addressed at the Fedora level. The relevant upstreams seem to be: ping, tracepath - https://github.com/iputils/iputils traceroute - http://traceroute.sourceforge.net geoiplookup - http://www.maxmind.com/app/c Looks like there is already an issue (and a Fedora bug) for ping at least: https://github.com/iputils/iputils/issues/5 https://bugzilla.redhat.com/show_bug.cgi?id=617934 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO Elections - June 2015 - Results
On 29/06/15 12:00, Josh Boyer wrote: On Mon, Jun 29, 2015 at 3:50 AM, Jan Kurik wrote: Greetings, all! The elections for FESCo - June 2015 have concluded, and the results are shown below. FESCo is electing 4 seats this time. A total of 90 ballots were cast, meaning a candidate could accumulate up to 540 votes (90 * 6). 90 ballots? I believe that is one of the all time low records on voter turnout. Probably not surprising given the silly way the election was announced... It certainly disenfranchised me. The problem you see is that the announcement was sent out on 20th June, but you couldn't actually vote then, because voting didn't open until the 22nd. So you couldn't just go and vote when you got the announcement but instead you had to remember to do so a few days later. Needless to say I forgot all about it until I saw, somewhat to my surprise, the result email this morning. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 17 Beta Observations
On 23/04/12 14:27, Mark Bidewell wrote: > So it looks for the VMWare 'vmwgfx' driver and it's not there (I'm not > sure if that driver is something Fedora would be expected to include, or > if it's a 'guest additions' kind of thing). Then it falls back on > 'vmwlegacy', which promptly blows up. Given that installing GNOME desktop and Base X via yum yields a functioning desktop, I would assume that the driver is included with Fedora. Well F16 seems to have drivers called "vmware" and "vmlegacy" and F17 has "vmware" only, all in the xorg-x11-drv-vmware package. Neither has a driver called "vmwgfx". Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 05/06/12 11:15, Paul Howarth wrote: On Mon, 04 Jun 2012 20:01:15 -0400 Gerry Reno wrote: Look back several years and you'll find still unaddressed installation bugs for anaconda/preupgrade. For example /boot on RAID. Hmm, I did a fresh F17 install two days ago with /boot on (MD) RAID1 and it worked just fine, with none of the grub issues F16 had with that. Yes you can install (or upgrade with anaconda I think) but what you can't do is upgrade using preupgrade if you have a mirrored system disk. Which is just one of the reasons I do all my upgrades with yum... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how does somobeody install perl(ExtUtils::Embed)
On 17/02/14 11:08, Reindl Harald wrote:
[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb subversion.spec
error: Failed build dependencies:
perl(ExtUtils::Embed) is needed by
subversion-1.8.5-2.fc20.20140217.rh.x86_64
rubygem(minitest) is needed by
subversion-1.8.5-2.fc20.20140217.rh.x86_64
[builduser@buildserver64:/rpmbuild/SPECS]$ sudo yum install
perl(ExtUtils::Embed) rubygem(minitest)
-bash: syntax error near unexpected token `('
_
how is somebody expected to translate such Require / Build-Requires
to a package name yum understands?
You have to quote it, to stop the shell interpreting the parenthesis:
sudo yum install 'perl(ExtUtils::Embed)' 'rubygem(minitest)'
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking
On 21/02/14 14:51, Alexander Todorov wrote: I want to track which packages *DO NOT* have any tests and later be able to focus on creating them (be it working with volunteers, GSoC participants or whoever is willing to step up to this task). Why would you file a bug in the Fedora bug tracker when the package has no test suite upstream? That makes no sense - if the upstream package has no tests then the bug belongs upstream not in Fedora. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking
On 21/02/14 14:57, Daniel P. Berrange wrote: On Fri, Feb 21, 2014 at 02:53:55PM +, Tom Hughes wrote: On 21/02/14 14:51, Alexander Todorov wrote: I want to track which packages *DO NOT* have any tests and later be able to focus on creating them (be it working with volunteers, GSoC participants or whoever is willing to step up to this task). Why would you file a bug in the Fedora bug tracker when the package has no test suite upstream? That makes no sense - if the upstream package has no tests then the bug belongs upstream not in Fedora. I don't believe that is what he is proposing. I read it as meaning filing bugs where upstream *does* have a test suite, but the RPM specfile has not enabled it in %check. That was what I thought he really meant originally, and that was what the wiki page suggested, but it doesn't seem to be what he is saying in the message I quoted. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 02/04/14 18:24, Jaroslav Reznik wrote: == Detailed Description == lbzip2 is an independent implementation of bzip2 compression tool. It provides interface strictly compatible with bzip2, but also adds several new features and improvements, such as: * multi-threaded operation for both compression and decompression, with almost linear scalability, Does that mean that it creates multiple streams in the compressed file? If it does then be aware that some bzip2 decoders (notable the Java one) will not be able to decompress the result. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 02/04/14 19:22, Mikolaj Izdebski wrote: lbzip2 creates only *one* stream per compressed file, even when using multiple threads. Such files can be decompressed with all versions of bzip2, libbz2 and other tools, such as Apache Commons Compress. This is a difference between lbzip2 and pbzip2, which creates multiple streams. Files created with pbzip2 cannot be decompressed by some software, such as libbzip2 (all versions), bzip2 older than version 0.9.0, Apache Commons Compress. That's great then. I was aware that this was an issue with pbzip2 and wanted to make sure it wasn't a problem here. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libdwarf soname bump
I'm about to land a libdwarf update to version 20140519 in rawhide that includes an soname bump to libdwarf.so.1. There only appears to be one dependant package, dyninst, so that will need to be rebuilt - a quick check suggests that it doesn't use the interface that has changed to require the soname bump so a simple rebuild should suffice. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide buildroot creation changes
On 10/10/15 10:59, Rex Dieter wrote: Dennis Gilmore wrote: as of this morning US time we have changed the way rawhide buildroots are created in koji. rawhide is now using dnf to install the packages into the buildroot. this means that in f24 and on dnf will be used to create the buildroot. as well as manage the updates on your system. We will not be making the same change to f22 or f23 in koji, yum will continue to create the buildroot there. please report to Release Engineering [1][2][3] any issue you encounter as a result of this change. Seems all (most?) rawhide builds are failing now. https://fedorahosted.org/rel-eng/ticket/6273 That's the only one I've had that failed in that way. I had another koschei report but that was in the actual build when running tests and passed when run again as a manual scratch build. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive maintainer and unupdated package
On 19/10/15 12:22, Chaoyi Zha wrote: I think someone else has also recently e-mailed about this unresponsive maintainer, "patches". I am looking to update one of his packages, "nodejs" It is currently at version 0.10 in our PkgDB but the current version is 4.2.1 I would be happy to update and maintain this package, but I do not have any rights to it and it is not orphaned yet. Updating nodejs is nothing to be done lightly. It was supposed to be updated to 0.12 for F23: https://fedoraproject.org/wiki/Changes/NodeJS012 There was also an io.js plan: https://fedoraproject.org/wiki/Changes/iojs I don't think that either happened in the end though, and obviously events have been somewhat overtaken by the remerger with io.js. I'd suggest contacting the nodejs list in the first instance anyway as that is where all the experts will be, including patches normally. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unresponsive maintainer and unupdated package
On 19/10/15 12:33, Chaoyi Zha wrote: Ah, there is a Node.js list? I'll look into it and see if anything is going on over there. There is, yes: https://lists.fedoraproject.org/mailman/listinfo/nodejs Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: C++11 enabling in F22?
On 26/10/15 11:23, Peter Robinson wrote: On Mon, Oct 26, 2015 at 11:13 AM, Marek Skalický wrote: Hello everyone, I would like to ask what do you think about enabling c++11 in library in F22? Is it permitted by Fedora guidelines? I am asking because of this bug - https://bugzilla.redhat.com/show_bug.cgi?id=1274307 . And I want to know the opinion of someone else, to decide. It was explicitly not enabled in F-22 because it's not backwards compatible and required a mass rebuild for all c++ applications. It's enabled by default, and we had a mass rebuild as a result, in Fedora 23. As a result of the impact we won't be making such changes for a release that is long GA. You're confusing two different things, though without knowing what that configure patch actually does we can't know what the answer is here. There is, as far as I know, no problem using -std=c++11 in F22 or any other version of Fedora, it's just that the result might not be fully standards compliant. Specifically in F22 there are two minor changes which require a change to the library ABI and as F22 was built with the old ABI you won't get those changes. Neither should affect whether code compiles and works though. So the only thing you must not do in F22 is to set the define that selects the new ABI but you would probably find out quite quickly as you did as you would fail to link if you used any other C++ libraries that had been built with the old ABI. Which is why I say we need to know what the configure flag does - my guess is that it just sets -std=c++11 which is fine. If it also sets the define to select the new ABI then that might be a problem. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: C++11 enabling in F22?
On 26/10/15 12:50, Tim Niemueller wrote: - the driver works only with software which is built for the same ABI, it is one of the cases where things break immediately otherwise You need to be very clear what you mean here. Do you mean built with -std=c++11 or built with -D_GLIBCXX_USE_CXX11_ABI=1? The latter is, as I understand it, unacceptable in Fedora. In any event it's unlikely to even build and link because all the other libraries are not built with that so if it tries to link to any C++ libraries other than libstdc++ then the link will likely fail. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: C++11 enabling in F22?
On 26/10/15 13:01, Tim Niemueller wrote: On 26.10.2015 13:59, Tom Hughes wrote: On 26/10/15 12:50, Tim Niemueller wrote: - the driver works only with software which is built for the same ABI, it is one of the cases where things break immediately otherwise You need to be very clear what you mean here. Do you mean built with -std=c++11 or built with -D_GLIBCXX_USE_CXX11_ABI=1? I mean the former, -std=c++11. Right, so you should stop talking about ABI then, because setting that doesn't change the ABI. That's kind of the whole point. All it does is enable C++11 language features. Now that might cause the ABI of the package you are building to change if it has ifdefs to add extra functions in that case or something but it's not what gcc refers to as the "C++11 ABI". Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BuildRequires: pythonN-devel unnecessary
On 28/10/15 19:12, Mike Bonnet wrote: https://fedoraproject.org/wiki/Packaging:Python#BuildRequires This is *not* required for pure Python packages, only for packages compiling native extensions: Are you sure? Don't you need them for the RPM macros they contain? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: System V to systemd unit migration
On 28/10/15 19:47, Adam Jackson wrote: As a quick audit (based on 'grep _initrddir' and 'grep _initddir' over a fairly recent checkout of the spec files in pkg git, and then some manual inspection) I think the following packages will be affected: ...and initscripts for network and netconsole ;-) Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: BuildRequires: pythonN-devel unnecessary
On 29/10/15 11:34, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 29 October 2015 at 01:31, Christopher Meng wrote: Not my first time hitting on missing macros just because lack of pythonN-devel, but if you just extract them from pythonN-devel to package similar to these packages below, I reckon that it should be acceptable: --- ghc-srpm-macros gnat-srpm-macros go-srpm-macros ocaml-srpm-macros perl-srpm-macros --- How about naming them: rpm-build-ghc rpm-build-gnat rpm-build-go rpm-build-ocaml rpm-build-perl rpm-build-python and so on? Also, add Supplements: rpm-build to each of them. Just to add extra confusion there is nodejs-packaging as well which is the equivalent package for nodejs... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
On 06/11/15 14:18, Germano Massullo wrote: I just removed 32bit CPU support from Darktable's spec file due technical reasons. Are there any other things I need to clean up in Fedora infrastructure? Well you should start by reading the relevant guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Koji read-only filesystem error?
I just had a build fail: http://koji.fedoraproject.org/koji/taskinfo?taskID=11770578 It seems that a filesystem has gone read-only: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1161, in runTask response = (handler.run(),) File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 156, in run self.createWorkdir() File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 182, in createWorkdir os.makedirs(self.workdir) File "/usr/lib/python2.7/os.py", line 150, in makedirs makedirs(head, mode) File "/usr/lib/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 30] Read-only file system: '/var/tmp/koji/tasks/578' Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: wayland in rawhide
On 12/11/15 00:58, David Airlie wrote: Close all remaining feature parity gaps between the Wayland and the X11 session: input methods on-screen keyboard hi-dpi support clipboard proxy for xwayland attached modal dialogs tablet support startup notification touch proxy for xwayland accessibility features output rotation These are just the missing features (never mind dialog boxes in wierd places bugs) and it doesn't even contain the USB output hotplugging, or secondary GPU output use cases. You forgot primary selection/middle click paste, which was what made me go back to X when I tried it in F23. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: wayland in rawhide
On 12/11/15 10:51, Jared K. Smith wrote: On Thu, Nov 12, 2015 at 2:10 AM, Tom Hughes mailto:t...@compton.nu>> wrote: You forgot primary selection/middle click paste, which was what made me go back to X when I tried it in F23. I've been testing Wayland myself since around the F22 time period, but "middle click paste" and the occasional odd bug keep annoying me enough to go back to X. Can you elaborate on the plans for supporting middle click to paste, or is it considered a relic of a bygone era and I should try to unlearn? I'm generally in favor of pushing the envelope a bit when it comes to new features, but I have to admit that defaulting to Wayland at this point seems a bit premature to me, even for rawhide. All I know is what I found by googling: https://bugzilla.redhat.com/show_bug.cgi?id=1214655 https://ask.fedoraproject.org/en/question/75924/fedora-23-wayland-gnome-terminal-mouse-middle-click-paste/ Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: wayland in rawhide
On 12/11/15 14:10, Chuck Anderson wrote: On Thu, Nov 12, 2015 at 10:59:02AM +, Tom Hughes wrote: On 12/11/15 10:51, Jared K. Smith wrote: On Thu, Nov 12, 2015 at 2:10 AM, Tom Hughes mailto:t...@compton.nu>> wrote: You forgot primary selection/middle click paste, which was what made me go back to X when I tried it in F23. I've been testing Wayland myself since around the F22 time period, but "middle click paste" and the occasional odd bug keep annoying me enough to go back to X. Can you elaborate on the plans for supporting middle click to paste, or is it considered a relic of a bygone era and I should try to unlearn? I'm generally in favor of pushing the envelope a bit when it comes to new features, but I have to admit that defaulting to Wayland at this point seems a bit premature to me, even for rawhide. All I know is what I found by googling: https://bugzilla.redhat.com/show_bug.cgi?id=1214655 https://ask.fedoraproject.org/en/question/75924/fedora-23-wayland-gnome-terminal-mouse-middle-click-paste/ My brain hurts after reading that. Since Wayland decided there should be Only One clipboard buffer (which is probably a good idea), would it be too hard to just make Menu Copy/Paste do the same thing as Keyboard Copy/Paste (Ctrl-C/Ctrl-V) do the same thing as Select/Middle-Click Copy/Paste, all with the same single clipboard buffer, on/between both Xwayland apps and native Wayland apps? I think the bug explains fairly well why that is a bad idea. It's not so much on the paste side, where having middle click paste whatever was in the clipboard side would not be a major problem. It's more that you probably wouldn't want your clipboard buffer overwritten whenever you selected some text. Currently X has two (well three, but let's ignore the secondary selection) buffers. One for primary selection that is overwritten when you select and pasted with middle click and one for the clipboard selection that is overwritten on Ctrl+C and pasted on Ctrl+V. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: On running gui applications as root
On 17/11/15 18:11, Andrew Haley wrote: On 11/17/2015 05:55 PM, Joonas Sarajärvi wrote: My impression is that by default in fedora, virt-manager runs as non-root. I guess it might ask for the root password in order to manage the libvirtd that runs as privileged mode, but even in that case the user interface would run as your normal user. Sure, but even that is a UI regression: applications which ask for the root password discourage long root passwords and train people to type the root password whenever it's asked for. I should not even need to know the root password. Well you'll be pleased to know then that virt-manager doesn't normally ask for the root password. If you're in the libvirt group then I don't think it will ask at all, otherwise if you're an administrative user then it will ask for your password. If you weren't an admin user then it might ask for the root password but I don't think I've ever tried that. It does whatever polkit does for auth_admin basically. Certainly there is no good reason to run virt-manager as root. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Some analysis on the size of the minimal and Server installs of Fedora 23
On 19/11/15 09:11, Reindl Harald wrote: Am 19.11.2015 um 01:46 schrieb Zbigniew Jędrzejewski-Szmek: 2. What about non-glibc stuff? /usr/share/locale/ is 800MB on my system. It would be nice to trim this down too. Afaics, #156477 or the glibc subpackaging proposal will not help here at all 800 MB? on my desktop it's 459 MB on servers between between 89 MB and 124 MB interesting where these differences are from and yes it's large because it's around 10% of the whole rootfs Well it entirely depends on what packages are installed. On my desktop it's 894Mb, on a stripped down firewall box it's only 107Mb. It's not just glibc - anything that installs translations will be putting stuff in /usr/share/locale/*/LC_MESSAGES. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F24 System Wide Change: Fedora 24 Boost 1.60 uplift
On 27/11/15 08:32, Jan Kurik wrote: I am re-sending this Change announcement to the devel@ list, as due to the migration of mailinglists the original announcement [1] has reached only devel-announce@ mailing list and has never been forwarded to the devel@ list. That's not actually true. It arrived via devel just fine, as did your message the other day where you said the same thing. [1] https://lists.fedoraproject.org/archives/list/devel-announce%40lists.fedoraproject.org/thread/7I6QJPJLXO4X6J24NORV2OR44UE5VBVS/ Here's the devel version: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FYDALWQUDJEFO5SEPHU3FVEUFJOOPOP6/ Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Review swap request
On 28/11/15 17:12, Mattia Verga wrote: This is a quite simple review: kpmcore https://bugzilla.redhat.com/show_bug.cgi?id=1285042 I can take another package to swap reviews, but I'm not a sponsor. I've taken it, if you wouldn't mind looking at https://bugzilla.redhat.com/show_bug.cgi?id=1231460 for me in return. Thanks, Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Koji build fails, scratch-build works
On 29/11/15 18:18, Michael Schwendt wrote: On Sun, 29 Nov 2015 19:10:25 +0100, Mattia Verga wrote: Solved by changing .spec file name as set in PackageDB. The developer himself uses both kpmcore and KPMcore in the project, so I think there's no problem in adopting KPMcore as name in Fedora. Sorry for the noise. Both https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_File_Naming and https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming apply. And it can be quite tiresome, if such issues come up during review. Yes, as the reviewer in this case I would definitely have objected to a mixed case name on the basis of the guidelines. Of course the spec file I was reviewing wasn't mixed case and I didn't notice that the bug title was different. It always used to be the case that the request for a package to be added to pkgdb was rejected if the title didn't match, so has a bug been introduced there by the new pkgdb process? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Node.js 4.2
On 02/12/15 08:27, Vít Ondruch wrote: > Is there some testing version of v8 somewhere? Will we have time to play > with rubygem-therubyracer, if we can convince it to run with recent v8 > or what else have to be done? The same applies for MongoDB if I am not > mistaken. Stephen Gallagher built nodejs 4.2.2 in the side tag last night, but using a bundled v8 so it shouldn't affect other users of v8. The spec file now says: # Node.js is closely tied to the version of v8 that is used with it. It makes # sense to use the bundled version because upstream consistently breaks ABI # even in point releases. Node.js upstream has now removed the ability to build # against a shared system version entirely. # See https://github.com/nodejs/node/commit/d726a177ed59c37cf5306983ed00ecd858cfbbef Provides: bundled(v8) = 4.6.85 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: fedora notifications
On 08/12/15 12:05, Nikos Mavrogiannopoulos wrote: I'm quite lost with the fedora notifications [0] for email. Do you know which is the option to send me an email once a package is ready to be pushed to stable? (i.e., when the waiting period has passed or the feedback reached the threshold). I don't think there is one. That functionality went missing during the bodhi 2 upgrade and I don't think it has returned yet. I believe the direct mailing was removed on the assumption notifications would do but that it can't yet for some reason. I thought there was a bodhi ticket about it but I can't find it... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Direct messages
On 09/12/15 09:34, Dmitrij S. Kryzhevich wrote: If your username is krege you got at least three e-mail on 2015-11-26, -15 and -10 to krege fedoraproject org, therefore I suggest that you check your Spam folder/e-mail configuration. And I found those letters. Sorry, it was... very nontrivial. Heades (@ sign was manually edited): From: opensource-at-till.name To: devel-at-lists.fedoraproject.org // ! (my note) ... Delivered-To: krege-at-fedoraproject.org // and here we are Sure it was auto-moved into devel@ folder. Is it OK to use such a "To" field? Well it's a report to the list, bcced to you as an affected person presumably. If you want to filter list mails then List-Id is a much better thing to filter on than the To header. That way a direct copy to you won't trigger the filter. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
mapnik soname bump in rawhide
An update of mapnik has just completed building in rawhide so the soname has changed to libmapnik.so.3.0 and dependencies will need to be rebuilt. It think all of the dependencies are mine anyway, so I shall be working on rebuilding them now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Linker issue when moving from RHEL 6 to Fedora/RHEL7
On 16/12/15 19:48, Dave Johansen wrote: On Wed, Dec 16, 2015 at 12:32 PM, Richard Shaw mailto:hobbes1...@gmail.com>> wrote: On Wed, Dec 16, 2015 at 1:15 PM, Dave Johansen mailto:davejohan...@gmail.com>> wrote: I'm running into a linker issue when moving code that builds on RHEL 6 to Fedora or RHEL 7. Here's a simple reproducer: Download simple.c from https://github.com/markkilgard/glut/blob/master/progs/examples/simple.c and then run: g++ simple.c -lglut -o simple My SWG would be that for some reason on EL 6 you're getting the symbols for free perhaps due to the transitive nature of linking dynamic libraries? Since all you need to add is "-lGL" and it won't hurt anything on EL 6, seems like a pretty straight forward fix. Yes, in this simple example the fix is easy, but in our actual code it would mean changing the build command for hundreds of programs and several of them depend on multiple libraries which depend on multiple libraries, so it would be pretty time consuming. Plus, that's not even to mention the complexity and confusion that will be added when everyone wonders why a program is linking against a library it doesn't use. It is using it, or you wouldn't get that error. The reference is in the .o file that the compiler has generated in /tmp for your input, not in a library you are linking to. The cause of the change in behaviour will be this: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: nodejs/npm coupling
On 21/12/15 01:36, Dennis Jacobfeuerborn wrote: I'm currently looking into using npm v3 with nodejs v4. The problem I've run into is that npm is apparently part of the main nodejs package which effectively joins them at the hip for no apparent good reason. Upstream ships npm with nodejs because they need npm to bootstrap the environment and cannot rely on a higher level dependency mechanism because there is none. As a result they encourage to simply install a new npm by replacing the old one. In an rpm based environment however this does not work because the files are owned by the rpm and any reinstall or update will overwrite these files again with the ones from the rpm. On the other hand rpm has its own dependency resolution so the bootstrapping issue doesn't exists. As a result I would like to see npm separated from nodejs so that alternative versions can be installed in the same way that some packages require a mail transfer agent but not a specific one. For nodejs this would mean that by default the npm version that is now bundled gets pulled in by default but that the user has the option to specify an explicit package (like npm v3) that can satisfy the npm dependency. I'm not really sure what exactly it is you're asking here... Who exactly is it that you want to "separate" npm from nodejs? Fedora already ignores the npm that is bundled with nodejs and instead packages it by packaging all the modules that make up npm directly from their own sources, with a seprate srpm for each module. As far as nodejs 4 / npm 3 goes we (the Node.js SIG referred to in Peter's answer) are already working on it - we have nodejs 4.2.3 built in a side tag and are working on the npm stack currently. Current working status of the npm dependency stack update is at: https://fedoraproject.org/wiki/Node.js/npm_update_status But as Peter said, the nodejs list is probably the best place to ask any questions. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Poll: emacs.desktop or emacsclient.desktop?
On 05/01/16 10:23, Jan Synacek wrote: For me, it's emacs.desktop, since clicking the desktop icon is then simply consitent with the rest of the icons. The emacsclient behavior is just weird. Agreed, emacs.desktop is the application. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PostgreSQL 9.5 in rawhide
On 07/01/16 15:40, Pavel Kajaba wrote: we are going to change version of PostgreSQL from 9.4 to 9.5. You should consider rebuilding these packages: postgis is missing from those lists but also needs rebuilding if the failures I'm seeing in koschei are anything to go by: server started + createdb -h /builddir/build/BUILD/mapnik-v3.0.9 template_postgis + psql -h /builddir/build/BUILD/mapnik-v3.0.9 -c 'CREATE EXTENSION postgis' template_postgis ERROR: incompatible library "/usr/lib64/pgsql/postgis-2.1.so": version mismatch DETAIL: Server is version 9.5, library is version 9.4. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Updating summary and description of a package on pkgdb and the spec
On 08/01/16 13:41, Ankur Sinha wrote: On Fri, 2016-01-08 at 13:36 +, Ankur Sinha wrote: Hiya! Can the summary and description of a package be changed on pkgdb? Also, if it can't, is it OK if the summary and description on pkgdb differ from the spec? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1296914 Got my answer from puiterwijk over IRC: Pkgdb picks up the summary and description from the spec itself, so one just needs to update the spec and it should reflect in pgkdb after the next push. So the whole business of faffing around extracting the description to paste into the new package form is a bit pointless then, because it will just get overwritten when the initial spec is pushed? Does that apply to the upstream URL as well? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Boost 1.60?
Are we expecting boost 1.60 to land in Rawhide today? I see 1.60.0-1 built in the f24-boost side tag yesterday and then 1.60.0-2 this morning in the main f24 tag? Obviously that has triggered a bunch of dependency failures in koschei. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Boost 1.60?
On 14/01/16 13:27, Jonathan Wakely wrote: On 14/01/16 13:23 +, Jonathan Wakely wrote: On 14/01/16 12:40 +, Tom Hughes wrote: Are we expecting boost 1.60 to land in Rawhide today? I see 1.60.0-1 built in the f24-boost side tag yesterday and then 1.60.0-2 this morning in the main f24 tag? Obviously that has triggered a bunch of dependency failures in koschei. Argh! Sorry, I started the rebuilds in the side tag but didn't use --target for the 1.60.0-2 build. I'll get it re-tagged. Sorry about that! koji gave me a "TypeError: 'int' object is not iterable" exception but the build seems to have bee re-tagged as f24-boost now. Welcome to the BZ#1186994 club, you're just in time for it's first anniversary celebration. I'm sure a fix will be along any year now. Did any other builds get done against the new boost, that should also be re-tagged? I didn't do any, but I don't know about anybody else. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Debugging practices and hardened packages
On 19/01/16 10:55, Jonathan Wakely wrote: Is there a way to tell it to ignore certain core files? I run parts of the GCC testsuite several times a day, and many of the tests are expected to call abort() to terminate. I don't want hundreds of them clogging up my journal, or being stored in ABRT. If you set RLIMIT_CORE to one byte (yes one, not zero) then the kernel won't send the core to the configured pipe at all. It's a bit of a hack really - it relies on the fact that when the kernel starts a process to pipe a core dump to it it deliberately sets the limit to one to avoid recursion if that process crashes. The main problem is that ulimit and most shells builtin limit commands take the core dump size limit in kB or other similar larger units but you can do it with setrlimit using a wrapper program I actually patch zsh to add a limitcore command that takes bytes as an argument so that I can block coredumps in my development windows as otherwise something like an asan abort tries to write a multi gigabyte coredump to abrt which doesn't end well, or rather doesn't end for a very long time... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
