devel October 2016

devel@lists.fedoraproject.org

244 participants
352 discussions

[Fwd: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?]
by Sérgio Basto 11 Nov '16

11 Nov '16

Hello, I'd like understand how groups of package are now detect , specially in 3rd repo packages which can't use comps.xml. Thanks ! -------- Forwarded Message -------- From: Sérgio Basto <sergio(a)serjux.com> To: packaging(a)lists.fedoraproject.org Subject: Re: [Fedora-packaging] Re: why the Group tag is obsolete ? Date: Sun, 28 Aug 2016 07:24:58 +0100 On Seg, 2016-08-01 at 09:17 -0600, Dave Johansen wrote: > > On Sun, Jul 31, 2016 at 9:23 PM, Sérgio Basto <sergio(a)serjux.com> > wrote: > > > > Hi, > > A year ago, I learned that Group tag is obsolete [1] I remember ask > > the > > reason and is something about comps.xml that I don't remember > > neither > > find on google , but for projects that still use repoview, Group > > tag is > > needed. So the questions are, have we any replacement for repoview > > ? or > > another way to show one repo content ? and why the Group tag is > > obsolete ? can someone remind me why. And how we now the group of > > one > > package ? . > > > > Thanks. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1239067#c1 > Here's the FPC ticket about it: > https://fedorahosted.org/fpc/ticket/199 Thanks I was able to find the reason: RPM in Fedora 18 does not require the presence of the Group tag in the spec file. If the tag is defined, it will be ignored. The package groups of the yum application are used on a Fedora 18 system as the relevant source of information on which group is the package a part of. I remembered in one thread of devel mailing list on create hawaii group and bingo found the link: https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gr… So now, how I know the group of the package (via yum or dnf) ? seems to me many packages will not have group ... and 3rd-part software ? Also /usr/bin/gnome-software how find the group of the package ? Well this is not a very important matter , but I'd like try organize packages in groups , via repoview. Thanks. -- Sérgio M. B. -- Sérgio M. B.

6 13

ATTN: OCaml 4.03 in Rawhide, could affect POWER, s/390, RHEL 7.4, CentOS 7.4
by Richard W.M. Jones 08 Nov '16

08 Nov '16

OCaml 4.03 has been out for a while. I'm intending to add it to Fedora Rawhide once a side tag has been created: https://fedorahosted.org/rel-eng/ticket/6486 This will require rebuilding every OCaml package, which I normally do using a script, but probably there will be manual rebuilds necessary too. A few issues that may affect people: (1) There is a new ppc backend upstream, and I intend to switch to this. For years we have maintained our own out-of-tree ppc64 & ppc64le backends. I want to switch to the upstream ppc backend (which supports, in theory, ppc 32 bit, ppc64 and ppc64le). However when I actually tried this I found it to be rather buggy, it couldn't even compile many basic OCaml packages. This time I intend to switch, and we'll deal with the bugs. (2) There is a new s/390x backend upstream. This should enable us to compile all s/390x packages as native code. It also means that all supported architectures (yes, even riscv64) will support native compilation for OCaml. (3) The real reason I'm doing this now is because partners have asked us to update the OCaml compiler in RHEL 7.4. This will be a binary ABI break -- it's unfortunately unavoidable -- and will require all OCaml-using programs to be recompiled, and of course that will affect CentOS and any other RHEL derivatives. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

3 5

DNF and PackageKit background data usage
by Adam Williamson 07 Nov '16

07 Nov '16

Hi folks! I kinda hate kicking off discussions like this without having a solid solution to propose or being able to promise to work on one, but this really seems important. Unfortunately I can't claim I'm gonna have time to do any concrete work on it, though I'd really *like* to. But I thought it would be worthwhile to kick around still; perhaps someone else will be inspired. I just read Hedayat's review of Fedora 25 Beta: https://hedayatvk.wordpress.com/2016/10/30/fedora-25-beta and this really jumped out at me: "And, if you care about your internet usage, make sure that you disable both dnf makecache timer, and stop PackageKit from downloading updates automatically. I don’t allow a new Fedora installation to access internet before doing these, as it might just eat a considerable amount of data." There's two things I think are somewhat unfortunate here: 1) Both dnf and GNOME Software / PackageKit default to performing fairly data-hungry transactions in the background, out of the box, without telling you about it. GNOME's is particularly bad, as it will happily download available updates in the background, which can be gigabytes worth of data. DNF only updates its metadata caches (on a systemd timer), but even that could be behaviour that users in certain circumstances really really do not want. 2) There is no particularly obvious or visible mechanism for a 'typical user' (or, if you prefer, many of the target 'personas' for our flavors) to configure this behaviour...and you have to figure out two completely *different* configuration mechanisms in order to shut off both. I think this is kind of poor behaviour on our part and we should make it better. Do I have a specific concrete proposal? No. But I do have some vague ideas. * We could have some kind of configuration interface appear on install / first boot. This would require integration with anaconda and/or initial-setup and gnome-initial-setup. * We could invert the defaults and have the apps ask the user if they want to enable data-hungry background operations on first interaction: the first time you use dnf (without -y) it could say 'hey, do you want to turn on background cache refreshes?' Similarly, the first time you run GNOME Software or click on an update notification, it could say 'hey, do you want to turn on background update downloads'? * We could at least make both of them respect one single config setting for 'do data hungry background operations' (this is kinda one small part of the bigger issue that is 'dnf and PK-based stuff don't share any configuration aside from repo definitions'). Anyone have thoughts on this? Any DNF or Software devs want to say I'm totally wrong and an idiot? Anyone inspired to do something more concrete than a mailing list post? :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

30 67

Private Bugzilla bugs
by Florian Weimer 05 Nov '16

05 Nov '16

Why does Bugzilla allow filing private Fedora bugs? I'm not sure who has the capability (it may be tied to specific accounts). It is not all that helpful because accounts on the Cc: list still receive notifications and can access the bug. Recipients of the notifications may include public mailing lists. This is probably not what people make bugs private expect. The other problem is that I keep having to ask people filing private bugs if it is okay with them to make them public, and then to open the bugs again if they accidentally turn it private afterwards. Surely it's best to remove this capability from Bugzilla? (In case anyone wonders: We do not file Fedora bugs for embargoed security issues at all, so a Bugzilla permissions change would have zero impact on that front.) Thanks, Florian

11 24

Bodhi For Rawhide?
by Vít Ondruch 05 Nov '16

05 Nov '16

Hi all, I am thinking, why we don't have enabled Bodhi for Rawhide? I know that you might think now that I went nut and it is bureaucracy, but let me explain. If I understand it correctly, during several past years, our build process was more streamlined and we are trying to do the Rawhide composes in a similar fashion we are doing stable releases. But for some reason, we are still not using Bodhi for Rawhide and I see no reasons not to use it. Here are some benefits if we were using Bodhi: * One of the nice things which Bodhi does is running several check, such as depcheck, rpmlint (actually question if we are using rpmlint for Fedora builds was what triggered this email), etc. On one hand, I'd love to see these checks running in Koji, but there is no support for them and I don't even see the support coming. So enabling Bodhi for Rawhide would give us this opportunity. It is actually quite interesting, that while most of the development happens in Rawhide, there is less sanity checks then for the Rawhide, so if you screw up something in Rawhide, it will get into stable version and you might not notice until you submit some stable update. * From time to time, there is necessary to build some framework, which consist of several components which must be released together. Currently, we either temporarily break Rawhide or we are asking for side tag. But why not use koji for that? Users of stable releases are not affected by incomplete builds, since the don't reach even the update-testing without pushing via Bodhi. * And probably last think, why the Rawhide should be really exception? Why we should not use Bodhi if we are using it anywhere else? Lets use Bodhi for Rawhide, where the submitted update would immediately go into Rawhide, unless maintainer wishes some testing period. Any comments on this topic? V.

13 37

Many directories without owning packages
by Dridi Boukelmoune 04 Nov '16

04 Nov '16

Hello, I was surprised to see /usr/share/texlive on my system although I remembered very well removing it months ago. It turned out to be caused by two rpmsave files, although some *empty* directories weren't removed: $ find /usr/share/texlive/ /usr/share/texlive/ /usr/share/texlive/texmf-dist /usr/share/texlive/texmf-dist/web2c /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf.rpmsave /usr/share/texlive/texmf-dist/web2c/updmap.cfg.rpmsave /usr/share/texlive/texmf-dist/tex /usr/share/texlive/texmf-dist/tex/latex /usr/share/texlive/texmf-dist/tex/latex/misc /usr/share/texlive/tlpkg /usr/share/texlive/tlpkg/TeXLive /usr/share/texlive/tlpkg/tlpostcode /usr/share/texlive/tlpkg/translations But then I decided to check my whole /usr tree and found more orphans than I expected. My crude data gathering: $ find /usr/ -type d -exec rpm -qf {} \; | grep 'not owned' | tee not_owned.txt And the results on my current fc24 laptop: $ wc -l <not_owned.txt 828 $ sort not_owned.txt | awk '{print $2}' | head /usr/include/at-spi2-atk/2.0 /usr/include/at-spi2-atk /usr/include/mono-2.0 /usr/include/mono-2.0/mono/cil /usr/include/mono-2.0/mono /usr/include/mono-2.0/mono/jit /usr/include/mono-2.0/mono/metadata /usr/include/mono-2.0/mono/utils /usr/include/nss3/templates /usr/lib64/akonadi/contact/editorpageplugins Most directories contain files that are owned by packages, although I could find an interesting number of actual orphan files on my /usr tree! Upon quick inspection it looks like remains from old packages after they got upgraded. Some of the remains date fc22. There's an insignificant bunch of files I installed in /usr/local too. $ find $(awk '{print $2}' <not_owned.txt) -type f | grep -v ' ' | # I don't want to deal with spaces in file names xargs rpm -qf | grep 'not owned' | wc -l find: ‘/usr/lost+found’: Permission denied find: ‘/usr/share/rhel/secrets’: Permission denied 1191 Sparing you more shell soup, under /usr I currently have 10738 files owned by a package whose parent directories are *not all* owned, belonging to 290 packages. Once my /usr is clean I will try to monitor it after each upgrade. It should be easy enough to script, although scanning 18GB of /usr against the whole RPM database takes some time. I don't know whether we have tools checking this automatically, and if DNF/RPM tells you about paths that weren't removed along with their packages during a transaction, I'm interested in having this information on every `dnf update`. Cheers, Dridi

5 13

[OT] Best Practices: Populating RPM SPEC %defines in basic Ant build management
by Bryan Smith 03 Nov '16

03 Nov '16

PREFACE: My apologies as this may be off-topic. But I figured this might be the best set of SMEs to ask this question, especially since I'm drawing a blank from when I had to do this a few years ago. Environment: - Disconnected systems (no or very limited Internet access) - Apache Ant build management Best Practice Sought: - Solution to populate %defines at the top of RPM SPEC files Feel free to tell me to RTFM with a link or anything else. I just haven't kept up with the latest set of 'Best Practices' and/or tools to manage many of the common %defines at the top of RPM SPEC files in an Ant build management solution. I.e., I assume there is a way to manage this better than just some scripts called as part of the buildfile that does direct file manipulation (e.g., via sed) and/or populates via environmental variables Side Note: We were looking at introducing Maven-Nexus as well, but we're sticking with just our Git repos and Ant to match our traditional software development and its build process. This would be for packaging things into RPM atop of all that. Again, likely off-topic and/or remedial for this list, but I'd figure I'd ask as I'm several years out-of-date. -- bjs -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me

2 2

PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.
by Matthew Miller 02 Nov '16

02 Nov '16

I've talked about this before, but maybe the F26 cycle is time to make it happen. Right now, we have only one way of saying "this bug is important to the project as a whole; could we please get resources focused on it?" — and that way is to stop the whole vehicle until someone does something about it. This has always been kind of problematic, even though it has served well enough so far... but as we move to more deliverables and add things with different lifecycles, I think we need something else. We have the Accepted Blockers <https://qa.fedoraproject.org/blockerbugs/milestone/25/final/buglist> list. The process is nicely documented at <https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process>; please read that if you're not familiar. I propose we create a parallel "Critical Issues" list, using basically the same procedures. Issues eligible for this status would be those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective. Since Fedora is a volunteer process, this can't be backed by a hard mandate (like the "block the release!" emergency brake), but if we agree together to take it seriously, I think it will still provide a useful list. Anyone with a package or component involved in the issue will be able to see the impact, and take that into account when prioritizing. As FPL, it'd give me a nice overview of issues that might need extra resources or coordination. We could either implement this by extending the existing blocker bug process — adding a new tracker bug, add a new category in the blockerbug app, and review candidate issues at the normal blocker review meetings. Or, it could be done in parallel, with a separately-configured instance of the blockerbug app and with review in a separate meeting called as needed (or maybe just FESCo?) As with the existing Blocker or Freeze Exception levels, we could also introduce a second tier "Important Issues", which could have a wider net than the rules for "Critical Issues". I'm not sure about that. In any case, what do you all think? -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

19 50

Pondering security update time frames
by Andrew Lutomirski 02 Nov '16

02 Nov '16

It seems to me that Fedora has three severe distribution wide issues relating to security updates: 1. Updates, even critical security updates, are very slow. Getting an update out involves creating a build and an update (which is reasonably fast for most packages), pushing the update to updates-testing, getting karma, and pushing to updates. The latter three can happen in parallel in the best case. The big problem as I see it is that pushing updates is painfully slow. For reasons that I'm sure make a lot of internal sense, updates seem to get stuck behind broken composes and such all the time. Can this be made better? IMO it should be possible for a security update to be checked, incrementally, for sanity with respect to the rest of the package repository, and then pushed out, without needing to do whatever expensive work a compose does. If some other update breaks the compose, I don't think this should cause security updates to get stuck. 2. There doesn't appear to be a working process to get updates out quickly. As a current and pressing example, there is no build for Firefox 49.0.2. 3. AFAIK Fedora has no means by which it can participate in embargoed updates. For this to work, I think there ought to be private git branches, a way to get Koji to make a private build from a private git branch, and a way to get private karma on a private update. Then, when an embargo is lifted, the packager could merge the private branch in, the various infrastructure bits could notice that the very same git commit is now public and permit all of the private builds, updates, and karma to become public and allow an immediate push to updates.

14 39

Intel Vulkan driver status
by Michael Cronenworth 02 Nov '16

02 Nov '16

Why is the Vulkan driver being left out right now? Here's the RFE[1] from July asking for it to be enabled. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1356229

4 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2016