Re: On packager motivation
On Wed, 2016-02-03 at 18:44 -0700, Kevin Fenzi wrote: > On Thu, 04 Feb 2016 09:09:33 +0800 > Ian Kent wrote: > > > I agree. > > > > I believe that package ownership has at least a couple of clear > > advantages for obvious reasons and I find it hard to understand how > > people can discount their usefulness. > > > > 1) A point of contact and co-ordination for changes is needed. > > > > Often, when dealing with difficult problems it's necessary to seek > > advice from maintainers of other packages. Being able to find out who > > that is and having at least some chance they will be familiar with > > upstream package status is important. > > > > 2) Taking (even notional) ownership of a package implies there is at > > least some interest in the package from an upstream POV. > > > > Some (probably many) packages need a packager to take an interest in > > what is happening upstream. Building relationships with upstream > > maintainers doesn't always work too well but even that is an > > important part of knowing what the upstream status of a package is. > > > > This is essential to be able to provide 1) above, someone who has some > > understanding of the upstream status really is needed to at least > > help keep our packages as stable as we can. > > > > It's true that package owners don't always have enough upstream > > knowledge of packages they own or relationships with upstream but > > that doesn't mean that ownership is a bad thing. After all a point of > > contact is still needed IMHO. > > I agree with what you are saying, but disagree that anything above > requires you to "own" packages and guard them from anyone else. > > You can still be a point of contact and/or interested upstream and want > to help keep the packages in Fedora high quality and working, but still > be willing to work as part of the entire collection of maintainers not > isolated or defensive. We all want to improve things, even if we make > mistakes doing so. Sure, anyone that argues against this is not playing well with others. But I do feel like my use of "owner" has been misunderstood. I certainly don't mind if changes are made to packages I look after, it happens and is mostly not a problem. So I think the problem being discussed won't be resolved by changing to a model of not having a package "owner" (however that's defined), it's not process or policy, it's behavioural based. That's probably not going to change no matter what efforts are made to change processes and policy. So I don't really know what to say to improve matters, sorry. Ian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 3 Feb 2016 08:44:32 -0700 Jerry James wrote: > Several people have said something similar lately, and it worries me. > I understand that we're trying to combat the hostility some packagers > show when somebody does something to "their" packages, but I'm > concerned that we may have swung the pendulum too far the other way. > I foresee two problems: > > 1. Demotivating packagers > > I know a number of companies have experimented with "ownership-free" > models of code development, but they are able to offer incentives that > Fedora cannot offer, such as money and kudos offered in front of > coworkers. What motivates volunteer packagers to do what they do? > I'd like to hear from a few packagers on this topic. > > What motivates me is pride in my work, and recognition of that good > work by others. If I'm just one packager in a big cloud of packagers, > and none of us is really responsible for anything ... well, that's > quite demotivating. But thats not how I look at it least. Instead of being one package who says "My packages are great", you can say "My packages are great, and other people help me when they can, and I help them out and our community is great". It's not that no one is responsible for anything, it's that everyone is responsible for everything. If you see some way you can help, you do, and you don't stop with "oh, thats not my package, I'll let the owner deal with it" > I am the primary point of contact for a few dozen packages where I > have done all of the packaging work, all of the reporting of bugs > upstream, all of the arguing with upstream to do something about > sticky license situations, all of the handling of bug reports. I'm > sure the same is true for many other packagers. People feel ownership > of what they work on. This is human nature. I fear that by denying > human nature with this "those aren't your packages" mantra, we will > suck the joy out of packaging work and see packagers less willing to > do that work. I don't think anyone wants to take that away. Instead we just want to avoid the "These packages are mine mine mine, and no one can touch them" when in fact you are just stewarding them for Fedora. > > 2. Motivating responsibility-free drive-by modifications > > If nobody owns any packages, then who is responsible for fixing > package problems? I think the reason some packagers react with > hostility to others changing "their" packages is that we have a > handful of provenpackagers who make incorrect changes to packages and > then walk away, without sticking around to fix the problems they > caused with their incorrect changes. I've got two recent examples of > this. I won't use any names, because my purpose is not to point > fingers. It's not that nobody owns any packages, it's that we all do. snip cases of bad provenpackager behavior > If I send these two provenpackagers a somewhat hostile email, are you > going to blame me? I have no problem with most provenpackager > changes. In general, they have an obvious purpose and save me the > work of making the same change myself. But changes like the ones > above make more work for me, work that could have been avoided if the > provenpackager in question had just bothered to make some attempt, any > attempt, to contact me first. Well, yes, because I don't think hostile email is ever a good idea. :) But did you manage to talk to either of these provenpackagers and hear back from them? > > I think we need to ask ourselves, as a project, what behaviors we want > to motivate and what behaviors we want to demotivate in our packagers. > I think we need to take human nature, flawed as it is, into account > when doing so. I fear that this "nobody owns any packages" mantra is > not providing the motivations and demotivations that we really want. Perhaps we can explain it better by saying "everyone owns all packages" ? kevin pgpF9bD2YxixI.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160203 compose check report
Missing expected images: Kde disk raw armhfp Cloud disk raw i386 Cloud disk raw x86_64 Cloud_atomic disk raw x86_64 Images in this compose but not Rawhide 20160202: Design_suite live x86_64 Generic boot x86_64 Lxde live i386 Soas disk raw armhfp Xfce disk raw armhfp Security live i386 Scientific_kde live x86_64 Lxde live x86_64 Design_suite live i386 Games live x86_64 Workstation live i386 Games live i386 Workstation disk raw armhfp Generic boot i386 Xfce live x86_64 Minimal disk raw armhfp Cinnamon live i386 Security live x86_64 Soas live i386 Cinnamon live x86_64 Kde live x86_64 Mate live x86_64 Workstation live x86_64 Soas live x86_64 Kde live i386 Mate live i386 Mate disk raw armhfp Scientific_kde live i386 Server disk raw armhfp Xfce live i386 No images in Rawhide 20160202 but not this. Failed openQA tests: 14 of 69 ID: 4818Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/4818 ID: 4817Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/4817 ID: 4797Test: i386 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/4797 ID: 4791Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/4791 ID: 4785Test: i386 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/4785 ID: 4779Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/4779 ID: 4776Test: i386 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/4776 ID: 4775Test: i386 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/4775 ID: 4774Test: i386 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/4774 ID: 4773Test: i386 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/4773 ID: 4772Test: i386 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/4772 ID: 4771Test: i386 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/4771 ID: 4770Test: i386 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/4770 ID: 4769Test: i386 universal package_set_minimal URL: https://openqa.fedoraproject.org/tests/4769 Passed openQA tests: 52 of 69 3 openQA tests may be still running or broken! -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Thu, 04 Feb 2016 09:09:33 +0800 Ian Kent wrote: > I agree. > > I believe that package ownership has at least a couple of clear > advantages for obvious reasons and I find it hard to understand how > people can discount their usefulness. > > 1) A point of contact and co-ordination for changes is needed. > > Often, when dealing with difficult problems it's necessary to seek > advice from maintainers of other packages. Being able to find out who > that is and having at least some chance they will be familiar with > upstream package status is important. > > 2) Taking (even notional) ownership of a package implies there is at > least some interest in the package from an upstream POV. > > Some (probably many) packages need a packager to take an interest in > what is happening upstream. Building relationships with upstream > maintainers doesn't always work too well but even that is an > important part of knowing what the upstream status of a package is. > > This is essential to be able to provide 1) above, someone who has some > understanding of the upstream status really is needed to at least > help keep our packages as stable as we can. > > It's true that package owners don't always have enough upstream > knowledge of packages they own or relationships with upstream but > that doesn't mean that ownership is a bad thing. After all a point of > contact is still needed IMHO. I agree with what you are saying, but disagree that anything above requires you to "own" packages and guard them from anyone else. You can still be a point of contact and/or interested upstream and want to help keep the packages in Fedora high quality and working, but still be willing to work as part of the entire collection of maintainers not isolated or defensive. We all want to improve things, even if we make mistakes doing so. > > I fail to see how allowing ad-hoc changes to packages, which will > often not even involve letting others interested in the package know > what has happened, will lead to improvement overall. * The change is something cosmetic over vast piles of packages (like the recent note that %defattr is useless) Sure you can clean that up yourself, but if we have an automated way of fixing it, why not let the automation do so? * The issues might be things on some other arch that you don't have access to or care about, so someone interested in making Fedora better on that arch might add a patch or the like. * Some fix or workaround might be needed urgently and you may be unavailable. When you get back you can work on the real fix or whatever, and the things blocked went on in your absense. * Some package your package(s) depend on may have changed and that maintainer wants to rebuild your package against their new one so everything keeps working. However IMHO for all these cases there should be mention on list, directly to maintainers, bugzilla, or be completely obvious. ...snip... kevin pgp0NnSPLIKVy.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide 20160203 compose check report
Missing expected images: Kde disk raw armhfp Cloud disk raw i386 Cloud disk raw x86_64 Cloud_atomic disk raw x86_64 Images in this compose but not Rawhide 20160202: Design_suite live x86_64 Generic boot x86_64 Lxde live i386 Soas disk raw armhfp Xfce disk raw armhfp Security live i386 Scientific_kde live x86_64 Lxde live x86_64 Design_suite live i386 Games live x86_64 Workstation live i386 Games live i386 Workstation disk raw armhfp Generic boot i386 Xfce live x86_64 Minimal disk raw armhfp Cinnamon live i386 Security live x86_64 Soas live i386 Cinnamon live x86_64 Kde live x86_64 Mate live x86_64 Workstation live x86_64 Soas live x86_64 Kde live i386 Mate live i386 Mate disk raw armhfp Scientific_kde live i386 Server disk raw armhfp Xfce live i386 No images in Rawhide 20160202 but not this. Failed openQA tests: 31 of 92 ID: 4757Test: x86_64 universal server_multi URL: https://openqa.fedoraproject.org/tests/4757 ID: 4756Test: x86_64 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/4756 ID: 4754Test: x86_64 universal server_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/4754 ID: 4753Test: x86_64 universal server_delete_pata URL: https://openqa.fedoraproject.org/tests/4753 ID: 4752Test: x86_64 universal server_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/4752 ID: 4750Test: x86_64 universal server_repository_http_variation URL: https://openqa.fedoraproject.org/tests/4750 ID: 4751Test: x86_64 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/4751 ID: 4791Test: i386 kde_live default_install URL: https://openqa.fedoraproject.org/tests/4791 ID: 4785Test: i386 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/4785 ID: 4781Test: x86_64 generic_boot default_install@uefi URL: https://openqa.fedoraproject.org/tests/4781 ID: 4780Test: x86_64 generic_boot default_install URL: https://openqa.fedoraproject.org/tests/4780 ID: 4787Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/4787 ID: 4792Test: x86_64 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/4792 ID: 4758Test: x86_64 universal server_multi@uefi URL: https://openqa.fedoraproject.org/tests/4758 ID: 4797Test: i386 workstation_live default_install URL: https://openqa.fedoraproject.org/tests/4797 ID: 4771Test: i386 universal server_scsi_updates_img URL: https://openqa.fedoraproject.org/tests/4771 ID: 4770Test: i386 universal server_repository_http_graphical URL: https://openqa.fedoraproject.org/tests/4770 ID: 4793Test: x86_64 workstation_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/4793 ID: 4817Test: x86_64 kde_live default_install URL: https://openqa.fedoraproject.org/tests/4817 ID: 4818Test: x86_64 kde_live default_install@uefi URL: https://openqa.fedoraproject.org/tests/4818 ID: 4759Test: x86_64 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/4759 ID: 4769Test: i386 universal package_set_minimal URL: https://openqa.fedoraproject.org/tests/4769 ID: 4772Test: i386 universal server_simple_encrypted URL: https://openqa.fedoraproject.org/tests/4772 ID: 4773Test: i386 universal server_software_raid URL: https://openqa.fedoraproject.org/tests/4773 ID: 4748Test: x86_64 universal european_language_install URL: https://openqa.fedoraproject.org/tests/4748 ID: 4823Test: x86_64 universal european_language_install URL: https://openqa.fedoraproject.org/tests/4823 ID: 4774Test: i386 universal server_btrfs URL: https://openqa.fedoraproject.org/tests/4774 ID: 4775Test: i386 universal server_ext3 URL: https://openqa.fedoraproject.org/tests/4775 ID: 4729Test: x86_64 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/4729 ID: 4776Test: i386 universal server_lvmthin URL: https://openqa.fedoraproject.org/tests/4776 ID: 4779Test: i386 universal package_set_kde URL: https://openqa.fedoraproject.org/tests/4779 Passed openQA tests: 52 of 92 9 openQA tests may be still running or broken! -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 2016-02-03 at 16:04 +, Jonathan Wakely wrote: > > If I send these two provenpackagers a somewhat hostile email, are you > > going to blame me? I have no problem with most provenpackager > > changes. In general, they have an obvious purpose and save me the > > work of making the same change myself. But changes like the ones > > above make more work for me, work that could have been avoided if the > > provenpackager in question had just bothered to make some attempt, any > > attempt, to contact me first. > > I don't think that's always realistic to expect. > > When a provenpackager is rebuilding *hundreds* of packages at once, > and trying to deal with maybe dozens of build failures, sending emails > to all the package owners and waiting to see if they respond promptly > is not an efficient way to get things fixed. Waiting for a reply adds > a lot of latency, and then you have to context-switch back to a > package you were dealing with a day or two ago. That's impractical > when you have a patch ready to go now and loads more packages to look > at. > > Sometimes a provenpackager will make a bad change, and that's > unfortunate, but it happens. Sometimes package owners make bad changes > too! :-) > > If I make a bad change to a package please do let me know. If I appear > to change things and walk away it's probably because I've moved on to > look at other packages that also need attention, not just a careless > hit & run. I would expect it's similar for others. Sorry but this sounds more like a process definition problem than anything. In fact, problems like this sound like they would be better dealt with by alerting the package maintainer and passing the ball to them. If the problem isn't dealt with quickly enough then perhaps that package should not be re -built at this time. There should be some responsibilities for package maintainers. And, surely, in this case the provenpackager has too much to do to pay suitable attention to changes needed and really does need to move on. Yes, there would be some need to define process around this so the ball could come back to a provenpackager on a second pass, hopefully when they have a little more time to attend to the problem, if there was no response from the maintainer. This reminds me of the saying "more haste less speed"! Ian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote: > > I think we need to ask ourselves, as a project, what behaviors we want > to motivate and what behaviors we want to demotivate in our packagers. > I think we need to take human nature, flawed as it is, into account > when doing so. I fear that this "nobody owns any packages" mantra is > not providing the motivations and demotivations that we really want. I agree. I believe that package ownership has at least a couple of clear advantages for obvious reasons and I find it hard to understand how people can discount their usefulness. 1) A point of contact and co-ordination for changes is needed. Often, when dealing with difficult problems it's necessary to seek advice from maintainers of other packages. Being able to find out who that is and having at least some chance they will be familiar with upstream package status is important. 2) Taking (even notional) ownership of a package implies there is at least some interest in the package from an upstream POV. Some (probably many) packages need a packager to take an interest in what is happening upstream. Building relationships with upstream maintainers doesn't always work too well but even that is an important part of knowing what the upstream status of a package is. This is essential to be able to provide 1) above, someone who has some understanding of the upstream status really is needed to at least help keep our packages as stable as we can. It's true that package owners don't always have enough upstream knowledge of packages they own or relationships with upstream but that doesn't mean that ownership is a bad thing. After all a point of contact is still needed IMHO. I fail to see how allowing ad-hoc changes to packages, which will often not even involve letting others interested in the package know what has happened, will lead to improvement overall. If the goal is to reduce the barrier for others to contribute then that doesn't necessarily mean doing away with package owners. It means defining processes to allow this while keeping the owner (the one that probably has some idea of the upstream package status) in the loop. Whether that also means power of veto over changes is slightly different but somehow I think that must be the case to maximize package stability. It might be obvious that my view is influenced a lot because I'm also an upstream package maintainer. Clearly I strongly believe in the need for downstream packagers to be in touch with what's happening upstream. And, yes, it can be hard to take the "no" or "I don't like that change" or an "I'm not going to do that" but that is all part of working with upstream and knowing a package, the bit downstream packagers seem to miss all too often IMHO. Don't forget, the relationship (that is needed) is just as hard for upstream as it is for downstream, that's just life. Ian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
Kevin Fenzi wrote: > Why would it be a pointless edit? Surely you are editing it to update > to the new version, why wouldn't you also just edit it to adjust the > so files? or do you not test your version upgrade specs before firing > off official builds? Of course not. The rule of thumb is "Rawhide first", so of course I first build in Rawhide, then I build updates for releases (i.e. for what I actually run), and then I test those before they go out to stable. > There's a difference IMHO between a known bug (which is actively being > worked by upstream) that prevents you from compiling and a known bug > that prevents already existing things from working. Sure there is: The FTBFS prevents actual Rawhide work (development) from being done, the runtime broken dependency does not (or if it does make your build fail, you just rebuild the offending package and move on, whereas the GCC bug has been breaking my builds for days now). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On Qua, 2016-02-03 at 15:10 -0800, Samuel Sieb wrote: > On 02/03/2016 02:28 PM, Felix Miata wrote: > > Problem #3: > > When running from say the /boot directory the same dnf command > > above: > > > > # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > > > dnf reports cannot install package inityada, cannot install package > > vmliyada, > > It ought to be smart enough not to try to install local files > > that are > > not installation package files (e.g., those ending in .rpm or any > > other type > > it might understand and support). > > > This is not something dnf can do anything about. Bash handles the > globbing and passes the filenames to dnf. That's why you should > quote > them. Dnf doesn't know that you were using wildcards unless the > glob > doesn't match any filenames in which case bash will pass it > on. Once > "vmlinuz" is on the command line to dnf, it can't know that you > didn't > mean that to be a package name. conclusion you should use: # dnf update "kd*" "kf* "q*" "per* "pyt*" "u*" "v*" "x*" "y*" "z*" I got many errors like this or packages that are obsolete: Error: package z88dk-1.10.1-8.20150709cvs.fc23.x86_64 conflicts with z80asm provided by z80asm-1.8-8.fc23.x86_64 In those cases you may exclude the package with : # dnf update "kd*" "kf* "q*" "per* "pyt*" "u*" "v*" "x*" "y*" "z*" \ --exclude="z80asm*" --exclude=perl-gettext -exclude=qca2 etc. -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
Chris Murphy composed on 2016-02-03 15:54 (UTC-0700): > Felix Miata wrote: ... >> Does anyone here agree that each of the three would represent legitimate >> wishlist bugs, unlikely to be summarily dismissed as wontfix? > My expectation is that's a lot more work than for dnf to do a better > estimate and enforcement of free space before starting an upgrade in > the first place. Surely that would be most welcome. > And probably a stronger warning and/or enforcement > for sane root fs size to grow, at installation time. Sane for a normal user's installation differs from sane here. Recommended sizes are vastly different from what will serve the special purposes of testing specific subsets of a normal system. > I also think such a staged approach to updates increases the chances > of a wrecked installation if this sort of staged upgrade is > interrupted by a crash or power failure. It goes without saying. Nevertheless, working on UPSes with throwaways and easy to create/backup/restore little filesystems have their own advantages. I've been doing this for over a decade, experiencing many power failures here in the lightning capital of North America, subscribed to the least reliable power provider I'm aware of in any civilized country. I can't remember the last time an upgrade process on Mageia or openSUSE was ever destroyed by power failure, if it ever happended at all. I probably spend as much money on UPS batteries than I do on PC hardware. > It's even less atomic of an > update than what we have now, and is the opposite of the direction > Fedora wants to go in. > ...There is actually a very straightforward way to > get atomic updates now with Btrfs, and doing the update either in a BTRFS, nor any other filesystem type, is not something I care to include in my testing processes. > chroot or container (nspawn or docker) and a rw snapshot. The changes > happen completely out of tree, so not only is your running system not > yanked out from under it while you're working, but if it fails for any > reason the hosed fs trees can just be deleted and the update attempt > retried. If it works, update fstab and the bootloader configuration to > now boot the upgraded tree, leaving the old one intact in case the > reboot goes wrong or there's some regression. All mine are multiboot installations, so I have ample fallback and option, without any need for radical surgery on what ain't broke. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On Wed, Feb 3, 2016 at 6:10 PM, Samuel Sieb wrote: > On 02/03/2016 02:28 PM, Felix Miata wrote: > >> Problem #3: >> When running from say the /boot directory the same dnf command above: >> >> # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* >> >> dnf reports cannot install package inityada, cannot install package >> vmliyada, >> It ought to be smart enough not to try to install local files that >> are >> not installation package files (e.g., those ending in .rpm or any other >> type >> it might understand and support). >> >> This is not something dnf can do anything about. Bash handles the > globbing and passes the filenames to dnf. That's why you should quote > them. Dnf doesn't know that you were using wildcards unless the glob > doesn't match any filenames in which case bash will pass it on. Once > "vmlinuz" is on the command line to dnf, it can't know that you didn't mean > that to be a package name. More specifically, the command should be: # dnf update 'kd*' 'kf*' 'q*' 'per*' 'pyt*' 'u*' 'v*' 'x*' 'y*' 'z*' or you can backslash-escape each asterisk. On fish shell for example, commands like these will simply fail if you forget to escape wildcards that are not actually meant for the shell. > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
courier-unicode and maildrop update for rawhide
I'll be updating these in rawhide only. The big change is that courier-unicode has changed the library name to libcourier-unicode and includes a couple extra header files. As far as I can tell the only package that cares is maildrop, so this shouldn't be an issue. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 3 Feb 2016 23:26:23 + Ian Malone wrote: > If this is a requirement then it rules out a lot of potential > packagers who are not full time employed to work on OSS. I could not > sit at my desk and respond to IRCs about Fedora all day. As with so much in life, IMHO, it's not a black and white issue, it's somewhere in between. It's nice when you can find a maintainer on IRC and ask about something quickly, but if they aren't there then thats too bad and you can either just send them email or update the bug or update the package if it's particularly urgent. Communication is important. As a provenpackager if you are changing a bunch of packages for some issue, it's unlikely you can mail each maintainer/co-maintainer separately, but you should definitely keep the list updated and answer questions sent to you about it. kevin pgpYGM3JzoqA6.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Wed, 03 Feb 2016 23:27:30 +0100
Kevin Kofler wrote:
> Yaakov Selkowitz wrote:
> > This is the hazard of using %{_libdir}/*.so.* in %files. Is there
> > any reason why such a syntax should NOT be formally discouraged in
> > the packaging guidelines?
>
> There is: I do not want to have to pointlessly edit my specfile each
> time some soname changes, and waste a failed build (i.e., ultimately
> MY time). The other packages will need to be rebuilt ANYWAY. They may
> as well do so when the Rawhide broken dependencies report comes in.
> Rawhide is supposed to be a place for development, not something that
> always works for end users.
Why would it be a pointless edit? Surely you are editing it to update
to the new version, why wouldn't you also just edit it to adjust the
so files? or do you not test your version upgrade specs before firing
off official builds?
If you tell people about the soname bump or rebuild the affected
packages there's no need to break everything, you can be proactive
instead of reactive.
> By the way, all this talk about keeping Rawhide usable is all the
> more ridiculous given that we allow broken trunk snapshots of GCC
> into Rawhide which fail to compile packages due to known regressions
> such as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 (which is
> keeping me from building QtWebEngine and testing the improvements I
> am working on). THOSE are the changes that hinder development and
> thus Rawhide's actual purpose, not a broken dependency in one day's
> Rawhide compose.
There's a difference IMHO between a known bug (which is actively being
worked by upstream) that prevents you from compiling and a known bug
that prevents already existing things from working.
kevin
pgpjRAGhsQCHI.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On 3 February 2016 at 23:00, Kevin Kofler wrote: > > Really, it is not realistic to expect people who need to urgently fix > something to write up a polite e-mail and wait possibly days for you to > reply (especially if you then answer that you don't want the change and more > days are wasted going back and forth arguing for why the change is needed). > Either you are reachable quickly through real-time communication (which > effectively means IRC in the Free Software world) or you will just not be > asked. > > I always curse when I try to contact a packager and see either no IRC > contact info, or an IRC nick that is clearly not in active use (last seen > weeks ago). > If this is a requirement then it rules out a lot of potential packagers who are not full time employed to work on OSS. I could not sit at my desk and respond to IRCs about Fedora all day. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On Wed, Feb 3, 2016, at 05:54 PM, Chris Murphy wrote: > > > NAICT, DNF, like Yum before it, offers no option I can recognize from its > > man > > page to download less than all the to-be-updated/installed packages before > > proceeding to install any packages. Thus it downloads (typically hundreds of > > packages), cutting into available / freespace. Then it does transaction > > checking before package installation begins, ... > If you check out Project Atomic or rpm-ostree, the gist is that there > is no local package manager, instead you deploy trees. A whole new > updated tree (containing changes from the current tree) is downloaded > and installed in an atomic fashion, ie the file system tree that's > currently deployed is not touched, and therefore a failed upgrade > doesn't ever wreck it. I'm actually working on a hybrid mode for rpm-ostree which stores unpacked packages cached individually in ostree itself, which as a side effect also solves the "download lots of RPMs, then install" problem by importing them exploded as they're downloaded. This work is targeted at container roots, but will also be essential for a good "package layering" experience: https://github.com/projectatomic/rpm-ostree/pull/107 If anyone is interested in more, I'll be talking about the current work at my Devconf.cz talk: https://devconfcz2016.sched.org/event/32299ab85fa02e48a2fcf77826c5cc82 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Self Introduction: Fran Tsao
Hello /all, I've been using GNU/Linux since 1998. That year I joined to GPUL, the Coruña (North Spain) Linux Users Group. In these years I organised with my LUG a lot of free software hackmeetings, the greatest one, the GUADEC 2012. I was a Debian zealot more than 10 years, but because my current work I began to dive in deep in the RPM world three years ago. So now I am a convert ;-) and I decided to humbly collaborate with Fedora Project. I saw there is not a pam_usb package [0], so I made my first package with it, and I submitted a review bug[1]. Maybe I can co-maintain some packages too if anybody needs help. I'm specially interested in sysadmin/devops tools, and my favorite programming languages are Python, C/C++, AWK and (cough cough) Fortran ;-) Best regards, Fran Tsao [0] https://github.com/aluzzardi/pam_usb [1] https://bugzilla.redhat.com/show_bug.cgi?id=1304125 -- Francisco Javier Tsao Santín http://gattaca.es 1024D/71CF4D62 42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On 02/03/2016 02:28 PM, Felix Miata wrote: Problem #3: When running from say the /boot directory the same dnf command above: # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* dnf reports cannot install package inityada, cannot install package vmliyada, It ought to be smart enough not to try to install local files that are not installation package files (e.g., those ending in .rpm or any other type it might understand and support). This is not something dnf can do anything about. Bash handles the globbing and passes the filenames to dnf. That's why you should quote them. Dnf doesn't know that you were using wildcards unless the glob doesn't match any filenames in which case bash will pass it on. Once "vmlinuz" is on the command line to dnf, it can't know that you didn't mean that to be a package name. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with Rawhide build error with GCC 6.0
Jonathan Wakely wrote: > A workaround would be to make it too hard for the compiler to see the > problem: > > void* ptr = page->data; > _root = new (ptr) impl::xml_document_struct(page); > > This way GCC doesn't see that the address refers to a 1-byte array. Why not simply: char data[ #ifndef __GNUC__ 1 #endif ]; or: #ifdef __GNUC__ char data[]; #else char data[1]; #endif or if you want GCC to accept this even in strict standards-compliant modes: #ifdef __GNUC__ __extension__ char data[]; #else char data[1]; #endif ? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
Jerry James wrote: > a. Last fall, a provenpackager updated a package for which I am the > primary point of contact (as well as the original submitter). The > update was to an upstream alpha release. It was alpha for a reason. > The release is super buggy. I had not updated to it on purpose. A > provenpackager strolled by, updated to the buggy release, then > strolled away. Guess who has been getting the bug reports? Not the > person who did the update, the person who did not even bother > contacting the primary point of contact to see if updating was okay. Looking at: https://admin.fedoraproject.org/accounts/user/view/jjames https://fedoraproject.org/wiki/User:Jjames I see no IRC contact info at all. And you're surprised that people did not try to contact you? Really, it is not realistic to expect people who need to urgently fix something to write up a polite e-mail and wait possibly days for you to reply (especially if you then answer that you don't want the change and more days are wasted going back and forth arguing for why the change is needed). Either you are reachable quickly through real-time communication (which effectively means IRC in the Free Software world) or you will just not be asked. I always curse when I try to contact a packager and see either no IRC contact info, or an IRC nick that is clearly not in active use (last seen weeks ago). > b. Just last week, another provenpackager dropped two patches into a > package for which I am the primary point of contact (as well, again, > as the original submitter). One patch only has effect on non-Linux > systems, so adding it was pointless. I don't even have any idea what > the other patch does. It changes stuff, I can see that, but why? The > person who did this did not add any comments to the PatchN: lines in > the spec file, so I don't know if they have been submitted upstream, > are from upstream, or what. Here, again, the provenpackager made *no* > attempt at all to contact the primary point of contact. Patch comments are also overrated. Often, the patch name already clearly says what the patch does. (E.g., guess what kdelibs-3.5.10-CVE-2015-7543.patch is for. :-) That said, I always try to add at least 1 line of comments for patches, even in my own packages; the particular patch I cited here actually has a 4-line comment.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
On Wed, Feb 3, 2016 at 3:28 PM, Felix Miata wrote: > I have lots of test installations using identical partition sizes for EXT3 or > EXT4 / filesystems. the filesystem space these provided is adequate on all if > running Mageia or openSUSE, but quite often not for Fedora. Working around > the inadequacy on Fedora presents problems #2 & #3. > > Problem #1: > NAICT, DNF, like Yum before it, offers no option I can recognize from its man > page to download less than all the to-be-updated/installed packages before > proceeding to install any packages. Thus it downloads (typically hundreds of > packages), cutting into available / freespace. Then it does transaction > checking before package installation begins, and after which commonly it > halts, reporting some small amount of freespace is required on the / > filesystem, space that obviously wasn't required for the installation to be > operable. By intervening updating of packages in various bunches instead, > updating, though laborious, is successful, and freespace when done is > perfectly adequate, resulting in total freespace roughly equivalent to Mageia > and openSUSE. > > Problem #2: > A way to work around problem #1 is with wildcards, e.g. > > # dnf update g* i*, kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > When this example is used following observance of problem #1, DNF naturally > skips downloading packages already downloaded and meeting the cmdline spec, > and silently deletes all already downloaded packages not meeting the spec, so > that when e.g. the following is run > > # dnf a* b* c* d* e* f* h* > > the cache begins empty, and it downloads the packages deleted mere minutes > ago. > > Problem #3: > When running from say the /boot directory the same dnf command above: > > # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > dnf reports cannot install package inityada, cannot install package vmliyada, > It ought to be smart enough not to try to install local files that are > not installation package files (e.g., those ending in .rpm or any other type > it might understand and support). > > The reason Mageia doesn't have any of these problems is that it naturally and > by default downloads a small bunch, installs them, downloads another bunch, > installs those, etc. Similarly, openSUSE's zypper offers options to download > one, install one, download second, install second, download third, install > third, etc. (DownloadAsNeeded), and another option to do more or less as > Mageia's urpmi does (DownloadInHeaps), as alternatives to its default > (DownloadInAdvance). Updating Mageia and openSUSE typically takes 30-60 > minutes to update 600-800 packages without babysitting the cmdline, while > Fedora on these installations can take several hours between waiting on the > duplicate downloads and not looking at the screen at the right time to answer > y or input another group of packages using wildcards. > > Does anyone here agree that each of the three would represent legitimate > wishlist bugs, unlikely to be summarily dismissed as wontfix? My expectation is that's a lot more work than for dnf to do a better estimate and enforcement of free space before starting an upgrade in the first place. And probably a stronger warning and/or enforcement for sane root fs size to grow, at installation time. I also think such a staged approach to updates increases the chances of a wrecked installation if this sort of staged upgrade is interrupted by a crash or power failure. It's even less atomic of an update than what we have now, and is the opposite of the direction Fedora wants to go in. If you check out Project Atomic or rpm-ostree, the gist is that there is no local package manager, instead you deploy trees. A whole new updated tree (containing changes from the current tree) is downloaded and installed in an atomic fashion, ie the file system tree that's currently deployed is not touched, and therefore a failed upgrade doesn't ever wreck it. There is actually a very straightforward way to get atomic updates now with Btrfs, and doing the update either in a chroot or container (nspawn or docker) and a rw snapshot. The changes happen completely out of tree, so not only is your running system not yanked out from under it while you're working, but if it fails for any reason the hosed fs trees can just be deleted and the update attempt retried. If it works, update fstab and the bootloader configuration to now boot the upgraded tree, leaving the old one intact in case the reboot goes wrong or there's some regression. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: DNF pains
Do we have zypper in Fedora? Perhaps we should give that a try? On Feb 3, 2016 23:28, "Felix Miata" wrote: > I have lots of test installations using identical partition sizes for EXT3 > or > EXT4 / filesystems. the filesystem space these provided is adequate on all > if > running Mageia or openSUSE, but quite often not for Fedora. Working around > the inadequacy on Fedora presents problems #2 & #3. > > Problem #1: > NAICT, DNF, like Yum before it, offers no option I can recognize from its > man > page to download less than all the to-be-updated/installed packages before > proceeding to install any packages. Thus it downloads (typically hundreds > of > packages), cutting into available / freespace. Then it does transaction > checking before package installation begins, and after which commonly it > halts, reporting some small amount of freespace is required on the / > filesystem, space that obviously wasn't required for the installation to be > operable. By intervening updating of packages in various bunches instead, > updating, though laborious, is successful, and freespace when done is > perfectly adequate, resulting in total freespace roughly equivalent to > Mageia > and openSUSE. > > Problem #2: > A way to work around problem #1 is with wildcards, e.g. > > # dnf update g* i*, kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > When this example is used following observance of problem #1, DNF naturally > skips downloading packages already downloaded and meeting the cmdline spec, > and silently deletes all already downloaded packages not meeting the spec, > so > that when e.g. the following is run > > # dnf a* b* c* d* e* f* h* > > the cache begins empty, and it downloads the packages deleted mere minutes > ago. > > Problem #3: > When running from say the /boot directory the same dnf command above: > > # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* > > dnf reports cannot install package inityada, cannot install package > vmliyada, > It ought to be smart enough not to try to install local files that are > not installation package files (e.g., those ending in .rpm or any other > type > it might understand and support). > > The reason Mageia doesn't have any of these problems is that it naturally > and > by default downloads a small bunch, installs them, downloads another bunch, > installs those, etc. Similarly, openSUSE's zypper offers options to > download > one, install one, download second, install second, download third, install > third, etc. (DownloadAsNeeded), and another option to do more or less as > Mageia's urpmi does (DownloadInHeaps), as alternatives to its default > (DownloadInAdvance). Updating Mageia and openSUSE typically takes 30-60 > minutes to update 600-800 packages without babysitting the cmdline, while > Fedora on these installations can take several hours between waiting on the > duplicate downloads and not looking at the screen at the right time to > answer > y or input another group of packages using wildcards. > > Does anyone here agree that each of the three would represent legitimate > wishlist bugs, unlikely to be summarily dismissed as wontfix? > -- > "The wise are known for their understanding, and pleasant > words are persuasive." Proverbs 16:21 (New Living Translation) > > Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! > > Felix Miata *** http://fm.no-ip.com/ > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
DNF pains
I have lots of test installations using identical partition sizes for EXT3 or EXT4 / filesystems. the filesystem space these provided is adequate on all if running Mageia or openSUSE, but quite often not for Fedora. Working around the inadequacy on Fedora presents problems #2 & #3. Problem #1: NAICT, DNF, like Yum before it, offers no option I can recognize from its man page to download less than all the to-be-updated/installed packages before proceeding to install any packages. Thus it downloads (typically hundreds of packages), cutting into available / freespace. Then it does transaction checking before package installation begins, and after which commonly it halts, reporting some small amount of freespace is required on the / filesystem, space that obviously wasn't required for the installation to be operable. By intervening updating of packages in various bunches instead, updating, though laborious, is successful, and freespace when done is perfectly adequate, resulting in total freespace roughly equivalent to Mageia and openSUSE. Problem #2: A way to work around problem #1 is with wildcards, e.g. # dnf update g* i*, kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* When this example is used following observance of problem #1, DNF naturally skips downloading packages already downloaded and meeting the cmdline spec, and silently deletes all already downloaded packages not meeting the spec, so that when e.g. the following is run # dnf a* b* c* d* e* f* h* the cache begins empty, and it downloads the packages deleted mere minutes ago. Problem #3: When running from say the /boot directory the same dnf command above: # dnf update kd*, kf*, q*, per*, pyt*, u*, v*, x* y*, z* dnf reports cannot install package inityada, cannot install package vmliyada, It ought to be smart enough not to try to install local files that are not installation package files (e.g., those ending in .rpm or any other type it might understand and support). The reason Mageia doesn't have any of these problems is that it naturally and by default downloads a small bunch, installs them, downloads another bunch, installs those, etc. Similarly, openSUSE's zypper offers options to download one, install one, download second, install second, download third, install third, etc. (DownloadAsNeeded), and another option to do more or less as Mageia's urpmi does (DownloadInHeaps), as alternatives to its default (DownloadInAdvance). Updating Mageia and openSUSE typically takes 30-60 minutes to update 600-800 packages without babysitting the cmdline, while Fedora on these installations can take several hours between waiting on the duplicate downloads and not looking at the screen at the right time to answer y or input another group of packages using wildcards. Does anyone here agree that each of the three would represent legitimate wishlist bugs, unlikely to be summarily dismissed as wontfix? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
Yaakov Selkowitz wrote:
> This is the hazard of using %{_libdir}/*.so.* in %files. Is there any
> reason why such a syntax should NOT be formally discouraged in the
> packaging guidelines?
There is: I do not want to have to pointlessly edit my specfile each time
some soname changes, and waste a failed build (i.e., ultimately MY time).
The other packages will need to be rebuilt ANYWAY. They may as well do so
when the Rawhide broken dependencies report comes in. Rawhide is supposed to
be a place for development, not something that always works for end users.
By the way, all this talk about keeping Rawhide usable is all the more
ridiculous given that we allow broken trunk snapshots of GCC into Rawhide
which fail to compile packages due to known regressions such as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69241 (which is keeping me from
building QtWebEngine and testing the improvements I am working on). THOSE
are the changes that hinder development and thus Rawhide's actual purpose,
not a broken dependency in one day's Rawhide compose.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, Feb 3, 2016 at 2:19 PM, Michael Schwendt wrote: > On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote: > >> When a provenpackager is rebuilding *hundreds* of packages at once, >> and trying to deal with maybe dozens of build failures, sending emails >> to all the package owners and waiting to see if they respond promptly >> is not an efficient way to get things fixed. Waiting for a reply adds >> a lot of latency, and then you have to context-switch back to a >> package you were dealing with a day or two ago. That's impractical >> when you have a patch ready to go now and loads more packages to look >> at. > > https://fedoraproject.org/wiki/Provenpackager_policy > > | Provenpackagers should try to communicate with owners of a package in > | bugzilla, irc or email prior to making changes. > > | They should be careful not to change other people's packages needlessly > | and try to do the minimal changes required to fix problems, as explained > | more in depth in the policy explaining who is allowed to modify which > | packages. > | -> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages > > Even if says "should" two times, Jerry refers to "no prior contact" and > a version upgrade to alpha level software. That doesn't sound like anything > provenpackagers should do within arbitrary packages. > > I wonder whether a message at the top would have changed the provenpackager's > mind? > Yes, as far as the guidelines state, provenpackager is not carte blanche to do drive-by modifications of packages at will - there needs to be communication, even if it seems inconvenient. For that matter, it's also not license to violate packaging guidelines by adding patches without comments or upgrading versions outside of the stable update guidelines, so I sympathize with Jerry's original mail in that respect. If you read https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages, there's even more suggestions for how to go about editing others' packages, including: "if you committed changes to another package wait some hours if possible (normally 24 or 48) before you actually build the updated package as long it is nothing serious that should be fixed quickly (security problems, ...). That leaves some time for the maintainer to wake up ;-) " I'll also not that the above page seems not reflect at all the "Nobody owns packages" mantra that Jerry is responding to, like where it says: "Normally the maintainer that is listed as primary maintainer in the PackageDB (formerly this was owners.list) of a package is the only one who modifies the package or gives others permission (e.g. by accepting them as co-maintainers) to commit and build changes for that package." I'm not sure who maintains that page or if its an official guideline, but it certainly outlines what my impresson of the best way to go about changing things is. Speaking for myself, I do all of my Fedora work in my free time outside of $DAYJOB, so I do appreciate when others step in and help out with issues in my packages. It also means I'm not always able to respond to bug reports or rawhide failures within a couple of days, but I do try my best to get to things within a week or so. That said, I do have a life, and things occasionally fall off of my radar. Keeping up with others' changes to my packages, especially if they're not high caliber changes, just takes more time I could be spending on other things. It's a much better use of my time to respond to a bug or email to the package-owner alias about forthcoming changes than to try to reverse engineer changes after the fact. In that vein, and to address the *hundreds* of packages at once issue, a mass email to package owner aliases that says "i'm going to make X huge change in a few days, these are the packages affected, I plan on resolving fallout, let me know if you'd like to handle it instead" is a good compromise that only extends the time it takes for you to do your work by a reasonable notification period. Similarly, status updates like "This side tag will be merged on $DATE, please be ready for fall-out" will help everyone else help you for big changes. >> Sometimes a provenpackager will make a bad change, and that's >> unfortunate, but it happens. Sometimes package owners make bad changes >> too! :-) > > You're taking it too lightly. Somebody who performs version upgrades really > needs to take care of a package and incoming problem reports as well. Agreed. "They did it too!" is not a strong defense. I also object to the following comment: >> If I appear >> to change things and walk away it's probably because I've moved on to >> look at other packages that also need attention, not just a careless >> hit & run. I would expect it's similar for others. These things are not mutually exclusive. Other packagers can't tell what you're up to if you don't communicate with them. Rich -- devel mailing list devel@lists.fedoraproject.org http://lists.fedor
Re: On packager motivation
Michael Schwendt (mschwe...@gmail.com) said: > > Sometimes a provenpackager will make a bad change, and that's > > unfortunate, but it happens. Sometimes package owners make bad changes > > too! :-) > > You're taking it too lightly. Somebody who performs version upgrades really > needs to take care of a package and incoming problem reports as well. Is "you, as a provenpackager, are responsible for seeing any changes you make to completion, and dealing with any fallout from them" not the current policy? If not, why wouldn't it be? Bill -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On 02/03/2016 02:21 PM, Marek Polacek wrote: > Looks like a g++ bug; I opened > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658 > to track it further. Thanks. Always nice to have someone else agree that it probably isn't my fault. :D ~tom == Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On Wed, Feb 03, 2016 at 02:10:46PM -0500, Tom Callaway wrote:
> On 02/03/2016 01:57 PM, Florian Weimer wrote:
>
> > Okay, self-contained test case is:
> >
> > struct GVector4 {
> > GVector4(int);
> > };
> > struct GNamedSVGcolor {
> > char Name[22];
> > GVector4 RGBA;
> > };
> >
> > static const GNamedSVGcolor SVGColors[1] = {
> > { "aliceblue", GVector4(1) },
> > };
> >
> > The RGBA member and the constructor argument appear required to trigger
> > this.
>
> I agree. Is anything explicitly wrong with that test case? It feels like
> a false positive, but I'm not expert enough in C++ to be sure.
Looks like a g++ bug; I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69658
to track it further.
Marek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 3 Feb 2016 16:04:19 +, Jonathan Wakely wrote: > When a provenpackager is rebuilding *hundreds* of packages at once, > and trying to deal with maybe dozens of build failures, sending emails > to all the package owners and waiting to see if they respond promptly > is not an efficient way to get things fixed. Waiting for a reply adds > a lot of latency, and then you have to context-switch back to a > package you were dealing with a day or two ago. That's impractical > when you have a patch ready to go now and loads more packages to look > at. https://fedoraproject.org/wiki/Provenpackager_policy | Provenpackagers should try to communicate with owners of a package in | bugzilla, irc or email prior to making changes. | They should be careful not to change other people's packages needlessly | and try to do the minimal changes required to fix problems, as explained | more in depth in the policy explaining who is allowed to modify which | packages. | -> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages Even if says "should" two times, Jerry refers to "no prior contact" and a version upgrade to alpha level software. That doesn't sound like anything provenpackagers should do within arbitrary packages. I wonder whether a message at the top would have changed the provenpackager's mind? > Sometimes a provenpackager will make a bad change, and that's > unfortunate, but it happens. Sometimes package owners make bad changes > too! :-) You're taking it too lightly. Somebody who performs version upgrades really needs to take care of a package and incoming problem reports as well. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On 02/03/2016 01:57 PM, Florian Weimer wrote:
> Okay, self-contained test case is:
>
> struct GVector4 {
> GVector4(int);
> };
> struct GNamedSVGcolor {
> char Name[22];
> GVector4 RGBA;
> };
>
> static const GNamedSVGcolor SVGColors[1] = {
> { "aliceblue", GVector4(1) },
> };
>
> The RGBA member and the constructor argument appear required to trigger
> this.
I agree. Is anything explicitly wrong with that test case? It feels like
a false positive, but I'm not expert enough in C++ to be sure.
~tom
==
Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On 02/03/2016 07:51 PM, Tom Callaway wrote:
> On 02/03/2016 01:49 PM, Florian Weimer wrote:
>> On 02/03/2016 07:37 PM, Tom Callaway wrote:
>>
>>> Ideas?
>>
>> Please tells us which package and which build. This needs more context
>> for an investigation, I think.
>
> amanith:
> https://kojipkgs.fedoraproject.org//work/tasks/6502/12806502/build.log
Okay, self-contained test case is:
struct GVector4 {
GVector4(int);
};
struct GNamedSVGcolor {
char Name[22];
GVector4 RGBA;
};
static const GNamedSVGcolor SVGColors[1] = {
{ "aliceblue", GVector4(1) },
};
The RGBA member and the constructor argument appear required to trigger
this.
Florian
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On 02/03/2016 01:49 PM, Florian Weimer wrote: > On 02/03/2016 07:37 PM, Tom Callaway wrote: > >> Ideas? > > Please tells us which package and which build. This needs more context > for an investigation, I think. amanith: https://kojipkgs.fedoraproject.org//work/tasks/6502/12806502/build.log ~tom == Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Another GCC 6 & Rawhide build failure
On 02/03/2016 07:37 PM, Tom Callaway wrote: > Ideas? Please tells us which package and which build. This needs more context for an investigation, I think. Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
releng pushed to bucardo (master). "- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild"
From b1efc082c60eae772d5f0edb3caf7b63ed916140 Mon Sep 17 00:00:00 2001
From: Dennis Gilmore
Date: Wed, 3 Feb 2016 17:15:59 +
Subject: - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
---
bucardo.spec | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/bucardo.spec b/bucardo.spec
index 29e0477..8bd741d 100644
--- a/bucardo.spec
+++ b/bucardo.spec
@@ -1,7 +1,7 @@
%define realname Bucardo
Name: bucardo
Version:5.4.1
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Postgres replication system for both multi-master and
multi-slave operations
Group: Applications/Databases
License:BSD
@@ -107,6 +107,9 @@ install -Dp -m644 %{SOURCE1} .
%{_datadir}/%{name}
%changelog
+* Wed Feb 03 2016 Fedora Release Engineering -
5.4.1-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
+
* Thu Dec 10 2015 Itamar Reis Peixoto - 5.4.1-2
- improve spec file and disable test's for now
--
cgit v0.11.2
http://pkgs.fedoraproject.org/cgit/bucardo.git/commit/?h=master&id=b1efc082c60eae772d5f0edb3caf7b63ed916140
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org
Another GCC 6 & Rawhide build failure
First the C++ code:
namespace Amanith {
struct GNamedSVGcolor {
GChar8 Name[22];
GVector4 RGBA;
};
static const GNamedSVGcolor SVGColors[147] = {
{ "aliceblue", GVector4(0.941, 0.973, 1.000, 1.000) },
{ "antiquewhite", GVector4(0.980, 0.922, 0.843, 1.000) },
{ "aqua", GVector4(0.000, 1.000, 1.000, 1.000) },
{ "aquamarine", GVector4(0.498, 1.000, 0.831, 1.000) },
{ "azure", GVector4(0.941, 1.000, 1.000, 1.000) },
{ "beige", GVector4(0.961, 0.961, 0.863, 1.000) },
{ "bisque", GVector4(1.000, 0.894, 0.769, 1.000) },
{ "black", GVector4(0.000, 0.000, 0.000, 1.000) },
{ "blanchedalmond", GVector4(1.000, 0.922, 0.804, 1.000) },
...
{ "yellowgreen", GVector4(0.604, 0.804, 0.196, 1.000) }
};
// Yes, it initializes all elements of the SVGColors[147].
}
**
Now, the GCC 6 errors:
../src/rendering/gopenglboard.cpp:280:1: error: C99 designator
'Amanith::GNamedSVGcolor::Name' outside aggregate initializer
};
^
../src/rendering/gopenglboard.cpp:280:1: error: C99 designator
'Amanith::GNamedSVGcolor::Name' outside aggregate initializer
(This repeats 146 more times)
Ideas?
~tom
==
Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On 02/03/2016 08:44 AM, Jerry James wrote: > On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon > wrote: >> Well, one thing about this is that no-one owns packages anymore. We are a >> community and there are package maintainers in that community. >> Each package has one or more maintainers, but nobody owns it. The only >> reason we >> even have a point of contact is because of bugzilla that requires a single >> account to assign the bug reports to. >> >> So sorry but you do not own your packages, you maintain them and where you >> are >> the point of contact, you are merely the primary recipient of the bug >> reports :) > > Several people have said something similar lately, and it worries me. > I understand that we're trying to combat the hostility some packagers > show when somebody does something to "their" packages, but I'm > concerned that we may have swung the pendulum too far the other way. > I foresee two problems: > > 1. Demotivating packagers > > I know a number of companies have experimented with "ownership-free" > models of code development, but they are able to offer incentives that > Fedora cannot offer, such as money and kudos offered in front of > coworkers. What motivates volunteer packagers to do what they do? > I'd like to hear from a few packagers on this topic. > > What motivates me is pride in my work, and recognition of that good > work by others. If I'm just one packager in a big cloud of packagers, > and none of us is really responsible for anything ... well, that's > quite demotivating. > > I am the primary point of contact for a few dozen packages where I > have done all of the packaging work, all of the reporting of bugs > upstream, all of the arguing with upstream to do something about > sticky license situations, all of the handling of bug reports. I'm > sure the same is true for many other packagers. People feel ownership > of what they work on. This is human nature. I fear that by denying > human nature with this "those aren't your packages" mantra, we will > suck the joy out of packaging work and see packagers less willing to > do that work. I guess I wouldn't have used the phrase "merely the primary recipient of the bug reports". It's pretty obvious that most packages have a single primary maintainer, and that maintainer should justifiably be able to take pride in the work they do maintaining their packages. That said, this is also a community project, and we really do need to get away from the "I own this, stay away" mentality that has arisen in some contributors. > 2. Motivating responsibility-free drive-by modifications > > If nobody owns any packages, then who is responsible for fixing > package problems? I think the reason some packagers react with > hostility to others changing "their" packages is that we have a > handful of provenpackagers who make incorrect changes to packages and > then walk away, without sticking around to fix the problems they > caused with their incorrect changes. I've got two recent examples of > this. I won't use any names, because my purpose is not to point > fingers. > > a. Last fall, a provenpackager updated a package for which I am the > primary point of contact (as well as the original submitter). The > update was to an upstream alpha release. It was alpha for a reason. > The release is super buggy. I had not updated to it on purpose. A > provenpackager strolled by, updated to the buggy release, then > strolled away. Guess who has been getting the bug reports? Not the > person who did the update, the person who did not even bother > contacting the primary point of contact to see if updating was okay. > > b. Just last week, another provenpackager dropped two patches into a > package for which I am the primary point of contact (as well, again, > as the original submitter). One patch only has effect on non-Linux > systems, so adding it was pointless. I don't even have any idea what > the other patch does. It changes stuff, I can see that, but why? The > person who did this did not add any comments to the PatchN: lines in > the spec file, so I don't know if they have been submitted upstream, > are from upstream, or what. Here, again, the provenpackager made *no* > attempt at all to contact the primary point of contact. > > If I send these two provenpackagers a somewhat hostile email, are you > going to blame me? I have no problem with most provenpackager > changes. In general, they have an obvious purpose and save me the > work of making the same change myself. But changes like the ones > above make more work for me, work that could have been avoided if the > provenpackager in question had just bothered to make some attempt, any > attempt, to contact me first. Those are unfortunate and inappropriate, and I think would justify complaint. > I think we need to ask ourselves, as a project, what behaviors we want > to motivate and what behaviors we want to demotivate in our packagers. > I think we need
Re: Firefox - call for testing (Gtk3 effort)
On 02/03/2016 05:08 PM, Jonathan Wakely wrote: On 03/02/16 11:58 +0100, Jakub Jelen wrote: Don't know it it will help, but I see Firefox almost always crash when I open new window and try to close it on F23. Sometimes earlier after opening the windows, sometimes later after closing. I've been seeing this recently when I close a tab that was running a plugin. I've submitted crash reports to mozilla every time. Great. Unfortunately the Mozilla upstream crashes does not contain backtraces of system libraries. Could you please try to catch those crashes in gdb and submit a bug at bugzilla.redhat.com? Instructions are here: http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Application_crash Or you can try to catch the crash by ABRT tool. Thanks! ma. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On 02/03/2016 12:42 PM, Michael Schwendt wrote: On Wed, 3 Feb 2016 05:26:23 -0500, Matthew Miller wrote: On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote: This approach really scales badly and creates busywork. And breaking rawhide however often due to unnoticed soname bumps does scale well and does not cause busywork? Right. Tooling should stop that too. And I'm not just talking _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where any package build which breaks other packages (or possibly other integration testing) gets automatically shuttled to a temporary side repo. That's a good idea. This is good idea for releases, but would be utterly counter productive to rawhide. You'd end up with not being able or drowning in bureaucracy e.g. to add SONAME breaking changes. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with Rawhide build error with GCC 6.0
On 03/02/16 17:30 +, Jonathan Wakely wrote:
On 03/02/16 10:59 -0600, Richard Shaw wrote:
With the release of GCC 6.0 in Rawhide I'm having a build
warning/error[1,2] with OpenImageIO I'm not sure what to do with (other
than adding a flag to ignore it).
tl;dr either add -Wno-error=placement-new for now or try the
workaround at the bottom of this mail.
Upstream is looking into it but currently thinks that the pugixml API is
requiring a method that GCC 6.0 doesn't like:
No, the code is trying to place a large object in a tiny buffer, and
GCC issues a warning about that, because it looks suspect. Because the
package uses -Werror (which I won't rant about now) that warning
becomes an error and so breaks the build.
It looks like the code is possibly safe though, meaning the warning is
a false-positive. The code appears to be using an emulated form of C99
flexible-array member (which isn't supported in standard C++). I
assume there is a 1-byte array at the end of the object, and then they
over-allocating for the object so they can store something else in the
location beginning at the 1-byte array e.g.
#include
struct X {
enum Type { Int, Double };
Type type;
char data[1];
};
int main()
{
X* p = (X*)malloc(sizeof(X) + sizeof(double) - 1);
*(double*)p->data = 1.0;
Oops, I pasted the wrong version of the example. To reproduce the same
warning the line above should be:
double* d = new (p->data) double(1.0);
p->type = X::Double;
}
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with Rawhide build error with GCC 6.0
On 03/02/16 10:59 -0600, Richard Shaw wrote:
With the release of GCC 6.0 in Rawhide I'm having a build
warning/error[1,2] with OpenImageIO I'm not sure what to do with (other
than adding a flag to ignore it).
tl;dr either add -Wno-error=placement-new for now or try the
workaround at the bottom of this mail.
Upstream is looking into it but currently thinks that the pugixml API is
requiring a method that GCC 6.0 doesn't like:
No, the code is trying to place a large object in a tiny buffer, and
GCC issues a warning about that, because it looks suspect. Because the
package uses -Werror (which I won't rant about now) that warning
becomes an error and so breaks the build.
It looks like the code is possibly safe though, meaning the warning is
a false-positive. The code appears to be using an emulated form of C99
flexible-array member (which isn't supported in standard C++). I
assume there is a 1-byte array at the end of the object, and then they
over-allocating for the object so they can store something else in the
location beginning at the 1-byte array e.g.
#include
struct X {
enum Type { Int, Double };
Type type;
char data[1];
};
int main()
{
X* p = (X*)malloc(sizeof(X) + sizeof(double) - 1);
*(double*)p->data = 1.0;
p->type = X::Double;
}
(This example ignores alignment requirements, so isn't OK, the real
code in OpenImageIO might be OK).
I'll take a closer look, but if this is doing something reasonable
then we'll need to make GCC's warning smarter, so it allows cases like
this.
/builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58:
error: placement new constructing an object of type
'OpenImageIO::v1_6::pugi::impl::xml_document_struct' and size '44' in a
region of type 'char [1]' and size '1' [-Werror=placement-new]
_root = new (page->data) impl::xml_document_struct(page);
A workaround would be to make it too hard for the compiler to see the
problem:
void* ptr = page->data;
_root = new (ptr) impl::xml_document_struct(page);
This way GCC doesn't see that the address refers to a 1-byte array.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On Wed, 2016-02-03 at 08:44 -0700, Jerry James wrote: > I know a number of companies have experimented with "ownership-free" > models of code development, but they are able to offer incentives > that > Fedora cannot offer, such as money and kudos offered in front of > coworkers. What motivates volunteer packagers to do what they do? > I'd like to hear from a few packagers on this topic. I can't speak to the rest of the issues you've experienced as I haven't so far. I became a packager because software I was using on some of our systems weren't in Fedora/EPEL. I was using them and building them and figured, a) I've always wanted to contribute to FOSS but haven't really been able to yet. b) These are packages that I already have to deal with, might as well have them in the distro to make life easier and provide them for others. Since that first package I'm the point of contact for a mere 12 packages and co-maintainer of 3. Each of those because I was using something and needed newer versions or what have you. Looking at the list, there are a number of dependencies on a package I'm the maintainer of but no longer actively use, however it doesn't change much so why not keep at it. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with Rawhide build error with GCC 6.0
On Wed, Feb 3, 2016 at 11:15 AM, Florian Weimer wrote: > On 02/03/2016 05:59 PM, Richard Shaw wrote: > > > In member function 'void > OpenImageIO::v1_6::pugi::xml_document::create()': > > > /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58: > > error: placement new constructing an object of type > > 'OpenImageIO::v1_6::pugi::impl::xml_document_struct' and size '44' in a > > region of type 'char [1]' and size '1' [-Werror=placement-new] > >_root = new (page->data) impl::xml_document_struct(page); > > It's the use of char data[1] as a flexible array member. I'm not sure > if this is valid C++. Warning about it is certainly appropriate. I passed your suggestions on to upstream, they're usually pretty responsive. Thanks! Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Help with Rawhide build error with GCC 6.0
On 02/03/2016 05:59 PM, Richard Shaw wrote: > In member function 'void OpenImageIO::v1_6::pugi::xml_document::create()': > /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58: > error: placement new constructing an object of type > 'OpenImageIO::v1_6::pugi::impl::xml_document_struct' and size '44' in a > region of type 'char [1]' and size '1' [-Werror=placement-new] >_root = new (page->data) impl::xml_document_struct(page); It's the use of char data[1] as a flexible array member. I'm not sure if this is valid C++. Warning about it is certainly appropriate. You should remove the data member, use sizeof(xml_memory_page) instead of offsetof(xml_memory_page, data), and replace page->data with reinterpret_cast(page) + sizeof (impl::xml_memory_page), or ideally, have xml_memory_page::construct() return both pointers. You probably should check for wraparound in the size computations as well, to avoid allocating less memory than requested. Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Help with Rawhide build error with GCC 6.0
With the release of GCC 6.0 in Rawhide I'm having a build warning/error[1,2] with OpenImageIO I'm not sure what to do with (other than adding a flag to ignore it). Upstream is looking into it but currently thinks that the pugixml API is requiring a method that GCC 6.0 doesn't like: [ 3%] Building CXX object src/libutil/CMakeFiles/OpenImageIO_Util.dir/filter.cpp.o cd /builddir/build/BUILD/oiio-Release-1.6.9/build/linux/src/libutil && /usr/bin/c++ -DNDEBUG -DOpenImageIO_Util_EXPORTS -DUSE_EXTERNAL_PUGIXML=1 -DUSE_FIELD3D=1 -DUSE_FREETYPE -DUSE_OCIO=1 -DUSE_OPENCV -DUSE_OPENEXR_VERSION2=1 -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/usr/include/OpenEXR -I/usr/include/libraw -I/builddir/build/BUILD/oiio-Release-1.6.9/src/include -I/builddir/build/BUILD/oiio-Release-1.6.9/build/linux/include/OpenImageIO -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 -O2 -g -DNDEBUG -fPIC -Wall -Werror -fno-math-errno -Wno-error=unused-local-typedefs -Wno-unused-local-typedefs -Wno-unused-result -o CMakeFiles/OpenImageIO_Util.dir/filter.cpp.o -c /builddir/build/BUILD/oiio-Release-1.6.9/src/libutil/filter.cpp In file included from /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugiconfig.hpp:41:0, from /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.hpp:20, from /builddir/build/BUILD/oiio-Release-1.6.9/src/libOpenImageIO/formatspec.cpp:45: /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp: In member function 'void OpenImageIO::v1_6::pugi::xml_document::create()': /builddir/build/BUILD/oiio-Release-1.6.9/src/include/OpenImageIO/pugixml.cpp:5143:58: error: placement new constructing an object of type 'OpenImageIO::v1_6::pugi::impl::xml_document_struct' and size '44' in a region of type 'char [1]' and size '1' [-Werror=placement-new] _root = new (page->data) impl::xml_document_struct(page); ^ Any ideas would be appreciated. Thanks, Richard [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=12804782 [2] https://kojipkgs.fedoraproject.org//work/tasks/4782/12804782/build.log -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PATH contains at build time
On Wed, Feb 03, 2016 at 11:09:48AM -0500, Matthew Miller wrote:
> On Wed, Feb 03, 2016 at 03:12:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > Using %{_sbindir} is just busywork. It is safe it too asume that is
> > $PATH.
>
> I sadly agree. Ship sailed for fixing this about a decade ago. It'd be
> a nice usability enhancement to get programs which are not intended to
> be run by humans out of $PATH, but I don't think it'd be worth the
> churn to do it.
It is still possible, by keeping various things in /usr/lib or
/usr/libexec. E.g. systemd does this to a large extent with a bunch of
binaries in /usr/lib/systemd.
The difference between /bin and /sbin was more about admin/non-admin
stuff, but with policykit and capabilities and whatnot things have become
so blurred that this distinction doesn't make much sense anymore.
Zbyszek
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: nss_myhostname as default in Fedora
Sorry to reply with such a delay. On Mon, Jan 25, 2016 at 07:43:35PM -0800, Andrew Lutomirski wrote: > I also think that the whole gethostname(2) mechanism is terminally > screwed up. We abuse the hostname for multiple purposes: > > 1. It shows up in the default bash prompt. > > 2. It gets sent to remote DHCP servers. I think this is a mistake on > desktop machines. Like discussed elsewhere in the thread, this is used by DDNS, which is very useful in closed environments. It is also useful for diagnostics: if I look on the router what leases were made, it's much nicer to see the names rather than just the MAC addresses. The hostname is something that essentially is used to identify a machine for humans, and not allowing the hostname to be visible defeats the purpose. Not sending the hostname in DHCP requests on non-trusted networks was discussed in the other part of the thread. It's a great idea, but not really relevant to this discussion, since DHCP libraries already make this configurable (e.g. SendHostname=, Hostname= settings described in systemd.network(5)). The issue is knowing when to set it on and when to off, but this is needs to be solved at a slightly higher level. > 3. Some programs seem to thing that gethostbyname(gethostname()) > should return some reasonable concept of "my ip address" despite the > general nonexistence of such a concept. > > I'll propose a strawman: > > - gethostname(2) always returns "localhost". So you are proposing to make the current hostname mechanism useless and add a replacement mechanism. I don't get the point, if this got implemented we would be in the same place a few years down the road. If the point is to avoid DHCP sending out the hostname, this can already be achieved with a simple config change. > - "localhost" always resolves to 127.0.0.1 or ::1 That's what nss-myhostname provides. > - bash learns to use some intelligent value derived from whatever > hostnamectl would return I think bash is fine now: is shows gethostname(), which defaults to contents of /etc/hostname. > - the default DHCP clients send a client identifier that's a function > only of the MAC address used to send the query It's better not to send anything if not desired as discussed above. DHCP servers don't use this to generate leases, so there's little point in sending a random value. > - Whatever systemd magic special-cases "localhost" as "trust what > DHCP says" goes away. No, systemd doesn't do that. First, nss-myhostname resolves localhost statically to 127.0.0.1. Second, sd-dhcp refuses 'localhost' as the lease name. Systemd will use the DHCP provided "transient" name, but only if the "static" name (from /etc/hostname is not set). The "transient" name is a fallback value only. > This trivially solves one silly annoyance: when I install Fedora, why > on Earth is "what's your hostname" a reasonable question to ask me? Because all installations of Fedora are similar and a 16 byte UUID is not something that most humans can remember. > Servers may have their own considerations, and NetworkManager and/or > networkd could consider having a client-id override. (They do.) > If people really want to force a non-"localhost" hostname on a server, > then forcing it to resolve to something intelligent might make sense, > as having everything fail when resolution times out or ends up with > SERVFAIL or NXDOMAIN is nasty. But when I force my hostname to > "foo.corp.bar.com", I probably have something other than 127.0.0.1 in > mind. This is something to be discussed, certainly. We already ask for a user name, so it might be nice to simply to default to a hostname generated from that, and the automatically detected chassis type (user 'Mikey' → login 'mikey' → pretty hostname "Mikey's Laptop" → hostname "mikeys-laptop"). This field should still be editable, but a sensible default would work nicely. IIRC, this is what Windows does more or less, and it is pretty intuitive. At least for Workstation. Anaconda could say "This computer will be visible as "Mikey's Laptop" in the local network." to make people aware that the name is visible. Zbyszek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream release monitoring issue
I would have just made the lib a subproject but the version is higher than that of the binary/overall version. Maybe the best thing to do is just to go ahead and bite the bullet and bump the Epoch and do it that way. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream release monitoring issue
On Wed, 3 Feb 2016 07:32:33 -0600, Richard Shaw wrote:
> On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann wrote:
>
> > Is there any reason why two packages provide tsqllib and tsqllib-devel?
> > See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the
> > related .spec files in git repos?
>
>
> They used to be supplied as two separate archives which was nice because
> they are versioned separately. They combined them a while back but
> maintained the separate versioning which has made my spec file quite
> complex and the auto bump specs always break it.
If you're concerned about the auto bump, there are ancient ways to avoid
the breakage with a slightly changed spec file. See further below.
First of all, let me point out that giving sub-packages an own Version
and/or Release tag also implicitly redefines the %version and %release
macros for the remainder of the spec file. That can lead to complications
already and will break in customised rpmbuild environments, such as those
used by several packagers where sourcedir depends on %version.
Secondly, in trustedqsl.spec, the macro usage is not consequent enough, IMO.
In the subpkg section you rely on %version instead of your explicitly
defined %libtqslver. In the lines below, you could not access the base
package %version, because %version got redefined by the subpkg.
If you don't like using rpmdev-bumpspec, or if you don't like changing the
spec file, better stop reading here. ;-)
A first way to adjust the spec would be to insert a %baserelease value
into all Release tag definitions, either before %dist or after it and
starting at 0 or 1:
@@ -1,3 +1,5 @@
+%global baserelease 0
+
# Because upstream is not good about bumping the library version for ABI
# incompatible changes the Release should not be reset to 1 unless both version
# numbers change, otherwise the NEVR of the library may cause a package not to
@@ -8,8 +10,8 @@
# The tsql library needs to maintain it's own release version otherwise it
# would not be "newer" than the installed version when the application release
# resets to 1.
-%global tqslrel 11%{?dist}
-%global libtqslrel 11%{?dist}
+%global tqslrel 11%{?dist}.%{baserelease}
+%global libtqslrel 11%{?dist}.%{baserelease}
Name: trustedqsl
@@ -61,7 +63,7 @@
Version:%libtqslver
Release:%{libtqslrel}
Summary:Development files the for TrustedQSL library
-Requires: tqsllib%{?_isa} = %{version}-%{libtqslrel}
+Requires: tqsllib%{?_isa} = %{libtqslver}-%{libtqslrel}
%description -n tqsllib-devel
The TrustedQSL library is used for generating digitally signed
For minor updates, simply bumping %baserelease would do the job, would not
break anything and would match the minor version bumps guidelines, too.
The solution would also survive auto bumps, because rpmdev-bumpspec does
not touch any Release tags once it bumped an earlier %baserelease or
%release macro definition.
For version upgrades, properly resetting *and* bumping your custom release
macros would be needed as with the current spec, too.
If the resulting release value is considered not readable/clear enough,
the final release values could be calculated on-the-fly:
%global baserelease 0
%global buildrel() %%(dc -e '%1 %baserelease +p')%{?dist}
%global tqslrel %buildrel 11
%global libtqslrel %buildrel 11
For rebuilds and minor changes, one would simply bump %baserelease.
For version changes, one would adjust the release macros (i.e. reset
the upgraded one to 1 and bump the other one as with the current spec,
too) *and* reset the %baserelease offset to 0 again.
A third way would be to define your %tqslrel and %libtsqlrel macros
only after the definition of the related Release tags:
@@ -8,13 +8,12 @@
# The tsql library needs to maintain it's own release version otherwise it
# would not be "newer" than the installed version when the application release
# resets to 1.
-%global tqslrel 11%{?dist}
-%global libtqslrel 11%{?dist}
Name: trustedqsl
Version:%{tqslver}
-Release:%{tqslrel}
+Release:11%{?dist}
+%global tqslrel %{release}
Summary:TrustedQSL ham-radio applications
License:BSD
URL:http://sourceforge.net/projects/trustedqsl/
@@ -48,7 +47,8 @@
%package -n tqsllib
Version:%libtqslver
-Release:%{libtqslrel}
+Release:11%{?dist}
+%global libtqslrel %{release}
Summary:TrustedQSL library
%description -n tqsllib
@@ -59,9 +59,9 @@
%package -n tqsllib-devel
Version:%libtqslver
-Release:%{libtqslrel}
+Release:11%{?dist}
Summary:Development files the for TrustedQSL library
-Requires: tqsllib%{?_isa} = %{version}-%{libtqslrel}
+Requires: tqsllib%{?_isa} = %{libtqslver}-%{libtqslrel}
%description -n tqsllib-devel
The TrustedQSL library is used for generating digitally signed
The major pitfall is, of course, that while rpmdev-bumpspec w
Re: PATH contains at build time
On Wed, Feb 03, 2016 at 03:12:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Using %{_sbindir} is just busywork. It is safe it too asume that is
> $PATH.
I sadly agree. Ship sailed for fixing this about a decade ago. It'd be
a nice usability enhancement to get programs which are not intended to
be run by humans out of $PATH, but I don't think it'd be worth the
churn to do it.
--
Matthew Miller
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
On 03/02/16 11:58 +0100, Jakub Jelen wrote: Don't know it it will help, but I see Firefox almost always crash when I open new window and try to close it on F23. Sometimes earlier after opening the windows, sometimes later after closing. I've been seeing this recently when I close a tab that was running a plugin. I've submitted crash reports to mozilla every time. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Wed, Feb 3, 2016 at 3:26 AM, Matthew Miller wrote: > Right. Tooling should stop that too. And I'm not just talking > _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where > any package build which breaks other packages (or possibly other > integration testing) gets automatically shuttled to a temporary side > repo. I think I asked this question before, but I don't remember the answer. Will Dennis's work include some way of letting high priority packages break low priority packages? As an example, I maintain the polymake package, which has way too much knowledge about perl internals. Very nearly every perl update breaks polymake in one way or another. Sometimes the breakage is easy to fix and I just go ahead and do it. Other times I have to go to polymake upstream and ask them to fix it. Either way, we should let polymake break and let me fix it as soon as I can. Perl updates should not be delayed. Will that be possible? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: On packager motivation
On 03/02/16 08:44 -0700, Jerry James wrote: 1. Demotivating packagers I know a number of companies have experimented with "ownership-free" models of code development, but they are able to offer incentives that Fedora cannot offer, such as money and kudos offered in front of coworkers. What motivates volunteer packagers to do what they do? I'd like to hear from a few packagers on this topic. I want Fedora to be better. If I send these two provenpackagers a somewhat hostile email, are you going to blame me? I have no problem with most provenpackager changes. In general, they have an obvious purpose and save me the work of making the same change myself. But changes like the ones above make more work for me, work that could have been avoided if the provenpackager in question had just bothered to make some attempt, any attempt, to contact me first. I don't think that's always realistic to expect. When a provenpackager is rebuilding *hundreds* of packages at once, and trying to deal with maybe dozens of build failures, sending emails to all the package owners and waiting to see if they respond promptly is not an efficient way to get things fixed. Waiting for a reply adds a lot of latency, and then you have to context-switch back to a package you were dealing with a day or two ago. That's impractical when you have a patch ready to go now and loads more packages to look at. Sometimes a provenpackager will make a bad change, and that's unfortunate, but it happens. Sometimes package owners make bad changes too! :-) If I make a bad change to a package please do let me know. If I appear to change things and walk away it's probably because I've moved on to look at other packages that also need attention, not just a careless hit & run. I would expect it's similar for others. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 24 Mass Rebuild
Hi all, Per the Fedora 24 schedule[1] we will be starting a mass rebuild for Fedora 24 very shortly. We are doing a mass rebuild for Fedora 24 for https://fedoraproject.org/wiki/Changes/GCC6 we will start the mass rebuild on 2016-02-03 This is a heads up that it will be done in a side tag and moved over when completed. We will be running scripts to output failure stats. please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on freenode. Failures can be seen http://dl.fedoraproject.org/pub/alt/mass-rebuild/f24-failures.html Things still needing rebuilt http://dl.fedoraproject.org/pub/alt/mass-rebuild/f24-need-rebuild.html Regards Dennis signature.asc Description: This is a digitally signed message part. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On 3 February 2016 at 15:27, Brian C. Lane wrote: > On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote: > > = Proposed Self Contained Change: Graphical System Upgrades = > > https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades > > This change is really light on details (or progress?). How is this going > to be different (and why) from the dnf system-upgrade plugin? Since it > is GNOME Software related I guess it is going to run while the system is > active, not during reboot? Part of the reason for fedup/system-upgrade > was to avoid breakage resulting from upgrading changing running code. > > Also can we ensure that gnome software/packagekit updates the dnf database correctly before we recommend, or even enable, this upgrade method? It's bad enough right now with F23 and dnf autoremoving stuff installed via the packagekit interfaces but add in a whole system upgrade being out of sync with the way dnf thinks of the system and it sounds like a recipe for disaster. Bonus points for dnf history showing packagekit actions too ;) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On packager motivation
On Tue, Feb 2, 2016 at 11:30 PM, Pierre-Yves Chibon wrote: > Well, one thing about this is that no-one owns packages anymore. We are a > community and there are package maintainers in that community. > Each package has one or more maintainers, but nobody owns it. The only reason > we > even have a point of contact is because of bugzilla that requires a single > account to assign the bug reports to. > > So sorry but you do not own your packages, you maintain them and where you are > the point of contact, you are merely the primary recipient of the bug reports > :) Several people have said something similar lately, and it worries me. I understand that we're trying to combat the hostility some packagers show when somebody does something to "their" packages, but I'm concerned that we may have swung the pendulum too far the other way. I foresee two problems: 1. Demotivating packagers I know a number of companies have experimented with "ownership-free" models of code development, but they are able to offer incentives that Fedora cannot offer, such as money and kudos offered in front of coworkers. What motivates volunteer packagers to do what they do? I'd like to hear from a few packagers on this topic. What motivates me is pride in my work, and recognition of that good work by others. If I'm just one packager in a big cloud of packagers, and none of us is really responsible for anything ... well, that's quite demotivating. I am the primary point of contact for a few dozen packages where I have done all of the packaging work, all of the reporting of bugs upstream, all of the arguing with upstream to do something about sticky license situations, all of the handling of bug reports. I'm sure the same is true for many other packagers. People feel ownership of what they work on. This is human nature. I fear that by denying human nature with this "those aren't your packages" mantra, we will suck the joy out of packaging work and see packagers less willing to do that work. 2. Motivating responsibility-free drive-by modifications If nobody owns any packages, then who is responsible for fixing package problems? I think the reason some packagers react with hostility to others changing "their" packages is that we have a handful of provenpackagers who make incorrect changes to packages and then walk away, without sticking around to fix the problems they caused with their incorrect changes. I've got two recent examples of this. I won't use any names, because my purpose is not to point fingers. a. Last fall, a provenpackager updated a package for which I am the primary point of contact (as well as the original submitter). The update was to an upstream alpha release. It was alpha for a reason. The release is super buggy. I had not updated to it on purpose. A provenpackager strolled by, updated to the buggy release, then strolled away. Guess who has been getting the bug reports? Not the person who did the update, the person who did not even bother contacting the primary point of contact to see if updating was okay. b. Just last week, another provenpackager dropped two patches into a package for which I am the primary point of contact (as well, again, as the original submitter). One patch only has effect on non-Linux systems, so adding it was pointless. I don't even have any idea what the other patch does. It changes stuff, I can see that, but why? The person who did this did not add any comments to the PatchN: lines in the spec file, so I don't know if they have been submitted upstream, are from upstream, or what. Here, again, the provenpackager made *no* attempt at all to contact the primary point of contact. If I send these two provenpackagers a somewhat hostile email, are you going to blame me? I have no problem with most provenpackager changes. In general, they have an obvious purpose and save me the work of making the same change myself. But changes like the ones above make more work for me, work that could have been avoided if the provenpackager in question had just bothered to make some attempt, any attempt, to contact me first. I think we need to ask ourselves, as a project, what behaviors we want to motivate and what behaviors we want to demotivate in our packagers. I think we need to take human nature, flawed as it is, into account when doing so. I fear that this "nobody owns any packages" mantra is not providing the motivations and demotivations that we really want. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: nss_myhostname as default in Fedora
Hi, On Wed, Jan 27, 2016 at 11:57:37PM +0100, Jan Pokorný wrote: > attempt on settle this one down: http://tools.ietf.org/html/rfc6761 rfc6761 is a useful reference, but it doesn't really solve this discussion one way or another. It's concerned with names to be "carved off a sub-tree of the DNS namespace in which the modified name treatment rules apply", but single label names are already special anyway. > (also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856) This is one of the problems that myhostname solves. Zbyszek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote: > = Proposed Self Contained Change: Graphical System Upgrades = > https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades This change is really light on details (or progress?). How is this going to be different (and why) from the dnf system-upgrade plugin? Since it is GNOME Software related I guess it is going to run while the system is active, not during reboot? Part of the reason for fedup/system-upgrade was to avoid breakage resulting from upgrading changing running code. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PATH contains at build time
On Wed, Feb 03, 2016 at 09:44:21AM -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/03/2016 09:35 AM, Petr Pisar wrote:
> > On 2016-02-02, Florian Weimer wrote:
> >> May packages assume that /usr/sbin is on PATH when they are built?
> >>
> >> If you need a program which is currently only in /usr/sbin, should a
> >> package use an absolute path, or reset PATH to include /usr/sbin?
> >>
> > When I was small, I was tought that sbin is for programs executed by
> > superuser, therefore only root user's login shell adds sbin into PATH.
> >
> > Thus the question boils down to: What user does build the package?
> >
> > But I can forsee the answer for `Does Fedora support building packages as
> > non-root?' The answer is `defined by koji^Wimplementation'. So does not
> > have answer.
> >
> > I would call the programs by absolute path.
> >
>
> Koji/mock will only build as a non-root user.
> That said, we have a specific RPM macro for this: %{_sbindir}, which should be
> used for calling sbin binaries. (Ditto %{_bindir} for /usr/bin binaries).
Please don't. /usr/bin and /usr/sbin have been in both root's and
normal users' path for ages now. Path setting is decentralized, at
least util-linux [1], systemd, and gdm set it, and they all include
both /usr/sbin and /usr/bin in path for users. Mock shells have it.
If /usr/sbin was removed from users' path, too many things would
break, and it's never going to happen. The only reason that /usr/bin
and /usr/sbin are still separate is consolehelper.
Using %{_sbindir} is just busywork. It is safe it too asume that is
$PATH.
Zbyszek
[1] c.f. https://bugzilla.redhat.com/show_bug.cgi?id=1251320
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PATH contains at build time
On 3 February 2016 at 14:35, Petr Pisar wrote: > On 2016-02-02, Florian Weimer wrote: >> May packages assume that /usr/sbin is on PATH when they are built? >> >> If you need a program which is currently only in /usr/sbin, should a >> package use an absolute path, or reset PATH to include /usr/sbin? >> > When I was small, I was tought that sbin is for programs executed by > superuser, therefore only root user's login shell adds sbin into PATH. > > Thus the question boils down to: What user does build the package? > > But I can forsee the answer for `Does Fedora support building packages as > non-root?' The answer is `defined by koji^Wimplementation'. So does not > have answer. > On what architecture is root required to build packages? I thought a build user was recommended? -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PATH contains at build time
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2016 09:35 AM, Petr Pisar wrote:
> On 2016-02-02, Florian Weimer wrote:
>> May packages assume that /usr/sbin is on PATH when they are built?
>>
>> If you need a program which is currently only in /usr/sbin, should a
>> package use an absolute path, or reset PATH to include /usr/sbin?
>>
> When I was small, I was tought that sbin is for programs executed by
> superuser, therefore only root user's login shell adds sbin into PATH.
>
> Thus the question boils down to: What user does build the package?
>
> But I can forsee the answer for `Does Fedora support building packages as
> non-root?' The answer is `defined by koji^Wimplementation'. So does not
> have answer.
>
> I would call the programs by absolute path.
>
Koji/mock will only build as a non-root user.
That said, we have a specific RPM macro for this: %{_sbindir}, which should be
used for calling sbin binaries. (Ditto %{_bindir} for /usr/bin binaries).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iEYEARECAAYFAlayEkAACgkQeiVVYja6o6Nv6ACgnWLvpEdcKuYp5pDeWuJR4BYF
QDoAn02L/4yozYcgP3CcCcxPD9YI9v/n
=sEB5
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: PATH contains at build time
On 2016-02-02, Florian Weimer wrote: > May packages assume that /usr/sbin is on PATH when they are built? > > If you need a program which is currently only in /usr/sbin, should a > package use an absolute path, or reset PATH to include /usr/sbin? > When I was small, I was tought that sbin is for programs executed by superuser, therefore only root user's login shell adds sbin into PATH. Thus the question boils down to: What user does build the package? But I can forsee the answer for `Does Fedora support building packages as non-root?' The answer is `defined by koji^Wimplementation'. So does not have answer. I would call the programs by absolute path. -- Petr -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On 02/03/2016 03:16 PM, Heiko Adams wrote: > Am Mittwoch, den 03.02.2016, 15:00 +0100 schrieb Jan Kurik: >> First supported version is going to >> be Fedora 23->24 upgrades. > Does this mean the changes will be backported to GNOME Software 3.18? No. The plan is to put GNOME Software 3.20 in F23, so that the rest of the GNOME stays at 3.18, but GNOME Software gets a major version update. This is just for F23 to get system upgrade support in; later on in F24+ we'll stick with the regular GNOME updates policy where we don't put major updates in a stable Fedora release. -- Kalev -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 System Wide Change: The GNU C Library version 2.23
= Proposed System Wide Change: The GNU C Library version 2.23 = https://fedoraproject.org/wiki/Changes/GLIBC223 Change owner(s): * Carlos O'Donell Switch glibc in Fedora 24 to glibc version 2.23. == Detailed Description == The GNU C Library version 2.23 will be released at the end of February 2016; we have started closely tracking the glibc 2.23 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 24 will branch before GLIBC 2.23. Fedora 24 will be rebased on the stable GLIBC 2.23 release. == Scope == Proposal owners: * Update glibc to 2.23 from tested upstream release. Other developers: * Aside from Carlos O'Donell , Florian Weimer , Torvald Riegel , Martin Sebor , and Patsy Franklin , no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 24 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated. Release engineering: * In general coordination with release engineering is not required. A mass rebuild is not required. Policies and guidelines: * The policies and guidelines do not need to be updated. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On Wed, Feb 03, 2016 at 03:21:26PM +0100, Kalev Lember wrote: > >> We'll implement a graphical user interface for system upgrades. The > >> implementation will use PackageKit and the libhif stack as a backend > >> and GNOME Software as a frontend. First supported version is going to > >> be Fedora 23->24 upgrades. > > Since we just agreed to officially support "n-2" upgrades, will this > > also include F22->F24? > No, but it will include F23->F25 in the future. It gets a bit too messy > to backport this to F22. Okay cool. We need to be careful about the messaging around this, then. > > *Everything* can benefit from testing, and we don't have enough > > documentation on what to do. > > > > The current documentation _does_ explain how to do an upgrade, and that > > should be updated as part of this. > > https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/chap-upgrading.html > Right; I'll fill these in when we have actual packages available to test > things. Thanks! -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On 02/03/2016 03:11 PM, Matthew Miller wrote: > On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote: >> We'll implement a graphical user interface for system upgrades. The >> implementation will use PackageKit and the libhif stack as a backend >> and GNOME Software as a frontend. First supported version is going to >> be Fedora 23->24 upgrades. > > Since we just agreed to officially support "n-2" upgrades, will this > also include F22->F24? No, but it will include F23->F25 in the future. It gets a bit too messy to backport this to F22. >> == Scope == > > The change proposal has > > "N/A (not a System Wide Change)" > > under both "How To Test" and "Documentation". This makes me sad. I see > that the template has that at the bottom of the boilerplate there, but > *especially* with testing, I don't think we should encourage that. > These sections don't need to be extensive, but it'd _really_ help if > they have at least a basic outline. > > *Everything* can benefit from testing, and we don't have enough > documentation on what to do. > > The current documentation _does_ explain how to do an upgrade, and that > should be updated as part of this. > https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/chap-upgrading.html Right; I'll fill these in when we have actual packages available to test things. -- Kalev -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 System Wide Change: Removal of librtkaio from glibc
= Proposed System Wide Change: Removal of librtkaio from glibc = https://fedoraproject.org/wiki/Changes/GLIBC223_librtkaio_removal Change owner(s): * Carlos O'Donell Remove librtkaio support from glibc in Fedora 24. == Detailed Description == On July 2003 the rtkaio add-on was added to Fedora in glibc 2.3.2-64. The rtkaio add-on provided a POSIX realtime API interface that used linux kernel Asynchronous IO support (KAIO) to provide high performance AIO for a small subset of files (those using O_DIRECT, and not all file types). Typically the use case was databases or high-speed transactional systems that needed fast AIO. The libraries were installed under /lib64/rtkaio/ e.g. /lib64/rtkaio/librt.so.1 (symlink to /lib64/rtkaio/librtkaio-X.Y.so with SONAME librt.so.1) and could be used by preloading (LD_PRELOAD), dynamic linker lookup path changes (LD_LIBRARY_PATH) or by directly opening the shared library (dlopen). This accelerated access to file was used by customers like Sybase during the development of their database Sybase ASE (now owned by SAP). It has been 12 years since rtkaio was released, and while it has seen some uptake, the only known usage example is Sybase ASE. Sybase now exclusively uses the Linux Kernel Asynchronous I/O Library (libaio) for over 10 years ago and no longer use rtkaio. The libaio project provides a unique API that is tailored to doing very fast AIO. An analysis of Fedora shows no packages using rtkaio. Lastly the rtkaio add-on was never contributed upstream, likely because it never provided full POSIX conformance and worked only with a small subset of the required POSIX realtime features, those supported by KAIO. It is the conclusion of the Fedora glibc team that the maintenance burden of rtkaio is no longer warranted. The glibc team suggest rtkaio be deprecated and removed. Application developers should use libaio if they want high performance KAIO, or use librt if they want portable and flexible AIO. What are the consequences of removing rtkaio? * Application developers using rtkaio will see a performance decrease if they were previously using KAIO on O_DIRECT opened files, but should otherwise see no semantic changes in their applications. * Application developers using LD_PRELOAD will see a warning that the preloaded library is missing, but the application will load the normal librt and continue to operate correctly. * Application developers using LD_LIBRARY_PATH will see no warning, and the application will load the normal librt and continue to operate correctly. * Application developers using dlopen will see a failure from dlopen since the library is missing. This is mitigated by shipping a symlink from the rtkaio library to librt in the official Fedora release. The rtkaio library and the librt library are ABI and API compatible, and therefore interchangeable. As long as we provide one of them we will meet our application compatibility requirements. We will continue to provide the POSIX realtime library (librt) forever. The following plan of action is suggested: * Immediately remove rtkaio from Fedora Rawhide, deprecating the library. See https://bugzilla.redhat.com/show_bug.cgi?id=1227855 No compatibility symlinks are provided for Rawhide. We want to use Rawhide to detect if any applications are actually using rtkaio. Before the F24 branch a compatibility symlink will be added and left in place for a full release after which it will be removed. == Scope == Proposal owners: * Update glibc and remove librtkaio. Other developers: * Aside from Carlos O'Donell , Siddhesh Poyarekar , Torvald Riegel , Martin Sebor , and Patsy Franklin , no other developers are required. These developers need to ensure that rawhide is stable and ready for the Fedora 24 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when librtkaio is removed. Release engineering: In general coordination with release engineering is not required. A mass rebuild is not required. Policies and guidelines: The policies and guidelines do not need to be updated. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
Am Mittwoch, den 03.02.2016, 15:00 +0100 schrieb Jan Kurik: > First supported version is going to > be Fedora 23->24 upgrades. Does this mean the changes will be backported to GNOME Software 3.18? -- Regards, Heiko Adams signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 System Wide Change: GNOME 3.20
= Proposed System Wide Change: GNOME 3.20 = https://fedoraproject.org/wiki/Changes/GNOME3.20 Change owner(s): * Kalev Lember Update GNOME to the latest upstream release, 3.20 == Detailed Description == The new features for 3.20 include: * Graphical System Upgrades * Cantarell font improvements * Shortcuts windows * New Mouse and Touchpad Settings * Improved CSS theming for GTK+ apps == Scope == Proposal owners: * Keep existing GNOME packages updated * Follow upstream module changes * Package new applications and new dependencies of existing GNOME packages for GNOME 3.20 Other developers: N/A Release engineering: N/A Policies and guidelines: N/A -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 Self Contained Change: Graphical System Upgrades
On Wed, Feb 03, 2016 at 03:00:53PM +0100, Jan Kurik wrote: > We'll implement a graphical user interface for system upgrades. The > implementation will use PackageKit and the libhif stack as a backend > and GNOME Software as a frontend. First supported version is going to > be Fedora 23->24 upgrades. Since we just agreed to officially support "n-2" upgrades, will this also include F22->F24? > == Scope == The change proposal has "N/A (not a System Wide Change)" under both "How To Test" and "Documentation". This makes me sad. I see that the template has that at the bottom of the boilerplate there, but *especially* with testing, I don't think we should encourage that. These sections don't need to be extensive, but it'd _really_ help if they have at least a basic outline. *Everything* can benefit from testing, and we don't have enough documentation on what to do. The current documentation _does_ explain how to do an upgrade, and that should be updated as part of this. https://docs.fedoraproject.org/en-US/Fedora/23/html/Installation_Guide/chap-upgrading.html -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
F24 Self Contained Change: Graphical System Upgrades
= Proposed Self Contained Change: Graphical System Upgrades = https://fedoraproject.org/wiki/Changes/GraphicalSystemUpgrades Change owner(s): * Kalev Lember < klember AT redhat DOT com > Add support for performing system upgrades to a newer Fedora release through GNOME Software. == Detailed Description == We'll implement a graphical user interface for system upgrades. The implementation will use PackageKit and the libhif stack as a backend and GNOME Software as a frontend. First supported version is going to be Fedora 23->24 upgrades. == Scope == Proposal owners: * Implement this change Other developers: N/A (not a System Wide Change) Release engineering: N/A (not a System Wide Change) List of deliverables: N/A (not a System Wide Change) Policies and guidelines: N/A (not a System Wide Change) Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
On 02/03/2016 02:45 PM, Jakub Jelen wrote: On 02/03/2016 10:53 AM, Martin Stransky wrote: Also please remove Firefox from ABRT blacklist at: /etc/abrt/abrt-action-save-package-data.conf ma. On 02/03/2016 10:43 AM, Martin Stransky wrote: Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. Installed the package from koji, debuginfo, set up the ABRT to handle the crashes (GPG,Unpackaged,Blacklist), restarted abrtd, crashed firefox few times, but I still don't see the crashes in abrt-cli. Is there some another config I am missing? Hm, no idea. Maybe ABRT maintainer may help here? (cc mhabr...@redhat.com) ma. Anyway I found that the Firefox was crashed by DNSSEC/TLSA Validator plugin: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ Disabled and works fine for me so far. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
On 02/03/2016 10:53 AM, Martin Stransky wrote: Also please remove Firefox from ABRT blacklist at: /etc/abrt/abrt-action-save-package-data.conf ma. On 02/03/2016 10:43 AM, Martin Stransky wrote: Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. Installed the package from koji, debuginfo, set up the ABRT to handle the crashes (GPG,Unpackaged,Blacklist), restarted abrtd, crashed firefox few times, but I still don't see the crashes in abrt-cli. Is there some another config I am missing? Anyway I found that the Firefox was crashed by DNSSEC/TLSA Validator plugin: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ Disabled and works fine for me so far. -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream release monitoring issue
On Tue, Feb 2, 2016 at 4:38 PM, Pierre-Yves Chibon wrote: > On Tue, Feb 02, 2016 at 04:11:46PM -0600, Richard Shaw wrote: > >I was notified by a user that a newer version of trustedqsl was > available > >so I looked into why I wasn't notified. > >For some reason it still thinks 1.13 is the current version when it is > >2.2: > >https://release-monitoring.org/project/4998/ > >I've tried tweaking things but can't seem to find the magic formula > to get > >it to work. > >Any suggestions? > > I fixed it. > > I had to set the name of the project to tqsl (which is the name of the > tarball > anitya looks for) and the name of the sourceforge project to trustedqsl > (so it > knows in which SF projects to look for this tarball). > I almost tried that but had already given up in frustration. The documentation is a little light and I wish it would show you the regex after making an update without having to make it check for the latest version. You should have received a notification for 2.2. > I did. Thanks. Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream release monitoring issue
On Tue, Feb 2, 2016 at 4:45 PM, Christian Stadelmann < genodeft...@fedoraproject.org> wrote: > Is there any reason why two packages provide tsqllib and tsqllib-devel? > See https://apps.fedoraproject.org/packages/s?search=trustedqsl and the > related .spec files in git repos? They used to be supplied as two separate archives which was nice because they are versioned separately. They combined them a while back but maintained the separate versioning which has made my spec file quite complex and the auto bump specs always break it. Richard -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Upstream release monitoring issue
On Wed, 3 Feb 2016 07:34:06 +0100, Pierre-Yves Chibon wrote: > On Tue, Feb 02, 2016 at 10:45:04PM -, Christian Stadelmann wrote: > > Is there any reason why two packages provide tsqllib and tsqllib-devel? See > > https://apps.fedoraproject.org/packages/s?search=trustedqsl and the related > > .spec files in git repos? > > Looks like one is using a tarball named tqsl > http://pkgs.fedoraproject.org/cgit/rpms/trustedqsl.git/tree/sources > while the other is using a tarball named tqsllib > http://pkgs.fedoraproject.org/cgit/rpms/tqsllib.git/tree/sources > > But the names are clearly confusing They depend on it other it seems. The review is here: https://bugzilla.redhat.com/455396 -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Wed, 3 Feb 2016 05:26:23 -0500, Matthew Miller wrote: > On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote: > > >This approach really scales badly and creates busywork. > > And breaking rawhide however often due to unnoticed soname bumps > > does scale well and does not cause busywork? > > Right. Tooling should stop that too. And I'm not just talking > _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where > any package build which breaks other packages (or possibly other > integration testing) gets automatically shuttled to a temporary side > repo. That's a good idea. Late Fedora Extras could run repoclosure on the buildsys' "needsign" queue (= packages waiting to be pushed *and* included in the buildroot immediately). Not fully automated, but the earliest opportunity to notify packagers about breakage and also the chance to withdraw such packages. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Tue, 02 Feb 2016 13:01:04 +0100, Adam Williamson wrote: > > Even if the spec file uses wildcards to include any shared library > > version, the automatic dependency checks for Rawhide will notice the > > SONAME change and inform the packager about it. > > [...] > > This is too late, though. We don't want to break Rawhide and then find > out after the fact, we want it to not be broken in the first place. That's only due to an artificial limitation imposed by the buildsys and/or the repo compose tool. They could be changed again to keep more than the latest build in the repos. Removing past builds from the repos too early is one of Fedora's weaknesses. The latest upgrade is broken? => People cannot downgrade or roll back unless they have kept any old packages that may be needed for that. And in Rawhide? The latest build can break buildroot creation and image compose tools much too easily, because previous builds are gone already, and depsolvers cannot choose them if needed. > It's actually written down somewhere that packagers are meant to notify > of soname bumps *before* they happen (and similar changes for other > forms of shared libraries) and co-ordinate or do the rebuilds of > dependent packages. That's a work-flow, education and policy issue. A non-wildcard SONAME in a %files list is not enough of a reminder that notifying devel@ list (or preferably the affected packagers directly) is necessary. Plus, the special handling for non-Rawhide builds only causes confusion (such as needing buildroot overrides for non-Rawhide builds whereas Rawhide buildroot is updated directly, and no broken deps check before using bodhi). > In this particular case, this soname bump caused one day's Rawhide > compose to be entirely broken; most images did not build at all. We > want to avoid that. Which is also because the repoclosure run comes too late is is decoupled from the masher. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
I'd need the ABRT backtrace for that - don't see it on my F23 box. On 02/03/2016 11:58 AM, Jakub Jelen wrote: Don't know it it will help, but I see Firefox almost always crash when I open new window and try to close it on F23. Sometimes earlier after opening the windows, sometimes later after closing. Jakub On 02/03/2016 10:43 AM, Martin Stransky wrote: Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
Don't know it it will help, but I see Firefox almost always crash when I open new window and try to close it on F23. Sometimes earlier after opening the windows, sometimes later after closing. Jakub On 02/03/2016 10:43 AM, Martin Stransky wrote: Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. -- Jakub Jelen Associate Software Engineer Security Technologies Red Hat -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote: > >Ideally, every line in a package definition (specfile or what have you) > >is only there because of some exception from the typical case. For > >well-behaved > >upstreams, the perfect packaging description would be _empty_. > I don't see how %files could ever be implicit. _Especially_ with the "unlisted file in buildroot" check rpmbuild has had for, like, a decade now, it's really pretty much busywork. RPM knows what's there and wants it all included or all removed. The only useful function what people are describing here: "alert packager that something has changed and force action", and there's _definitely_ better ways to do that. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Unannounced soname bump: libpsl
On Tue, Feb 02, 2016 at 06:13:13PM -0600, Yaakov Selkowitz wrote: > >This approach really scales badly and creates busywork. > And breaking rawhide however often due to unnoticed soname bumps > does scale well and does not cause busywork? Right. Tooling should stop that too. And I'm not just talking _completely_ in hand-wavy theory. This is Dennis Gilmore's plan, where any package build which breaks other packages (or possibly other integration testing) gets automatically shuttled to a temporary side repo. -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Firefox - call for testing (Gtk3 effort)
Also please remove Firefox from ABRT blacklist at: /etc/abrt/abrt-action-save-package-data.conf ma. On 02/03/2016 10:43 AM, Martin Stransky wrote: Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. Thanks! ma. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Firefox - call for testing (Gtk3 effort)
Folks, we see many Gtk3 crashes in Firefox recently (https://bugzilla.mozilla.org/show_bug.cgi?id=1239962) which comes from Gtk3 system library. If you's like to help here, please install latest FF updates from koji: F23: https://bodhi.fedoraproject.org/updates/FEDORA-2016-8344bd0b61 F22: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d73684df54 and also enable the ABRT tool. If Firefox crashes please submit the crash stat to ABRT retrace server. That would help up greatly to investigate root of this problem. Thanks! ma. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
