Re: replace unclutter with unclutter-xfixes?
On Fri, 30 Nov 2018, 06:05 Henrique Martins > the package is not maintained in Fedora anymore and going > > to be removed, soon. Would you be willing to maintain it > > in Fedora? > > Maybe, though I have no idea what's involved ... > It's explained at https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -- Peter Oliver ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: replace unclutter with unclutter-xfixes?
> the package is not maintained in Fedora anymore and going > to be removed, soon. Would you be willing to maintain it > in Fedora? Maybe, though I have no idea what's involved ... -- Henrique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Tracking translation status of a package built in koji
Hi Everyone, At times this could be a requirement to track or know translation status of a package which has (just) built in koji. Transtats could be used for this purpose. We just need to run a job. Steps: 1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based 2. Select 'Sync Package Build System' job template and proceed. 3. You may read and continue with the tasks defined in YML. 4. Select or enter package name. For example: anaconda. Select Build System and Tag. For example: koji and rawhide Click 'Next' 5. And run the job. Upon successful completion an unique URL will be created. This could really be helpful. We are working on creating alerts or warnings. Feel free to share comments on this here: http://feedback.transtats.xyz thanks, sundeep ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Thu, Nov 29, 2018 at 12:15:52PM +, Peter Robinson wrote: > This is basically the problem I have with the work we're doing in IoT. > The basically will make me re-evaluate if IoT is now worth doing at > all in Fedora or whether I am now better off focusing my efforts > elsewhere. Is there something specific you're concerned about, or is it a general sense that there's likely to be something that you want updated? Since IoT is ostree-based, is it possible we could solve this by including packages from a newer module of whatever is problematic -- or even rawhide builds? (That is, you say that modularity isn't capable of soving this, but I'm not sure why not.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora Hardware portal
On Thu, Nov 29, 2018 at 04:57:33PM +0300, Andrey Ponomarenko wrote: > https://github.com/linuxhw/hw-probe (various packages are available: > AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to Have you considered packaging this directly in Fedora? That would make it a lot easier for users to just run the program. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: A smart cache-y proposal for composes
On Thu, 2018-11-29 at 16:01 -0500, Randy Barlow wrote: > "NO" -adamw =) More seriously, to me this is kinda a natural consequence of what we've already talked about quite a bit with associating inputs and outputs. But I dunno if I'd think of it as *caching*, exactly, just more along the lines of 'only generate outputs when the relevant inputs change'. But, I mean, it's fine to think of it as caching too, I guess, it just hadn't occurred to me to look at it that way. Like all caching, it's fine so long as the implementation is correct, and a giant PITA when it isn't :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: A smart cache-y proposal for composes
"NO" -adamw signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
A smart cache-y proposal for composes
So, I had an idea of one method of attack for composes and lifecycles that I thought I would toss out there to see what others thought of it. Instead of redesigning and reimplementing our current build/compose/test pipeline we improve it by making the current process cache as much of everything as it possibly can and listening and operating on any changes in inputs. So, instead of gathering everything all the time from all the inputs every time we only do 'full' composes every so often (weekly?) and then less and less often as our caching is fixed. At each place we currently gather or query an input, we instead query it and check it against what we already have. If they are the same, go on, if they are different, cache it and change only those things that are affected by that input. Some examples: a new xfce4-session package is built. The composer sees this and goes through all things affected by 'new package': * Does it pass CI? * remove old package from package caches/repos and update them. * is it in a deliverable? yes, a Xfce live and a xfce arm image * make those (just those) and test * If everything passes, release those deliverables (a updated repo where you just have the one package updated and new repodata, some images and checksum files) A new kernel is built: * Does it pass CI? * remove old package from package caches/repos and update them. * is it in a deliverable? yes, almost all of them. * build and test each deliverable in order of importance. * If they all pass, release those deliverables (new repos, new images, new checksums, etc). This of course really only works for rawhide, and in practice (at least at first) we would swamp it pretty easily (ie, kernel and coreutils and dnf update nearly at the same time could result in tons of activity), but it could be nice down the road as it would mean we are always ready for a release anytime we choose to do so. There will of course be cases of caches not updating, or updating, but not building all the affected outputs. It would also require a lot of mapping of input to outputs, but almost any approach we have will need that. Thoughts? or better yet: Other concrete ideas how to approach this re-tooling? kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Last dbus upgrade issues
On Monday, 26 November 2018 at 23:49, Tomasz Kłoczko wrote: [...] > Cleaning the session is perfect example of what can be done with using > Solaris contracts which is kind of grouping attribute for some group > of processes which needs to be treated as the group. When session The Linux implementation is called control groups (cgroups) and systemd makes heavy use of it. Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
Damn!, I thought this was a done deal and booked my six month holiday :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 12:42 PM Nicolas Mailhot wrote: > > Le jeudi 29 novembre 2018 à 10:56 -0500, Josh Boyer a écrit : > > > > Of the large number of packages that you maintain, how many of them > > are critical to freeze at a specific version for a given Fedora > > release? Possibly some, but I would think across the distribution it > > would not be a huge number. > > It's not so much that many packages need freezing, but quite a lot need > coordinated rebuilds (mini mass rebuilds). Once thing current cadencing > provides is "free" mass rebuilds (you just make sure to commit the key > packages before branching and releng will usually mass rebuild all the > other things that depend on those key parts for some other reason). > > Fix the tooling so those mini mass rebuilds are cheap to setup and are > not human packager intensive, and there's not reason the rebuild result > could not be pushed to every release. Or to a rolling release. Or > whatever. Yes, agreed. Fixing the tooling is what much of these threads are about ;) > We really need to evolve our tooling from "packages can be handled > independently in reviews, builds, and pushes, coordinated changes are > the exception" to "we manage sets of packages by default, single-package > changes are just set changes with set = 1" Modularity does that for a number of cases, but it isn't a silver bullet. Our package dependencies web is much too complex to make it feasible for everything to be in a module, at least right now. (We should really also revisit our package dependencies in general and try to minimize as much as we can for a variety of reasons, leveraging rich/weak deps. That's a different topic though.) josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
Le jeudi 29 novembre 2018 à 10:56 -0500, Josh Boyer a écrit : > > Of the large number of packages that you maintain, how many of them > are critical to freeze at a specific version for a given Fedora > release? Possibly some, but I would think across the distribution it > would not be a huge number. It's not so much that many packages need freezing, but quite a lot need coordinated rebuilds (mini mass rebuilds). Once thing current cadencing provides is "free" mass rebuilds (you just make sure to commit the key packages before branching and releng will usually mass rebuild all the other things that depend on those key parts for some other reason). Fix the tooling so those mini mass rebuilds are cheap to setup and are not human packager intensive, and there's not reason the rebuild result could not be pushed to every release. Or to a rolling release. Or whatever. We really need to evolve our tooling from "packages can be handled independently in reviews, builds, and pushes, coordinated changes are the exception" to "we manage sets of packages by default, single-package changes are just set changes with set = 1" -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Changing nsswitch.conf on a running system (was Re: /etc/nssswitch.conf is supposed to be a symlink now?)
On 11/29/18 8:29 AM, Kevin Kofler wrote: Ray Strode wrote: (defer until next offline update?) That would be never on many systems. Most users using command-line DNF and all users using plasma-pk-updates or dnfdragora never do offline updates by design. I, being of the old school, still try to stick to online updates, but I came to believe that we just don't have the infinitely rolling update capability any more, so your online updates have to be punctuated by reboots anyway. This is true on several levels: - kernel updates---the livepatch / ksplice capabilites are not mainstream enough - basic session infrastructure does not support online updates, e.g. recent dbus discussion where people explicitly said that dbus cannot be restarted cleanly - application-level issues (IPC protocol or file formats, etc) Even though my updating method does not force it, I restart my system whenever I see that I am running a kernel that's more than one-two behind the latest update, or when I see instability in some userland processes I use. I have given up trying for uptimes measured in months--in practice, my uptimes range between weeks and months. I don't even think infinite uptime is a reasonable goal---I'd rather work on setting my system up so that all long-term tasks restart automatically and correctly pick up where they left off --- I monitor/collect several extended datasets, such as weather/soil/environmental conditions, home automation, etc. Having said that, I definitely want control over offline/online updating---the choice between 'interruptions all the time' and 'interruptions only when it is most annoying' is not acceptable :) I do think there should be a clear, established way to determine when the reboot is needed. There was "needs-restarting" from yum-utils, but it effectively disappeared because yum-utils conflict with dnf now, and it was a little flaky anyway. There's a lot of gray area between the dnfdragora suggestion of rebooting for every update, and rebooting only for Fedora N-2->N version upgrades at the N-2 EOL. I don't know if it's practical or desirable to automate this, but maybe there should be a package boolean marking each upgrade as 'requiring reboot' or not; kernel and dbus upgrades would have it always as 'YES', and other packages would reflect the judgment of packagers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora 30 Self-Contained Change proposal: Migrate Python-based Nautilus extensions to Python 3
https://fedoraproject.org/wiki/Changes/NautilusExtensionsPython3 The Python backend for the nautilus-python extension will be updated from python2 to python3. All Nautilus extensions written in Python will need to be checked for Python 3 compatibility and updated if necessary. Extensions compatible only with Python 2 will no longer be supported. ## Owner Name: Kalev Lember, Frank Dana Email: klem...@redhat.com, ferd...@gmail.com Release notes owner: ## Detailed Description The nautilus-python package allows Nautilus extensions to be written in the Python scripting language. In Fedora releases up to and including Fedora 29, these extensions were executed in a Python 2 environment. With the general move to Python 3 as Fedora's default Python runtime and the impending deprecation of Python 2, nautilus-python will execute extension code in a Python 3 context. Compatibility with Python 3 will be required for all Python-based Nautilus extensions. (Note: In Fedora 28 the nautilus-python package was named python2-nautilus. For Fedora 29 the name has been reverted to nautilus-python to better indicate its status as a Nautilus component.) ## Benefit to Fedora In addition to eliminating nautilus-python's direct dependency on Python 2, this change will remove all Python-based Nautilus extensions from the list of Fedora components which still require the legacy Python 2 interpreter (which has been deprecated, and is slated for removal). It will allow us to ensure that all Python-based Nautilus extensions still in use are fully compatible with Python 3. ## Scope Proposal owners: Build nautilus-python with Python 3 support and deploy. 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) ## Upgrade/compatibility impact N/A (not a System Wide Change) ## How To Test Launch the Nautilus file manager and verify that any functionality provided by Python-based extensions is still available. ## User Experience As long as Python 3 compatibility is verified for all Nautilus Python extensions, users will see no impact from this change. If any extensions are not compatible with Python 3 and must be removed, users may notice loss of certain functionality from Nautilus. ## Dependencies Any Nautilus extensions which use nautilus-python will have to be checked for Python 3 compatibility. Repackaging should not be necessary, as the nautilus-python dependency Required by those packages will be carried forward to Python 3 builds. The list of packages in the Fedora 29 repos which depend on nautilus-python is, as of 2018-11-08: kde-connect-nautilus nautilus-font-manager nautilus-pastebin nautilus-phatch nextcloud-client-nautilus nitroshare-extension-nautilus onionshare owncloud-client-nautilus qdigidoc-nautilus rabbitvcs-nautilus tilix-nautilus tortoisehg-nautilus ## Contingency Plan Continue shipping builds of nautilus-python based on Python 2. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 11:15 AM Neal Gompa wrote: > > On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer wrote: > > > > On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > > > > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > > > >> In other words, the "technical debt" we are trying to solve here is > > > > >> not project wide and doesn't justify slowing down the whole project > > > > >> permanently. > > > > > I completely disagree. Our release process and tooling is built on > > > > > heroism and tech debt. > > > > > > > > People working on release and people working on packages maintenance > > > > are different group - they are not disjunct, but it > > > > is not the same group. > > > > For example *I* am a maintainer of lots of packages, but the additional > > > > works because of the fedora release is about one > > > > working day per year - and it is mostly because of fedora-upgrade > > > > package. Other packages do not need so much work. I am > > > > more affected by upstream releases. > > > > > > > > Do not forget that annual releases will mean that N-1 release will > > > > implicate 24 months support for packages which will > > > > mean a much more significant impact on us-the maintaners. > > > > I'll echo what Paul says below with a +1, but I wanted to touch on > > this point a bit because it implies an assumption that the maintenance > > model remains the same even if lifecycle options change. I don't > > think that needs to be the case, nor do I think it would even be good. > > > > Of the large number of packages that you maintain, how many of them > > are critical to freeze at a specific version for a given Fedora > > release? Possibly some, but I would think across the distribution it > > would not be a huge number. So if there is no essential need to > > freeze them at a specific version, why would you want to maintain the > > packages *separately* for each release? That sounds like extra work > > for no benefit. If we instead take a maintenance approach that you > > maintain package foo and it is built for all releases, then you only > > really need to maintain it in a singular instance. > > > > Today that is something that can be accomplished with modularity, but > > I would suggest that we look at stream branching as a solution even > > for regular packages. So you wouldn't have fc22-fc32 branches under > > package foo. You'd have foo/stream- and you could build that > > wherever you'd like. Couple that with automated CI testing and I > > believe you actually decrease your maintenance burden while increasing > > your quality. > > > > There are many details that would need to be worked out and I don't > > want to trivialize them, but I do want to at least get people thinking > > about it in the long term. If we are going to improve the way we > > build and deliver our operating system, we shouldn't assume we can do > > that without changing the way we maintain it either. > > > > We can change this _today_, actually. fedpkg supports an in-repo > config file to specify distro targets to push whenever running `fedpkg > build`. So you could do a repo with only a master branch and have it > push to all distro targets enabled for the repo at once. This is > probably a useful optimization for the overwhelming majority of > packages held by packagers. Yep, I know :) For a lot of packages, this could be done now. I think to get the full benefits from it across the distro, we'd need to really define that platform layer so maintainers know what they can depend on, etc. > It's just not documented or available as an option for setup when you > file a repo creation request. Right. I think we should start encouraging its use. I kind of dislike using 'master' as the branch because it's ambiguous depending on how you look at it, but it's not wrong. A stream branch just provides a bit more context. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 10:57 AM Josh Boyer wrote: > > On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > > >> In other words, the "technical debt" we are trying to solve here is > > > >> not project wide and doesn't justify slowing down the whole project > > > >> permanently. > > > > I completely disagree. Our release process and tooling is built on > > > > heroism and tech debt. > > > > > > People working on release and people working on packages maintenance are > > > different group - they are not disjunct, but it > > > is not the same group. > > > For example *I* am a maintainer of lots of packages, but the additional > > > works because of the fedora release is about one > > > working day per year - and it is mostly because of fedora-upgrade > > > package. Other packages do not need so much work. I am > > > more affected by upstream releases. > > > > > > Do not forget that annual releases will mean that N-1 release will > > > implicate 24 months support for packages which will > > > mean a much more significant impact on us-the maintaners. > > I'll echo what Paul says below with a +1, but I wanted to touch on > this point a bit because it implies an assumption that the maintenance > model remains the same even if lifecycle options change. I don't > think that needs to be the case, nor do I think it would even be good. > > Of the large number of packages that you maintain, how many of them > are critical to freeze at a specific version for a given Fedora > release? Possibly some, but I would think across the distribution it > would not be a huge number. So if there is no essential need to > freeze them at a specific version, why would you want to maintain the > packages *separately* for each release? That sounds like extra work > for no benefit. If we instead take a maintenance approach that you > maintain package foo and it is built for all releases, then you only > really need to maintain it in a singular instance. > > Today that is something that can be accomplished with modularity, but > I would suggest that we look at stream branching as a solution even > for regular packages. So you wouldn't have fc22-fc32 branches under > package foo. You'd have foo/stream- and you could build that > wherever you'd like. Couple that with automated CI testing and I > believe you actually decrease your maintenance burden while increasing > your quality. > > There are many details that would need to be worked out and I don't > want to trivialize them, but I do want to at least get people thinking > about it in the long term. If we are going to improve the way we > build and deliver our operating system, we shouldn't assume we can do > that without changing the way we maintain it either. > We can change this _today_, actually. fedpkg supports an in-repo config file to specify distro targets to push whenever running `fedpkg build`. So you could do a repo with only a master branch and have it push to all distro targets enabled for the repo at once. This is probably a useful optimization for the overwhelming majority of packages held by packagers. It's just not documented or available as an option for setup when you file a repo creation request. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] tinyxml2 SONAME bump (7.x)
And it's in rawhide. On Tue, Nov 27, 2018 at 10:54 AM Igor Gnatenko wrote: > > Hi folks, > > I'm going to update tinyxml2 to 7.x later this week. > > Affected packages: > * cppcheck > * dvblinkremote > * fuse > * gazebo > * kodi (rpmfusion) > * libmediainfo > * vdr > > I'm going to rebuild all of them myself. > > --- > > Maintainers by package: > cppcheck fcami jussilehtola sgrubb > dvblinkremotemelmorabity > fuse peter spot > gazebo rmattes > libmediainfo ivanromanov vascom > vdr martinkg vpv > > Packages by maintainer: > fcami cppcheck > ivanromanov libmediainfo > jussilehtola cppcheck > martinkg vdr > melmorabity dvblinkremote > peter fuse > rmattesgazebo > sgrubb cppcheck > spot fuse > vascom libmediainfo > vpvvdr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 10:22 AM Paul Frields wrote: > > On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > > >> In other words, the "technical debt" we are trying to solve here is > > >> not project wide and doesn't justify slowing down the whole project > > >> permanently. > > > I completely disagree. Our release process and tooling is built on > > > heroism and tech debt. > > > > People working on release and people working on packages maintenance are > > different group - they are not disjunct, but it > > is not the same group. > > For example *I* am a maintainer of lots of packages, but the additional > > works because of the fedora release is about one > > working day per year - and it is mostly because of fedora-upgrade package. > > Other packages do not need so much work. I am > > more affected by upstream releases. > > > > Do not forget that annual releases will mean that N-1 release will > > implicate 24 months support for packages which will > > mean a much more significant impact on us-the maintaners. I'll echo what Paul says below with a +1, but I wanted to touch on this point a bit because it implies an assumption that the maintenance model remains the same even if lifecycle options change. I don't think that needs to be the case, nor do I think it would even be good. Of the large number of packages that you maintain, how many of them are critical to freeze at a specific version for a given Fedora release? Possibly some, but I would think across the distribution it would not be a huge number. So if there is no essential need to freeze them at a specific version, why would you want to maintain the packages *separately* for each release? That sounds like extra work for no benefit. If we instead take a maintenance approach that you maintain package foo and it is built for all releases, then you only really need to maintain it in a singular instance. Today that is something that can be accomplished with modularity, but I would suggest that we look at stream branching as a solution even for regular packages. So you wouldn't have fc22-fc32 branches under package foo. You'd have foo/stream- and you could build that wherever you'd like. Couple that with automated CI testing and I believe you actually decrease your maintenance burden while increasing your quality. There are many details that would need to be worked out and I don't want to trivialize them, but I do want to at least get people thinking about it in the long term. If we are going to improve the way we build and deliver our operating system, we shouldn't assume we can do that without changing the way we maintain it either. josh > Let's not get too focused on an annual release (or any specific > timeframe for longer release). I know this is something that some > people want. I understand that, and it's *possible* to do in a future > state where more people are empowered to make releases happen. But a > longer release is not the primary goal, merely something that's > possible. > > I'm more interested in a shorter release that implies less added > maintainer effort. We already put time into Rawhide, and I would like > to see that better leveraged in what we push to consumers. Right now > our branch cycle is six months, at which point we have numerous > freezes and other operations that consume a lot of manual time. They > also bottleneck our pace. > > I want to increase automation, decrease manual bottlenecks and > freezes, and spread out permissions to assemble and push out "ready" > content. I would like to optimize for a faster release, making any > slower releases possible. Those releases should be based on what the > consumers of that release need, as well as the efforts our maintainers > have available. > > -- > Paul > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: replace unclutter with unclutter-xfixes?
Hi Henrique, On Wed, Nov 28, 2018 at 08:40:29AM -0800, Henrique Martins wrote: > Unclutter seems to be an orphaned package that keeps being > rebuilt, there even is an fc30 rpm. The URL given in the > fc29 package points to a dead link on MIT. I filed a > bugzilla report on this and no one replied. the package is not maintained in Fedora anymore and going to be removed, soon. Would you be willing to maintain it in Fedora? Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Wed, Nov 28, 2018 at 7:43 AM Fabio Valentini wrote: > I think the kernel is a bad example here. It's exceedly stable across > releases, so it's probably the one component that's least problematic > to upgrade during a fedora release. The fedora kernel team is already > doing that, and they are doing an excellent job, which they definitely > deserve more praise for than they get. For me, the frequent, > well-executed stable kernel updates are one thing that positively > distinguishes fedora from other non-rolling distros. [...snip...] I wanted to offer a hearty +1 here. I have been thinking more about the optimization needed for a faster release process, which would *not* disadvantage our awesome kernel team. I wouldn't foresee, for example, that we'd freeze on a specific kernel for such a process. On the contrary, the kernel team does an *amazing* job making sure that Fedora is relevant to the upstream kernel community as much as possible. We routinely get fresh kernels with updated hardware support. I wouldn't want to see this stop. I understand the lifecycle goals theoretically also make possible a longer term release. How that would happen should be based on what its consumers need, and (maybe even more importantly) what our maintainers are able to do without each being issued a Fedora Time Turner[1]. I don't want to optimize for that case because a much shorter cycle (even with less fanfare) encourages us to pursue more automation and more contributor empowerment. * * * [1] http://harrypotter.wikia.com/wiki/Time-Turner ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
On Thu, Nov 29, 2018 at 4:47 AM Miroslav Suchý wrote: > > Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): > >> In other words, the "technical debt" we are trying to solve here is > >> not project wide and doesn't justify slowing down the whole project > >> permanently. > > I completely disagree. Our release process and tooling is built on > > heroism and tech debt. > > People working on release and people working on packages maintenance are > different group - they are not disjunct, but it > is not the same group. > For example *I* am a maintainer of lots of packages, but the additional works > because of the fedora release is about one > working day per year - and it is mostly because of fedora-upgrade package. > Other packages do not need so much work. I am > more affected by upstream releases. > > Do not forget that annual releases will mean that N-1 release will implicate > 24 months support for packages which will > mean a much more significant impact on us-the maintaners. Let's not get too focused on an annual release (or any specific timeframe for longer release). I know this is something that some people want. I understand that, and it's *possible* to do in a future state where more people are empowered to make releases happen. But a longer release is not the primary goal, merely something that's possible. I'm more interested in a shorter release that implies less added maintainer effort. We already put time into Rawhide, and I would like to see that better leveraged in what we push to consumers. Right now our branch cycle is six months, at which point we have numerous freezes and other operations that consume a lot of manual time. They also bottleneck our pace. I want to increase automation, decrease manual bottlenecks and freezes, and spread out permissions to assemble and push out "ready" content. I would like to optimize for a faster release, making any slower releases possible. Those releases should be based on what the consumers of that release need, as well as the efforts our maintainers have available. -- Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Thu, Nov 29, 2018 at 2:58 PM Gerald Henriksen wrote: > > On Thu, 29 Nov 2018 12:15:52 +, you wrote: > > >From an IoT perspective where we're looking at some features around > >security that could be cross component dependent > >(toolchain/kernel/userspace) to be unable to consume for possibly an > >18 month window, yes we rebase kernels but we need to rebase other > >components and build against those, in a stable release is a complete > >and utter disaster. > > Is it specific to the F30/31 timeframe, or is it something that could > be alleviated by instead delaying to a F31/32 delay? > > In other words, if the delay is necessary is there a better choice of > time to do it that would help to minimize the disruption to the > various Fedora communities? At the moment I don't see that changing at all from an IoT perspective. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Thu, 29 Nov 2018 12:15:52 +, you wrote: >From an IoT perspective where we're looking at some features around >security that could be cross component dependent >(toolchain/kernel/userspace) to be unable to consume for possibly an >18 month window, yes we rebase kernels but we need to rebase other >components and build against those, in a stable release is a complete >and utter disaster. Is it specific to the F30/31 timeframe, or is it something that could be alleviated by instead delaying to a F31/32 delay? In other words, if the delay is necessary is there a better choice of time to do it that would help to minimize the disruption to the various Fedora communities? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: compilation of mlt-freeworld-6.12.0 fails
Many thanks, now it works. Martin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: compilation of mlt-freeworld-6.12.0 fails
thanks for your answer, but there a new error message: /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/bin/melt + grep -vP 'mlt/avformat|libmltavformat.so' + find /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64 -type f -print0 + xargs -0 rm rm: cannot remove 'Binary file (standard input) matches'$'\n': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.xUeMnu (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.xUeMnu (%install) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: compilation of mlt-freeworld-6.12.0 fails
Oh, and I think the grep will also have to be tweaked with a -z to take
the null termination into account:
find %{buildroot} -type f -print0 | grep -vPz
"mlt/avformat|libmltavformat.so" | xargs -0 rm
On 29/11/2018 14:21, J. Randall Owens wrote:
> There are spaces in the file names, so it sees something like "Ut Video"
> and xargs parses it as meaning "Ut" and "Video". Easiest way to fix it
> is probably to change the paths to be null-terminated, by adding -print0
> to the find and -0 to the xargs, like so:
>
> find %{buildroot} -type f -print0 | grep -vP
> "mlt/avformat|libmltavformat.so" | xargs -0 rm
>
> Hope that helps; xargs isn't something I know especially well, just
> enough to be dangerous.
>
> On 29/11/2018 14:12, Martin Gansser wrote:
>> Hi,
>>
>> want to compile new mlt-freeworld-6.12.0 [1], but it fails in the %install
>> section
>>
>> ...
>> %install
>> %make_install
>> #before remove it print it to check with main mlt package
>> find %{buildroot} | grep -vP "mlt/avformat|libmltavformat.so"
>> # remove all execept avformat (ffmpeg part)
>> find %{buildroot} -type f | grep -vP "mlt/avformat|libmltavformat.so" |
>> xargs rm
>> find %{buildroot} -type l -delete
>> find %{buildroot} -type d -empty -delete
>> ..
>>
>> The error message is:
>>
>> + find /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64
>> -type f
>> + xargs rm
>> + grep -vP 'mlt/avformat|libmltavformat.so'
>> rm: cannot remove
>> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/lossless/Ut':
>> No such file or directory
>> rm: cannot remove 'Video': No such file or directory
>> rm: cannot remove
>> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Quicktime':
>> No such file or directory
>> rm: cannot remove 'Animation': No such file or directory
>> rm: cannot remove
>> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Ut':
>> No such file or directory
>> rm: cannot remove 'Video': No such file or directory
>> error: Bad exit status from /var/tmp/rpm-tmp.KGk9Ye (%install)
>>
>> [1] https://martinkg.fedorapeople.org/Packages/test/mlt-freeworld.spec
>>
>> Thanks
>> Martin
>
--
J. Randall Owens | http://www.GhiaPet.net/
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: compilation of mlt-freeworld-6.12.0 fails
There are spaces in the file names, so it sees something like "Ut Video"
and xargs parses it as meaning "Ut" and "Video". Easiest way to fix it
is probably to change the paths to be null-terminated, by adding -print0
to the find and -0 to the xargs, like so:
find %{buildroot} -type f -print0 | grep -vP
"mlt/avformat|libmltavformat.so" | xargs -0 rm
Hope that helps; xargs isn't something I know especially well, just
enough to be dangerous.
On 29/11/2018 14:12, Martin Gansser wrote:
> Hi,
>
> want to compile new mlt-freeworld-6.12.0 [1], but it fails in the %install
> section
>
> ...
> %install
> %make_install
> #before remove it print it to check with main mlt package
> find %{buildroot} | grep -vP "mlt/avformat|libmltavformat.so"
> # remove all execept avformat (ffmpeg part)
> find %{buildroot} -type f | grep -vP "mlt/avformat|libmltavformat.so" | xargs
> rm
> find %{buildroot} -type l -delete
> find %{buildroot} -type d -empty -delete
> ..
>
> The error message is:
>
> + find /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64
> -type f
> + xargs rm
> + grep -vP 'mlt/avformat|libmltavformat.so'
> rm: cannot remove
> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/lossless/Ut':
> No such file or directory
> rm: cannot remove 'Video': No such file or directory
> rm: cannot remove
> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Quicktime':
> No such file or directory
> rm: cannot remove 'Animation': No such file or directory
> rm: cannot remove
> '/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Ut':
> No such file or directory
> rm: cannot remove 'Video': No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.KGk9Ye (%install)
>
> [1] https://martinkg.fedorapeople.org/Packages/test/mlt-freeworld.spec
>
> Thanks
> Martin
--
J. Randall Owens | http://www.GhiaPet.net/
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
compilation of mlt-freeworld-6.12.0 fails
Hi,
want to compile new mlt-freeworld-6.12.0 [1], but it fails in the %install
section
...
%install
%make_install
#before remove it print it to check with main mlt package
find %{buildroot} | grep -vP "mlt/avformat|libmltavformat.so"
# remove all execept avformat (ffmpeg part)
find %{buildroot} -type f | grep -vP "mlt/avformat|libmltavformat.so" | xargs rm
find %{buildroot} -type l -delete
find %{buildroot} -type d -empty -delete
..
The error message is:
+ find /home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64 -type
f
+ xargs rm
+ grep -vP 'mlt/avformat|libmltavformat.so'
rm: cannot remove
'/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/lossless/Ut':
No such file or directory
rm: cannot remove 'Video': No such file or directory
rm: cannot remove
'/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Quicktime':
No such file or directory
rm: cannot remove 'Animation': No such file or directory
rm: cannot remove
'/home/martin/rpmbuild/BUILDROOT/mlt-freeworld-6.12.0-1.fc29.x86_64/usr/share/mlt/presets/consumer/avformat/alpha/Ut':
No such file or directory
rm: cannot remove 'Video': No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.KGk9Ye (%install)
[1] https://martinkg.fedorapeople.org/Packages/test/mlt-freeworld.spec
Thanks
Martin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora Hardware portal
Hi, The Linux-Hardware.org database has been divided recently into a set of databases, one per each Linux distro. The one for Fedora is available at: https://linux-hardware.org/?d=Fedora Everyone can contribute to the database with the help of https://github.com/linuxhw/hw-probe (various packages are available: AppImage, Snap, Flatpak, Docker, RPM, etc.). The tool is intended to simplify collecting of hardware info and logs necessary for investigating hardware related problems. You need to execute only one simple command to collect all system logs at once: sudo hw-probe -all -upload Hardware failures are highlighted in the collected logs (important SMART attributes, errors in dmesg and xorg.log, etc.). Also it's handy to search for particular hardware configurations in the community and review errors in logs to check operability of devices on board (for some devices this is done automatically by hw-probe — see statuses of devices in your probe). Hardware stats and raw data are dumped to Github repositories: https://github.com/linuxhw Enjoy! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Changing nsswitch.conf on a running system (was Re: /etc/nssswitch.conf is supposed to be a symlink now?)
Ray Strode wrote: > (defer until next offline update?) That would be never on many systems. Most users using command-line DNF and all users using plasma-pk-updates or dnfdragora never do offline updates by design. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/28/18 11:22 PM, Jan Pokorný wrote: On 28/11/18 11:48 -0400, Robert Marcano wrote: There is another thing I found wrong. The backed up nsswitch.conf has these lines appended (ckey and incomplete aliases line) after the real end of the original file (aliases: files): aliases:files ckey: files aliases:fil I can repeat this bad backup indefinitely: 1) check current nsswitch has no such lines 2) run authselect select --force ... 3) backup at /usr/lib/authselect/backup//nsswitch has the appended lines Have observed a similar corruption (with explicitly named backup, but it's likely of no significance) yesterday with Rawhide, but at that time it was least of my problems (see dbus-broker [vs. systemd-nspawn] in a slightly older thread, nsswitch.conf/pam was actually a false start based on some messages in journal I thought might be related). Buffer handling bug? This is a bug. I opened upstream issue: https://github.com/pbrezina/authselect/issues/123 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/28/18 3:59 PM, Henrique Martins wrote: My configuration is different, just take as FYI. ... it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. It is still a file and not a link on my f29, which has been dnf-upgraded for I can't remember how many revisions. I did edit nsswitch.conf and remove all mdns references, as I run a local DNS server. Yes, authselect does not overwrite any existing configuration so if you just upgrade it was never invoked. # authselect check It replies with Current configuration is valid. on my system. authselect-1.0.2-1.fc29.x86_64 glibc-2.28-20.fc29.x86_64 nss-mdns-0.14.1-2.fc29.x86_64 systemd-libs-239-6.git9f3aed1.fc29.x86_64 I have the same rpms. Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). I have avahi/bonjour disabled, thus can't check for this. I do have a network printer, on socket://. -- Henrique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/28/18 6:35 PM, Richard W.M. Jones wrote: On Wed, Nov 28, 2018 at 05:02:17PM +0100, Reindl Harald wrote: Am 28.11.18 um 15:45 schrieb Florian Weimer: * Richard W. M. Jones: Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). We're down a rabbit hole where it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we ship it. If find out which packages replaces our configuration with a symbolic link, please file a bug against that package. If they want to take over /etc/nsswitch.conf, this is negotiable, but it needs coordination with the glibc package. and that's why i do "chattr +i /etc/nsswitch.conf" and "chattr +i /etc/resolv.conf" for year - guys stop mangle around in /etc - this is admin area and way too often the mdns crap was added unasked or "mysql" for nss-mysql touched in the past years finding you perfectly working config in a damned .bak file everything which touchs /etc at updates is broken by design Yes I've been doing chattr +i /etc/resolv.conf for a very long time. Updates to systemd or nss-mdns breaks generated authselect configuration, because they rewrite nsswitch.conf. This is something we know about and trying to find the best way for both parties to fix it. However in the case of /etc/nsswitch.conf, changing it (with the cooperation of glibc of course) to be a symlink seems reasonable. What I'm (still) missing is what's the actual plan? What should things look like? At this moment, if you install system without any kickstart, anaconda invokes authselect (sssd profile, before it did the same thing but with authconfig). If you use kickstart you can choose to not call authselect and stick with glibc/pam defaults. So basically, you can choose to use authselect and you can choose not to use it. At any time, you can just manually update any file you want to, "authselect check" will complain but the only implication is that you will be required to use "authselect select $profile --force" to go back to authselect configuration. As I said in the other mail, authselect would like to take ownership of nsswitch.conf and pam in the future, but we need to first solve its issues so no action was taken in this area yet. Rich. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/29/18 12:59 PM, Robert Marcano wrote: On 11/29/18 7:46 AM, Pavel Březina wrote: On 11/28/18 4:37 PM, Robert Marcano wrote: On 11/28/18 11:20 AM, Ralf Corsepius wrote: On 11/28/18 3:45 PM, Florian Weimer wrote: * Richard W. M. Jones: Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). We're down a rabbit hole where it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we ship it. If find out which packages replaces our configuration with a symbolic link, It's authselect. # rpm -qV glibc L c /etc/nsswitch.conf # ls -l /etc/nsswitch.conf lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf My clean F29 installation had no such symbolic link, has to "authselect select --force ..." to force the creation of the link. The non symlinked /etc/nsswitch.conf even had the header: # Do not modify this file manually. # If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. So, was it generated at some point by authselect and not as symbolic link? Note: Today I got new update for authselect (1.0.2-1.fc29) Authselect did not take over default nsswitch.conf (that comes from glibc) and pam settings (from pam). Installation of authselect package it self does not make any changes, you need to invoke the authselect command somehow -- anaconda invokes it automatically during installation without kickstart. If you see this comment in nsswitch.conf and yet nsswitch.conf is a file, not a symlink to /etc/authselect I suppose you are using some sort of snapshot? The presence of the comments tell me that probably authselect was properly called by anaconda as you say, but some other package decided to modify nsswitch (The only external repository I have is VS Code). Will try to test on a new VM reinstalling my current package list in order to try to detect what or why. It was probably systemd or nss-mdns. This is a known issue and I am in touch with their maintainers to solve this. Also, see the other thread "nsswitch.conf: list of module packages that enables themselves". ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Improving the compose: leave the current compose in place
On Tue, Nov 27, 2018 at 7:01 PM Paul Frields wrote: > > On Tue, Nov 27, 2018 at 9:59 AM Owen Taylor wrote: > > A lot of discussion about improving the compose process seem to end up > > with a "reality check" - that ideas have already been tried but don't > > work because of requirements a) b) c) d). You can't have the pony, but > > maybe if a lot of effort is put into it, you can have a faster rocking > > horse. > > > > If want to fundamentally improve the Fedora workflow we need compose > > ponies, we can't just have rocking horses! > > > > Perhaps it would make sense to leave the current 8-10 hour compose in > > place for the forseeable future, and work on a new system in parallel > > where the primary constraint is to be as fast as possible. Hopefully > > most problems with the slow compose will get sorted out in the fast > > composes, and the slow compose will become more reliable. Perhaps in a > > distant future, we can make the new system do everything > > Indeed, this is basically the investigation I've proposed. I also think > > > I don't know what the system would look like exactly, but you could > > imagine things like: > > > > * Composed of several micro-composes (micro-compose-services?) to > > avoid blocking on everything completing successfully. > > > > * Able to do speculative composes for CI > > > > * Either x86_64-only, or with decoupled architectures so that we can > > throw x86_64 hardware (or cloud resources) at it, and make it super > > fast. > > > > * No IO /mnt/koji during the compose - having a big network share be > > central to the process creates a performance bottleneck, makes it hard > > to move to the cloud, and potentially adds a lot of "noise" to > > figuring out what is going on where things are slow because of some > > other entirely different thing is goin gon. > > > > Add your own bullet points :-) > > I would like to redefine a couple working assumptions: > > * Big tools are unwieldy and inevitably silo knowledge. The people > behind them are often smart, hard-working, and care about great > results. But bedrock FOSS principles say we get more value from > rapidly iterating tools to which many people can/do contribute. We > should see if we can avoid big tools that solve everything. > > * Reproducibility is something we can better enforce at development > time than use time. It's pretty easy to pick one or more git heads at > a certain time (for a tool, a containerized environment, etc.). Let's > not get one hand tied behind our back at the outset via outmoded > assumptions. That is not entirely true. A level of reproducibility is also at build time based on versions of other packages that the package has been built against. The versions of components that another component is built/composed against will greatly affect the reproducibility of a component and that information is not in git. Peter ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Tue, Nov 27, 2018 at 3:39 PM Owen Taylor wrote: > > One of the key parts of making a decision to delay/skip F31 is > figuring out, ahead of the decision, what the expected experience is > for users and packagers. Does F30 have normal stability, or do we try > to keep users happy by moving things forward with ad-hoc updates and > cross-our-fingers and hope nothing breaks? > > I tend to think about this in terms of GNOME - would we rebase to > GNOME 3.34 in the middle of F30 or not? But there's a lot of other > pieces of software where similar considerations apply: container > tools, cockpit, NetworkManager, etc. This is basically the problem I have with the work we're doing in IoT. The basically will make me re-evaluate if IoT is now worth doing at all in Fedora or whether I am now better off focusing my efforts elsewhere. Going back to the F-20/F21 cycle we had major issues with the year gap in releases for ARM64. We were waiting on toolchain enhancements that landed about around a week (exact time-frames allude me) after Fedora 20 branched, which meant ultimately we had to wait 18 months from branch to a stable release for end users to actually be able to consume these enhancements, there was another one, I don't remember exact component details, that due to upstream timing as well basically meant it was longer than that more than that to consume. For reference Fedora 20 branched on 2013-08-20 [1] and Fedora 21 was released on 2014-12-09. From an IoT perspective where we're looking at some features around security that could be cross component dependent (toolchain/kernel/userspace) to be unable to consume for possibly an 18 month window, yes we rebase kernels but we need to rebase other components and build against those, in a stable release is a complete and utter disaster. Unfortunately this is not a problem that modularity is capable of solving and IoT doesn't have the cycles to even begin to consider dealing with that at the lower levels. Sure, it would be fine for IoT app stacks, such as noodejs, in a container but not below that. Peter [1] https://fedoraproject.org/wiki/Releases/20/Schedule [2] https://en.wikipedia.org/wiki/Fedora_(operating_system)#Releases ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/28/18 3:52 PM, Tom Hughes wrote: On 28/11/2018 14:45, Florian Weimer wrote: * Richard W. M. Jones: Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). We're down a rabbit hole where it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we ship it. That's true but... If find out which packages replaces our configuration with a symbolic link, please file a bug against that package. If they want to take over /etc/nsswitch.conf, this is negotiable, but it needs coordination with the glibc package. ...as I understood it under the old authconfig regime the glibc installed version was overwritten by the authconfig generated version as part of the install? and I thought authselect was supposed to have taken over that role. True. At this point, authselect only replaces authconfig. The difference is that authconfig only created symlinks for pam configuration files owned by pam (e.g. /etc/pam.d/system-auth -> system-auth-ac), authselect also creates symlink for nsswitch.conf owned by glibc for clarity. It is not done by the package installation, it must be called. Anaconda calls it instead of authconfig automatically when there is no kickstart provided. We do have future plans to take over these files completely, but we did not start this discussion with neither glibc nor pam since there are still things that needs to be solved before this can happen. Pavel. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does extended F30 cycle mean for F29?
No, we did NOT do that. A quick search on the devel list archives shows that F19 was released in July 2013: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SSLJL6ZJC7M7TAOPNHJY7UAS7MA66PMR/ ...and EOL'd on in January 2015: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OKQNYF6AL5WVHIQB7G3MLIYFUXO37U2Z/ ...which gives F19 a 19-month support window. I wasn't a packager back then, so it may be easy for me to say this, but either way - I agree with Kevin Koffer. The current Release Life Cycle states that release N is supported for one month after N+2 is released. This is a promise we make to our users, and breaking this promise would be a very nasty thing to do. If we arrive at the conclusion that we don't have the manpower to extend F29's support window past the usual 13 months, then I argue that we should NOT prolong the F30 development cycle. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/29/18 7:46 AM, Pavel Březina wrote: On 11/28/18 4:37 PM, Robert Marcano wrote: On 11/28/18 11:20 AM, Ralf Corsepius wrote: On 11/28/18 3:45 PM, Florian Weimer wrote: * Richard W. M. Jones: Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). We're down a rabbit hole where it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we ship it. If find out which packages replaces our configuration with a symbolic link, It's authselect. # rpm -qV glibc L c /etc/nsswitch.conf # ls -l /etc/nsswitch.conf lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf My clean F29 installation had no such symbolic link, has to "authselect select --force ..." to force the creation of the link. The non symlinked /etc/nsswitch.conf even had the header: # Do not modify this file manually. # If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. So, was it generated at some point by authselect and not as symbolic link? Note: Today I got new update for authselect (1.0.2-1.fc29) Authselect did not take over default nsswitch.conf (that comes from glibc) and pam settings (from pam). Installation of authselect package it self does not make any changes, you need to invoke the authselect command somehow -- anaconda invokes it automatically during installation without kickstart. If you see this comment in nsswitch.conf and yet nsswitch.conf is a file, not a symlink to /etc/authselect I suppose you are using some sort of snapshot? The presence of the comments tell me that probably authselect was properly called by anaconda as you say, but some other package decided to modify nsswitch (The only external repository I have is VS Code). Will try to test on a new VM reinstalling my current package list in order to try to detect what or why. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: /etc/nssswitch.conf is supposed to be a symlink now?
On 11/28/18 4:37 PM, Robert Marcano wrote: On 11/28/18 11:20 AM, Ralf Corsepius wrote: On 11/28/18 3:45 PM, Florian Weimer wrote: * Richard W. M. Jones: Trying to track down a bug in IPP printing (https://bugzilla.redhat.com/show_bug.cgi?id=1653276). We're down a rabbit hole where it seems that in Fedora 29 /etc/nssswitch.conf ought to be a symlink. This machine has been upgraded from F28 and this is not the case. AFAIK I have never edited the file. /etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we ship it. If find out which packages replaces our configuration with a symbolic link, It's authselect. # rpm -qV glibc L c /etc/nsswitch.conf # ls -l /etc/nsswitch.conf lrwxrwxrwx. 1 root root 29 Nov 18 04:58 /etc/nsswitch.conf -> /etc/authselect/nsswitch.conf My clean F29 installation had no such symbolic link, has to "authselect select --force ..." to force the creation of the link. The non symlinked /etc/nsswitch.conf even had the header: # Do not modify this file manually. # If you want to make changes to nsswitch.conf please modify # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'. So, was it generated at some point by authselect and not as symbolic link? Note: Today I got new update for authselect (1.0.2-1.fc29) Authselect did not take over default nsswitch.conf (that comes from glibc) and pam settings (from pam). Installation of authselect package it self does not make any changes, you need to invoke the authselect command somehow -- anaconda invokes it automatically during installation without kickstart. If you see this comment in nsswitch.conf and yet nsswitch.conf is a file, not a symlink to /etc/authselect I suppose you are using some sort of snapshot? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposal: Move to an annual platform release starting at F30
Dne 27. 11. 18 v 17:04 Josh Boyer napsal(a): >> In other words, the "technical debt" we are trying to solve here is >> not project wide and doesn't justify slowing down the whole project >> permanently. > I completely disagree. Our release process and tooling is built on > heroism and tech debt. People working on release and people working on packages maintenance are different group - they are not disjunct, but it is not the same group. For example *I* am a maintainer of lots of packages, but the additional works because of the fedora release is about one working day per year - and it is mostly because of fedora-upgrade package. Other packages do not need so much work. I am more affected by upstream releases. Do not forget that annual releases will mean that N-1 release will implicate 24 months support for packages which will mean a much more significant impact on us-the maintaners. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] Rawhide buildroot now has glibc-minimal-langpack instead
That is huge. Thx a lot. Vít Dne 28. 11. 18 v 20:33 Igor Gnatenko napsal(a): > Hello, > > the removal of glibc-all-langpacks from the buildroot[0] is done. > Standard buildroot has decreased from 445 to 237 megabytes in > installed size ;) > > Before: > DEBUG util.py:439: Install 146 Packages > DEBUG util.py:439: Total download size: 86 M > DEBUG util.py:439: Installed size: 445 M > > After: > DEBUG util.py:439: Install 146 Packages > DEBUG util.py:439: Total download size: 61 M > DEBUG util.py:439: Installed size: 237 M > > All thanks go to zbyszek and mboddu :champagne:! > > [0]https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
