Re: Co-maintainers for my ham packages
Richard, as I am no longer able to run or test the above Ham packages, I will remove myself from them. I've reassigned several open bug reports to you (you were already on cc and recently addressed one issue with sdrpp - thank you!). Thanks, Matt N5MLD On Sun, Jun 5, 2022 at 9:22 PM Matt Domsch wrote: > Blaise, I appreciate your offer. I regret I won't have time in the next > several months to be a packaging Elmer myself. > > Richard, I've added you as an admin to each of these. Note that kni also > is an admin for SoapySDR and swt2c is an admin for CubicSDR. > > Thanks, > Matt N5MLD > > On Thu, May 26, 2022 at 10:24 PM Blaise Pabon wrote: > >> Well, I have been wanting to become a fedora packager for a while and I >> have some of that hardware somewhere around here. >> I might need an Elmer to help me through the first iteration. >> >> -Blaise >> >> On Thu, May 26, 2022 at 6:28 PM Richard Shaw >> wrote: >> >>> On Thu, May 26, 2022 at 1:59 PM Matt Domsch wrote: >>> >>>> Due to an impending move to NYC and related downsizing of my house into >>>> a 2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't >>>> be able to test any of the Fedora packages I maintain with actual >>>> hardware. Would anyone be interested in maintaining or co-maintaining >>>> these? >>>> >>>> - direwolf - Sound Card-based AX.25 TNC >>>> - CubicSDR - Cross-Platform Software-Defined Radio Panadapter >>>> - liquid-dsp - Digital Signal Processing Library for Software-Defined >>>> Radios >>>> - sdrpp - SDRPlusPlus bloat-free SDR receiver software >>>> - SoapySDR - A Vendor Neutral and Platform Independent SDR Support >>>> Library >>>> - soapy-rtlsdr - SoapySDR module for RTL-SDR hardware >>>> >>> >>> Whichever ones aren't taken, just give them to me (or orphan them and >>> let me know). >>> >>> But if someone wants them, please take them! I need more packages like I >>> need a new hole in my head. :) >>> Thanks, >>> Richard >>> K5OIM >>> ___ >>> devel mailing list -- devel@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >>> Do not reply to spam on the list, report it: >>> https://pagure.io/fedora-infrastructure >>> >> >> >> -- >> LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora >> <https://www.quora.com/profile/Blaise-Pabon> | Github >> <https://github.com/blaisep> >> “If you want to go fast, go alone. If you want to go far, go together.” >> --African >> proverb >> > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Co-maintainers for my ham packages
Blaise, I appreciate your offer. I regret I won't have time in the next several months to be a packaging Elmer myself. Richard, I've added you as an admin to each of these. Note that kni also is an admin for SoapySDR and swt2c is an admin for CubicSDR. Thanks, Matt N5MLD On Thu, May 26, 2022 at 10:24 PM Blaise Pabon wrote: > Well, I have been wanting to become a fedora packager for a while and I > have some of that hardware somewhere around here. > I might need an Elmer to help me through the first iteration. > > -Blaise > > On Thu, May 26, 2022 at 6:28 PM Richard Shaw wrote: > >> On Thu, May 26, 2022 at 1:59 PM Matt Domsch wrote: >> >>> Due to an impending move to NYC and related downsizing of my house into >>> a 2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't >>> be able to test any of the Fedora packages I maintain with actual >>> hardware. Would anyone be interested in maintaining or co-maintaining >>> these? >>> >>> - direwolf - Sound Card-based AX.25 TNC >>> - CubicSDR - Cross-Platform Software-Defined Radio Panadapter >>> - liquid-dsp - Digital Signal Processing Library for Software-Defined >>> Radios >>> - sdrpp - SDRPlusPlus bloat-free SDR receiver software >>> - SoapySDR - A Vendor Neutral and Platform Independent SDR Support >>> Library >>> - soapy-rtlsdr - SoapySDR module for RTL-SDR hardware >>> >> >> Whichever ones aren't taken, just give them to me (or orphan them and let >> me know). >> >> But if someone wants them, please take them! I need more packages like I >> need a new hole in my head. :) >> Thanks, >> Richard >> K5OIM >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > > > -- > LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora > <https://www.quora.com/profile/Blaise-Pabon> | Github > <https://github.com/blaisep> > “If you want to go fast, go alone. If you want to go far, go together.” > --African > proverb > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Co-maintainers for my ham packages
Due to an impending move to NYC and related downsizing of my house into a 2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't be able to test any of the Fedora packages I maintain with actual hardware. Would anyone be interested in maintaining or co-maintaining these? - direwolf - Sound Card-based AX.25 TNC - CubicSDR - Cross-Platform Software-Defined Radio Panadapter - liquid-dsp - Digital Signal Processing Library for Software-Defined Radios - sdrpp - SDRPlusPlus bloat-free SDR receiver software - SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library - soapy-rtlsdr - SoapySDR module for RTL-SDR hardware Thanks, Matt N5MLD ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: koji / doxygen / mock failures making directories sometimes
Success, thank you Vitaly. On Sun, Aug 22, 2021 at 9:10 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 22/08/2021 15:28, Matt Domsch via devel wrote: > > I say intermittent because it succeeded completely during a > > scratch-build, and then failed on subsequent koji builds on different > > builders (failed on 2 builders in one run, then failed on one different > > builder on another run). > > It looks like a race condition. Try to build in 1 thread: > > %global _smp_build_ncpus 1 > > -- > Sincerely, >Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
koji / doxygen / mock failures making directories sometimes
Building opendbx, I'm seeing intermittent failures creating an output directory. From build.log during the Doxygen portion of the build: error: Could not create output directory /builddir/build/BUILD/opendbx-1.4.6/doc/html I say intermittent because it succeeded completely during a scratch-build, and then failed on subsequent koji builds on different builders (failed on 2 builders in one run, then failed on one different builder on another run). https://koji.fedoraproject.org/koji/taskinfo?taskID=74312216 (scratch-build succeeded) https://koji.fedoraproject.org/koji/taskinfo?taskID=74313500 (failed armv7hl and x86_64) https://koji.fedoraproject.org/koji/taskinfo?taskID=74313435 (failed i686) Advice wanted. Thanks, Matt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Upgrading SoapySDR to 0.8.1
Jaroslav - you and I each have a Soapy hardware package (soapy-uhd and soapy-rtlsdr respectively) in Fedora. Doug Mitchell has packaged up soapy-airspy and soapy-hackrf in Copr and should begin the review process for those soon. SoapySDR 0.8.1 is available as the latest upstream. I've built it, these 4 hardware plugins, and CubicSDR, against it for a Fedora 34 system, and while I only have an rtlsdr hardware, it appears to be working. I'd like to push 0.8.1 into rawhide and rebuild soapy-uhd, soapy-rtlsdr, and CubicSDR against it then. Doug - the spec file lines that reference modules0.7 need to be changed to modules* so the packages can be built against either base version. Jaroslav's soapy-uhd package already supports this. Upstream commit log: https://github.com/pothosware/SoapySDR/compare/soapy-sdr-0.7.2...soapy-sdr-0.8.1 Thoughts? Thanks, Matt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Running rawhide mockbuild on Fedora 33 fails with GPG check
One problem is mock doesn't have the right GPG key for rawhide at this point. It's easy to fix. # ls -al /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-* ... -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary -rw-r--r--. 1 root root 1668 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary lrwxrwxrwx. 1 root root 29 Jul 26 07:59 /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary -> RPM-GPG-KEY-fedora-35-primary # cd /usr/share/distribution-gpg-keys/fedora/ # rm RPM-GPG-KEY-fedora-rawhide-primary rm: remove symbolic link 'RPM-GPG-KEY-fedora-rawhide-primary'? y # ln -s RPM-GPG-KEY-fedora-36-primary RPM-GPG-KEY-fedora-rawhide-primary Furthermore, /etc/mock/templates/fedora-rawhide.tpl has hard-coded version 35 which needs to bump to 36. There's a second problem, that fedora-review claims to take a --mock-config= option, but it seems not to work. It always wants to build for rawhide. Thanks, Matt On Sun, Aug 15, 2021 at 7:06 AM Otto Urpelainen wrote: > Sérgio Basto kirjoitti 15.8.2021 klo 3.12: > > Hi, > > > > I'm seeing the same problem, for a quick fix, we need update > > /etc/mock/templates/fedora-rawhide.tpl line 12 with > > config_opts['releasever'] = '36', as reference [1] ... > > > > We need a new mock-core-configs package with configurations for "Fedora > > 35 branched" some work in progress here [2] > > Having followed the Fedora process for some time now, I have noticed > that issues of this kind happen at every branching. > > I wonder if more things could work like dist-git branches already do, > where rawhide is always rawhide, branching does not affect it, and > branched releases receive a new configuration at the moment of > branching? Opposed to that, Mock and other places follow a model where > rawhide is Fedora N+1 and branching means a) reconfiguring rawhide as > Fedora N+2 and b) creating a new configuration for the actual Fedora > N+1. The need to do a) means that rawhide easily breaks when branching > occurs. > > When you branch B off from A, it is understandable that B won't be > completely functional until the branching is completed. But there should > be no reason for A to stop working, simply because there should not be > any reason to modify A at all. > > I am not very familiar with Mock internals, but I suppose that Mock is > *not* one of the places where such change of approach would be easy. I > suppose it has a relation with dist tags, and if you changed rawhide's > dist tag from 'fc(n+1)' to 'rawhide', you should probably do mass > rebuild only after branching to get dist tag right in the branched > release. And you would probably have to consider a lot of other things, > too. > > But there are also places where it would be easy to avoid breakage > simply calling rawhide, 'rawhide': At least the thing where a Toolbox > container build from f34 image can be either actually Fedora 34 or > Fedora Rawhide, depending on things [1]. > > [1]: https://github.com/containers/toolbox/issues/722 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
unretiring CubicSDR from rawhide
CubicSDR provides a panadapter experience, showing the RF spectrum for the band you have selected. I use it with my Yaesu FTDX3000D radio frequently, along with an inexpensive RTL-SDR adapter. I've prepared CubicSDR to be unretired from Fedora rawhide (F33), now that wxGTK 3.1 is available in rawhide. Package review ticket here: https://bugzilla.redhat.com/show_bug.cgi?id=1821987 Reviews appreciated. Thanks, Matt N5MLD ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Potential module for wxGTK3.1 unstable series / Audacity
CubicSDR (Ham Radio panadapter spectrum visualizer using inexpensive receivers) upstream moved to wxWidgets 3.1 over 18 months ago. While I had some success in backing out some specific changes that let it compile with wxGTK 3.0, upstream has moved on considerably since then, making extensive use of wxGLAttributes in various calls, which is far harder to back out. Furthermore, upstream won't look at issues on older releases. [1] Lending some urgency are multiple abrt-reported segfaults, including on F30 and F31 [2]. Either a wxGTK 3.1 package in the main repos, or in copr, will be needed to make this package usable again. [1] https://github.com/cjcliffe/CubicSDR/issues/726 [2] https://retrace.fedoraproject.org/faf/summary/?component_names=CubicSDR&daterange=2019-01-01%3A2019-12-03&resolution=m -Matt ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: > On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: > > On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: > > > The challenge here is that because struct netdev is initialized to all > > > zeros, code that consumes dev_id can't tell the difference between a > > > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a > > > default (unset) value of 0. I think the only solution here is to make > > > sure the kernel drivers, if they need to set it, always set this > > > non-zero, so udev, seeing a non-zero value, knows it's a valid value > > > to use. > > > > These seem to be the 4 drivers currently setting dev_id: > > > > drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: > > adap->port[i]->dev_id = j; > > drivers/net/ethernet/freescale/fec.c: fep->dev_id = dev_id++; > > Look up a few lines: > > /* setup board info structure */ > fep = netdev_priv(ndev); > > fep is not a pointer to the net_device, but to the private device > structure. This is why I didn't include it in the list. Good catch. > > drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; > > drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = > > EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; > > > > of these, both the mlx4 and siena drivers set them starting at 0. I > > think the fec driver might be doing so as well, but it's not as > > obvious. I'm pretty sure cxgb4 starts numbering at 1 just from > > reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be > > comfortable relying on the value of dev_id. > > I agree it looks like some cleanup is needed due to the inconsistency. > > This is still only an issue when a single function supports multiple > ethernet devices, right? I believe so, yes. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: > On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: > > On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: > > > Matt Domsch (matt_dom...@dell.com) said: > > > > On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: > > > > > > If we can solve the installtime naming convention choice to not > > > > > > eliminate biosdevname, be able to disable systemd/udevd naming, and > > > > > > have the default be possible on a per-system-vendor basis, and solve > > > > > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > > > > > > proposal. Without fixing these shortcomings though, my customers > > > > > > will > > > > > > have a fit at me. > > > > > > > > > > If you're agreeing that biosdevname should be limited to type9/type41 > > > > > (if I'm reading you right), and if the systemd/udev names still use > > > > > those > > > > > fields, what parts of biosdevname are you still requiring? The actual > > > > > namespace used, or something else? > > > > > > > > I'd prefer if we didn't force users through another namespace change. > > > > I took a lot of flack for changing the namespace once. From their > > > > perspective, it's still udev doing the renaming, only now the code > > > > moved from a udev helper into udev itself. > > > > > > True; the users likely don't care other than how they enable/disable it. > > > > > > > I'd like to see the SR-IOV & NPAR devices handled. Those aren't > > > > represented in type9/type41, and their commonplace on Dell systems. > > > > > > > > I'd like to see the Dell-specific PCI VPD-R code from biosdevname > > > > included in udev, as that's used to map multi-port devices to port > > > > numbers. Those aren't represented in type9/type41, and they're > > > > commonplace on Dell systems. > > > > > > OK. > > > > > > > I'd like to see kernel driver work to be sure every multi-port driver > > > > with the same PCI b/d/b/f sets dev_id. That isn't necessarily true > > > > today, which makes it hard to trust. biosdevname needs this too, > > > > until such a time as it's dead. > > > > > > Do we have a list of these, or is it a matter of doing a driver audit? > > > CC'ing gospo. > > > > (Thanks, Bill, though I've been following this thread as I am on the > > list). > > > > Right now almost no drivers actually set dev_id. In fact mlx4_en, > > cxgb4, and sfc seem to be the only ones right now. If we feel like this > > a requirement there will be work on the kernel side to add this. > > The challenge here is that because struct netdev is initialized to all > zeros, code that consumes dev_id can't tell the difference between a > driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a > default (unset) value of 0. I think the only solution here is to make > sure the kernel drivers, if they need to set it, always set this > non-zero, so udev, seeing a non-zero value, knows it's a valid value > to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap->port[i]->dev_id = j; drivers/net/ethernet/freescale/fec.c: fep->dev_id = dev_id++; drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev->dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 28, 2013 at 09:20:51AM -0600, John Reiser wrote: > On 02/28/2013 06:55 AM, Kay Sievers wrote: > > On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek > > wrote: > > > >>>> I'd like to see kernel driver work to be sure every multi-port driver > >>>> with the same PCI b/d/b/f sets dev_id. That isn't necessarily true > >>>> today, which makes it hard to trust. biosdevname needs this too, > >>>> until such a time as it's dead. > > > >>> Do we have a list of these, or is it a matter of doing a driver audit? > >>> CC'ing gospo. > > > >> Right now almost no drivers actually set dev_id. In fact mlx4_en, > >> cxgb4, and sfc seem to be the only ones right now. If we feel like this > >> a requirement there will be work on the kernel side to add this. > > > > This only matters if there are multiple devices created by a driver > > for one and the same pci device. Like when we have only one entry in > > lspci, but multiple interfaces of the same type having this one device > > as a parent. > > > > Is this really common? I would expect this is a very rare exception. > > How does this relate to a hosting service which assigns a different IP4 > for each client domain to the same physical ethernet port? My service > has many dozen different IP4 [advertised via DNS] assigned to the same port. No conceptual change here. You would still assign many IPv4 addressess to the same network device, just as you always have. The only difference is instead of assigning them to device eth0, you would assign them to device en1. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: > On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: > > Matt Domsch (matt_dom...@dell.com) said: > > > On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: > > > > > If we can solve the installtime naming convention choice to not > > > > > eliminate biosdevname, be able to disable systemd/udevd naming, and > > > > > have the default be possible on a per-system-vendor basis, and solve > > > > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > > > > > proposal. Without fixing these shortcomings though, my customers will > > > > > have a fit at me. > > > > > > > > If you're agreeing that biosdevname should be limited to type9/type41 > > > > (if I'm reading you right), and if the systemd/udev names still use > > > > those > > > > fields, what parts of biosdevname are you still requiring? The actual > > > > namespace used, or something else? > > > > > > I'd prefer if we didn't force users through another namespace change. > > > I took a lot of flack for changing the namespace once. From their > > > perspective, it's still udev doing the renaming, only now the code > > > moved from a udev helper into udev itself. > > > > True; the users likely don't care other than how they enable/disable it. > > > > > I'd like to see the SR-IOV & NPAR devices handled. Those aren't > > > represented in type9/type41, and their commonplace on Dell systems. > > > > > > I'd like to see the Dell-specific PCI VPD-R code from biosdevname > > > included in udev, as that's used to map multi-port devices to port > > > numbers. Those aren't represented in type9/type41, and they're > > > commonplace on Dell systems. > > > > OK. > > > > > I'd like to see kernel driver work to be sure every multi-port driver > > > with the same PCI b/d/b/f sets dev_id. That isn't necessarily true > > > today, which makes it hard to trust. biosdevname needs this too, > > > until such a time as it's dead. > > > > Do we have a list of these, or is it a matter of doing a driver audit? > > CC'ing gospo. > > (Thanks, Bill, though I've been following this thread as I am on the > list). > > Right now almost no drivers actually set dev_id. In fact mlx4_en, > cxgb4, and sfc seem to be the only ones right now. If we feel like this > a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: > > If we can solve the installtime naming convention choice to not > > eliminate biosdevname, be able to disable systemd/udevd naming, and > > have the default be possible on a per-system-vendor basis, and solve > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this > > proposal. Without fixing these shortcomings though, my customers will > > have a fit at me. > > If you're agreeing that biosdevname should be limited to type9/type41 > (if I'm reading you right), and if the systemd/udev names still use those > fields, what parts of biosdevname are you still requiring? The actual > namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. I'd like to see the SR-IOV & NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. So, aside from the naming convention change (which, hey, if someone else takes the pain for making that change again, not me or my company - go nuts!), the rest is straightforward technical and code can be cribbed if desired from biosdevname or just rewritten. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
> On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch wrote:
>
> >We
> >will need a method to enable/disable on a per-vendor basis as we
> >added to RHEL in the udev rules that invoke (or don't) biosdevname.
> >The suggestion of linking in (or not) rules files won't work for a
> >distro-wide per-vendor configuration.
>
> Udev rules are installed in /usr/lib and can be "masked" by creating
> empty files in /etc with the same file name. That way entire rules
> files can be enabled/disabled, if needed.
I am concerned about the naming convention at installtime. The
current proposal removes biosdevname from comps @core as mandatory,
and I presume would also remove it from the anaconda install
environment as well. This leaves the kernel default naming scheme,
which we agree is poor. So I also presume this proposal will be
extended to enable systemd/udevd naming at installtime, which for all
network installs the device naming is prompted for on screen and/or
read from kickstart files. In this proposal there is no way to use
biosdevname names at installtime, or disable systemd/udevd names
entirely if so desired (akin to biosdevname=0 on the kernel command
line). The RHEL model of disabling biosdevname by some hardware
vendors, at installtime, is not accounted for in the current proposal.
> If needed, we could add a kernel command line option to the rules too.
We do need this. We also need to be able to enable biosdevname at
installtime, again by kernel command line. The existing biosdevname=1
flag seems a good choice.
I am less concerned about runtime, as actions can be taken at runtime
to enable/disable/change the naming conventions for future boots. I
agree anything can be done at runtime given a smart system
administrator (as much as I would like not to rely on a smart system
administrator for each install).
> > C) There are several cases that biosdevname handles that udev doesn't
> >(yet) - NPAR and SR-IOV at least. These are widely used in Dell
> >and other vendors' servers.
>
> These SR-IOV show up with their own PCI function number in the kernel
> and they are unique that way. From my point of view this is good
> enough and we don't need to do anything here. If people want "pretty"
> names they should provide custom and meaningful names on their own.
> Udev does not want to establish any cross-device relations for naming,
> and only look at the single device it is currently handling.
I disagree that users should provide their own "pretty" names, when we
do have all the information we need about these devices to provide
"pretty" names by default ourselves. By the same argument, I don't
need anything more from systemd/udevd now than I've had for years with
70-persistent-net.rules files.
There are very good reasons to, in the device name, identify the
separate (to the kernel) devices that represent the same physical
cable jack. Dell's engineers have been adding code to the bonding
driver to recognize when someone is bonding two kernel devices that
share a single physical cable jack, as that's not usually the intended
configuration. With the growing set of "applicance distributions"
that auto-configure bonding across all visible network devices, this
is even more important.
The biosdevname convention of using _{1234} to identify such
sub-devices is mirrored in your convention of appending f{1234}.
Which works until you get to single PCI b/d/f devices with multiple
ports (e.g. Mellanox adapters), after which you need further
information to disambiguate the network devices. The biosdevname
maintainers are trying to tackle this right now.
> > D) the udev scheme will run out of characters in IFNAMSIZ (you've got
> >at most 15 chars to work with,
>
> Sure, it's an unfortunate kernel limitation we have to live with. We
> just do not rename anything if the name we composed does not fit. It's
> not really a problem, more an exotic corner case that can be
> covered/fixed by custom config if it really happens.
>
> >really less 5 because decimal-based
> >VLAN tagging is allowed, hence MAC-based won't fit).
>
> VLANS do not need to be named with their number in the network device
> name, they are created by custom config and not by detected hardware,
> so the naming problem can be solved at that level too, instead of the
> hardware-centric view udev has. For now, all VLANs are ignored by
> udev.
VLAN devices are created in userspace by vconfig, with its own naming
policy:
* name-type: VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)
I agree udev doesn't need
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
I haven't chimed in on this thread yet, and as the original biosdevname author, I suppose I should. Some points of consideration, which I had shared with Lennart and Kay when they first showed me their work. A) I'm glad to see someone else recognize and want to tackle this. Doing it in udev makes a lot of sense, and will certainly force more distros and hardware vendors to use it. RHEL6 still has it enabled only for Dell systems, by request of (other hardware vendors) who didn't want to inflict biosdevname on their users. We will need a method to enable/disable on a per-vendor basis as we added to RHEL in the udev rules that invoke (or don't) biosdevname. The suggestion of linking in (or not) rules files won't work for a distro-wide per-vendor configuration. B) I have had far more positive feedback about the effectiveness of biosdevname from Dell customers than I have negative. They love that finally the physical external chassis labels have a direct correlation to the Linux (and Windows Server 2012 if you're counting) device name. C) There are several cases that biosdevname handles that udev doesn't (yet) - NPAR and SR-IOV at least. These are widely used in Dell and other vendors' servers. D) the udev scheme will run out of characters in IFNAMSIZ (you've got at most 15 chars to work with, really less 5 because decimal-based VLAN tagging is allowed, hence MAC-based won't fit). Once you allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254 as suffix), leaving you with 6 usable. You take 2 to define the interface type (en,wl,ww), leaving 4 to describe the PCI topology. Not gonna fit... And last time I looked, we can't make IFNAMESIZ bigger, as it's kernel ABI to userspace and used in a ton of places. This is why the biosdevname naming convention is not as pretty as yours - there simply isn't enough space in IFNAMSIZ to do much given the claims already on the space that we can't ignore. "We can't solve that, so we won't" is not acceptable. Real people use these network features every day. E) In this thread, it has come up several times that biosdevname falls back to an emumeration method in some cases where the BIOS information is not present. Yes, it does, though there are command line flags that can disable that in general (e.g. --smbios26 means it won't trigger unless the info is present in firmware). As I've handed of maintenance of biosdevname to a whole engineering team, I don't know the current state of any other enumeration codepaths, but I agree, that's a lousy way to get the "right" answer, and I'm sure the engineering team would take suggestions on how to fix it, rather than 'throw out the baby with the bathwater'. F) "sane" (to a programmer) PCI bus topology is getting more and more difficult to come by, as multiple PCI roots now hang off specific CPUs. It will not be unusual for embedded devices to hang off the second CPU slot, which may or may not be populated with a CPU. We're long past the days where I can convince any motherboard designers to physically route their boards to bring sanity to OS device naming schemes. So, in short, I support making Consistent Network Device Names better. But I'm not convinced the udev proposal is the right solution. I'd like to see an analysis of what I got wrong in biosdevname, proposals to fix those that don't cause even more problems, and then come to a solution. I expect Lennart and Kay have already done this, but the only argument I keep hearing on this thread is "biosdevname sometimes does enumeration of its own - that's evil" which is correct, but not sufficient justification to throw it out. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO pgp_g0s6eanZ7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gutenprint update in rawhide, soname bump
On Mon, Jul 09, 2012 at 08:53:14AM -0500, Jiri Popelka wrote: > This soname bump has been an upstream error. > Please rebuild (again) cinepaint and photoprint once this gets into rawhide. > Thanks. Photoprint is rebuilt for rawhide now. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gutenprint update in rawhide, soname bump
On Wed, Jun 13, 2012 at 08:59:08AM -0500, Jiri Popelka wrote: > Hi > > I built gutenprint 5.2.8 in rawhide. > This introduces a soname bump (libgutenprint.so.2 to .3). > > These packages (owners CCed) need rebuilding: > > cinepaint > photoprint Photoprint scratch build succeeded, picked up libgutenprint.so.3. Normal build started. If someone else wanted to take over this package, I'd be happy to pass it off. It hasn't seen a point release in nearly 3 years, or even a prerelease in 2, so maintenance on it is very light, but I find it useful, so I've done the minimal work to keep it going. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/sbin/validate clash with /usr/bin/validate
On Wed, May 23, 2012 at 01:22:35PM -0500, Paul Wouters wrote: > > I just got caught in having two different "validate" commands in my > path. > > The /usr/bin/validate version is from the dnssec-tools package. It has a > man page and usage info and is a tool to diagnose dnssec lookups. I humbly suggest that the dnssec-tools package should consider changing the name of that executable as well, perhaps dnssec-validate. There are many tools that could claim the term 'validate' for an aspect of what they do. What if 'rpm -V package' had instead been written as 'validate package' ? Or 'gpg -v signaturefile' had been 'validate signaturefile' ? I know, first come first served, but it feels presumptuous to lay claim to a generic action such as this. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [announce] yum: parallel downloading
On Mon, May 21, 2012 at 05:33:51AM -0500, Zdenek Pavlas wrote: > > The number of concurrent users is now lower because, well, each of > > them now completes a "yum update" in one third of the time. > > I think Glen's concerns were that the consumed resources > (flow caches, TCP hash entries, sockets) may scale faster > than the aggregated downloading speed. > > I am aware of this, and in most cases the downloader in urlgrabber > will make just 1 concurrent connection to a mirror, because: > > 1) The Nth concurrent connection to the same host is assumed >to be N times slower than 1st one, so we'll very likely >not select the same mirror again. > > 2) maxconnections=1 in every metalink I've seen so far. >This is a hard limit, we block until a download finishes >and reuse one connection when the limit is maxed out. That's MirrorManager's doing. I don't have a box for mirror admins to tell MM otherwise - that they'd be happy with >1 connection. I suppose that could be added, default to 1. > The reason for NOT banning >1 connections to the same host altogether > is that (as John Reiser wrote) 2nd connection does help quite a lot > when downloading many small files and just one mirror is available. > I agree that using strictly 1 connection and HTTP pipelining would > be even better, but we can't do that with libcurl. I'd be happy if yum/urlgrabber/libcurl finally used http keepalives. Last time I looked (and it has been a while), it didn't, so you always paid the TCP slow startup penalty for each package. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
On Wed, Nov 09, 2011 at 07:46:57PM -0600, Adam Williamson wrote: > It's rather infuriating to have to go in and 'fix' a bunch of > 'conflicts' which are not conflicts at all, but just the changes you > wanted to merge with a bunch of silly >>>> and <<<< around them. I use this: fedpkg switch-branch f16 git merge -s recursive -X theirs master and have a git alias for it in ~/.gitconfig: [alias] copymaster = merge -s recursive -X theirs master This forces the f16 branch contents to match the master branch contents. I haven't looked closely at what it does to the linear git history though. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-distutils-extra for EPEL?
On Wed, Sep 07, 2011 at 10:28:19AM -0500, Matt Domsch wrote: > > 05.09.2011, 20:35, "Fedora Python SIG" > > : > > > 31.08.2011, 00:58, "Matt Domsch" : > > > - Is anyone in the Python SIG interested in maintaining > > > - python-distutils-extra in el6? The Fedora maintainer has declined to > > > - participate in EPEL, but would welcome someone else doing so. The > > > - rawhide copy builds clean in koji against el6 right now, so it > > > - shouldn't be that hard to maintain. > > > - > > > - This is needed by openstack-nova, which the Cloud SIG is in process of > > > - packaging for Fedora and EL6. > > > On Wed, Sep 07, 2011 at 06:25:23AM -0500, nomc...@yandex.ru wrote: > > It's very interesting.How and what can I > > begin? Before I didn't realise such tasks. > > While above I said python-distutils-extra, I really meant the package > bpython. p-d-e was built by fab, and he pushed it to updates-testing > for EPEL. I built bpython, and pushed it to updates-testing for EPEL. > > Going forward, I would like you to maintain bpython for EPEL, just as > you do for Fedora. (by "you", I mean a member of the python SIG who is interested in such. I recognize nomctan is not the official owner of bpython Fedora branches). -- Matt Domsch Technology Strategist Dell | Office of the CTO ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: python-distutils-extra for EPEL?
> 05.09.2011, 20:35, "Fedora Python SIG" : > > 31.08.2011, 00:58, "Matt Domsch" : > > - Is anyone in the Python SIG interested in maintaining > > - python-distutils-extra in el6? The Fedora maintainer has declined to > > - participate in EPEL, but would welcome someone else doing so. The > > - rawhide copy builds clean in koji against el6 right now, so it > > - shouldn't be that hard to maintain. > > - > > - This is needed by openstack-nova, which the Cloud SIG is in process of > > - packaging for Fedora and EL6. On Wed, Sep 07, 2011 at 06:25:23AM -0500, nomc...@yandex.ru wrote: > It's very interesting.How and what can I > begin? Before I didn't realise such tasks. While above I said python-distutils-extra, I really meant the package bpython. p-d-e was built by fab, and he pushed it to updates-testing for EPEL. I built bpython, and pushed it to updates-testing for EPEL. Going forward, I would like you to maintain bpython for EPEL, just as you do for Fedora. The el6 branch now exists in the bpython git package. https://fedoraproject.org/wiki/Joining_EPEL https://fedoraproject.org/wiki/EPEL_Package_Maintainers Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sun, Jul 10, 2011 at 04:43:30PM +0100, Matthew Garrett wrote: > On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: > > > * Fedora should (IMO) institute mandatory mass rebuilds. Either every > > cycle, or every other cycle. I've briefly discussed with Dennis. > > Bootstrapping (and similar activities) are far easier with a clean set > > of deps, which is the case for F15. It should always be the case that we > > know everything builds and self-hosts through a mass rebuild per cycle. > > This has been raised with FESCO in the past, and I don't think there's > any fudnamental disagreement on it. But scheduling one mass rebuild per > cycle doesn't prevent us ending up in a broken state unless we do it > right at the end of the cycle, and right now that's problematic in terms > of release process - rebuilding everything we've just QAed is an > excellent way to introduce subtle breakage. So it really needs to be an > out-of-archive verification rather than one that's targetted at the > release, and we need the resources and manpower to handle it. Alternately, we could take a lesson from our compatriots at openSUSE. Their openSUSE Build Service throws a combination of automated intelligence and hardware at the problem. Given the package dependency tree, if package B BuildRequires package A, then every time A gets rebuilt, B is also bumped and rebuilt. This causes build breakage to get caught fairly early in the process (rather than via an asynchronous out-of-tree process), and the resulting packages are available in their equivalent of the rawhide tree for test and use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - FRIDAY
On Sat, Jul 09, 2011 at 11:45:33PM -0400, Jon Masters wrote: > It's becoming clear that several points do need raising with FESCo: > * Fedora should (IMO) institute mandatory mass rebuilds. Either every > cycle, or every other cycle. I've briefly discussed with Dennis. > Bootstrapping (and similar activities) are far easier with a clean set > of deps, which is the case for F15. It should always be the case that we > know everything builds and self-hosts through a mass rebuild per cycle. I agree with Jon 100%. As folks know, I have been an ardent supporter of self-hosting since I started working with Linux (and RHL/Fedora) 12 years ago. I'm not alone in this position, and have had the help of many maintainers over the years to fix FTBFS bugs as I've uncovered and reported them - Thank You! However, I haven't had as much time to put into that effort recently as I believe it deserves. FESCo asked me to draft a procedure [1], a task from [2] for ensuring identified FTBFS packages were blocked, which I've done. But the procedure lacks a key component - identifying, through Fedora Project-maintained efforts (and not my own private efforts), the list of pacakges that FTBFS. That could be a rel-eng mass rebuild run. That could be a stand-alone rebuild effort. I'm not going to dictate. I have had some interest from individuals asking how they could help, but they seemed to be daunted by the need for a good deal of builder resources to do a mass rebuild in a reasonable amount of time. And unfortunately, I'm not in a position to put the builders I scrounged up on the public internet for use. If self-hosting and reliable package building is important to you, please chime in with ideas for how we can make this a standard part of the Fedora release process. [1] https://fedoraproject.org/wiki/Deprecate_FTBFS_packages [2] https://fedoraproject.org/wiki/Release_Engineering_Release_Tickets Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname in fedora 15 - why is this inconsistency?
On Fri, Jul 08, 2011 at 10:22:07AM -0600, Petrus de Calguarium wrote: > Tom Hughes wrote: > > > Did you upgrade this machine from an earlier version of Fedora? If so > > then I suspect the old names will stick because you will have udev > > persistent naming rules for them. > > No, I did a clean install. I installed a week before the first Test > Candidate for the first Release Candidate of the Alpha for Fedora 15 > came out. I indicated in the bug that we had a few last-minute fixes for this feature that landed around that time frame; it's possible that the pre-f15-alpha build he has missed such fixes. Otherwise, it's not obvious why it would fail. Petrus says he'll try again after F16 is released. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
On Wed, Jun 29, 2011 at 06:34:35PM +0100, Matthew Garrett wrote: > On Wed, Jun 29, 2011 at 12:27:47PM -0500, Matt Domsch wrote: > > > Portreserve is also useful to reserve (not let the OS make use of) > > ports that are needed by an embedded management controller that > > intercepts delivery of packets to the port and delivers them to the > > BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that > > behavior in newer systems, such are still in production use. > > Is that port number exposed to the OS in any way? Not that I can recall, which is why it was a horrible design. IIRC it was just the remote IPMI port, but there may have been a few others. I misremembered [1] the system type, it was the PowerEdge 1855, not the newer 1955. So we did fix that particular bit of pain in newer generations. In that case, it was the IPMI port 623/tcp that was snarfing packets. [1] http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023606.html -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Deprecating portreserve
On Wed, Jun 29, 2011 at 04:48:58PM +0100, Tim Waugh wrote: > Now that systemd is used by default, I think it is time to deprecate > portreserve. > > For those unfamiliar with it, portreserve is a small utility which binds > specific network ports early on during the boot process, so that > services using those ports can claim them when they start. The point is > to avoid accidental clashes when services use random unbound privileged > ports. > > Currently portreserve has a SysV initscript. It doesn't make a lot of > sense to migrate it to a systemd service unit because of the fact that > systemd avoids the problem. Portreserve is also useful to reserve (not let the OS make use of) ports that are needed by an embedded management controller that intercepts delivery of packets to the port and delivers them to the BMC (e.g. the PowerEdge 1955 BMC). While we've done away with that behavior in newer systems, such are still in production use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package drops due to FTBFS
On Thu, Jun 23, 2011 at 10:09:40AM -0500, Matt Domsch wrote: > Below are the of packages which have outstanding FTBFS bugs from > earlier Fedora releases. I've split them up by their 'dist' tag which > shows when they were last successfully built. > > I recommend and propose to FESCo that all non-building packages with > Fedora 12 and 13 dist tags be considered for dropping prior to > branching Fedora 16. At today's FESCo meeting, FESCo approved a policy to deprecate and block packages that FTBFS with dist tags of (N-2) and earlier, therefore .f12, .f13, and .f14 in prep for the f16 branch. At this point, there are no packages which FTBFS from that date which do not have a dist tag. https://fedoraproject.org/wiki/Deprecate_FTBFS_packages has been added to the Release Engineering Release SOP for comment and review enacting this. The packages below are the initial candidate list; packages which have new builds present in rawhide prior to branching f16 will no longer be considered candidates, so fix your packages sooner rather than later please... > Since Fedora 12: > > gnome-do-plugins-0.8.2-1.fc12 [u'599889 NEW'] (build/make) nushio,antiaircraft > guile-gnome-platform-2.16.1-4.fc12 [u'599864 NEW'] (build/make) laxathom > imgtarget-0.1.4-4.fc12 [u'599895 NEW'] (build/make) grof > kanatest-0.4.8-3.fc12 [u'631023 NEW'] (build/make) robmv > kdetv-0.8.9-13.fc12 [u'631359 NEW'] (build/make) subhodip > kpolynome-0.1.2-15.fc12 [u'599875 NEW'] (build/make) chitlesh > ktechlab-0.3.70-3.20090304svn.fc12 [u'631203 NEW'] (build/make) chitlesh > libctl-3.0.2-10.fc12 [u'599894 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > edhill,deji > libopensync-plugin-kdepim-0.22-6.fc12 [u'599881 NEW'] (build/make) awjb > multiget-1.2.0-7.fc12 [u'631052 NEW'] (build/make) guidoledermann,mtasaka > netgo-0.5-12.fc12 [u'631087 NEW'] (build/make) spot > notecase-1.6.1-6.fc12 [u'631448 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > bouska > photoprint-0.4.0-7.fc12 [u'599755 NEW'] (build/make) grof > pigment-0.3.17-3.fc12 [u'599828 NEW'] (build/make) thias > postgresql-pgpool-ha-1.1.0-8.fc12 [u'599834 NEW'] (build/make) devrim > qgo-1.5.4r2-3.fc12 [u'631091 NEW'] (build/make) orphan > qucs-0.0.15-4.fc12 [u'631404 NEW'] (build/make) tanguy > rubygem-cobbler-1.6.1-1.fc12 [u'599799 NEW'] > (unpackaged_files/python-egg-info?) jeckersb > starlab-4.4.3-7.fc12 [u'599988 ASSIGNED'] (build/make) lkundrak,mmahut > subtitlecomposer-0.5.3-3.fc12 [u'599833 NEW'] (build/make) tuxbrewr > xdx-2.4.1-3.fc12 [u'599818 NEW'] (build/make) bjensen,sindrepb > xsri-2.1.0-17.fc12 [u'599802 NEW'] (build/make) ssp > > > Since Fedora 13: > > automake15-1.5-29.fc13.1 [u'631216 NEW'] (build/make) karsten > automake16-1.6.3-18.fc13.1 [u'631215 NEW'] (build/make) karsten > db4o-7.4-2.fc13 [u'631066 NEW'] (build/make) pfj > fsvs-1.2.1-1.fc13 [u'631437 NEW'] (build/make) davidf,wolfy > gpar2-0.3-9.fc13 [u'631134 NEW'] (build/make) drago01 > gwave-2-18.20090213snap.fc13 [u'599862 NEW'] > (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) > chitlesh,tnorth > klibido-0.2.5-13.fc13 [u'631410 NEW'] (build/make) faucamp > linbox-1.1.7-0.2.svn3214.fc13 [u'631173 NEW'] (build/make) jjames > > > Since Fedora 14: > > agave-0.4.7-1.fc14 [u'631411 NEW'] (build/make) bonii > gnusim8085-1.3.6-1.fc14 [u'631067 NEW'] (build/make) sherry151,chitlesh > kazehakase-0.5.8-9.svn3873_trunk.fc14 [u'631305 NEW'] (build/make) mtasaka > link-grammar-4.6.7-3.fc14 [u'599978 NEW'] (build/make) uwog > rubygem-rcov-0.9.8-1.fc14 [u'631350 NEW'] (build/make) mmorsi > tilda-0.9.6-4.fc14 [u'631372 NEW'] (build/make) laxathom Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Mon, Jun 27, 2011 at 08:03:17AM +0200, V?t Ondruch wrote: > Hi Matt, > > I just want to note that your script is not listing the package owners > correctly. There should be listed only people who have commit access, > but there are listed also people who just watch bugzilla and commits, > [1] for example. Unfortunately nobody of listed owners: > > rubygem-rack-1.1.0-2.fc14 (build/make) kanarip,mmorsi,stahnma,vondruch > > > can do something about it except kanarip. I originally had only the "package owner". I changed it to be "package owner and bugzilla cc: list" as, if you're signed up for cc: messages, you likely want to know, even if you can't commit a change to the package. (Some on cc: are provenpackagers). pkgdb does have a method for me to query only those with commit access, but I would prefer to leave it as-is, letting more people (those who have shown interest by signing up for bugzilla cc: list) get the notification rather than fewer (those who have commit rights), in hope of action being taken. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Sat, Jun 25, 2011 at 01:33:49AM +, Ben Boeckel wrote: > Matt Domsch wrote: > > ghc-hinotify-0.3.1-9.fc16 (build/make) mathstuf,haskell-sig > > Jens opened another bug for this[1]. Should I mark as CLOSED DUPLICATE > or set a dependency? CLOSED DUPLICATE is right in this instance, as the bug I filed blocks the F16FTBFS bug already. I did so. Thanks for the quick response. I'm still looking forward to chasmd... :-) -Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Fri, Jun 24, 2011 at 10:37:34AM -0400, David Malcolm wrote: > On Wed, 2011-06-22 at 19:17 -0500, Matt Domsch wrote: > > Fedora Fails To Build From Source Results for x86_64 > > using rawhide from 2011-06-16 > > > > Good hunting! > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > pypy-1.5-1.fc16 (build/make) dmalcolm,tomspur > > I don't see a directory for this within the i386/x86_64 subdirectories > of the above ^^^ my bad. pypy has been taking nearly 7 hours to (fail to) build; I excluded it in the last run, which nuked the logs from the previous failure runs. In a couple cases it did complete, in others it didn't. I think you can ignore it for now. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Wed, Jun 22, 2011 at 07:17:45PM -0500, Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2011-06-16 As a reminder, please do not simply "CLOSED NOTABUG" your FTBFS bugs. By the time I started mass-filing 564 bugs yesterday, any packages I filed bugs against had failed to build at least 6 times through, so _something_ is failing. It may not be a bug in your package; it may well be a bug in mock, or in a package you BR. However, your package does FTBFS. If you believe this is actually a bug in another package, do NOT change the component in this bug or close this bug. Instead, add the appropriate bug number from the other package to the "Depends on" line in this bug. If the other package does not yet have a bug created that you think matches, please create one. Doing so helps us properly track bugs and their dependencies, just as we track package dependencies. (If you close this bug, and the other package is not fixed before the next FTBFS run, a new bug will get created. Please follow the above advice to avoid such duplication.) There are a couple common failures we're seeing now: * Bug 716267 - mock 1.1.11 moves to build step even if buildroot had depsolving problems. The symptom of this is that root.log indicates some SKIPBROKEN lines, your BR packages were not installed into the buildroot, and in build.log you see configure fail due to missing BR'd packages. In this case, set "Depends on" in your bug to 716267. (mock does not use --skip-broken; the SKIPBROKEN lines are seen because the script runs yum at highest debugging level.) * There is a secondary bug in each of these instances, which is that a package you BR cannot be installed into the buildroot due to dependency issues of its own. Packages that require sendmail fail for this reason. In this case, put both the mock bug number and the package bug number into the Depends on: list in your bug. ** Sendmail bug 716460 Error: Package: sendmail-8.14.5-1.fc16.x86_64 (ftbfs) Requires: libdb-5.1.so()(64bit) * Bug 716354 pango uses deprecated G_CONST_RETURN, symptom in your build.log: /usr/include/pango-1.0/pango/pango-script.h:132:12: error: unknown type name 'G_CONST_RETURN' /usr/include/pango-1.0/pango/pango-script.h:133:12: error: unknown type name 'G_CONST_RETURN' Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Fri, Jun 24, 2011 at 03:05:52PM +0200, Michal Hlavinka wrote: > On Wednesday 22 of June 2011 19:17:45 Matt Domsch wrote: > > Fedora Fails To Build From Source Results for x86_64 > > using rawhide from 2011-06-16 > > > > Good hunting! > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > ... > > Total packages: 10614 > > Number failed to build: 603 > > Number expected to fail due to ExclusiveArch or ExcludeArch: 27 > > Leaving: 576 > > > > Of those expected to have worked... > > Without a bug filed: 531 > > -- > ... > > mhlavink: mksh > > this should not be on the list: > ... > Wrote: /builddir/build/RPMS/mksh-39c-4.fc16.x86_64.rpm > Wrote: /builddir/build/RPMS/mksh-debuginfo-39c-4.fc16.x86_64.rpm > ... > > build.log shows it works fine You are correct. I have been continuing to repeat the failed builds, as there are some transient failures that are not specific to any one package. As of when I sent that note, this package had failed to build at least 3 times through the loop; it subsequently succeeded yesterday prior to my mass-filing FTBFS bugs in bugzilla. Thanks for looking into it. -Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
On Mon, Jun 20, 2011 at 10:34:10AM -0700, Toshio Kuratomi wrote: > Due to the requirement for contributors to sign the FPCA by Thursday of last > week, certain package owners who haven't yet signed will be removed from the > packager group soon. When that happens, the packages that they own will be > orphaned. > photoprint I'll take photoprint. I just updated it to latest upstream and fixed it FTBFS. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed package drops due to FTBFS
Below are the of packages which have outstanding FTBFS bugs from earlier Fedora releases. I've split them up by their 'dist' tag which shows when they were last successfully built. I recommend and propose to FESCo that all non-building packages with Fedora 12 and 13 dist tags be considered for dropping prior to branching Fedora 16. Since Fedora 12: gnome-do-plugins-0.8.2-1.fc12 [u'599889 NEW'] (build/make) nushio,antiaircraft guile-gnome-platform-2.16.1-4.fc12 [u'599864 NEW'] (build/make) laxathom imgtarget-0.1.4-4.fc12 [u'599895 NEW'] (build/make) grof kanatest-0.4.8-3.fc12 [u'631023 NEW'] (build/make) robmv kdetv-0.8.9-13.fc12 [u'631359 NEW'] (build/make) subhodip kpolynome-0.1.2-15.fc12 [u'599875 NEW'] (build/make) chitlesh ktechlab-0.3.70-3.20090304svn.fc12 [u'631203 NEW'] (build/make) chitlesh libctl-3.0.2-10.fc12 [u'599894 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) edhill,deji libopensync-plugin-kdepim-0.22-6.fc12 [u'599881 NEW'] (build/make) awjb multiget-1.2.0-7.fc12 [u'631052 NEW'] (build/make) guidoledermann,mtasaka netgo-0.5-12.fc12 [u'631087 NEW'] (build/make) spot notecase-1.6.1-6.fc12 [u'631448 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) bouska photoprint-0.4.0-7.fc12 [u'599755 NEW'] (build/make) grof pigment-0.3.17-3.fc12 [u'599828 NEW'] (build/make) thias postgresql-pgpool-ha-1.1.0-8.fc12 [u'599834 NEW'] (build/make) devrim qgo-1.5.4r2-3.fc12 [u'631091 NEW'] (build/make) orphan qucs-0.0.15-4.fc12 [u'631404 NEW'] (build/make) tanguy rubygem-cobbler-1.6.1-1.fc12 [u'599799 NEW'] (unpackaged_files/python-egg-info?) jeckersb starlab-4.4.3-7.fc12 [u'599988 ASSIGNED'] (build/make) lkundrak,mmahut subtitlecomposer-0.5.3-3.fc12 [u'599833 NEW'] (build/make) tuxbrewr xdx-2.4.1-3.fc12 [u'599818 NEW'] (build/make) bjensen,sindrepb xsri-2.1.0-17.fc12 [u'599802 NEW'] (build/make) ssp Since Fedora 13: automake15-1.5-29.fc13.1 [u'631216 NEW'] (build/make) karsten automake16-1.6.3-18.fc13.1 [u'631215 NEW'] (build/make) karsten db4o-7.4-2.fc13 [u'631066 NEW'] (build/make) pfj fsvs-1.2.1-1.fc13 [u'631437 NEW'] (build/make) davidf,wolfy gpar2-0.3-9.fc13 [u'631134 NEW'] (build/make) drago01 gwave-2-18.20090213snap.fc13 [u'599862 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) chitlesh,tnorth klibido-0.2.5-13.fc13 [u'631410 NEW'] (build/make) faucamp linbox-1.1.7-0.2.svn3214.fc13 [u'631173 NEW'] (build/make) jjames Since Fedora 14: agave-0.4.7-1.fc14 [u'631411 NEW'] (build/make) bonii gnusim8085-1.3.6-1.fc14 [u'631067 NEW'] (build/make) sherry151,chitlesh kazehakase-0.5.8-9.svn3873_trunk.fc14 [u'631305 NEW'] (build/make) mtasaka link-grammar-4.6.7-3.fc14 [u'599978 NEW'] (build/make) uwog rubygem-rcov-0.9.8-1.fc14 [u'631350 NEW'] (build/make) mmorsi tilda-0.9.6-4.fc14 [u'631372 NEW'] (build/make) laxathom Since Fedora 15: cone-0.84-1.fc15 [u'631345 ON_QA'] (build/make) steve gtkdatabox-0.9.1.1-7.fc15 [u'631349 NEW'] (build/make) ework kadu-0.6.5.4-5.fc15 [u'599796 NEW'] (build/make) radekl,gajownik,radekl monafont-2.90-12.fc15 [u'631326 NEW'] (build/make) mtasaka Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Thu, Jun 23, 2011 at 03:03:12PM +0200, Mattias Ellert wrote: > ons 2011-06-22 klockan 19:17 -0500 skrev Matt Domsch: > > Fedora Fails To Build From Source Results for x86_64 > > using rawhide from 2011-06-16 > > > > Good hunting! > > > > lcgdm-1.8.0.1-7.fc16 (build/make) ellert,stevetraylen > > This is already resolved (by an update of CGSI-gSOAP). The package built > fine on 2011-06-20 in koji during the perl mass rebuild: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=248860 > > > root-5.28.00d-1.fc16 (build/make) ellert,stevetraylen > > This needs the update of lcgdm above to be in the buildroot in order to > build. That build is not in rawhide yet, only in dist-f16-perl. > > Mattias Thanks for the report. Because my scripts can't see dist-f16-perl, only what's in rawhide, you're going to get bug created for these, which you can mark CLOSED RAWHIDE as soon as dist-f16-perl is merged in. It's situations like this that a FTBFS system more integrated with our packaging and release system would be beneficial. I don't have the time now to write such; there has been some interest from other contributors, but that seems to have stalled out given the daunting amount of hardware desired (not necessarily required) to do a run over all 10.6k packages in a reasonable amount of time. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 x86_64
On Wed, Jun 22, 2011 at 07:17:45PM -0500, Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2011-06-16 There are several false failures in this list due to what seems to be a race condition between my RHEL5 NFS server and F15 clients. If your mock.log includes a line such as: ERROR: Could not create dir /home/build/mock-results/x86_64/straw-0.27-19.fc15.src.rpm/result/. Error: [Errno 13] Permission denied: '/home/build' with a python traceback, that's the symptom, and those builds are failing but not due to anything related to the specific package. The directory exists (it was created immediately before mock was invoked), but python seems not to think so. I'll try to keep those failures from being included in the results going forward. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2011-06-16 i386
TurboGears,python-migrate tremble: TurboGears,perl-Expect,rubygem-nokogiri trondd: avr-gdb,avr-libc tuju: libdigidocpp,smartcardpp tuxbrewr: PackageKit,digikam,digikam,kdebase3,kdebindings,ohm,spicebird,squeak-vm,subtitlecomposer,tripwire uwog: abiword,link-grammar varekova: man-pages-ru,uClibc,uClibc vda: uClibc verdurin: arpage virtmaint: seabios,virt-mem vlg: granule vondruch: ruby,rubygem-rack,rubygem-tilt vpv: openoffice.org-voikko walters: gnome-python2-desktop,gnome-python2-extras wolfy: fsvs,grip,halevt,libzrtpcpp wtogami: ltsp xavierb: openvas-libraries ynakam: seedit yyang: plexus-containers -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2011-06-16 x86_64
ed,supertux steved: nfs-utils,rpcbind stevetraylen: lcgdm,root stingray: cuetools subhodip: kdetv,straw sundaram: clutter-gst,deja-dup,gnote,gtkmm24,pino supercyper: Mayavi,libqttracker,libwps,pino,qtiplot,scidavis suravee: CodeAnalyst-gui svahl: devilspie,kdebase3 tagoh: im-chooser,kinput2,paps,ruby,uim tanguy: qucs tbzatek: gamin,seahorse-plugins th0br0: mumble than: kdebase3,kdebindings,wordtrans thias: autodir,blackbox,camE,keepalived,openvpn-auth-ldap,pigment,zziplib thm: dexter thomasvs: mach timlau: postr,postr timn: fawkes,libdc1394,stage tjikkun: telepathy-gabble tmraz: gnupg tmz: gtkpod tnorth: LabPlot,alliance,avr-gdb,avr-libc,gwave,liborigin tomeu: hulahop tomspur: hamster-applet,pypy,python-daemon,python3 topdog: libpuzzle,php-pecl-geoip,php-pecl-lzf,php-pecl-sphinx toshio: TurboGears,python-migrate tremble: TurboGears,perl-Expect,rubygem-nokogiri trondd: avr-gdb,avr-libc tuju: libdigidocpp,smartcardpp tuxbrewr: PackageKit,digikam,digikam,kdebase3,kdebindings,spicebird,squeak-vm,subtitlecomposer,tripwire tuxmadhu: grub uwog: abiword,link-grammar varekova: man-pages-ru,uClibc,uClibc vda: uClibc verdurin: arpage virtmaint: seabios,virt-mem vlg: granule vondruch: ruby,rubygem-rack vpv: openoffice.org-voikko walters: gnome-python2-desktop,gnome-python2-extras wolfy: fsvs,grip,halevt,libzrtpcpp wtogami: ltsp xavierb: openvas-libraries ynakam: seedit yyang: plexus-containers -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Same noarch update to several releases?
On Tue, May 31, 2011 at 06:24:08AM -0500, Bruno Wolff III wrote: > I am co-maintaining boswars-addons which has been setup to not use dist > as part of the versions, since the package is noarch and the same build > is usable accross releases. It's 48 MB, so it has been considered large > enough to be worth not triggering updates when updating between Fedora > releases. > > So now I want to get the same update into F13, F14, F15 and rawhide. > Is there a reasonable way to do this? I think I can get it into F13 > and rawhide, but I am not sure how to get the same build into multiple > updates repos for released versions. Can I do this one at a time? So > that after it has made it all the way to updates in one release, to > start again in another using manual tagging into updates-pending before > using bodhi again? I would expect rel-eng could tag that build into each of the updates manually. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The future of FTBFS?
On Thu, Apr 07, 2011 at 05:11:00PM +0100, Jonathan Underwood wrote: > On 7 April 2011 16:02, Matt Domsch wrote: > > Question is, is it valuable enough to the Project as a whole, that > > someone else should take it on now? > > Absolutely! > > Actually, have you published you use to BFS the scripts anywhere? http://linux.dell.com/files/fedora/FixBuildRequires/ftbfs-nov08.tgz though I admit the scripts are ugly as sin, and if someone were to take this on, the first thing to do would be rewrite them all in a non-bash language. Some of the individual helper scripts for obtaining info from bugzilla, filing bugs in bugzilla, retriving the list of package owners and emails, etc, would be nice to have in a common library. (FWIW, when I started the project, I did it because we had a need around the Fedora 6 time frame to find out what was going to break in a mass rebuild, the first for Fedora. I dind't intend it to live so long, but as with all good ideas, they take on a life of their own.) -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
The future of FTBFS?
As my job and family responsibilities have shifted over time, I have been giving less and less attention to the FTBFS (fails to build from source) process that I started 5 years ago on a "see, it _can_ be done" lark. I think FTBFS has been valuable. Through the process, hundreds, maybe even a couple thousand, bugs have been discovered and fixed before they affected our users or downstream remixes and derivatives. I find the breakage, file bugs, and the package owners fix them. Sure, I get the occasional "why are you filling my mailbox with this" message, but overall, the response has been very positive. Question is, is it valuable enough to the Project as a whole, that someone else should take it on now? If so, should it become standard process of the Project, rather than a personal project? With resources (koji servers) owned and managed by the project, instead of the servers I could scrounge? FTBFS cuts across Packagers, BugZappers, QA, Developers, and Release Engineering. As such, I think it needs to be part of standard processes for the Project. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
biosdevname v0.3.7 - karma requested
FYI, I built and pushed biosdevname 0.3.7 with the recent bugfixes and
behavioral fixes. I wanted to get this out for testing in the F15
Alpha cut. To that end, I need 3 people to give +1 karma to the
update
https://admin.fedoraproject.org/updates/biosdevname-0.3.7-1.fc15
Thanks,
Matt
- Forwarded message from Matt Domsch -
Date: Thu, 17 Feb 2011 10:15:40 -0600
From: Matt Domsch
To: linux-hotp...@vger.kernel.org, net...@vger.kernel.org,
"K, Narendra" ,
"Hargrave, Jordan" ,
"Rose, Charles" ,
Colin Watson
Subject: biosdevname v0.3.7
biosdevname, now version 0.3.7.
Major visible changes include no longer using '#' in device names (by
popular demand), no longer suggesting new names if running inside a VM
guest (tested with KVM, SLES 10 Xen, XenServer, VMware ESX, but it
uses the generic cpuid test, so should work on most virt platforms),
and a new kernel command line option 'biosdevname={0|1}' which udev
honors, to force enabling or disabling of invoking biosdevname.
Still to come: NPAR partition->port mapping support (initially
Dell-specific, but if NIC vendors have other ways to expose this,
please let me know).
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide and F15, and I encourage
other distributions to pick it up as well.
shortlog:
Andrew Cooper (3):
Fix segfault when BIOS advertises zero sized PIRQ Routing Table
Add 'bonding' and 'openvswitch' to the virtual devices list
Typo fixes
Harald Hoyer (1):
Add kernel command line parameter "biosdevname={0|1}" to turn off/on
Matt Domsch (7):
don't build or package dump_pirq, use biosdecode from dmidecode instead
don't use '#' in names, use 'p' instead, by popular demand
properly look for SMBIOS, then $PIR, then recurse
update changelog
Fix test for PIRQ table version
fail PIRQ lookups if device domain is not 0
exit(4) if running a virtual machine
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
- End forwarded message -----
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
- End forwarded message -
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On Sat, Jan 15, 2011 at 11:14:42AM -0500, Genes MailLists wrote: > On 01/15/2011 10:38 AM, John Reiser wrote: > > > Perhaps it was Fedora 15 (and not Fedora 14) that took 4 days? See below. > > > >> So it took 2x4x10x96=7680 corehours to build 2 packages, at an average > >> of 7680*60/2=23 coreminutes/package. > >> > >> And we get that on average one package takes 6 minutes on a 4 core machine. > >> That makes sense. > >Is it possible to break down how much time is in compiling versus > packaging versus whatever else is involved ? patches to mock to produce such would be welcome I'm sure. For my part, I run '/usr/bin/time mock ...' on each package built, and those times are recorded alongside the output RPMs, for the curious: [vim-7.3.069-1.fc15.src.rpm]$ cat time.log real 253.96 user 211.30 sys 32.11 -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On Sat, Jan 15, 2011 at 03:52:34PM -0500, Jon Masters wrote:
> On Fri, 2011-01-14 at 16:51 -0600, Matt Domsch wrote:
>
> > It took my build system 96 hours to build all of rawhide (>10k
> > packages) for both x86_64 and i386. Builders are 10 Dell PowerEdge
> > 1955 servers, each with 2 sockets 3GHz Xeon 5160 CPUs (4 cores each),
> > 8GB RAM. Builders running Fedora 14.
>
> OOI, do you sequentially build one package at a time on a builder, or do
> you do parallel builds?
Each builder runs 2 build processes for each of i386 and x86_64 in
parallel, so 4 parallel builds per server. Each package may be using
make %{_smp_flags} which would then overcommit the CPUs. But in all,
it's disk-bound, not CPU-bound, especially now that I can't use tmpfs.
The builders have ext4 (Fedora 14 default) where the mock chroots
live. When the runs start, each builder creates the basic chroot, and
mock caches that and unpacks it at the start of each package build, to
save some time. The non-base buildrequires packages get fetched from
a local server over 1GbE, so that could become a bottleneck, but isn't
terribly limiting.
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora distribution build times
On Wed, Jan 12, 2011 at 12:24:41PM +0530, Shakthi Kannan wrote: > Greetings! > > I would like to know as to how long it takes to build a complete > Fedora distribution, say i686, from .src.rpms. > > Are there any statistics available or is it possible to provide any > info on the hardware specifications (RAM, number of processors, kernel > used etc.), time it takes to build the complete Fedora distribution, > and other build related statistics? It took my build system 96 hours to build all of rawhide (>10k packages) for both x86_64 and i386. Builders are 10 Dell PowerEdge 1955 servers, each with 2 sockets 3GHz Xeon 5160 CPUs (4 cores each), 8GB RAM. Builders running Fedora 14. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname v0.3.4
On Fri, Dec 17, 2010 at 07:16:56AM -0600, Matt Domsch wrote: > On Fri, Dec 17, 2010 at 04:57:35PM +0800, Simon Yan wrote: > > This is neat, thanks for the effort. > > Just tried it and works great. > > > > One suggestion, can you add the logic if the program is not executed > > by root it exits with a non-0 value and print out a warning message? > > That's a good idea for now. Ideally we would expose all the necessary > bits in sysfs so it wouldn't need to be root (right now it reads > /dev/mem), but enough bits are missing from sysfs today that it isn't > feasible. Patch is in upstream now, will be in the next release. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname v0.3.4
On Fri, Dec 17, 2010 at 04:57:35PM +0800, Simon Yan wrote: > This is neat, thanks for the effort. > Just tried it and works great. > > One suggestion, can you add the logic if the program is not executed > by root it exits with a non-0 value and print out a warning message? That's a good idea for now. Ideally we would expose all the necessary bits in sysfs so it wouldn't need to be root (right now it reads /dev/mem), but enough bits are missing from sysfs today that it isn't feasible. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
biosdevname v0.3.4
biosdevname, now version 0.3.4. The main visible change is that port indices now start at 1 rather than 0, when assigned by biosdevname (such as falling back to PIRQ) rather explicitly assigned by BIOS. This is in keeping with how the indices are assigned by BIOS on Dell and HP servers. em where port starts at 1 pci# where port starts at 1 As a side effect, the first VMware Workstation guest NIC now appears as pci3#1 because the virtual machine BIOS exposes the device as being in a PCI slot via PIRQ. This also drops an explicit dependency check on a particular udev version. That version was supposed to properly handle parallel conflicting renames when swizzling within the ethX namespace, but as we've discovered, that doesn't always work. The udev in RHEL5 is older than what we were specifying, but it works just fine, so no more check. Furthermore, if biosdevname somehow messes up (either through its own bug or because of a buggy BIOS), and would assign the same name to two different devices, it won't try to assign names to either (who knows which is correct?). You can see the duplciates when running with the -d debug option. Grab it here: http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz.sign git://linux.dell.com/biosdevname.git I built this today for Fedora rawhide (will be 15), and I encourage other distributions to pick it up as well. shortlog: Matt Domsch (5): require any udev Return nothing if duplicate names would be assigned. Don't assign names to unknown devices only supress duplicates, not all names if any duplicates exist start with port index 1, not index 0 Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On Wed, Dec 15, 2010 at 09:24:40AM -0500, seth vidal wrote: > After this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=663340 > > I realize I'm not remembering to update the EOL date often enough. > > So, I'm orphaning system-auto-death. If no one steps up to take care of > it I'm going to issue an update which disables the cron job. I mentioned this in the bug, but preupgrade needs to know about the EOL date of a release too. Hence: http://mirrors.fedoraproject.org/releases.txt includes an eol-date entry: [Fedora 12 (Constantine)] stable=True preupgrade-ok=True version=12 mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-12&arch=$basearch installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/12/Fedora/$basearch/os eol-date=20101202 This is kept updated (mostly by me), it lives in the fedora-web git tree in infrastructure. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Sat, Dec 11, 2010 at 01:44:54AM +0100, Kevin Kofler wrote: > Matt Domsch wrote: > > Last built on Fedora 12 (52): > > Huh? > > The right metric is not "when was this last built" but "when was this last > BUILDABLE". We don't randomly rebuild stuff which doesn't need to be > rebuilt. > > E.g.: > > celestia-1.5.1-2.fc12 [u'631077 NEW'] (build/make) steve,mmahut > (the first one on that list) is in F14FTBFS, so it should be recorded as > last buildable in F13 / during early F14 development. Fair point, I simply looked at the dist tag when making that list, instead of looking at the decendents of F*FTBFS which captures the "when" better. Doesn't change that I'd like to seem them all fixed if possible (and several have been since I posted the list), or dropped if impossible (and a few have been blocked by their owners now as being dead upstream, unfixable, and/or obsoleted). Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
biosdevname v0.3.3
biosdevname, now version 0.3.3. I re-added the PCI IRQ Routing Table lookup code. This is used as a fallback, in the event system BIOS doesn't provide index and label information in a way we can get at via sysfs, or via reading SMBIOS directly. This is necessary as quite a few systems I want to have this feature on do not yet expose this info via SMBIOS, yet the values in $PIR are perfectly usable for this purpose. Grab it here: http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz.sign git://linux.dell.com/biosdevname.git I built this today for Fedora rawhide (will be 15), and I encourage other distributions to pick it up as well. shortlog: Matt Domsch (5): add back in PCI IRQ Routing Table lookups, as a fallback add in the pirq.[ch] files too sort PCI device list, set embedded_index better, use PIRQ info as a last resort remove Dell-specific code from make_release.sh bump version Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Wed, Dec 08, 2010 at 12:01:39PM +, Bastien Nocera wrote: > On Wed, 2010-12-08 at 00:50 -0800, Adam Williamson wrote: > > On Wed, 2010-12-08 at 01:05 +, Bastien Nocera wrote: > > > > > And I'll go back to fixing actual bugs encountered by people instead of > > > random bot-driven bugs. > > > > every abrt report, ever, is an actual bug encountered by an actual > > person. They have to be sufficiently narked about the app crashing (and > > it really must have crashed) to click through a rather convoluted > > process (the first time, anyway) to send in a report. > > Given the time it takes triage them, compared to how long it takes to > file them, I'm not sure it's a win for us. > > > so are all these bugs, for that matter: they're actual bugs encountered > > by Matt. The package failing to build is clearly a bug. Matt tried to > > build it and so encountered the bug. Where does it fail to meet your > > criteria? > > It's a file'n'dump bug. There's no one that actually looked at the bugs > to try and analyse them, nobody to offer a reminder in the bugs (they > were filed and left untouched). > > > I agree it's a bit questionable whether we should block packages for > > FTBFS, but the argument can clearly be made; being self-hosting is > > obviously important for an F/OSS project. At some point it devolves into > > Stallmanite wankery about whether you can flash your mouse, but where > > exactly we should draw the line isn't a slam-dunk :) > > I'm not sure what this has to do with anything. The signal to noise > ratio in the RH bugzilla is far too low to be anything useful, and > piling another bug on top of other bugs, with no reminder apart from > this mail is rude. I'm confused. You want reminders filed in the bugs, but then you say the S-to-N ratio is to low to be useful. I could add automatic reminders in bugzilla, but I don't think that solves your key concern. The packages I posted last night were since F12 only. Personally, I'd like to see all FTBFS since even F14 fixed (they all have bugs filed). -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, Dec 06, 2010 at 11:01:20PM -0600, Matt Domsch wrote: > I would like to propose blocking packages at the F15 alpha compose > point if they have not resolved their FTBFS from F14 or earlier. The > lists may be broken down by when they last did build. With 3 > exceptions, these 110 bugs are all still in NEW state as well, so they > haven't had much maintainer love in quite some time (6-18 months). > > I trust module-init-tools will get resolved with an impending upstream > release. Not like that can go unfixed forever. :-) > > > Last built on Fedora 12 (52): And if I resolve all the packages that depend on these 52, I wind up with a few more (136, but this counts some twice, and is binary packages, not source package, so not quite as many in reality): beldi-0:0.9.25-2.fc12.x86_64 celestia-0:1.5.1-2.fc12.x86_64 chm2pdf-0:0.9.1-8.fc14.noarch classpathx-jaf-0:1.0-15.1.fc12.x86_64 classpathx-jaf-javadoc-0:1.0-15.1.fc12.x86_64 cone-0:0.78-3.fc12.x86_64 cone-devel-0:0.78-3.fc12.i686 cone-devel-0:0.78-3.fc12.x86_64 cone-doc-0:0.78-3.fc12.x86_64 coq-0:8.2pl1-1.fc12.x86_64 coq-coqide-0:8.2pl1-1.fc12.x86_64 coq-doc-0:8.2pl1-1.fc12.x86_64 coq-emacs-0:8.2pl1-1.fc12.x86_64 cpm-0:0.23-0.3.beta.fc12.x86_64 drgeo-0:1.1.0-16.fc12.x86_64 drgeo-doc-0:1.6-11.fc12.noarch dumbster-0:1.6-9.fc12.noarch gdmap-0:0.8.1-6.fc12.x86_64 genius-0:1.0.7-1.fc12.x86_64 genius-devel-0:1.0.7-1.fc12.i686 genius-devel-0:1.0.7-1.fc12.x86_64 gnokii-0:0.6.28-1.fc12.i686 gnokii-0:0.6.28-1.fc12.x86_64 gnokii-devel-0:0.6.28-1.fc12.i686 gnokii-devel-0:0.6.28-1.fc12.x86_64 gnokii-smsd-0:0.6.28-1.fc12.x86_64 gnokii-smsd-mysql-0:0.6.28-1.fc12.x86_64 gnokii-smsd-pgsql-0:0.6.28-1.fc12.x86_64 gnome-do-plugins-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-banshee-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-bibtex-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-clawsmail-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-eog-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-epiphany-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-evolution-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-firefox-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-flickr-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-pidgin-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-rhythmbox-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-tasque-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-thunderbird-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-tomboy-0:0.8.2-1.fc12.x86_64 gnome-do-plugins-vinagre-0:0.8.2-1.fc12.x86_64 gnome-genius-0:1.0.7-1.fc12.x86_64 gnome-phone-manager-0:0.65-8.fc14.x86_64 gnome-phone-manager-telepathy-0:0.65-8.fc14.x86_64 gpsk31-0:0.5-4.fc12.x86_64 gshutdown-0:0.2-6.fc12.x86_64 gsql-0:0.2.1-4.fc12.i686 gsql-0:0.2.1-4.fc12.x86_64 gsql-devel-0:0.2.1-4.fc12.i686 gsql-devel-0:0.2.1-4.fc12.x86_64 gsql-engine-mysql-0:0.2.1-4.fc12.x86_64 gsql-plugins-0:0.2.1-4.fc12.x86_64 gtkglextmm-0:1.2.0-10.fc12.i686 gtkglextmm-0:1.2.0-10.fc12.x86_64 gtkglextmm-devel-0:1.2.0-10.fc12.i686 gtkglextmm-devel-0:1.2.0-10.fc12.x86_64 guile-gnome-platform-0:2.16.1-4.fc12.i686 guile-gnome-platform-0:2.16.1-4.fc12.x86_64 guile-gnome-platform-devel-0:2.16.1-4.fc12.i686 guile-gnome-platform-devel-0:2.16.1-4.fc12.x86_64 gwave-0:2-18.20090213snap.fc13.x86_64 htmldoc-0:1.8.27-13.fc12.x86_64 imgtarget-0:0.1.4-4.fc12.x86_64 ipa-server-0:1.2.2-4.fc15.x86_64 jack-audio-connection-kit-0:1.9.6-2.fc15.i686 jack-audio-connection-kit-0:1.9.6-2.fc15.x86_64 javatar-0:2.5-2.fc13.x86_64 kanatest-0:0.4.8-3.fc12.x86_64 kdetv-0:0.8.9-13.fc12.i686 kdetv-0:0.8.9-13.fc12.x86_64 koji-web-0:1.4.0-4.fc15.noarch kpolynome-0:0.1.2-15.fc12.x86_64 ktechlab-0:0.3.70-3.20090304svn.fc12.x86_64 libctl-0:3.0.2-10.fc12.i686 libctl-0:3.0.2-10.fc12.x86_64 libctl-devel-0:3.0.2-10.fc12.i686 libctl-devel-0:3.0.2-10.fc12.x86_64 libfreebob-0:1.0.11-6.fc12.i686 libfreebob-0:1.0.11-6.fc12.x86_64 libfreebob-devel-0:1.0.11-6.fc12.i686 libfreebob-devel-0:1.0.11-6.fc12.x86_64 libopensync-plugin-gnokii-1:0.22-4.fc12.x86_64 libopensync-plugin-kdepim-1:0.22-6.fc12.x86_64 manaworld-0:0.0.29.1-2.fc12.x86_64 manaworld-music-0:0.0.20-4.fc12.noarch maven-embedder-0:2.0.4-6.fc12.noarch maven-embedder-javadoc-0:2.0.4-6.fc12.noarch maven-plugin-cobertura-0:2.3-3.fc12.noarch maven-plugin-cobertura-javadoc-0:2.3-3.fc12.noarch mingw32-gtkmm24-0:2.19.6-1.fc14.noarch mingw32-libglademm24-0:2.6.7-8.fc12.noarch mingw32-pangomm-0:2.26.0-1.fc12.noarch mingw32-plotmm-0:0.1.2-4.fc12.noarch mod_auth_kerb-0:5.4-5.fc12.x86_64 multiget-0:1.2.0-7.fc12.x86_64 netgo-0:0.5-12.fc12.x86_64 notecase-0:1.6.1-6.fc12.x86_64 oorexx-0:4.0.0-2.4801.fc12.x86_64 oorexx-devel-0:4.0.0-2.4801.fc12.i686 oorexx-devel-0:4.0.0-2.4801.fc12.x86_64 oorexx-docs-0:4.0.0-2.4801.fc12.x86_64 oorexx-libs-0:4.0.0-2.4801.fc12.i686 oorexx-libs-0:4.0.0-2.4801.fc12.x86_64 openvas-client-0:3.0.0-8.fc14.x86_64 ovirt-server-0:0.100-5.fc15.noarch petitboot-0:0.2-4.fc12.x86_64 pigment-0:0.3.17-3.fc12.i686 pigment-0:0.3.17-3.fc12.x86_64 pigment-devel-0:0.3.17-3.fc12.i686 pigment-devel-0:0.3.17-3.fc12.x86_64 pigment-python-0:0.3.12-3.fc14.x86_64 postgresql-pgpool-ha-0:1.1.
Re: Proposed package blocking due to FTBFS
On Tue, Dec 07, 2010 at 02:10:00PM -0500, Orcan Ogetbil wrote: > On Tue, Dec 7, 2010 at 12:01 AM, Matt Domsch wrote: > > I would like to propose blocking packages at the F15 alpha compose > > point if they have not resolved their FTBFS from F14 or earlier. ??The > > lists may be broken down by when they last did build. ??With 3 > > exceptions, these 110 bugs are all still in NEW state as well, so they > > haven't had much maintainer love in quite some time (6-18 months). > > > > The subtlety here is that a FTBFS does not imply the package is not > functional. A package may be FTBFS due to various trivial reasons, > e.g. the name of a BuildRequires has changed and the new BuildRequires > does not Provides the old one. In such cases, from the functionality > perspective, the package does not need a rebuild. > > Note that I am not advocating keeping these packages unfixed. I wanted > to point out that things might turn ugly and might even trigger an > avalanche when you remove the FTBFS packages from the repo and then > the packages that depend on them will start to cry. skvidal pointed out repoquery --tree-whatrequires can help us find the whole affected set of packages. I'm looking at generating that list now. If we include all ~550 orphan packages in the run, plus the ~100 FTBFS packages, plus all packages that these depend on, I'm sure it'll wind up being a long list. All the more reason to look _now_, and not 2 days before Alpha compose. I believe keeping the distribution self-hosting (meaning, it can build itself) is an important goal. When we have packages that no longer build, either through their fault or through the fault of one of their dependencies, we lose the ability to be self-hosting, and I question the value of being open source if we can't use that source anymore. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Tue, Dec 07, 2010 at 03:35:35PM +1000, Jeffrey Fearn wrote: > Matt Domsch wrote: > > I would like to propose blocking packages at the F15 alpha compose > > point if they have not resolved their FTBFS from F14 or earlier. The > > lists may be broken down by when they last did build. With 3 > > exceptions, these 110 bugs are all still in NEW state as well, so they > > haven't had much maintainer love in quite some time (6-18 months). > > > > I trust module-init-tools will get resolved with an impending upstream > > release. Not like that can go unfixed forever. :-) > > > > perl-Makefile-Parser-0.211-3.fc14 [u'631098 NEW'] (build/make) > > nb,nb,perl-sig > > Isn't the real bug here that koji is allowing Auto Install to run? > > Koji should be exporting: > > export PERL_EXTUTILS_AUTOINSTALL="--skipdeps" Perhaps - but not Koji - mock. I don't use koji in my builds, I use plain vanilla mock, on systems with limited network ability - e.g. no outbound http/ftp/mail capability. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On Mon, Dec 06, 2010 at 11:13:49PM -0600, Garrett Holmstrom wrote: > On 12/6/2010 23:01, Matt Domsch wrote: > > I would like to propose blocking packages at the F15 alpha compose > > point if they have not resolved their FTBFS from F14 or earlier. The > > lists may be broken down by when they last did build. With 3 > > exceptions, these 110 bugs are all still in NEW state as well, so they > > haven't had much maintainer love in quite some time (6-18 months). > > Is the policy we already have for this [1] insufficient or merely > unenforced? > > [1] > http://fedoraproject.org/wiki/Fails_to_build_from_source#Package_Removal_for_Long-standing_FTBFS_bugs Unenforced at F14 alpha stage, and it requires someone preparing a candidate list to drop well ahead of the alpha stage, to give people fair warning. That's what I'm doing here. :-) -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposed package blocking due to FTBFS
ild/make) karsten automake16-1.6.3-18.fc13.1 [u'631215 NEW'] (build/make) karsten db4o-7.4-2.fc13 [u'631066 NEW'] (build/make) pfj eina-0.9.1-1.fc13 [u'599929 NEW'] (build/make) sundaram ember-0.5.6-5.fc13 [u'631439 NEW'] (build/make) atorkhov,wart etherboot-5.4.4-18.fc13 [u'631148 NEW'] (build/make) ehabkost,glommer,virtmaint flexdock-0.5.1-17.fc13 [u'599813 NEW'] (build/make) mycae fsvs-1.2.1-1.fc13 [u'631437 NEW'] (build/make) davidf,wolfy gengetopt-2.22.3-1.fc13 [u'599938 NEW'] (build/make) rishi gpar2-0.3-9.fc13 [u'631134 NEW'] (build/make) drago01 gwave-2-18.20090213snap.fc13 [u'599862 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) chitlesh,tnorth jansson-1.2-1.fc13 [u'599914 ASSIGNED'] (build/make) elanthis kiconedit-4.4.0-1.fc13 [u'599843 NEW'] (build/make) svahl,kkofler,ltinkl,rdieter,than,tuxbrewr klibido-0.2.5-13.fc13 [u'631410 NEW'] (build/make) faucamp linbox-1.1.7-0.2.svn3214.fc13 [u'631173 NEW'] (build/make) tomspur logback-0.9.18-4.fc13 [u'599884 NEW'] (build/make) mef mercury-1.0-0.2.alpha6.fc13 [u'631176 NEW'] (build/make) lkundrak moblin-panel-media-0.0.8-0.2.fc13 [u'631236 NEW'] (build/make) pbrobinson module-init-tools-3.11.1-2.fc13 [u'631365 ASSIGNED'] (build/make) jcm ocaml-deriving-0.1.1a-10.fc13 [u'631141 NEW'] (build/make) rjones,ocamlmaint padevchooser-0.9.4-0.11.svn20070925.fc13 [u'599757 NEW'] (missing_DSO_to_linker__http://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking) lennart puzzles-8887-2.fc13 [u'600029 NEW'] (build/make) bogado pynac-0.1.11-1.fc13 [u'631289 NEW'] (build/make) tomspur rubygem-eventmachine-0.12.10-3.fc13 [u'58 NEW'] (build/make) ruben synaptic-0.57.2-23.fc13 [u'631361 NEW'] (build/make) athimm,pmatilai Last built on Fedora 14 (32): agave-0.4.7-1.fc14 [u'631411 NEW'] (build/make) bonii apanov-edrip-fonts-20100430-2.fc14 [u'631402 NEW'] (build/make) nim,fonts-sig apanov-heuristica-fonts-0.2.2-2.fc14 [u'631412 NEW'] (build/make) nim,fonts-sig audacity-1.3.12-0.4.beta.fc14 [u'631165 NEW'] (build/make) orphan,dtimms beagle-0.3.9-19.fc14 [u'631378 NEW'] (build/make) orphan,psytux epiphany-extensions-2.30.1-2.fc14 [u'599800 NEW'] (build/make) pgordon,pgordon esc-1.1.0-12.fc14 [u'631401 NEW'] (build/make) jmagne halevt-0.1.6.2-1.fc14 [u'631333 NEW'] (build/make) kasal,pertusus,wolfy ircp-tray-0.7.4-1.fc14 [u'599861 NEW'] (build/make) lkundrak kile-2.1-0.8.b4.fc14 [u'599766 NEW'] (build/make) rdieter,kkofler,tuxbrewr libtranslate-0.99-23.fc14 [u'631105 NEW'] (build/make) buc,dwayne link-grammar-4.6.7-3.fc14 [u'599978 NEW'] (build/make) uwog maven-enforcer-1.0-0.1.b2.fc14 [u'631388 NEW'] (build/make) akurtakov,java-sig mingw32-gtkmm24-2.19.6-1.fc14 [u'631110 NEW'] (build/make) sailer,rjones ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make) dcbw mtd-utils-1.3.1-3.fc14 [u'631424 NEW'] (build/make) dwmw2,jwboyer NetworkManager-openvpn-0.8.1-1.fc14 [u'63 NEW'] (build/make) dcbw,choeger,huzaifas,steve NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw opencdk-0.6.6-1400.fc14 [u'631355 NEW'] (build/make) ensc perl-DBD-AnyData-0.09-7.fc14 [u'631453 NEW'] (build/make) spot,perl-sig perl-Gtk2-Sexy-0.05-7.fc14 [u'631368 NEW'] (build/make) cweyl,perl-sig perl-HTML-Template-2.9-7.fc14 [u'631307 NEW'] (build/make) spot,perl-sig perl-IPC-SharedCache-1.3-13.fc14 [u'631300 NEW'] (build/make) spot,perl-sig perl-Makefile-Parser-0.211-3.fc14 [u'631098 NEW'] (build/make) nb,nb,perl-sig perl-Moose-Policy-0.04-2.fc14 [u'631322 NEW'] (build/make) cweyl,perl-sig perl-SQL-Abstract-Limit-0.141-5.fc14 [u'631113 NEW'] (build/make) spot,perl-sig pinot-0.94-5.fc14 [u'599846 NEW'] (build/make) drago01 rsibreak-0.10-3.fc14 [u'631223 NEW'] (build/make) liquidat,rdieter rubygem-chronic-0.2.3-2.fc14 [u'631072 NEW'] (build/make) shreyankg rubygem-rcov-0.9.8-1.fc14 [u'631350 NEW'] (build/make) mkent tilda-0.9.6-4.fc14 [u'631372 NEW'] (build/make) laxathom zsh-4.3.10-5.fc14 [u'631197 NEW'] (build/make) james The best form of feedback is to resolve these bugs, or retire the packages if they're unresolveable or unloved, but specific feedback requested. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2010-12-01 i386
Request-Params,perl-IO-All,perl-IPC-SharedCache,perl-Makefile-Parser,perl-Module-Starter-Plugin-CGIApp,perl-Moose-Policy,perl-MooseX-Singleton,perl-Nagios-Plugin,perl-OpenFrame,perl-PDF-API2,perl-POE-Component-DBIAgent,perl-POE-Component-Logger,perl-POE-Component-SNMP,perl-POE-Component-Server-SOAP,perl-POE-Component-Server-SimpleHTTP,perl-POE-Component-Server-XMLRPC,perl-Params-CallbackRequest,perl-Pipeline,perl-SQL-Abstract-Limit,perl-Sys-Virt,perl-Test-Class,perl-Test-HTTP-Server-Simple-StashWarnings,perl-Test-Memory-Cycle,perl-Test-MockModule,perl-Test-MockObject,perl-Test-WWW-Mechanize,perl-Test-WWW-Mechanize-CGIApp,perl-Tk,perl-WWW-Mechanize pertusus: bitmap,fltk,fvwm,halevt,htmldoc,icewm,intuitively,ltsp,ncview peter: b43-tools pfj: boo,db4o,monodevelop,monodevelop-boo,nant pfrields: nautilus-open-terminal,nautilus-search-tool pghmcfc: perl-File-Comments pgordon: epiphany-extensions,epiphany-extensions,lucidlife pingou: R-Biostrings,R-GenomicRanges,homebank pmatilai: splint,synaptic ppisar: pl,yap psytux: beagle rajeeshknambiar: meiga rakesh: anjuta,gedit-plugins rathann: gnomeradio rdieter: PyKDE,fltk,kbluetooth,kdepim3,kdevelop,kiconedit,kile,knutclient,kopete-cryptography,qt-mobility,qtscriptgenerator,rsibreak,xine-lib,xine-lib rebus: openvas-client redragon: perl-Crypt-Cracklib,perl-Crypt-Cracklib rishi: anjuta,cluttermm rjones: collectd,mingw32-gtkmm24,mingw32-libglade2,mingw32-libglademm24,mingw32-libvirt,mingw32-libxml++,mingw32-pangomm,mingw32-plotmm,ocaml-camlimages,ocaml-deriving rlandmann: fop rnovacek: kdepim3,kdevelop,kdevplatform,taskjuggler robert: perl-CGI-SpeedyCGI robmv: kanatest rstrode: gnome-games,gnome-panel,gnome-utils,gtksourceview2 ruben: perl-Gearman-Client-Async,perl-Nagios-Plugin,pycryptopp,rubygem-eventmachine,whatsup rvokal: gob2,linuxdoc-tools ryan52: ltsp s4504kr: kaya sailer: mingw32-gtkmm24,mingw32-libglade2,mingw32-libglademm24,mingw32-libxml++,mingw32-pangomm,mingw32-plotmm salimma: chronojump,fillmore-lombard,gedit-vala,libhildon,quarry,shotwell scop: vdradmin-am sdz: hulahop sergiopr: esorex sgros: openvas-client shakthimaan: snacc sharkcz: cdcollect,ski sherry151: gnusim8085 sindrepb: gpsk31,xdx slankes: detox smilner: buildbot snirkel: gnokii,gnokii sochotni: aether,log4j,maven-changes-plugin,maven-dependency-plugin,maven-scm,plexus-classworlds,plexus-mail-sender,plexus-runtime-builder somlo: wmx sparks: fop spot: mono-ndoc,mono-nunit22,mono-sharpcvslib,netgo,perl-CGI-Untaint,perl-CGI-Untaint-email,perl-Class-DBI-AsForm,perl-DBD-AnyData,perl-HTML-Template,perl-HTTP-Request-Params,perl-IPC-SharedCache,perl-SQL-Abstract-Limit,perl-Test-MockModule,perl-Test-MockObject ssp: gnome-system-monitor,libSM,libXaw,libXdmcp,libXext,libXmu,libXtst,tsclient,xsri stahnma: rubygem-attributes steve: NetworkManager-openvpn,celestia,cone,perl-IO-All,perl-OpenFrame,perl-Params-CallbackRequest,perl-Pipeline,perl-Sys-Virt,perl-Test-Class,perl-Test-Memory-Cycle,tuxpaint-stamps stevetraylen: myproxy stingray: cuetools stransky: xulrunner-python subhodip: dbh,kdetv sundaram: eina,gxine,gyachi,pyclutter,shotwell supercyper: pcmanx-gtk2,qt-mobility,scidavis svahl: devilspie,kiconedit,kopete-cryptography tagoh: uim tanguy: qucs tbreeds: petitboot terjeros: moserial teseu: gluegen th0br0: pidgin-gfire than: kdevelop,kiconedit,kopete-cryptography,qt-mobility,wordtrans thias: autodir,blackbox,gentoo,libcaca,pigment thl: websec thomasj: kdevelop,kdevplatform,knutclient,six,xine-lib tmraz: ipsec-tools tnorth: LabPlot,avr-libc,gwave tomeu: hulahop tomspur: linbox,pynac toshio: python-nose trasher: gcompris,homebank tremble: perl-QWizard,rubygem-nokogiri trondd: avr-libc tuju: dfu-util tuxbrewr: kdevelop,kiconedit,kile,subtitlecomposer twaugh: foomatic-db ueno: fontik uwog: link-grammar virtmaint: collectd,etherboot,perl-Sys-Virt vlg: granule vpv: mozvoikko walters: gnome-python2-desktop,jna wart: bsd-games,ember,guichan,manaworld,sear wolfy: fsvs,halevt,tcpxtract wtogami: ltsp xavierb: openvas-client,perl-WWW-Search xgl-maint: xorg-x11-drv-geode yaneti: galeon ynakam: seedit yyang: maven-assembly-plugin -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2010-12-01 x86_64
X-Easy,perl-File-Comments,perl-Finance-Quote,perl-Gtk2-Sexy,perl-HTML-FillInForm,perl-HTML-FormFu-Model-DBIC,perl-HTML-Template,perl-HTTP-Request-Params,perl-IO-All,perl-IPC-SharedCache,perl-Makefile-Parser,perl-Module-Starter-Plugin-CGIApp,perl-Moose-Policy,perl-MooseX-Singleton,perl-Nagios-Plugin,perl-Net-FTPServer,perl-OpenFrame,perl-PDF-API2,perl-POE-Component-DBIAgent,perl-POE-Component-Logger,perl-POE-Component-SNMP,perl-POE-Component-Server-SOAP,perl-POE-Component-Server-SimpleHTTP,perl-POE-Component-Server-XMLRPC,perl-Params-CallbackRequest,perl-Pipeline,perl-SQL-Abstract-Limit,perl-Sys-Virt,perl-Test-Class,perl-Test-HTTP-Server-Simple-StashWarnings,perl-Test-Memory-Cycle,perl-Test-MockModule,perl-Test-MockObject,perl-Test-WWW-Mechanize,perl-Test-WWW-Mechanize-CGIApp,perl-Tk,perl-VCS-LibCVS,perl-WWW-Mechanize pertusus: bitmap,fltk,fvwm,halevt,htmldoc,icewm,intuitively,ltsp,ncview peter: b43-tools pfj: boo,db4o,monodevelop,monodevelop-boo,nant pfrields: nautilus-open-terminal,nautilus-search-tool pghmcfc: perl-File-Comments pgordon: epiphany-extensions,epiphany-extensions,lucidlife pingou: R-Biostrings,R-GenomicRanges,homebank pmatilai: splint,synaptic ppisar: pl psytux: beagle rajeeshknambiar: meiga rakesh: gedit-plugins rathann: gnomeradio rdieter: PyKDE,fltk,kbluetooth,kdepim3,kdevelop,kiconedit,kile,knutclient,kopete-cryptography,qt-mobility,qtscriptgenerator,rsibreak,xine-lib,xine-lib rebus: openvas-client redragon: perl-Crypt-Cracklib,perl-Crypt-Cracklib rishi: cluttermm,gengetopt rjones: collectd,mingw32-gtkmm24,mingw32-libglade2,mingw32-libglademm24,mingw32-libvirt,mingw32-libxml++,mingw32-pangomm,mingw32-plotmm,ocaml-camlimages,ocaml-deriving rlandmann: fop rnovacek: kdepim3,kdevelop,kdevplatform,taskjuggler robert: perl-CGI-SpeedyCGI robmv: kanatest rstrode: gnome-games,gnome-panel,gnome-utils,gtksourceview2 ruben: perl-Gearman-Client-Async,perl-Nagios-Plugin,whatsup rvokal: gob2,linuxdoc-tools ryan52: ltsp s4504kr: kaya sailer: mingw32-gtkmm24,mingw32-libglade2,mingw32-libglademm24,mingw32-libxml++,mingw32-pangomm,mingw32-plotmm salimma: chronojump,fillmore-lombard,gedit-vala,libhildon,quarry,shotwell scop: vdradmin-am scottt: qemu sdz: hulahop sgros: openvas-client shakthimaan: snacc sharkcz: cdcollect,ski sherry151: gnusim8085 shreyankg: rubygem-chronic sindrepb: gpsk31,xdx slankes: detox snirkel: gnokii,gnokii sochotni: aether,log4j,maven-changes-plugin,maven-dependency-plugin,maven-scm,plexus-classworlds,plexus-mail-sender,plexus-runtime-builder somlo: wmx sparks: fop spot: mono-ndoc,mono-nunit22,mono-sharpcvslib,netgo,perl-CGI-Untaint,perl-CGI-Untaint-email,perl-Class-DBI-AsForm,perl-DBD-AnyData,perl-HTML-Template,perl-HTTP-Request-Params,perl-IPC-SharedCache,perl-SQL-Abstract-Limit,perl-Test-MockModule,perl-Test-MockObject ssp: gnome-system-monitor,libSM,libXaw,libXdmcp,libXext,libXmu,libXtst,tsclient,xsri stahnma: rubygem-attributes steve: NetworkManager-openvpn,celestia,cone,perl-IO-All,perl-Net-FTPServer,perl-OpenFrame,perl-Params-CallbackRequest,perl-Pipeline,perl-Sys-Virt,perl-Test-Class,perl-Test-Memory-Cycle,tuxpaint-stamps stevetraylen: myproxy stingray: cuetools stransky: xulrunner-python subhodip: dbh,kdetv sundaram: eina,gxine,gyachi,pyclutter,shotwell supercyper: pcmanx-gtk2,qt-mobility,scidavis svahl: devilspie,kiconedit,kopete-cryptography tagoh: uim tanguy: qucs tbreeds: petitboot terjeros: moserial teseu: gluegen th0br0: pidgin-gfire than: kdevelop,kiconedit,kopete-cryptography,qt-mobility,wordtrans thias: autodir,blackbox,gentoo,libcaca,pigment thl: websec thomasj: kdevelop,kdevplatform,knutclient,six,xine-lib tmraz: ipsec-tools tnorth: LabPlot,avr-libc,gwave tomeu: hulahop tomspur: linbox,pynac toshio: python-nose trasher: gcompris,homebank tremble: perl-QWizard,rubygem-nokogiri trondd: avr-libc tuju: dfu-util tuxbrewr: kdevelop,kiconedit,kile,subtitlecomposer twaugh: foomatic-db ueno: fontik uwog: link-grammar virtmaint: collectd,perl-Sys-Virt,qemu vlg: granule vpv: mozvoikko walters: gnome-python2-desktop,jna wart: bsd-games,ember,guichan,manaworld,sear wolfy: fsvs,halevt,tcpxtract wtogami: ltsp xavierb: openvas-client,perl-WWW-Search yaneti: galeon ynakam: seedit yyang: maven-assembly-plugin -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 04:11:52PM -0600, Matt Domsch wrote: > On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote: > > Good day, > > > > Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch: > > > On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote: > > > > On 11/29/2010 08:27 PM, Matt Domsch wrote: > > > > > On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: > > > > >> I've just pushed biosdevname-0.3.1 into rawhide. This is not yet > > > > >> installed by default as part of @base, nor is it used by anaconda, > > > > >> but > > > > >> those changes will come over the next few days. > > > > > I've pushed the comps change to pull biosdevname into @base by > > > > > default. And I've posted a patch to anaconda-devel-list to pull > > > > > biosdevname into the installtime environment. Cross your fingers, > > > > > this is gonna be great! > > > > > > > > Can you expand the release notes section of > > > > > > > > http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > > > > > > > Please include the benefits in that. > > > > > > Done. > > > > I was curious and ran > > $ sudo biosdevname -i wlan0 > > em1 > > > > Does that mean that my wlan0 device would be named em1 when installing - > > lets say - F15? > > If so, this change would affect many users I suppose. > > > > Could you clarify what hardware is affected and what devices will get > > different names? > > In your case, system BIOS reports the device in SMBIOS, where > biosdevname finds it. Now, it marks it as type "Other", when > biosdevname should ignore (it should look for type "Ethernet") - I > think that's a bug in biosdevname, so I'll investigate. In the case of wireless drivers, the current biosdevname RPM includes udev rules that only invoke biosdevname if the kernel names the network device "eth*". Therefore, since the wireless driver named this device "wlan0", udev won't ever invoke biosdevname, and therefore the name will remain "wlan0". Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Wed, Dec 01, 2010 at 01:18:09PM -0500, Przemek Klosowski wrote: > On 11/30/2010 05:24 PM, Matt Domsch wrote: > > On Tue, Nov 30, 2010 at 04:22:54PM -0600, Matt Domsch wrote: > >> On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote: > > >>> Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop > >>> motherboard with dual-NICs. > >>> > >>> Handle 0x002D, DMI type 10, 6 bytes > >>> On Board Device Information > >>> Type: Ethernet > >>> Status: Enabled > >>> Description: Onboard Ethernet > >>> > >>> Handle 0x003D, DMI type 41, 11 bytes > >>> Onboard Device > >>> Reference Designation: Onboard Ethernet > >>> Type: Ethernet > >>> Status: Enabled > >>> Type Instance: 0 > >> > ^ > > > > specifically, em0 for the above device, and em for the > > second NIC specified in SMBIOS... > > > > Huh? so the first device (handle 2D) will be called 'em0' and the second > device (handle 3D) will be also called 'em0'? No. Handle 2D and handle 3D are the same object fundamentally. Type 41 obsoleted Type 10 and subsumed all its information, adding more and making it extensable. BIOS is encouraged to present both so that legacy OSs that don't know about Type 41 still continue to work, albeit without the new information Type 41 provides. This one device will only appear as em0. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 06:36:17PM -0600, Joe Nall wrote: > As someone who deals with HP DL580 boxes with 6+ NICs routinely, > this is good stuff. Deterministic naming of the built in NICs will > simplify installation instructions for us. Thanks for the good word! > Are the internal names going to be lomX or emX? embedded NICs are emX Add-in cards are pci# in both cases, if the device is an SR-IOV NIC, it will append _ to the name for each virtual function. Now, oddly, I don't have a lot of HP gear handy - especially not a Flex10. If someone does, I'd love to know how to tell the various partitions of a Flex10 are on the same port, so we can append _ similar to SR-IOV. I'm asking the same of Broadcom who just published an update to handle NPAR for their 57712 driver to netdev over the weekend. Than -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 04:29:32PM -0600, Michael Cronenworth wrote: > Matt Domsch wrote: > >> > Yes, your system, on new install, or if you delete > >> > /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from > >> > /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names. > > specifically, em0 for the above device, and em for the > > second NIC specified in SMBIOS... > > OK. Perhaps the wiki should be updated to state the feature works more > generically (SMBIOS 2.6+) and not for just Dell/HP systems? I've done so now. > Interesting work, Matt. I'm surprised the Unix purists who would fight > you to death to keep sendmail on desktops would allow you to change the > almighty eth* naming scheme. I've caught flack for years - that's why this is just now happening. The previous released version of biosdevname was over 3 years ago - the pushback was against changing the eth* naming scheme. But there's no other way to do it. I wish there was. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 04:22:54PM -0600, Matt Domsch wrote: > On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote: > > Matt Domsch wrote: > > > I don't expect desktops to expose > > > this information - they have only 1 NIC. > > > > Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop > > motherboard with dual-NICs. > > > > Handle 0x002D, DMI type 10, 6 bytes > > On Board Device Information > > Type: Ethernet > > Status: Enabled > > Description: Onboard Ethernet > > > > Handle 0x003D, DMI type 41, 11 bytes > > Onboard Device > > Reference Designation: Onboard Ethernet > > Type: Ethernet > > Status: Enabled > > Type Instance: 0 > > This is the interesting field. Type 41 obsoletes Type 10, and adds the > Type Instance field. > > > > > Will my network interface names change with this feature or is this > > purely for Dell/HP only? I'm a bit confused by the verbage on the wiki > > page and the part about SMBIOS 2.6. > > Yes, your system, on new install, or if you delete > /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from > /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names. specifically, em0 for the above device, and em for the second NIC specified in SMBIOS... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 04:18:10PM -0600, Michael Cronenworth wrote: > Matt Domsch wrote: > > I don't expect desktops to expose > > this information - they have only 1 NIC. > > Many desktops have dual-NICs. I'm typing from an SMBIOS 2.6 ASUS desktop > motherboard with dual-NICs. > > Handle 0x002D, DMI type 10, 6 bytes > On Board Device Information > Type: Ethernet > Status: Enabled > Description: Onboard Ethernet > > Handle 0x003D, DMI type 41, 11 bytes > Onboard Device > Reference Designation: Onboard Ethernet > Type: Ethernet > Status: Enabled > Type Instance: 0 This is the interesting field. Type 41 obsoletes Type 10, and adds the Type Instance field. > > Will my network interface names change with this feature or is this > purely for Dell/HP only? I'm a bit confused by the verbage on the wiki > page and the part about SMBIOS 2.6. Yes, your system, on new install, or if you delete /etc/udev/rules.d/70-persistent-net.rules and the HWADDR lines from /etc/sysconfig/network-scripts/ifcfg-*, will then use the new names. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote: > Good day, > > Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch: > > On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote: > > > On 11/29/2010 08:27 PM, Matt Domsch wrote: > > > > On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: > > > >> I've just pushed biosdevname-0.3.1 into rawhide. This is not yet > > > >> installed by default as part of @base, nor is it used by anaconda, but > > > >> those changes will come over the next few days. > > > > I've pushed the comps change to pull biosdevname into @base by > > > > default. And I've posted a patch to anaconda-devel-list to pull > > > > biosdevname into the installtime environment. Cross your fingers, > > > > this is gonna be great! > > > > > > Can you expand the release notes section of > > > > > > http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > > > > > Please include the benefits in that. > > > > Done. > > I was curious and ran > $ sudo biosdevname -i wlan0 > em1 > > Does that mean that my wlan0 device would be named em1 when installing - > lets say - F15? > If so, this change would affect many users I suppose. > > Could you clarify what hardware is affected and what devices will get > different names? In your case, system BIOS reports the device in SMBIOS, where biosdevname finds it. Now, it marks it as type "Other", when biosdevname should ignore (it should look for type "Ethernet") - I think that's a bug in biosdevname, so I'll investigate. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 03:25:45PM -0600, Michael Cronenworth wrote: > Matt Domsch wrote: > > I've pushed the comps change to pull biosdevname into @base by > > default. And I've posted a patch to anaconda-devel-list to pull > > biosdevname into the installtime environment. Cross your fingers, > > this is gonna be great! > > Could anaconda not be smart enough to pull this in to only Dell and HP > systems? Is there a reason all users need a new package for only a > handful of hardware that can use it? > > Not that I am attempting to downplay your work, I just wish to > understand why all my systems keep getting Dell packages (yum plugin) > when I don't own any Dell systems. I fixed the yum plugin bit, so that only gets pulled in (on new installs) if you explicitly install firmware-addon-dell. Before it was part of libsmbios, which was pulled in by hal, so was on everyone's system, but that wasn't intentional. There's no way in rpm/yum/anaconda to specify installing packages by hardware type. That I know of at least... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Tue, Nov 30, 2010 at 10:13:30PM +0100, Fabian Deutsch wrote: > Good day, > > Am Dienstag, den 30.11.2010, 13:04 -0600 schrieb Matt Domsch: > > On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote: > > > On 11/29/2010 08:27 PM, Matt Domsch wrote: > > > > On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: > > > >> I've just pushed biosdevname-0.3.1 into rawhide. This is not yet > > > >> installed by default as part of @base, nor is it used by anaconda, but > > > >> those changes will come over the next few days. > > > > I've pushed the comps change to pull biosdevname into @base by > > > > default. And I've posted a patch to anaconda-devel-list to pull > > > > biosdevname into the installtime environment. Cross your fingers, > > > > this is gonna be great! > > > > > > Can you expand the release notes section of > > > > > > http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > > > > > Please include the benefits in that. > > > > Done. > > I was curious and ran > $ sudo biosdevname -i wlan0 > em1 > > Does that mean that my wlan0 device would be named em1 when installing - > lets say - F15? > If so, this change would affect many users I suppose. > > Could you clarify what hardware is affected and what devices will get > different names? Can I get a dmidecode dump? Curious... That could be hitting a legacy codepath that I need to delete (looking up the value in the PCI IRQ Routing Table). My intention is to only report for devices that the BIOS explicitly exposes via SMBIOS, or in future, ACPI. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Wed, Dec 01, 2010 at 02:37:04AM +0530, Rahul Sundaram wrote: >On 12/01/2010 12:34 AM, Matt Domsch wrote: > > Can you expand the release notes section of > > [1]http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > Please include the benefits in that. > > Done. > >Can you explain why only those particular HP and Dell models are affected >by this change?* Is there more models expected to adopt this change?* It requires BIOS to expose the information the tool uses (SMBIOS 2.6, or HP's proprietary method). I know recent Dell and HP servers do, I'm not aware of any others at this time, nor do I have visibility into the plans of other vendors. I don't expect desktops to expose this information - they have only 1 NIC. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Mon, Nov 29, 2010 at 08:48:05PM +0530, Rahul Sundaram wrote: > On 11/29/2010 08:27 PM, Matt Domsch wrote: > > On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: > >> I've just pushed biosdevname-0.3.1 into rawhide. This is not yet > >> installed by default as part of @base, nor is it used by anaconda, but > >> those changes will come over the next few days. > > I've pushed the comps change to pull biosdevname into @base by > > default. And I've posted a patch to anaconda-devel-list to pull > > biosdevname into the installtime environment. Cross your fingers, > > this is gonna be great! > > Can you expand the release notes section of > > http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > > Please include the benefits in that. Done. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: > I've just pushed biosdevname-0.3.1 into rawhide. This is not yet > installed by default as part of @base, nor is it used by anaconda, but > those changes will come over the next few days. I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great! Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
biosdevname hitting rawhide
I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days. biosdevname, on at least Dell 10G and newer, and HP 6G and newer servers, provides "better" BIOS-suggested names for embedded NIC ports, and NIC ports on add-in PCI cards. If you have existing names, as defined in /etc/udev/rules.d/70-persistent-net.rules, those names will continue to be used, and biosdevname won't ever be invoked. Likewise, if you have device names assigned to MAC addresses in /etc/sysconfig/network-scripts/ifcfg-eth*, biosdevname won't be invoked. But going forward, on new installs, biosdevname _will_ be used to change the names. The naming scheme is thus: Embedded ports: em PCI cards: pci#_ (the latter on SR-IOV and soon Network Partitioned (NPAR) devices). If you have a Dell or HP server, and would like to try it out, please: # yum install biosdevname # rm /etc/udev/rules.d/70-persistent-net.rules # sed -i -e '/^HWADDR=/d' /etc/sysconfig/network-scripts/ifcfg-eth* # rmmod # modprobe (or reboot instead) # ifconfig -a will show all the devices with the new naming scheme. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Thu, Nov 18, 2010 at 10:06:17PM +, Peter Robinson wrote: > On Thu, Nov 18, 2010 at 9:16 PM, Matt Domsch wrote: > > On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote: > >> I've had a few off-list conversations with various community members > >> about this. One thing that came up was that the alternative namespace is > >> necessary, but also that "lom" is a sub-optimal choice. One idea that > >> did come up was simply to call them "net" (net0, etc.) or perhaps "net" > >> followed by another letter like "netm" or something. To avoid > >> bikeshedding this to death though, I think Matt's "lom" naming is fine > >> for the moment unless we happen to all agree on something else. > > > > There's an upstream conversation about the naming convention here: > > http://marc.info/?l=linux-hotplug&m=129003163201746&w=2 > > > > For the record, right now, biosdevname uses: > > > > ?emN_(vf).(vlan) for embedded devices > > ?pci(slot)#(port)_(vf).(vlan) for add-in cards. > > > > If the device does not support SR-IOV, then the _(vf) part is omitted. > > > > If no huge objections on the upstream thread, I'll push this into > > rawhide ASAP. > > Presumably there will be something in place that won't change this on > upgrades so that people don't end up in inoperable networking on the > next 'yum upgrade' after it gets installed. yes, if /etc/udev/rules.d/70-persistent-net.rules is in place, that is used in preference to whatever biosdevname would choose. If a rule for your device isn't in that file though, biosdevname kicks in to ask udev to rename it. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 08:48:09AM -0600, Chris Adams wrote: > In any case, is this going to be something that can be disabled easily? > We have something like 18 years of Linux networking history that says > ethernet devices are "eth[0-9]+", and I'm not really interested in > auditing all the tools and scripts I use to make sure they handle > something different at this time. It can always be disabled at runtime by writing whatever you want into /etc/udev/rules.d/70-persistent-net.rules. Whether or not we'll have a way to disable it in the installer is TBD, right now there won't be. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Tue, Nov 16, 2010 at 09:32:37AM -0500, Jon Masters wrote: > I've had a few off-list conversations with various community members > about this. One thing that came up was that the alternative namespace is > necessary, but also that "lom" is a sub-optimal choice. One idea that > did come up was simply to call them "net" (net0, etc.) or perhaps "net" > followed by another letter like "netm" or something. To avoid > bikeshedding this to death though, I think Matt's "lom" naming is fine > for the moment unless we happen to all agree on something else. There's an upstream conversation about the naming convention here: http://marc.info/?l=linux-hotplug&m=129003163201746&w=2 For the record, right now, biosdevname uses: emN_(vf).(vlan) for embedded devices pci(slot)#(port)_(vf).(vlan) for add-in cards. If the device does not support SR-IOV, then the _(vf) part is omitted. If no huge objections on the upstream thread, I'll push this into rawhide ASAP. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-11-17)
On Tue, Nov 16, 2010 at 12:38:28PM -0700, Kevin Fenzi wrote: > #topic #496 F15Feature: ConsistentNetworkDeviceNaming - > http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming > https://fedorahosted.org/fesco/ticket/496 I have several conflicts with the FESCo meeting time tomorrow where this will be discussed. I tried to make the feature page as complete as possible. There are clearly some details to be worked out yet, like the exact bikesheding name for onboard devices, but I would hope the committee could review recognizing that's only an implementation detail, not central to the feature. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sun, Nov 14, 2010 at 11:57:59AM +0100, Tomasz Torcz wrote: > On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: > > On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: > > > Greetings. > > > > > > Fedora 14 was a pretty relaxing and stable release. I'm thinking that > > > Fedora 15 may be much more exciting. ;) > > > > biosdevname installed by default, used in the installer and at runtime > > to rename Dell and HP server onboard NICs from non-deterministic > > "ethX" to clearly labeled "lomX" matching the chassis silkscreen. > > But why ???lomX??? for all? Isn't Lights-Out-Management available only on > first > ethernet port and often on dedicated port? This has nothing to do with Lights-Out-Management. LOM also == LAN on Motherboard. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 10:11:11PM -0800, John Reiser wrote:
> On 11/13/2010 06:34 PM, Matt Domsch wrote:
> > biosdevname installed by default, used in the installer and at runtime
> > to rename Dell and HP server onboard NICs from non-deterministic
> > "ethX" to clearly labeled "lomX" matching the chassis silkscreen.
> >
> > http://marc.info/?l=linux-hotplug&m=128892593821639&w=2
>
> In that message I see:
> ** No rename for all others "ethX" (no change for NICs in PCI
> slots/USB/others)
>
> I'd like an option to assign "ethX" to NICs in /sys/devices/pci* order.
> This matches chassis PCI slot order on many, many motherboards.
> I get confused when ethX is assigned in a different order.
>
> You can bind ethX to a specific card [not slot] by using HWADDR= in
> /etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer
> an option to assign ethX by PCI slot, because that's what I can see when
> I plug in the cables. My NICs are various brands and models,
> but I treat them all as generic because that is much simpler,
> especially in the beginning.
For you, biosdevname has alternate naming policies. You'll edit
/etc/udev/rules.d/71-netdevice.rules, changing --policy=loms to
--policy={something else}, with various choices available:
[loms|kernelnames|all_ethN|all_names|embedded_ethN_slots_names|smbios_names]
all_ethN does exactly what you want, embedded devices first, then all
other devices in ascending PCI slot order.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: > On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: > > Greetings. > > > > Fedora 14 was a pretty relaxing and stable release. I'm thinking that > > Fedora 15 may be much more exciting. ;) > > biosdevname installed by default, used in the installer and at runtime > to rename Dell and HP server onboard NICs from non-deterministic > "ethX" to clearly labeled "lomX" matching the chassis silkscreen. > > http://marc.info/?l=linux-hotplug&m=128892593821639&w=2 > > Exciting, not really. Necessary, absolutely! Feature page: https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a bunch of packages
On Sat, Nov 13, 2010 at 08:37:19PM -0600, Matt Domsch wrote: > On Sat, Nov 13, 2010 at 12:50:51PM -0600, Ian Weller wrote: > > Hi all, > > > > I haven't had the time to even look at these packages and keep them up > > to date, so I'm orphaning them. Please take them if they are important > > to you :) > > > > Many of these have either dead/slow upstreams, or I'm too dead/slow to > > update them in time. > > > > irclog2html > > I think Fedora Infrastructure uses this for zodbot logs, yes? I've > used it for Town Hall log postings predating zodbot. I or someone in > FI should take it if it's actively used... supybot-meetbot, which is what we use these days for zodbot, does its own log creation, not using irclog2html. I withdraw my offer to take this then. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org default repo on installation
On Fri, Nov 12, 2010 at 02:02:28PM +0100, Rudolf Kastl wrote: > Heyyas. I actually gave boot.fedoraproject.org a testrun and i > realized that by default a repository called "installation" is > selected with a static repo url. instead i have actually figured that > selecting the usual standard fedora repositories work aswell and they > point to the mirrorlist instead. Why is a seperate installation repo > selected by default? I use this setup for installs from behind my firewalls, where I would need an HTTP proxy to reach the normal Fedora mirrorlist public repos, but where my installation repo is inside the firewall, so install can complete, and I can later instruct yum to use a proxy to get updates etc. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a bunch of packages
On Sat, Nov 13, 2010 at 12:50:51PM -0600, Ian Weller wrote: > Hi all, > > I haven't had the time to even look at these packages and keep them up > to date, so I'm orphaning them. Please take them if they are important > to you :) > > Many of these have either dead/slow upstreams, or I'm too dead/slow to > update them in time. > > irclog2html I think Fedora Infrastructure uses this for zodbot logs, yes? I've used it for Town Hall log postings predating zodbot. I or someone in FI should take it if it's actively used... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: > Greetings. > > Fedora 14 was a pretty relaxing and stable release. I'm thinking that > Fedora 15 may be much more exciting. ;) biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic "ethX" to clearly labeled "lomX" matching the chassis silkscreen. http://marc.info/?l=linux-hotplug&m=128892593821639&w=2 Exciting, not really. Necessary, absolutely! Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
On Fri, Oct 08, 2010 at 06:03:04PM +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > In most cases I try sync all branches if there no real reasons to make > differences. > > After made some changes in origin/master and commit is I also must do > for each available branches something similar: > fedpkg switch-branch el5; > git pull > git merge origin/master > git push > fedpkg build > fedpkg update I find this works to apply the version from 'master' into the current (say, el5) branch. $ git merge -s recursive -X theirs master There are valid reasons for doing this - e.g. a bug fix release of a package by the upstream, that doesn't break the ABI. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-09-01 i386
On Tue, Sep 07, 2010 at 02:51:30PM -0700, Jesse Keating wrote: > How does that manage to build in Koji, which doesn't exactly have bigger > systems, just more of them. Koji doesn't use tmpfs for the buildroots, nor does it time out builds after 6 hours like I do... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-09-01 i386
On Tue, Sep 07, 2010 at 02:02:05PM -0600, Orion Poplawski wrote: > On 09/06/2010 08:24 PM, Matt Domsch wrote: > > paraview-3.8.0-4.fc14 (build/make) orion,pertusus > > Sorry [Errno 28] No space left on device > > Looks like a check for that is in order. Holy cow. So, 8GB RAM, 16GB swap, over 4 hours to compile (5 on i386), and it ran out of memory in the tmpfs. Repeatedly. Perhaps I need a way to specially build some apps, or just skip them. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-09-01 x86_64
On Wed, Sep 08, 2010 at 02:40:37AM +0900, Mamoru Tasaka wrote: > Matt Domsch wrote, at 09/07/2010 11:24 AM +9:00: > > Fedora Fails To Build From Source Results for x86_64 > > using rawhide from 2010-09-01 > > > > Full rebuild of all packages. Each failed package was retried two > > additional times. Those listed below have failed at least three > > attempts to build. > > > > Sorry I can't mail to everyone individually this round, we've grown to > > so many contributors that I've hit a scaling problem in FAS so I can't > > convert all the package owners to their real email addresses tonight. > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > Well, now you are going to file FTBFS bugs with the message like > "foo-V-R Failed To Build From Source against the _rawhide_ tree" > and to make these bugs block _F14FTBFS_ . > > Would you clarify if this build results are for rawhide (i.e. F-15) > tree or for F-14 tree? it's F14, not rawhide. The new "branch early" step wasn't reflected in my scripts, and I didn't catch that early enough. I'll start F15 once F14 releases, before it's called F15. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2010-09-01 i386
ooth: eclipse-emf-query,eclipse-emf-validation,eclipse-m2m-qvtoml,eclipse-mdt-ocl,eclipse-mdt-uml2,eclipse-phpeclipse,jakarta-commons-validator,msv,plexus-interactivity mccann: libfakekey mclasen: at-spi,seahorse-plugins,shotwell mcpierce: matahari mcrha: evolution,evolution-data-server mdomsch: gpxe mebourne: gdmap mef: apache-resource-bundles,jarjar,javamail,logback,maven-doxia melmorabity: apache-commons-exec mfojtik: rubygem-json mgarski: xscorch mgieseki: zint mhlavink: apcupsd mildew: bro mjakubicek: antlr3,valknut,valknut mjw: java-1.6.0-openjdk mkent: rubygem-rcov mmahut: celestia,cpm,gpredict,gpredict,sunbird mmaslano: perl-DBD-CSV,perl-DBD-CSV,perl-Log-Log4perl,perl-Log-Log4perl,perl-SQL-Statement,perl-SQL-Statement mmatejov: java-1.6.0-openjdk monnerat: insight mtasaka: gwaei,kazehakase,monafont,multiget,rubygem-hoe,sirius,tasque mterry: deja-dup musuruan: tecnoballz mycae: flexdock nando: jack-rack nb: perl-Makefile-Parser,perl-Makefile-Parser nbecker: filelight ndim: cstream,evolution-couchdb,libgphoto2 nhosoi: 389-admin nim: apanov-edrip-fonts,apanov-heuristica-fonts nkinder: 389-admin nmurray: ImageMagick npajkovs: alsa-plugins nsantos: matahari nushio: beagle,gnome-do-plugins ocamlmaint: coq,ocaml-camlimages,ocaml-cil,ocaml-deriving,ocaml-lablgtk oget: creox,kde-plasma-yawp,kmplayer,qjson,serafettin-cartoon-fonts olea: chronojump omajid: java-1.6.0-openjdk orion: cmake,eclipse-photran,environment-modules,hdf,hdf5,paraview orphan: tla overholt: aqute-bndlib,eclipse-anyedit pbrobinson: contacts,dates,evolution-couchdb,geoclue,gupnp-igd,libccss,moblin-panel-media,network-manager-netbook,syncevolution pcheung: axis,plexus-archiver perex: alsa-plugins perl-sig: pcsc-perl,perl-DBD-AnyData,perl-DBD-CSV,perl-DBD-Multi,perl-DBIx-Class,perl-GD,perl-Gtk2-Notify,perl-Gtk2-Sexy,perl-HTML-FormFu,perl-HTML-Template,perl-IPC-SharedCache,perl-Log-Log4perl,perl-Makefile-Parser,perl-Moose-Policy,perl-Perl-Critic,perl-RRD-Simple,perl-SQL-Abstract-Limit,perl-SQL-Statement,perl-Test-Email pertusus: cmake,fltk,gnash,halevt,hdf,hdf5,htmldoc,ncview,paraview,texlive peter: libmpdclient,pspp pfj: db4o pghmcfc: ORBit,bluefish,perl-RRD-Simple pgordon: epiphany-extensions,epiphany-extensions,lucidlife,nemiver phuang: ibus-qt pingou: R-BSgenome pknirsch: openhpi plindner: memcached pmachata: ElectricFence,ltrace pmatilai: synaptic pmuldoon: libgtk-java ppisar: perl-DBD-CSV pravins: scim-sayura psytux: beagle pwouters: driftnet,xoo rakesh: anjuta,gedit-plugins,ginac,ginac,uriparser rathann: freefem++,gabedit,mkvtoolnix,raidutils rdieter: cmake,eigen2,fltk,kdelibs3,kdepim,kdnssd-avahi,kdnssd-avahi,kiconedit,kile,kipi-plugins,kmplayer,konq-plugins,polkit-qt,rsibreak red: mailody remi: perl-Gtk2-MozEmbed rhughes: gnome-color-manager,gnome-packagekit,gnome-packagekit,gnome-power-manager,gnome-power-manager rishi: anjuta,gtest rjones: mingw32-gtkmm24,mingw32-libglademm24,mingw32-pangomm,mingw32-plotmm,mingw32-qwt,ocaml-camlimages,ocaml-cil,ocaml-deriving,ocaml-lablgtk rmeggins: 389-admin rmyers: eclipse-anyedit rnovacek: kdepim,python-psyco robmv: kanatest rombobeorn: PragmARC,mine_detector rrankin: gtk+extra rrelyea: coolkey,pam_pkcs11 rrix: kdepim rstrode: libgnome ruben: memcached,rubygem-eventmachine rvinyard: bit,clipsmm,conexus,dbus-cxx,papyrus rvokal: system-config-bind s4504kr: highlight,subcommander sailer: mingw32-gtkmm24,mingw32-libglademm24,mingw32-pangomm,mingw32-plotmm,mingw32-qwt salimma: chronojump,fbreader,gedit-vala,quarry schwab: glibc scop: javasqlite sharkcz: gtkterm,openhpi,roxterm sherry151: gnusim8085 sindrepb: gpsk31,xdx snecker: mapnik,mapnik snirkel: gnokii,gnokii sochotni: apache-commons-beanutils,jakarta-commons-discovery,jakarta-commons-validator,log4j,maven-dependency-plugin,maven-doxia,maven-eclipse-plugin,maven-idea-plugin,maven-jxr,maven-scm,maven-surefire,maven2,modello,plexus-appserver,plexus-containers,plexus-mail-sender,plexus-registry,plexus-runtime-builder,xbean spike: rmic-maven-plugin spot: banshee,banshee,gbdfed,netgo,pam_pkcs11,perl-DBD-AnyData,perl-GD,perl-HTML-Template,perl-IPC-SharedCache,perl-SQL-Abstract-Limit ssp: rdesktop,xorg-x11-drv-qxl,xsri stalwart: gsql stefanriemens: mingw32-OpenSceneGraph steve: NetworkManager-openvpn,celestia,cone,tuxpaint-stamps stevetraylen: root subhodip: kdetv sundaram: deja-dup,eina,shotwell supercyper: pcmanx-gtk2 svahl: kiconedit,konq-plugins swagiaal: libgtk-java tagoh: eruby tanguy: qucs tbreeds: petitboot tbzatek: fpc,nautilus,nautilus,seahorse,seahorse-plugins terjeros: gle,lshw,sqliteman than: doxygen,isdn4k-utils,kdelibs3,kdepim,kiconedit,konq-plugins,wordtrans thias: autodir,linux_logo,memcached,pigment thomasj: enlightenment,kdepim,kipi-plugins,stfl timn: papyrus tjikkun: python-telepathy tmraz: opensc,pcsc-perl,pcsc-tools tnorth: LabPlot,gwave tomspur: linbox,pynac trasher: gcompris tremble: rubygem-icalendar tu
Fedora rawhide FTBFS status 2010-09-01 x86_64
logo,memcached,pigment thm: lmms thomasj: kdepim,kipi-plugins,stfl timn: papyrus tjikkun: python-telepathy tmraz: opensc,pcsc-perl,pcsc-tools tnorth: LabPlot,alliance,gwave tomspur: linbox,pynac trasher: gcompris tremble: rubygem-icalendar tuxbrewr: kdelibs3,kdepim,kdnssd-avahi,kiconedit,kile,kipi-plugins,kmplayer,konq-plugins,spicebird,subtitlecomposer tuxmadhu: grub uggla: gwaei uwog: link-grammar vda: busybox,busybox victorv: freemarker vlg: granule walters: antlr3 wart: crossfire-maps,cyphesis,ember,manaworld,sear weli: buildnumber-maven-plugin,maven-deploy-plugin,maven-eclipse-plugin,maven-install-plugin,maven-resources-plugin wolfy: fsvs,grip,halevt xavierb: libclaw xgl-maint: xorg-x11-drv-qxl xhorak: scantailor yaneti: galeon yyang: maven-doap-plugin,maven-install-plugin,maven-one-plugin,maven-plugin-testing,maven-plugin-tools,maven-repository-plugin,maven-resources-plugin,maven-shared,maven-shared,maven-wagon,maven2,maven2,modello,plexus-containers zaitcev: chunkd zoeloelip: antlr3 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100805 changes
On Thu, Aug 05, 2010 at 06:21:00PM +0100, Richard W.M. Jones wrote: > On Thu, Aug 05, 2010 at 10:46:08AM +, Rawhide Report wrote: > > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 > > 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 > > Unfortunately qemu isn't installable at the moment so I can't rebuild > this. The error is: > > DEBUG util.py:255: Error: Package: > 2:qemu-system-x86-0.13.0-0.2.20100727gitb81fe95.fc14.x86_64 (build) > DEBUG util.py:255: Requires: /usr/share/gpxe/e1000-0x100e.rom That's due to the new gpxe I built this morning changing the name of that ROM file. jforbes says he'll get to it over the next few days. However, the f14 build shouldn't have even hit updates-testing yet, much less into the alpha compose. There is no bodhi update with it yet exactly because of this... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 mirror list still pointing at rawhide
On Sun, Aug 01, 2010 at 05:32:47PM +0100, M A Young wrote: > I was trying a yum update on F-14 (fedora-release-14-0.7) but was offered > a few F-15 packages. I checked > https://mirrors.fedoraproject.org/metalink?repo=fedora-14&arch=x86_64 > and the mirrors it points to are all rawhide rather than the F-14 branch. My bad, I missed the branch announcement to remove the redirects. They're removed now, you should be getting F14 content from the 14/ directories now. Thanks, Matt Fedora Mirror Wrangler -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-GnuPG-Interface/EL-6 .cvsignore, 1.4, 1.5 perl-GnuPG-Interface.spec, 1.11, 1.12 sources, 1.4, 1.5
Author: mdomsch
Update of /cvs/extras/rpms/perl-GnuPG-Interface/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv28707
Modified Files:
.cvsignore perl-GnuPG-Interface.spec sources
Log Message:
update to match devel branch
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 21 May 2008 00:32:59 - 1.4
+++ .cvsignore 8 Jul 2010 16:31:35 - 1.5
@@ -1 +1 @@
-GnuPG-Interface-0.36.tar.gz
+GnuPG-Interface-0.42.tar.gz
Index: perl-GnuPG-Interface.spec
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/perl-GnuPG-Interface.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-GnuPG-Interface.spec 26 Jul 2009 06:18:18 - 1.11
+++ perl-GnuPG-Interface.spec 8 Jul 2010 16:31:35 - 1.12
@@ -1,6 +1,6 @@
Name: perl-GnuPG-Interface
-Version:0.36
-Release: 3%{?dist}
+Version:0.42
+Release:4%{?dist}
Summary:Perl interface to GnuPG
Group: Development/Libraries
License:GPLv2+ or Artistic
@@ -8,9 +8,9 @@ URL:http://search.cpan.org/d
Source0:
http://cpan.org/modules/by-module/GnuPG/GnuPG-Interface-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: gpg, perl(Class::MethodMaker), perl(ExtUtils::MakeMaker)
+BuildRequires: gpg, perl(Any::Moose), perl(ExtUtils::MakeMaker)
Requires: gpg, perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
-Requires: perl(Class::MethodMaker)
+Requires: perl(Any::Moose)
%description
@@ -35,7 +35,8 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%check
chmod 0700 test
-make test
+# GnuPG-Interface needs to read from /dev/tty to run its tests.
+# make test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -44,11 +45,26 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc ChangeLog README NEWS THANKS COPYING GPL Artistic
%{perl_vendorlib}/GnuPG
-%{perl_vendorlib}/auto/GnuPG
%{_mandir}/man3/*.3*
%changelog
+* Thu Jul 8 2010 Matt Domsch - 0.42-4.el6
+- rebuild for RHEL 6
+
+* Sun May 02 2010 Marcela Maslanova - 0.42-4
+- Mass rebuild with perl-5.12.0
+
+* Mon Dec 7 2009 Stepan Kasal - 0.42-3
+- rebuild against perl 5.10.1
+
+* Sun Oct 04 2009 Emmanuel Seyman - 0.42-2
+- Disable tests because they need /dev/tty to run
+
+* Fri Oct 02 2009 Emmanuel Seyman - 0.42-1
+- Update to 0.42
+- Fix rpmlint errors
+
* Sat Jul 25 2009 Fedora Release Engineering
- 0.36-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
@@ -82,7 +98,7 @@ rm -rf $RPM_BUILD_ROOT
- FC-3 doesn't use the patch1
* Sun Sep 11 2005 Matt Domsch 0.33-3
-- use perldoc -t and %_smp_mflags
+- use perldoc -t and the _smp_mflags macro
* Sun Aug 28 2005 Matt Domsch 0.33-2
- add Requires: gpg, always apply secret-key-output-1.patch, as it works on
Index: sources
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 21 May 2008 00:32:59 - 1.4
+++ sources 8 Jul 2010 16:31:35 - 1.5
@@ -1 +1 @@
-6f097d3076b3311e8ef20ce3c2865c66 GnuPG-Interface-0.36.tar.gz
+c5cc5426c02b93900cb96f4879c9be28 GnuPG-Interface-0.42.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Licensing Guidelines Update - Please Read
Am Wed, 07 Jul 2010 16:29:01 -0400 > schrieb "Tom \"spot\" Callaway" : cim-schema-docs has no license file packaged with it. /me blames the DMTF. The content is a separate tarball. I suppose we could suck the license file out of the other content zip (the MOF files) and include here. Thoughts? mirrormanager-client and gpxe* are false positives - all subpackages include the licenses in %doc. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed release criteria additions for F14+
On Thu, Jun 24, 2010 at 11:28:16AM -0700, Adam Williamson wrote: > Sorry for the cross-post, but figured it's worth CCing devel in case > anyone has concerns on these. > > I'm currently working on a plan to expand desktop validation testing. As > part of the discussion around this, Christoph Wickert proposed several > additions to the release criteria that seem sensible to me. I'd like to > propose we add these to the criteria for F14 and on: > > * Saving passwords in the desktop default keyring (if the desktop > implements one), and retrieving passwords from the keyring, must work > > * The desktop default update manager must not periodically check for > updates when the system is booted live, but must periodically check for > updates when running on an installed system > > * The desktop's offered mechanisms for shutting down, logging out and > rebooting must work > > Anyone have comments or objections to these? Suggestions for what > release they should come in? I'd say #1 should be final and #2 and #3 > should be beta, off the top of my head. Given that #1 should be already present for several desktops, as a feature for any new desktops I'd expect it to be in place by Beta. Regression testing ahead of RC->Gold should test all three to ensure functionality. Otherwise, +1 for me. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Sun, Jun 20, 2010 at 10:24:27PM -0400, Orcan Ogetbil wrote: > On Thu, Jun 3, 2010 at 10:42 AM, Matt Domsch wrote: > > Fedora Fails To Build From Source Results for x86_64 > > using rawhide from 2010-06-01 > > > [cut] > > Question 1: > Suppose package A fails to build from source due to a bug in package B > that is listed in package A's BuildRequires. Now that package B gets > fixed, and it is possible to build package A from source without any > modification. Do we need to bump A's release and do the rebuild in > this case? No. List in bug A that it "Depends on" the bug number for B. Close the bug against A once package B is fixed and its own bug closed. > Question 2: > What is the likelihood of a mass rebuild in this cycle? I've heard rumors that it's likely, but I don't know for certain what the trigger would be this time. Likely a glibc or gcc change. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Fri, Jun 04, 2010 at 08:57:06AM +0200, Gianluca Sforna wrote: > On Thu, Jun 3, 2010 at 4:42 PM, Matt Domsch wrote: > > > > It also doesn't report any failing packages that have subsequently > > been built and published in koji's rawhide since 06-01. ??That should > > cut down on the "but I just fixed that!" ??responses from now on. > > One question. Is committing the fix in CVS enough or do I need to also > push an update? In my case the package missed a BR that was only used > to do tests in the %check section, I removed it now in CVS but the > resulting binary package is basically the same as before. Given that we'll likely have a mass rebuild during the F14 dev cycle, you can just fix it in CVS and wait for the mass rebuild to generate the new pacakge. But please leave the bug open, change to "MODIFIED" status, until the package is rebuilt. Otherwise, I'll wind up filing a duplicate bug. I'm not inclined to try to teach my scripts to pull from CVS directly. It's been really nice only dealing with published SRPMS, even though there is some latency involved (packages fixed in CVS this morning won't appear until tomorrow). Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-06-01 x86_64
On Thu, Jun 03, 2010 at 09:42:04AM -0500, Matt Domsch wrote: > Fedora Fails To Build From Source Results for x86_64 > using rawhide from 2010-06-01 > > This run continues from the previous run, rebuilding those packages > that failed during the earlier run, or that changed between 2010-05-27 > and 06-01. I filed a ton of bugzillas, basically this list. I apologize if there are some duplicates to already-existing FTBFS bugs opened for earlier releases - that wasn't intentional, but please take this opportunity to fix the problem and close both bugs then. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora rawhide FTBFS status 2010-06-01 i386
aker gajownik: kadu gemi: GtkAda,curry,gtkglarea2,gtklp,sweep,ucblogo,wings ghosler: gyachi giallu: buildbot grof: imgtarget,photoprint hadess: gmyth,gnome-phone-manager,sound-juicer hedayat: rcsslogplayer,rcssmonitor hman-it: themonospot-gui-qt hubbitus: qutim huzaifas: gnumeric,gnumeric i18n-team: ibus-table-erbi,ibus-table-extraphrase,ibus-table-translit,ibus-table-wubi,ibus-table-yong iankent: autofs iarnell: perl-Catalyst-Plugin-Session-Store-FastMmap,perl-DBIx-Class-TimeStamp,perl-Data-FormValidator-Constraints-DateTime icon: pidgin-sipe iefremov: ugene imain: matahari itamarjp: qt izhar: minbar jafo: python-pydns jakub: valgrind jcollie: python-lxml,python-lxml jeckersb: rubygem-cobbler jgold: qmpdclient,qmpdclient jjames: cvc3,pmd jjh: libtommath jjohnstn: jetty jkeating: plexus-containers jlayton: nfs-utils jlblanco: mrpt jmoyer: autofs jmrodri: tanukiwrapper,velocity john5342: qzion jorton: mod_auth_kerb jpopelka: python-lxml jreznik: kbluetooth,kdepim,kdesvn,qt julian: diveintopython,sap jussilehtola: pokerth jwboyer: petitboot jwrdegoede: TnL,cegui,chromium-bsu,hedgewars,vegastrike kaboon: amarok kaio: ibus-table-erbi,ibus-table-erbi,ibus-table-extraphrase,ibus-table-extraphrase,ibus-table-translit,ibus-table-translit,ibus-table-wubi,ibus-table-wubi,ibus-table-yong,ibus-table-yong kanarip: rubygem-attributes,rubygem-ferret,rubygem-pervasives kasal: halevt,perl-SVN-Mirror ke4qqq: php-pear-File-Bittorrent2 kevin: kphotoalbum kkofler: kbluetooth,kde-l10n,kdepim,kiconedit,kile,knutclient,konq-plugins,krusader,qt konradm: sympy kvolny: qmmp kwizart: aimage,cinepaint,icc_examin,oyranos kwright: symkey kylev: python-beaker,python-pylons langel: java-1.6.0-openjdk,json laxathom: gammu,gshutdown,guile-gnome-platform,pengupop,raidem,rubygem-json leigh123linux: rb_libtorrent lennart: padevchooser liangsuilong: ibus-table-extraphrase,ibus-table-translit,ibus-table-wubi,ibus-table-yong limb: cellwriter,cfdg,cfdg-fe,chipmunk,cylindrix,freenx-server,gnotime,liquidwar,nx,pengupop,tennix,vdrift linuxdonald: qps lkundrak: intellij-idea,ircp-tray,java-1.6.0-openjdk,jps,perl-Test-WWW-Selenium,starlab lmacken: python-beaker,python-migrate,python-repoze-what lonetwin: wmfire ltinkl: kde-l10n,kdepim,kiconedit,kipi-plugins,konq-plugins,qt lucilanga: evolution-rspam makghosh: qps,sirius mathstuf: kde-l10n,kdepim,krazy2,libqinfinity matt: condor maxamillion: gsh mbacovsk: python-migrate mbooth: eclipse-mylyn,jakarta-commons-validator mccann: libfakekey mclasen: seahorse-plugins mdbooth: libguestfs mebourne: gdmap mef: logback,maven-doxia melmorabity: apache-commons-exec mgarski: krusader,xscorch mildew: bro mjakubicek: json mjw: java-1.6.0-openjdk mkent: rubygem-mixlib-cli,rubygem-mixlib-config,rubygem-mixlib-log,rubygem-newgem mmahut: PythonCard,skychart,starplot mmaslano: perl-IO-Compress-Bzip2,perl-IO-Compress-Bzip2,perl-Padre,perl-XML-LibXSLT mmatejov: java-1.6.0-openjdk mtasaka: kazehakase,ochusha,sirius,themonospot-gui-qt mycae: flexdock nbecker: kdiff3 nsantos: matahari nushio: gnome-do-plugins ocamlmaint: ocaml-camlimages oget: kmplayer,mscore,serafettin-cartoon-fonts olea: chronojump oliver: eclipse ondrejj: sagator orion: gdl,kdesvn,pdfedit,plplot orphan: compat-libgda,kadu,nas overholt: eclipse,eclipse,eclipse-mylyn,jetty,json,maven2-plugin-shade pbrobinson: dates,emerillon,nbtk,network-manager-netbook,syncevolution pcheung: bcel,bsf,jakarta-commons-httpclient perl-sig: perl-Archive-RPM,perl-CGI-Application-Plugin-DBIx-Class,perl-Catalyst-Plugin-Session-Store-FastMmap,perl-Crypt-DSA,perl-DBI-Dumper,perl-DBIx-Class-TimeStamp,perl-Data-FormValidator-Constraints-DateTime,perl-DateTime-Format-DateManip,perl-Fedora-Bugzilla,perl-GSSAPI,perl-IO-Compress-Bzip2,perl-Module-Install,perl-POE-Component-Child,perl-POE-Component-Client-HTTP,perl-Padre,perl-Pod-Xhtml,perl-SVN-Mirror,perl-Test-Aggregate,perl-Test-WWW-Mechanize,perl-WWW-Curl,perl-XML-LibXSLT pertusus: halevt,ncview peter: pspp pghmcfc: perl-Crypt-DSA pgordon: epiphany-extensions,epiphany-extensions,lucidlife,rb_libtorrent pingou: R-BSgenome,R-BSgenome.Celegans.UCSC.ce2,R-Biostrings,R-IRanges,rkward pmachata: make ppisar: perl-IO-Compress-Bzip2,perl-Padre,perl-XML-LibXSLT pvrabec: bro pwouters: driftnet,xoo rajeeshknambiar: meiga rakesh: anjuta,gedit-plugins rdieter: OpenGTL,PyQt4,amarok,amarok,kasablanca,kbluetooth,kde-l10n,kdepim,kdnssd-avahi,kdnssd-avahi,kiconedit,kile,kipi-plugins,kmplayer,knutclient,konq-plugins,kphotoalbum,polkit-qt,qt,qzion rezso: mapnik,qgis rhughes: gnome-color-manager richardfearn: findbugs,findbugs-contrib ricky: python-migrate,python-webtest rishi: anjuta,gengetopt,gtest,starplot rjones: libguestfs,mingw32-boost,mingw32-qt,mingw32-qwt,ocaml-camlimages rmattes: mediatomb rmccabe: clustermon,ricci robmv: svnkit rombobeorn: GtkAda rrankin: gtk+extra rrix: kobby,libqinfinity rstrode: gnome-applets sailer: mingw32-boost,mingw32-qt,mingw32-qwt,vfrnav salimma: Django,chronojump,evolution-remove-duplicates,gedit-vala,pure sconklin: gpsk31,xdx,xfhell,xnec2c shishz: perl-XML-LibXSLT silfreed: qgis sindrepb: gpsk31,xdx,xfhell slankes: merkaartor smilner: Django,Django,buildbot snecker: mapnik snirkel: gnome-phone-manager,gnome-phone-manager sochotni: jakarta-commons-discovery,jakarta-commons-validator sparks: php-pear-File-Bittorrent2 spot: AcetoneISO2,R-RScaLAPACK,gbdfed,tcl-tileqt ssp: xsri stahnma: kflickr stefanriemens: mingw32-OpenSceneGraph steve: perl-GSSAPI,perl-Module-Install steved: nfs-utils,rpcbind stevetraylen: lcgdm sundaram: eina,gyachi supercyper: qtiplot,qtiplot svahl: kiconedit,konq-plugins sxw: perl-Catalyst-View-JSON tbreeds: petitboot tbzatek: seahorse-plugins tejas: choqok terjeros: sqliteman than: PyQt4,kde-l10n,kdepim,kiconedit,konq-plugins,qt,wordtrans thias: autodir,pigment,xar thm: python-markdown2 thomasj: amarok,blokkal,kipi-plugins,knutclient,me-tv till: merkaartor tmz: cgit tnorth: LabPlot,avr-libc,gwave toshio: python-migrate trondd: avr-libc tuxbrewr: amarok,kasablanca,kde-l10n,kdepim,kdnssd-avahi,kiconedit,kile,kipi-plugins,kmplayer,konq-plugins,kphotoalbum,qt,subtitlecomposer uwog: asio,link-grammar virtmaint: libguestfs vlg: granule walters: gnome-python2-desktop wart: ember,sear wolfy: halevt xgl-maint: xorg-x11-fonts ynemoy: spring yyang: maven-shared,maven-shared,maven2,maven2,modello -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
