Re: Needless use of %defattr (in 4464 packages)
On 01/29/2016 03:30 PM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Jan 29, 2016 at 12:36:24PM +0100, Petr Šabata wrote: On Mon, Jan 25, 2016 at 04:34:55PM -0600, Jason L Tibbitts III wrote: perl-Affix-Infix2Postfix (steve, psabata) perl-Algorithm-IncludeExclude (iarnell, psabata) perl-Algorithm-Merge (iarnell, psabata) perl-Authen-PAM (steve, psabata) perl-Carp-Clan-Share (iarnell, psabata) perl-Class-Container (steve, psabata) perl-Class-DBI-Plugin-DeepAbstractSearch (iarnell, mmaslano, ppisar, psabata, jplesnik) perl-Context-Preserve (iarnell, mmaslano, ppisar, psabata, jplesnik) perl-Convert-ASCII-Armour (steve, psabata) perl-Convert-Bencode (iarnell, psabata) perl-Convert-Bencode_XS (iarnell, psabata) perl-Crypt-CAST5_PP (iarnell, psabata) perl-Crypt-DES_EDE3 (steve, psabata) perl-Data-Denter (iarnell, mmaslano, ppisar, psabata, jplesnik) perl-Data-FormValidator-Constraints-DateTime (iarnell, psabata) perl-Data-Taxi (iarnell, psabata) perl-DateTime-Format-ICal (steve, xavierb, psabata) perl-DateTime-Format-SQLite (iarnell, ppisar, psabata, mmaslano, jplesnik) perl-DBIx-Class-TimeStamp (iarnell, psabata) perl-Devel-Caller (steve, psabata) perl-Devel-FastProf (iarnell, psabata) perl-Expect-Simple (iarnell, mmaslano, ppisar, psabata, jplesnik) perl-File-ChangeNotify (psabata, ppisar, mmaslano, jplesnik) perl-File-Pid (iarnell, psabata) perl-File-Read (iarnell, psabata) perl-File-Type (steve, psabata) perl-File-Type-WebImages (iarnell, psabata) Cleaned and modernized these. More next week. P Can you estimate how much time you spent on this? Though I am not Petr, I can tell how much time I spent to change this for my perl-packages. Ca. 20-30 per day. However this figure is misleading, because - I used this occasion as an opportunity to clean up my specs an to get rid of rpm-anachronisms (many of my perl package had not been touched for years). - I used this occasion as an opportunity to experiment with rpm. - this was done as a side-job in parallel to other tasks. Basically, wrt. perl-packages, I believe a more or less mechanical/scripted remover of "%defattr" would be possible, if that's what you're aiming at. However, I do not see much reason in such kind of undertaking, because I don't see any reason why %defattr needs to away in the next couple of years. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/27/2016 09:37 PM, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 27 January 2016 at 12:51, Ralf Corsepius wrote: On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote: Hi, Ralf. On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote: On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote: fakeroot (athimm, rathann, corsepiu, moceap) Are you sure the owners list you used is current? I stepped down as fakeroot maintainer and removed myself many months ago. While you're not listed as POC anymore, you're still listed as committer for rawhide, F23 and F22 branches of fakeroot, so the list above is correct. Crap, I wish fedora had a usable pkgdb UI ;) While we're at it: Did you notice that this package is completely messed up? I guess, I am going to BZ it. To be honest, I haven't. It works well enough for me. I only has two open bugs, one of which is a missing upstream feature. By all means, file a bug report if there is something else wrong with it. For reasons I do not understand, the package contains 0-sized files, files with permission 0 (non-exec, non-readable). Even rpmlint loudly complains about them. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1302526 Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/27/2016 01:22 PM, Pierre-Yves Chibon wrote: On Wed, Jan 27, 2016 at 12:51:03PM +0100, Ralf Corsepius wrote: On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote: Hi, Ralf. On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote: On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote: fakeroot (athimm, rathann, corsepiu, moceap) Are you sure the owners list you used is current? I stepped down as fakeroot maintainer and removed myself many months ago. While you're not listed as POC anymore, you're still listed as committer for rawhide, F23 and F22 branches of fakeroot, so the list above is correct. Crap, I wish fedora had a usable pkgdb UI ;) Upstream must have missed all the tickets you filled to improve things... Do you think this behavior of yours fair? I don't. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/27/2016 10:13 PM, Jason L Tibbitts III wrote: "RC" == Ralf Corsepius <rc040...@freenet.de> writes: RC> Are you sure the owners list you used is current? I pulled them directly from pkgdb at the time I generated the list. There's no way that they could have been any more current when I sent the mail. I realize, the pkgdb doesn't reflect reality. It seems to contain lots of "zombie maintainers". At least, I see people listed of whom I know to have left Fedora years ago, some of them even after a FESCO AWOL. Looks seems to me as if Fedora doesn't have a proper "checkout from Fedora" process, which is gradually turning pkgdb into a "zombie maintainer" graveyard. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/27/2016 11:32 AM, Dominik 'Rathann' Mierzejewski wrote: Hi, Ralf. On Wednesday, 27 January 2016 at 09:28, Ralf Corsepius wrote: On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote: fakeroot (athimm, rathann, corsepiu, moceap) Are you sure the owners list you used is current? I stepped down as fakeroot maintainer and removed myself many months ago. While you're not listed as POC anymore, you're still listed as committer for rawhide, F23 and F22 branches of fakeroot, so the list above is correct. Crap, I wish fedora had a usable pkgdb UI ;) While we're at it: Did you notice that this package is completely messed up? I guess, I am going to BZ it. Also, I noticed a number of maintainers on your list, whose accounts should have been closed down (AWOL) and their package ownership probably be removed (athimm is one example of such case, chitlesh would be another one). What's going on here? The list is correct according to PackageDB. I don't rememeber if anyone ever initiated the non-responsive packager process for athimm or chitlesh. I don't know if somebody filed one against athimm (I had thought so), but I am the one who filed one against chitlesh (https://fedorahosted.org/fesco/ticket/1484). Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Needless use of %defattr (in 4464 packages)
On 01/25/2016 11:34 PM, Jason L Tibbitts III wrote: fakeroot (athimm, rathann, corsepiu, moceap) Are you sure the owners list you used is current? I stepped down as fakeroot maintainer and removed myself many months ago. Also, I noticed a number of maintainers on your list, whose accounts should have been closed down (AWOL) and their package ownership probably be removed (athimm is one example of such case, chitlesh would be another one). What's going on here? Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should 'dnf install gtk3-devel.i686' work?
On 01/20/2016 05:59 PM, Michael Schwendt wrote: On Wed, 20 Jan 2016 17:32:52 +0100, Ralf Corsepius wrote: IMO, this is supposed to work => Bug The big question would be: Where? It cannot work as long as gtk3-devel relies on pkgconfig(foo) dependencies instead of arch-specific explicit Requires. AFAIU,the problem behind this is, in case of multilibs, there are several providers providing non-arched rpm tags: Example: # rpm -q -provides -p libXt-devel-1.1.5-2.fc23.i686.rpm libXt-devel = 1.1.5-2.fc23 libXt-devel(x86-32) = 1.1.5-2.fc23 pkgconfig(xt) = 1.1.5 # rpm -q -provides -p libXt-devel-1.1.5-2.fc23.x86_64.rpm libXt-devel = 1.1.5-2.fc23 libXt-devel(x86-64) = 1.1.5-2.fc23 pkgconfig(xt) = 1.1.5 Apparently, dnf doesn't resolve such deps correctly, but seem to try to resolve such deps either by a "first match" or "primary arch" strategy and doesn't take a depchains an "inherited arch" into account: # dnf remove libICE-devel libSM-devel libX11-devel libXt-devel # dnf install libXt-devel.i686 ... Installing: libICE-devel x86_64 1.0.9-3.fc23 fedora 54 k libSM-devel x86_64 1.2.2-3.fc23 fedora 17 k libX11i6861.6.3-2.fc23 fedora 616 k libX11-devel x86_64 1.6.3-2.fc23 fedora 984 k libXt i6861.1.5-2.fc23 fedora 174 k libXt-devel i6861.1.5-2.fc23 fedora 450 k [note: libICE-devel.i686, libSM-devel.i686 are missing] Seems to me as if history is repeating - IIRC, we've had this issue in early stage of yum, as well ;) Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should 'dnf install gtk3-devel.i686' work?
On 01/21/2016 09:27 AM, Richard W.M. Jones wrote: On Thu, Jan 21, 2016 at 04:10:00AM +0100, Ralf Corsepius wrote: On 01/20/2016 08:23 PM, Richard W.M. Jones wrote: I have filed a bug (against gtk3 for now) about this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1300432 I still don't know the cause of this issue, I don't think this is gtk3's fault (alone). It's possible to generate similar breakdowns for many packages (My gut feeling is, this culprit is dnf). Example: # dnf install usbguard-devel.i686 I don't know about this package, but for gtk3-devel.i686 No prob. This was just a random package with fewer deps than gtk3, I picked up for testing. I also tried yum-deprecated with the same results. I also tried - same result. I guess, investigating this any further will require pre-dnf Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should 'dnf install gtk3-devel.i686' work?
On 01/20/2016 08:23 PM, Richard W.M. Jones wrote: I have filed a bug (against gtk3 for now) about this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1300432 I still don't know the cause of this issue, I don't think this is gtk3's fault (alone). It's possible to generate similar breakdowns for many packages (My gut feeling is, this culprit is dnf). Example: # dnf install usbguard-devel.i686 Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should 'dnf install gtk3-devel.i686' work?
On 01/21/2016 12:45 AM, Neal Gompa wrote: We don't store libraries and headers in such a way that the different arches can coexist without clobbering. Headers being installed to /usr/include must be multilib capable. I.e. they either must be arch-independent or contain sufficient magic (conditionals) to cope with all fedora archs. That would be possible if we have something like this: /usr/lib/ /usr/include/ Current practice is /usr/include/ ... for nonarch headers. /usr/{lib,lib64}/... for arched parts of a package, comprising arched headers. For example, a 32-bit x86 platform would probably use "i686-redhat-linux-gnu", whereas a 64-bit x86 platform would use "x86_64-redhat-linux-gnu". Without that, it would be tough to guarantee that installing the 32-bit version of a devel package would produce a consistent and sane build compared to an actual 32-bit chroot. No, cf. above. Does anybody still have a non yum-only based x86_64 system? I suspecting and am pretty sure this issue is caused by yet another brokenness in dnf. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Should 'dnf install gtk3-devel.i686' work?
On 01/20/2016 04:50 PM, Richard W.M. Jones wrote: If you're on freshly installed Fedora 23 (x86-64), then dnf install gtk3-devel.x86_64 gets you everything you need to compile a simple Gtk3 application[1]. However on the same host if you do: dnf install gtk3-devel.i686 then there's a lot missing before you can compile a 32 bit Gtk3 application[2]. I had to install the following dependencies (found by tedious trial-and-error) before I could compile it: dnf -y install {pango,pixman,zlib,libpng,expat,mesa-libEGL,libX11,libdrm,libxcb,libXau,libXdamage,libXfixes,libXxf86vm,libXext,mesa-libGL,libXrender,harfbuzz,graphite2,gdk-pixbuf2,atk,cairo-gobject,libXinerama,libXi,libXrandr,libXcursor,libXcomposite,wayland,libwayland-client,libxkbcommon,libwayland-cursor,mesa-libwayland-egl,libepoxy,at-spi2-atk,at-spi2-core,dbus,glib2,glibc}-devel.i686 Is this a bug or is it not expected this would work or I am doing it wrong? IMO, this is supposed to work => Bug The big question would be: Where? Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F24 System Wide Change: Default Local DNS Resolver
On 12/11/2015 05:25 PM, Jiri Eischmann wrote: So my worry is that we would be an OS which is more secure than others, but doesn't work in many networks. If something doesn't work reliably, the logical consequence to me would be to keep it strictly optional (opt-in) and not to make it default. You can bet what the users would decide for... Exactly ... take into account the "user experience" some Fedora-"novelties" communicated over the years ;) Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: How to collect "bundled" virtual provide
On 12/02/2015 03:46 PM, Vít Ondruch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dne 2.12.2015 v 15:30 Stephen Gallagher napsal(a): In accordance with the bundling policy, it *is* carrying a virtual Provides to allow us to identify whether it is affected by discovered CVEs. This brings me to interesting question, how to actually know that one should be looking for some bundled library? I don't think this was ever addressed, c.f. the section "Bundling and Duplication of system libraries" in https://fedoraproject.org/wiki/Packaging:Guidelines but I believe it'd be useful to have some page where we can see what is bundled and where is it bundled. I don't think that "repoquery" is the answer, since this does not give good enough overview nor statistics, etc. repoquery has been rendered widely unusable by dnf. Ralf -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: where is mariadb-10.0.21-1.fc23 ?
On 11/11/2015 09:29 AM, Adam Williamson wrote: On Wed, 2015-11-11 at 07:02 +0100, Ralf Corsepius wrote: Other strange case is the package perl-Event-RPC-1.06-1.fc21 [2] even more strange [3] comment 16 says that push perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ... [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882 Similar - broken upgrade path: dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm No, the OP had it right. In some cases, we can wind up with older updates being pushed over newer ones. That is, if an update 'foo-2.0-1' is submitted, then an update 'foo-2.0-2' is submitted, then 'foo-2.0-2' is pushed stable, then 'foo-2.0-1' is pushed stable *later* (which can happen with auto-karma if the foo-2.0-1 update is never withdrawn), 2.0-1 can be pushed over the top of 2.0-2. NVRs in later fedora release/updates *must* be greater than those in older release, at all times. This is a defect of the release process, which needs to be fixed. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: where is mariadb-10.0.21-1.fc23 ?
On 11/11/2015 03:26 AM, Sérgio Basto wrote: Hi, Where is mariadb-10.0.21-1.fc23 ? [1] says that have been push to stable but upgrading my system, mariadb is downgraded from mariadb-10.0.21 to mariadb-10.0.20 ! [1] https://bodhi.fedoraproject.org/updates/FEDORA-2015-13442 Broken upgrade path. The NEVR of mariadb in fc23 is less than that in fc22: dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/m/mariadb-common-10.0.21-1.fc22.x86_64.rpm dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/m/mariadb-common-10.0.20-3.fc23.x86_64.rpm Other strange case is the package perl-Event-RPC-1.06-1.fc21 [2] even more strange [3] comment 16 says that push perl-Event-RPC-1.07-1.fc23 and one minute later comment 17 says perl-Event-RPC-1.06-1.fc23 has been pushed to the Fedora 23 ... [2] https://bodhi.fedoraproject.org/updates/FEDORA-2015-16392 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1264882 Similar - broken upgrade path: dl.fedoraproject.org/pub/fedora/linux/updates/22/x86_64/p/perl-Event-RPC-1.07-1.fc22.noarch.rpm dl.fedoraproject.org/pub/fedora/linux/development/23/x86_64/os/Packages/p/perl-Event-RPC-1.06-1.fc23.noarch.rpm Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
On 11/07/2015 04:55 AM, Reindl Harald wrote: Am 06.11.2015 um 20:11 schrieb Germano Massullo: For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it seriously? Probably. with that argumentation Fedora would drop i686 at all No. darktable handles the situation on sse3-less CPUs gracefully at run-time. The actually problem is darktable wanting to be compiled with -msse3, which means being compiled with a Fedora incompatible instruction set, on both i386 and x86_64. well, i don't have any non x86_64 machien but the argumentation is bous You are right, these days in professional PC-usage, i686ers likely are rare and hard to find. But in personal (private) PC-usage, the situation is different. There, 5/6-year old 32bit PCs are still wide spread and will be supported by Windows for many years. Also consider, people are using Linux on such machines to extend these machines life time. Feel free to drop the i386, if you want drop the end-user/desktop market and to leave this market to Ubuntu, Debian and other distributions. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
On 11/07/2015 05:03 AM, Reindl Harald wrote: Am 07.11.2015 um 05:00 schrieb Luya Tshimbalanga: On 06/11/15 07:29 PM, Ralf Corsepius wrote: But if upstream doesn't care, it's going to be a problem. :-( Exactly - That's the actual problem. Upstream does not care and Fedora seems unable to address this issue. Ralf According to my system, it has SSSE3. Is it SSE3? That's what my question actually was about. I see ssse3 on all my x86_64ers, I see sse3 on my 32bit atoms, but I don't know if ssse3 implies sse3 and I don't know what -msse3 actually does to the instruction set when being used on x86_64ers and which impact it has (-msse3 is not part of Fedora's gcc implicit CFLAGS). any system not older than 10 years has SSE3 and frankly systems older than 10 years are hardly a traget for Fedora at all So, Fedora or Linux as a resort to escape Windows on old HW is not a Fedora target anymore? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
On 11/06/2015 09:50 PM, Stuart Gathman wrote: On 11/06/2015 02:11 PM, Germano Massullo wrote: For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. For that kind of thing, add a runtime test for required CPU features at startup. That's what they actually do. cf. https://bugzilla.redhat.com/show_bug.cgi?id=1278064#c14 $ darktable [dt_init] unfortunately we depend on SSE3 instructions at this time. [dt_init] please contribute a backport patch (or buy a newer processor). That may not be necessary if the app already fails in a friendly way on old CPUs (as opposed to hanging or mysterious crashes). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Retire a package from Fedora i686 (not x86_64)
On 11/06/2015 10:00 PM, Kevin Kofler wrote: Germano Massullo wrote: For example, SSE3 instructions set is one of the minimum requirements and 99% of 32 bit only CPUs do not support it. Only Pentium 4 >= Prescott architecture supports it. I think building it with SSE3 is better than excluding the architecture entirely. And FYI, requiring SSE3 is not really allowed even for x86_64 (you are allowed to assume only SSE2), so by that argument, there is no architecture left. ACK. Does anybody know if there are any x86_64/64bit-CPUs which do not support sse3? I don't see sse3 in /proc/cpuinfo of any machine I have, but I also don't see any runtime error/warning from darktable. Of course, a better solution would be to fix the package to work on all CPUs you support. ACK. But if upstream doesn't care, it's going to be a problem. :-( Exactly - That's the actual problem. Upstream does not care and Fedora seems unable to address this issue. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: make unmaintained ??
On 10/26/2015 05:21 PM, drago01 wrote: On Sun, Oct 25, 2015 at 8:24 PM, Stephen John Smoogenwrote: On Oct 25, 2015 12:53, "Jan Kratochvil" wrote: On Sun, 25 Oct 2015 01:07:47 +0200, Zbigniew Jędrzejewski-Szmek wrote: I built 4.1 for rawhide. If that checks out to be OK, I can push an update for F23 also. I do not understand why a major rebase could be permitted after all the F-23 freezing stages? It may cause FTBFSes or even broken builds. What is then all the release engineering good for? Why not to just run Rawhide then? I have to agree. I have been bitten too many times by minor tweaks breaking builds in the OS. However the rules where a completely frozen build system was causing problems in the past so I am expecting make is considered less important than gcc? We have been shipping gcc bugfix updates all the time ... there is no reason why we shouldn't do the same for make. I do not agree with you. Make has a long history and has been known to be notorious of introducing subtile bugs and behavioral changes in minor releases. IMO, this should be sufficient reason to apply maximal prudence and caution to any update to make. In other words, I consider it reasonable apply make updates to rawhide only and to watch for what will happen during the next mass-rebuild. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf and file provides
On 10/24/2015 03:55 AM, Adam Williamson wrote: On Fri, 2015-10-23 at 18:19 -0600, Orion Poplawski wrote: Got this is a resent koji rawhide build: DEBUG util.py:393: No matching package to install: '/bin/csh' I'm assuming this is a quirk of dnf now being the default, but needs to get fixed. There is no /bin/csh in the package, only /usr/bin/csh /bin/csh is an explicit provides of the tcsh package The fact certain versions of dnf don't handle them correctly is yet another bug in dnf and/or it's infrastructure. . /bin is a symlink to /usr/bin , so you can call /bin/csh and it'll work, but /bin/csh does not exist in the package. Thus it does not provide it. Requires should always use /usr/bin or /usr/sbin . /bin/csh is similar to /bin/sh. They are being used in "#!" shebangs and therefore must stay in packages and must be handles correctly, independently of what the proponents of UsrMov believe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf and file provides
On 10/24/2015 02:19 AM, Orion Poplawski wrote: Got this is a resent koji rawhide build: DEBUG util.py:393: No matching package to install: '/bin/csh' I'm assuming this is a quirk of dnf now being the default, but needs to get fixed. This is dnf bug https://bugzilla.redhat.com/show_bug.cgi?id=1271053 which has broken f24's builders. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: jehane pushed to fusioninventory-agent (f23). "new version (..more)"
On 10/15/2015 07:46 PM, notificati...@fedoraproject.org wrote: From c7493300b75beeed3980723ecddc68185438a0a8 Mon Sep 17 00:00:00 2001 From: jehaneDate: Sun, 11 Oct 2015 17:01:09 +0200 Subject: new version - Upstream switch to github, minor spec adaptation --- .gitignore | 1 + fusioninventory-agent.spec | 16 ++-- sources| 2 +- 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/.gitignore b/.gitignore index c55cab8..5bdc389 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,3 @@ /FusionInventory-Agent-2.3.15.tar.gz /FusionInventory-Agent-2.3.16.tar.gz +/2.3.17.tar.gz diff --git a/fusioninventory-agent.spec b/fusioninventory-agent.spec index 75572f2..a8de963 100644 --- a/fusioninventory-agent.spec +++ b/fusioninventory-agent.spec @@ -9,11 +9,11 @@ Group: Applications/System License: GPLv2+ URL: http://fusioninventory.org/ -Version: 2.3.16 -Release: 5%{?dist} +Version: 2.3.17 +Release: 1%{?dist} #BuildArch: noarch -Source0: http://search.cpan.org/CPAN/authors/id/G/GR/GROUSSE/FusionInventory-Agent-%{version}%{?prever}.tar.gz -Source1: %{name}.cron +Source0: https://github.com/fusioninventory/fusioninventory-agent/archive/%{version}.tar.gz +Source1: %{name}.cron #Source2: %{name}.init #Source3: %{name}.service @@ -163,7 +163,7 @@ Requires: perl(Parse::EDID) %description task-inventory fusioninventory-task-inventory %prep -%setup -q -n FusionInventory-Agent-%{version}%{?prever} +%setup -q -n %{name}-%{version}%{?prever} # This work only on older version, and is ignored on recent cat < - 2.3.17 +- new version +- Upstream switch to github, minor spec adaptation Please reconsider the change and pick up tarballs from cpan.org. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposal: retire lesstif in f24 and beyond
On 10/10/2015 07:39 PM, Zbigniew Jędrzejewski-Szmek wrote: On Sat, Oct 10, 2015 at 07:20:22AM +0200, Ralf Corsepius wrote: I know, we are late in the release schedule, but I am considering to switching at least Inventor to motif on fc23, as well - It's unimportant enough to most users, but is important to me ;) I think that in a case of leaf package like that it totally makes sense to switch even this late before release. Removal of a dependency on lesstif seems important enough. Rebuilding Inventor against motif requires switching mesa-libGLw and Inventor to motif, i.e. a chain build consisting of mesa-libGLw and Inventor. As Inventor seems to be the only user of mesa-libGLw, this should be pretty harmless. Unless somebody objects, I am going to rebuild these 2 packages for fc23 tomorrow. Ralf PS.: derelict-GL3-devel also claims to require mesa-libGLw, but I can not spot any actual source-code nor object dependency beween GLw nor Xm. I therefore am inclined to believe this to be a packaging bug in derelict. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: retire lesstif in f24 and beyond
On 10/09/2015 09:17 PM, Stephen John Smoogen wrote: On 8 October 2015 at 17:04, Kevin Koflerwrote: Christopher Meng wrote: IMO motif should 'Obsoletes' lesstif in Fedora since motif is free now. The reason we kept lesstif even after OpenMotif was finally freed is because OpenMotif only implements the Motif 2 API, whereas lesstif implemented the Motif 1 API. Back then, a lot of Motif applications did not compile with Motif 2. A lot of applications still do not mainly because by the time OpenMotif was out.. "Motif" was dead except for legacy computer code that a lot of research institutes still use. It looks from the amount of porting that has been done in this thread that a lot of those problems are easier to fix now? From the people who did the porting was it a quick fix or a bunch of patches? As far as the packages I touched are concerned, the "porting effort" was very low. The effort basically was reflecting the packaging dep-naming changes into the specs. I did not have to apply any changes to the packages' source code. My guess is, on the code-level, today's "Motif" is sufficiently backward compatible, the packages already saw testing against Motif or even been developed on Motif (and then ported to lesstif)[1]. I point, I which makes me wonder, is Fedora seemingly being late in the switch to Motif in comparison to other distros. A problem hiding is package installation conflicts between the *-devel package of different versions of the lesstif, openmotif and motif packages. Therefore, I tried to stay with lesstif on fedora < 24 and switch to motif only on fedora >= 24. I know, we are late in the release schedule, but I am considering to switching at least Inventor to motif on fc23, as well - It's unimportant enough to most users, but is important to me ;) Ralf [1] In the ole' days, lesstif almost always had been the troublesome part, which required app-code to me modified, because of missing features or incompatibilities ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)
On 10/09/2015 12:08 AM, Dominik 'Rathann' Mierzejewski wrote: On Wednesday, 07 October 2015 at 21:17, Stephen Gallagher wrote: Meeting summary --- [...] * #1483 Decision on bundling policy in the Fedora Package Collection (sgallagh, 18:11:40) * LINK: http://paste.fedoraproject.org/276064/44243383/ is sgallaghs proposal without the critpath distinction (nirik, 18:43:49) * AGREED: Adjust the packaging policy as described in http://paste.fedoraproject.org/276064/44243383/ (+5, 3, -1) (sgallagh, 18:57:44) * ACTION: tibbs|w to inform FPC and work on removing the anti-bundling stuff from the guidelines (sgallagh, 18:59:17) This was handled far too quickly and without considering the full consequences of the change that was passed. Also, the way you handled this caused a lot of resentment among the FPC members (or at least that's the impression I have). Seconded. What FESCO did was such kind of utterly disrespectful and rude toward FPC. ATM, I consider it to be a matter politeness not furtherly pronounce my opinion because I would have to be personal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-10-07)
On 10/09/2015 03:51 PM, Matthew Miller wrote: On Fri, Oct 09, 2015 at 01:50:27PM +0100, Richard W.M. Jones wrote: This opens the door to all kinds of duplication, waste of disk space, waste of RAM, symbol conflicts and unfixed security issues! I agree - the new wording does appear to give in to poor programming practices. Do you have suggestions for improvements? Do I have to pronouce the obivious? FESCO to revert their faulty decision. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: retire lesstif in f24 and beyond
On 10/08/2015 12:24 PM, Marcin Juszkiewicz wrote: W dniu 08.10.2015 o 12:06, Marcin Juszkiewicz pisze: W dniu 02.10.2015 o 13:33, Jon Ciesla pisze: Lesstif being basically dead upstream and motif being available, I think it's probably time to retire lesstif. If anyone knows of other packages using it, please let me know and I can migrate them. dinotrace fbb xastir xmbdfed xvarstar Those are blocking aarch64. Will dig for more. alliance polyml That's all I found. I believe to have taken care about all of these (but alliance) throughout today and rebuilt them against motif on rawhide. alliance seems multiply pretty broken independently of motif/lesstif. I would consider it to be a candidate for retirement. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: XSD on EPEL7
On 10/08/2015 05:30 PM, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2015 05:19 PM, Jakub Jelen wrote: On 10/08/2015 03:13 PM, Antonio Trande wrote: On 10/01/2015 05:35 PM, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all. I need XSD on EPEL7. Is it possible a build? Package: https://admin.fedoraproject.org/pkgdb/package/xsd/ Bugzilla request: https://bugzilla.redhat.com/show_bug.cgi?id=1251682 Thanks. - -- Antonio Trande Please, can anyone contact the XSD maintainer or co-maintainers? Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1251682 The main contact was informed about your bug (if his mail is still working), since the bug is assigned to him. Not sure how active he is he at this point. Last build he issued in koji is from 2013. This means 2 years of inactivity. cf. http://koji.fedoraproject.org/koji/builds?userID=anttix His last activity on koji seems to date back to 2013-10-23 Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaned Packages in rawhide (2015-10-07)
On 10/08/2015 07:11 AM, Tomasz Torcz wrote: On Wed, Oct 07, 2015 at 09:56:53PM +, opensou...@till.name wrote: Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will be retired when the affected package gets retired. iipsrv (maintained by: trasher) iipsrv-1.0.0-4.0.git2431b45.fc23.i686 requires /sbin/restorecon ipsilon (maintained by: puiterwijk, simo) ipsilon-base-1.1.0-1.fc24.noarch requires /usr/sbin/restorecon ladvd (maintained by: ixs, ttorcz) ladvd-selinux-1.1.0-4.fc24.i686 requires /sbin/restorecon, /usr/sbin/semodule ocp (maintained by: cra) ocp-0.1.22-0.6.20150224gita07bf5d.fc23.i686 requires /sbin/restorecon ocsinventory (maintained by: remi, xavierb) ocsinventory-reports-2.1.2-6.fc23.noarch requires /sbin/restorecon ocsinventory-server-2.1.2-6.fc23.noarch requires /sbin/restorecon So what is correct requires nowadays? /usr/sbin/restorecon? Something else? Both should work. /usr/sbin/restorecon is a file-provides of the policycoreutils package and /sbin/restorecon is an explicit provides of the policycoreutils package # rpm -qlp policycoreutils-2.4-13.fc24.x86_64.rpm \ | grep sbin/restorecon ... /usr/sbin/restorecon # rpm -q --provides -p policycoreutils-2.4-13.fc24.x86_64.rpm \ | grep sbin/restorecon ... /sbin/restorecon => Likely, something is broken with the depchecker used to generated the reports above. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 10/02/2015 01:46 PM, Tomas Mraz wrote: On Pá, 2015-10-02 at 13:18 +0200, Vít Ondruch wrote: Dne 30.9.2015 v 16:52 Ralf Corsepius napsal(a): Like I've said many times before, I feel Fedora needs a serious vulnerability in a widespread bundled or static library, such that people finally comprehend the harm of bundling. This harms Fedora but not the upstream project which bundles. If there is discovered security issue in the bundled library, they fix it and release new version, they are in users view the good guys who cares about security. If we fix the same issue in unbundled library, it is invisible for users and at the end they demand updated version of the upstream project, since they believe that the issues is not fixed in Fedora yet. I am afraid that no matter how much education you'd like to apply to this issue, you will never reduce it, since honestly, most of the development is done on different platforms then Linux, where bundlind of various kinds is a norm. And TBH, as much as I hate this reduction of anti-budnling requirements, I also hate to hear from upstream that they don't wish their SW to be included in Fedora, since we break it due to unbundling policies. This seems like a strong argument for the current case where the bundling exception is provided by FPC. The question is only whether it needs to be FPC or some another body. The bundling should be approved only for projects where upstream is fully active and cares about the security vulnerabilities in the bundled copies of software well. Correct. That's one of the criteria, FPC is trying to consider when granting bundling exceptions. Openly said, these are the easy cases, we often grant bundling exceptions. The problematic ones are those cases, when it's obvious upstream lacks experience and/or technical skills to understand "unbundling" /"bundling" and resources to take care about "upstreams of their bundled sources. These often are smaller projects - in many cases - one-man shows. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: retire lesstif in f24 and beyond
On 10/02/2015 01:33 PM, Jon Ciesla wrote: Lesstif being basically dead upstream and motif being available, I think it's probably time to retire lesstif. I've migrated the remaining packages still using it I could find in rawhide: Inventor [Inventor maintainer speaking] Migrating Inventor to motif should not be much of a problem, however in past, this wasn't possible, because Fedora's lesstif-devel and motif-devel clashed and could not be installed in parallel. I'll try to investigate. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 10/02/2015 01:18 PM, Vít Ondruch wrote: Dne 30.9.2015 v 16:52 Ralf Corsepius napsal(a): Like I've said many times before, I feel Fedora needs a serious vulnerability in a widespread bundled or static library, such that people finally comprehend the harm of bundling. This harms Fedora but not the upstream project which bundles. Exactly. This "bundling everything" is upstream-centric. It's convenient to them, but it's harmful to wider system integration. If there is discovered security issue in the bundled library, they fix it and release new version, they are in users view the good guys who cares about security. Only if there is an active upstream, who actively works on its bundled sources. This applies to bigger projects such as Firefox and Chromium, but often doesn't apply to smaller projects. There, bundled sources often pretty soon don't get much attention and simply rot. Worse, when such upstream goes AWOL. I am afraid that no matter how much education you'd like to apply to this issue, you will never reduce it, since honestly, most of the development is done on different platforms then Linux, where bundlind of various kinds is a norm. Sure, but IMO, this shouldn't be reason for us to follow these system's mistakes. When you have a look at these systems, you'll soon notice bundling is one of the primary causes for vulnerabilities on these systems. And TBH, as much as I hate this reduction of anti-budnling requirements, I also hate to hear from upstream that they don't wish their SW to be included in Fedora, since we break it due to unbundling policies. So be it. It's their decision - I don't want Fedora to be taken hostage by short sighted upstreams and their non-system-integratible designs. Also, if there's sufficient interested in a piece of SW and if their design isn't too crappy, it should not be much of a problem for Fedora to properly integrate a SW into Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/30/2015 06:32 PM, Matthew Miller wrote: On Wed, Sep 30, 2015 at 04:52:48PM +0200, Ralf Corsepius wrote: people not declaring their bundles and not care about policies did the same before: not declare it and not ask for exceptions - there is a logical flow in "now that i don't need to ask FPC i don't declare it" Exactly, that's what I would consider a serious regression. But re-read what you're just replying to. The thing is, there's all sorts of bundling going on all throughout Fedora under the radar. I know - while Fedora is doing pretty good job on unbundling in many cases, there are case where Fedora is doing a missable job. IMO, this should be reason to encourage fighting bundling and not to weaken unbundling and weaken enforcing unbundling. Which is - as I feel - what you are currently doing. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 10/02/2015 12:09 AM, Adam Williamson wrote: On Thu, 2015-10-01 at 23:54 +0200, Ralf Corsepius wrote: Seems to me, as if today's generation of fedora users and esp. current Fedora leaders need to go through the lessons people who had been using Linux then were tought the cruel way. I know you always think you're the ONLY ONE WHO UNDERSTANDS, but the people proposing this have been doing it just as long as you. I'm long enough in open source to ignore this rude offensive tone of yours for now. They know the issues. You can't successfully argue against them by pretending they don't, and should just yield to your unquestionably superior wisdom. Their words and action speak a clear and misunderstandable language. Their proposal is just populist and against common sense. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/30/2015 05:20 PM, Neal Gompa wrote: On Wed, Sep 30, 2015 at 10:52 AM, Ralf Corsepius <rc040...@freenet.de <mailto:rc040...@freenet.de>>wrote: On 09/30/2015 04:25 PM, Reindl Harald wrote: the opposite is more likely: people trying to avoid the FPC burden now can declare it without fearing somebody takes notice and points out a violation If they don't care or are not aware about the consequences of their bundling? Like I've said many times before, I feel Fedora needs a serious vulnerability in a widespread bundled or static library, such that people finally comprehend the harm of bundling. Ralf Are you saying we're doing our job too well, so people don't see the advantages of the effort anymore? No. I am saying actively fighting bundling has prevented cases like the zlib disaster 15+ years to return. Seems to me, as if today's generation of fedora users and esp. current Fedora leaders need to go through the lessons people who had been using Linux then were tought the cruel way. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/30/2015 04:25 PM, Reindl Harald wrote: Am 30.09.2015 um 16:13 schrieb Orion Poplawski: On 09/30/2015 07:45 AM, Fabian Deutsch wrote: Yes, I also see this as a good compromise. We then have the ability to at least track bundling. I'd just like to point out that we have always had the requirement for package that bundled libraries to carry the "Provides: bundled(libname)" metadata. What's new here is not needing to go through the FPC to get an exception. Which perhaps leads to people not declaring their packages bundled libraries. how do you come to that conclusion? people not declaring their bundles and not care about policies did the same before: not declare it and not ask for exceptions - there is a logical flow in "now that i don't need to ask FPC i don't declare it" Exactly, that's what I would consider a serious regression. This proposal effectively is a carte-blanche to bundling and carelessness, which I would expect to seriously impact the quality of Fedora. the opposite is more likely: people trying to avoid the FPC burden now can declare it without fearing somebody takes notice and points out a violation If they don't care or are not aware about the consequences of their bundling? Like I've said many times before, I feel Fedora needs a serious vulnerability in a widespread bundled or static library, such that people finally comprehend the harm of bundling. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: redhat bugzilla probs
On 09/21/2015 03:38 PM, Ralf Corsepius wrote: Hi, When trying to file a BZ, bugzilla just greeter me with this: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /post_bug.cgi. Reason: Error reading from remote server Apache Server at bugzilla.redhat.com Port 443 Right now, it is happening, again - Same error as last week: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /show_bug.cgi. Reason: Error reading from remote server Apache Server at bugzilla.redhat.com Port 443 Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announcing the release of Fedora 23 Beta!
On 09/22/2015 07:33 PM, Matthew Miller wrote: On Tue, Sep 22, 2015 at 06:21:00PM +0100, Pádraig Brady wrote: I just used dnf distro-sync as per: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_22_-.3E_Fedora_23 This went fine, and I'm now typing this on F23 beta. What are the main advantages of system-upgrade? Should the above wiki mention the system-uprade instructions? There's actually a "fedup" script as part of the package. I think we should update the dnf-plugin-system-upgrade to Provide: fedup, and keep the instructions the same. Rationale: IMO, this discussion is moot. Because ppckaging-wise, the dnf-plugin-system-upgrade situation currently is broken [1]: dnf-plugin-system-upgrade Obsoletes: fedup, but lacks the corresponding Provides. The result is - "dnf install fedup" installs fedup - subsequent "dnf update" kicks out fedup and replaces it with dnf-plugin-system-upgrade. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1264937 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
redhat bugzilla probs
Hi, When trying to file a BZ, bugzilla just greeter me with this: Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /post_bug.cgi. Reason: Error reading from remote server Apache Server at bugzilla.redhat.com Port 443 Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/14/2015 01:56 PM, Haïkel wrote: 2015-09-14 13:17 GMT+02:00 Andrew Haley: On 09/13/2015 09:23 PM, Haïkel wrote: I'm not speaking about PHP, most of the upstream I deal with are python developers. Bad habits are rather spreading than regressing. We're not going to solve that problem by adopting bad habits ourselves. Andrew. Did I request somewhere to *drop* unbundling? I'm more concerned by the current habit to let bundled libraries sneak in the repositories without being properly tracked rather than a non-existing one. a) We don't have any such tracking system. b) So far, this has not been a problem. In the past, this these issues were commonly worked around by Fedora maintainers forking in private and them feeding them into Fedora as set of patches. Our role is mitigate bad habits and educate upstream, not ignoring them. Right, but you're underestimating the stubbornness and non-cooperativeness of some upstream and fedora maintainer. They usually believe to have an "ultra-clever design" and the FPC to be dumb idiots who are unable to comprehend their cleverness. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging guidelines for documentation clairfication needed
On 09/14/2015 04:13 PM, Richard Shaw wrote: While working through a package review[1] this excerpt from the documentation section[2] was brought to my attention: "Marking a /relative/ path with |%doc| in the |%files| section will cause RPM to copy the referenced file or directory from |%_builddir| to the proper location for documentation. Files can also be placed in |%_pkgdocdir|, and the build scripts of the software being packaged may do this automatically when called in |%install|. However, mixing these methods is problematic and may result in duplicated or conflicting files, so use of |%doc| with /relative/ paths and installation of files directly into |%_pkgdocdir| in the same source package is forbidden." In my case the project is installing html documentation during "make install". Reading this pedantically, it would appear that would prevent me from using %doc to install the obligatory COPYING, README, ChangeLog, NEWS, etc... This doesn't seem to be very practical and I'm not sure that's what was intended by the guidelines. Older versions of rpm allowed mixing relative %doc and direct installs into %_pkgdocdir. rpm - as upstream calls it - "fixed it" (IMHO, they broke rpm - of course upstreams disagrees with me). As a consequence of this, rpm now often errors out, when mixing both styles. The only reliable way, now seems to be to either manually install everything to %_pkgdocdir directly or only use relative %doc. ATM, I am recommending against using relative %doc and recommend to directly install docs into %_pkgdocdir. You typically end up with something similar to: %install make install DESTDIR=${RPM_BUILD_ROOT} install ... COPYING README ... ${RPM_BUILD_ROOT}%{_pkgdocdir} %files %{_pkgdocdir} ... Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/10/2015 03:53 PM, Stephen Gallagher wrote: I assume that subject line got your attention. The reason for this proposal is relatively simple: we know the advantages to unbundling, particularly with security and resource- usage. However, the world's developer community largely *does not care*. We fought the good fight, we tried to bring people around to seeing our reasoning and we failed. My view: It's an ongoing struggle and fight against upstream incompetence, carelessness, sloppiness and low-quality crap software. It's a fight we should not give up to, because it would cause damage the quality of Fedora. In that sense, I feel you are undermining and torpedoing Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements
On 09/10/2015 04:06 PM, Stephen Gallagher wrote: On Thu, 2015-09-10 at 09:03 -0500, Jon Ciesla wrote: On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagherwrote: I assume that subject line got your attention. Most definitely. :) So it's basically the same but without FPC as a gatekeeper? Do you have any proposals for enforcement? A periodic query of Provides (bundled-foo) and a BZ requesting a review? Sometime projects enable unbundling over time. I don't know that enforcement is strictly necessary. Maintainers that care will self-enforce. Maintainers that don't care won't be aided by this. Are you talking about upstream maintainers of fedora maintainers? The cause of the majority of cases of bundling is upstream maintainers who violently refuse to comprehend the evilness of bundling and who use bundling because "it's so convenient" to them. "Enforcement" implies adding more heavy process, which is part of the problem this is trying to avoid. You don't seem to be aware about the fact FPC already tries to enforce unbundling. Yes, this is a heavy and time-consuming process, esp. on occasions upstream's behave stubborn and refuse to listen. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal to reduce anti-bundling requirements
On 09/10/2015 04:08 PM, Josh Boyer wrote: On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagherwrote: Is the intention of your proposal to also allow Chromium into the main Fedora repos? I honestly can't tell where it draws the line. We have a long list of bundling exceptions in Fedora. I do not see much reasons why Chromium (or parts of it) could not be on this list. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/29/2015 05:40 PM, Rex Dieter wrote: Ralf Corsepius wrote: On 08/28/2015 01:00 PM, Rex Dieter wrote: Ralf Corsepius wrote: This morning, bodhi2 doesn't allow me to submit an update. After a seemingly successful login-in, when trying to submit an update, a popup pops up telling me: ACL validation mechanism was unable to determine ACLs Known issue, I hit it yesterday and filed a bug. bodhi upstream has been fixed, not sure when the fix will be rolled out into production. Does this mean my hung job locks up submissions issue is unrelated or doesn't exist at all? I don't know what hung job locks up submissions means, so I don't know. I had build a package for fc24, fc23 and fc22. The fc24 and fc23-builds succeeded, the fc22-build[1] hung in koji until the build-jobs timed out 24 hours later. During these 24 hours, I wasn't able to submit the fc23-built package for update in bodhi2. Ralf [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=10843003 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/28/2015 11:58 AM, Kevin Kofler wrote: Ralf Corsepius wrote: Also, I have not found any means to kill this job in bodhi/koji, Had you tried koji cancel-task 10843003? (It's too late to try it now, now that the build has timed out.) No, I wasn't aware this option exits. It's not mentioned in koji --help nor is there a man-page for koji. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/28/2015 01:00 PM, Rex Dieter wrote: Ralf Corsepius wrote: Hi, This morning, bodhi2 doesn't allow me to submit an update. After a seemingly successful login-in, when trying to submit an update, a popup pops up telling me: ACL validation mechanism was unable to determine ACLs Known issue, I hit it yesterday and filed a bug. bodhi upstream has been fixed, not sure when the fix will be rolled out into production. Does this mean my hung job locks up submissions issue is unrelated or doesn't exist at all? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On 08/28/2015 01:15 PM, Michael Schwendt wrote: The version tags ver and rel attributes may also be non-numerical. Why not epoch, too? I haven't looked into the sources, but IIRC, inside of rpm, while rel, ver etc. are strings, epoch is an integer. AFAIR, there are APIs which return the epoch as a *int, which may be NULL or a valid pointer. I.e. callers will have to special case accessing these pointers. Seems to me as if something doesn't get this right. (FWIW: All this was an FAQ 10 years ago :) ) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/28/2015 12:56 PM, Kalev Lember wrote: On 08/28/2015 12:45 PM, Ralf Corsepius wrote: On 08/28/2015 11:58 AM, Kevin Kofler wrote: Ralf Corsepius wrote: Also, I have not found any means to kill this job in bodhi/koji, Had you tried koji cancel-task 10843003? (It's too late to try it now, now that the build has timed out.) No, I wasn't aware this option exits. It's not mentioned in koji --help nor is there a man-page for koji. It is mentioned in koji enter. That's what I'd call room for improvement. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On 08/28/2015 02:18 PM, Michael Schwendt wrote: On Fri, 28 Aug 2015 13:59:12 +0200, Ralf Corsepius wrote: The version tags ver and rel attributes may also be non-numerical. Why not epoch, too? I haven't looked into the sources, but IIRC, inside of rpm, while rel, ver etc. are strings, epoch is an integer. See: https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html Bugs ... an undefined epoch is supposed to be treated as 0. I guess you also recall - the ability of some tools not to be able to cope with this was the origin why Fedora.us and early Fedoras once mandated Epoch: 0. Plus, RPM would not get to see repository metadata, but only downloaded packages, which contain the same bad Epoch values. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Undefined %epoch problem (Re: rawhide report: 20150730 changes)
On 08/28/2015 05:32 PM, Michael Schwendt wrote: On Fri, 28 Aug 2015 16:36:51 +0200, Ralf Corsepius wrote: See: https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html Bugs ... an undefined epoch is supposed to be treated as 0. No, that's the old case. No Epoch = Epoch 0. Both cases are equal on the rpm level. All tools which use rpm need to set their internal representation of an epoch to 0 if rpm returns an undefined epoch. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/27/2015 07:55 AM, Ralf Corsepius wrote: Hi, This morning, bodhi2 doesn't allow me to submit an update. After a seemingly successful login-in, when trying to submit an update, a popup pops up telling me: ACL validation mechanism was unable to determine ACLs This whole incident is bizarre. What I assume to have happened is: - A fc22 build job hung for unknown reasons [1]. This seems to have locked out package update submissions of this package for other fedora releases in bodhi. E.g.. bodhi rejected all attempts to submit an fc23 built. Also, I have not found any means to kill this job in bodhi/koji, - 24 hours later, the hung build job was automatically terminated/killed[2]. This seems to have unlocked package update submissions in bodhi. I finally was able to rebuild the fc22 package in koji and subsequently was able to submit the package's updates for other fedora-releases. Ralf [1] This package's test suite is suspected to suffer from dead-lock issues on highly parallel systems. I have never been able to locally reproduce these issues. Upstream so far ignored allproposals, which were claiming to fix this issue, probably because upstream also can't reproduce the problems. [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=10843003 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi2: ACL validation mechanism was unable to determine ACLs
On 08/27/2015 11:15 AM, Christopher Meng wrote: On Thursday, August 27, 2015, Ralf Corsepius rc040...@freenet.de mailto:rc040...@freenet.de wrote: Hi, This morning, bodhi2 doesn't allow me to submit an update. After a seemingly successful login-in, when trying to submit an update, a popup pops up telling me: ACL validation mechanism was unable to determine ACLs I met this as well when I edited updates. Then I manually typed the build in the field and pressed enter instead of selecting them with checkbox pulled after entering the package name. I don't think this applies here. I've tried several ways to submit the package, but no success so far. Also, meanwhile I've successfully requested a update for a different package, i.e. it's not a general issue with my account. I'd guess on a bodhi-koji interaction/sync issues (fc23), because another build of this package for a different fedora release (fc22) seems to be stuck in koji and doesn't want to finish for more than 12 hours. May-be, it'll once will time out or may-be I can find a way to kill it. We'll see if this changes something. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
bodhi2: ACL validation mechanism was unable to determine ACLs
Hi, This morning, bodhi2 doesn't allow me to submit an update. After a seemingly successful login-in, when trying to submit an update, a popup pops up telling me: ACL validation mechanism was unable to determine ACLs Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/21/2015 06:02 PM, Kevin Fenzi wrote: On Fri, 21 Aug 2015 05:27:37 +0200 Ralf Corsepius rc040...@freenet.de wrote: Upstreams, yes, but not Fedora. Fedora should be self-hosted. Can you please define Fedora and self-hosted as you use them above? A domain 100 operated and owned by Fedora (rsp. RH) and covered by the Fedora CLA. Whether github is popular does not matter all. It's third party out of Fedora's control. What you are doing, means pushing Fedora users around, in what I consider very rude ways. Fedora is part of the larger open source comunity. Fedora Infrastructure uses 100% open source software. All irrelevant. Bohdi is just a tool used by Fedora, like any other arbitrary tool. I.e. I am not interested in getting involved in bodhi, I am just using the bodhi instance Fedora has deployed and I am expecting to have a way to contact the Fedora personnel to report bugs. Anyhow, for the last time: github is currently the perferred way to report bodhi2 bugs. And for illiterate: github a legitimate way for upstream, but is not a way, which is acceptable to Fedora users. You guys, need to learn to distinguish your roles as upstream and as maintainers of an installation - These are *not* identical. If you have some objection to them, you can file a fedorahosted ticket or infrastructure fedorahosted ticket. Also, I have been trying to file tickets on issues I see in mailing lists that aren't filed. I am close to filing a ticket to FESCO and/or the Board/Council, to request to revert to bodhi one - bodhi2 has proven to suffer from very ugly bugs and to be close to being unusable. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/20/2015 07:40 PM, Stephen John Smoogen wrote: On 19 August 2015 at 22:24, Ralf Corsepius rc040...@freenet.de wrote: On 08/20/2015 06:08 AM, Christopher Meng wrote: On 8/20/15, Kevin Fenzi ke...@scrye.com wrote: Thanks for your patience as we roll out this new bodhi version. This update has reached 3 days in testing and can be pushed to stable now if the maintainer wishes This update has reached 14 days in testing and can be pushed to stable now if the maintainer wishes uh, can someone tell me where to push the updates? I am having the same issue. I am unable to find a way to push packages in the GUI. Also, there seem to be pretty nasty connectivity/accessibility issues. Accessibility to bodhi has never been overwhelming, but they now seem to have worsend. I am experiencing page loading times are in the order of several minutes and occasional time outs. FYI: I just submitted a new update trough bodhi. Wrist-watch measured, this update took 2 minutes+ GUI-turn-around time (Probably 2:30 min). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/21/2015 04:03 PM, Michael Schwendt wrote: On Fri, 21 Aug 2015 09:00:29 +0200, Ralf Corsepius wrote: On 08/21/2015 08:34 AM, Till Hofmann wrote: Also, it seems like I can revoke other people's updates. At least I could press the 'Revoke' button and I received a confirmation notification. Also, instead of the Revoke button, there is now a Push to Testing and a Push to Stable button. But there is no comment that the update has been revoked, so I'm not sure if it was revoked or not. The start page confirms that I revoked the torch-3.1-12.fc23 update: https://thofmann.fedorapeople.org/Screenshot%20from%202015-08-21%2008-42-52.png Ralf, sorry for messing with your update. Interesting - May be it's still in the process queue somewhere, but so far, I haven't been notified about this, neither in BZ nor per email. If you hadn't mentioned it, I'd not know about this incident. Fedora Notifications web site finds a notification about it: 7 hours ago thofmann revoked torch-3.1-12.fc23 Yes. This was the incident Till was referring to. Though, given that you are not the owner of the package, I guess this has not been forwarded to you. Correct - I acted as provenpackager, who stepped in to keep alive a package, whose maintainer likely is AWOL[1]. It would be bodhi's responsibility to submit a notification that refers to the update ticket owner, too. Exactly. IMO, this is a bug in bodhi. I would expect the update submitter and the bugzilla-ticket owner, an update is referring to be notified (In this case: both me). And perhaps you're also affected by issues with the default Fedora Notifications filters I've encountered. This thread: https://lists.fedoraproject.org/pipermail/devel/2015-August/213609.html I don't know - Possible. Due to the mass of notifications, I am receiving (100s - 1000s per day), I am filtering notifications and am moving most notifications to trash unread ;) Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1240072 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/20/2015 07:39 PM, Adam Williamson wrote: Well, I don't know if there was a Big Philosophical Discussion, but in practice all kinds of Fedora-ish stuff has its upstream in github these days, so yes, clearly times have changed. That's not the point. I am talking about separating Fedora web-infrastructure from the web-infrastructure's upstreams. In this case, I am talking about Fedora's infrastructure deployment/installation (A Fedora product - Responsible: Fedora) of bodhi to demand reporting bugs on Fedora's infrastructure to upstream (A bodhi-project product - Responsible: Upstream). In other words: Nobody with a sane mind would ask users of web shop's installation to file bugs at Oracle/MySQL etc - This is what is happening here. It's a classical case where people with multiple roles are unable to distinguish their roles. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/21/2015 08:47 AM, Till Hofmann wrote: On 08/21/2015 08:34 AM, Till Hofmann wrote: Also, it seems like I can revoke other people's updates. At least I could press the 'Revoke' button and I received a confirmation notification. Also, instead of the Revoke button, there is now a Push to Testing and a Push to Stable button. But there is no comment that the update has been revoked, so I'm not sure if it was revoked or not. The start page confirms that I revoked the torch-3.1-12.fc23 update: https://thofmann.fedorapeople.org/Screenshot%20from%202015-08-21%2008-42-52.png Ralf, sorry for messing with your update. Interesting - May be it's still in the process queue somewhere, but so far, I haven't been notified about this, neither in BZ nor per email. If you hadn't mentioned it, I'd not know about this incident. Anywas, this time bodhi offered me a push to testing and push to stable (!) button (Note: push to stable) I used pushed to testing to re-push it. BTW (I mentioned it before), Timestamps are still screwed up: ... Submitted 31 minutes ago, 2015-08-21 06:22:21.364583 Automated Test Results rpmlint torch-3.1-12.fc23 3 hours ago ... Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/20/2015 06:00 PM, Kevin Fenzi wrote: On Thu, 20 Aug 2015 17:55:01 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Ralf Corsepius wrote: I share this view. I refuse to create a github account and do not consider using any external account resources for Fedora to be acceptable. While I do have a GitHub account (no way for me to eschew it, sadly), I also do not understand why (and am sad that) Bodhi development moved off Fedora Hosted, where there is an issue tracker that works with Fedora accounts, and where we are not reliant on third-party proprietary software as a service. The fedorahosted instance is still there, you can use it if you like. Likely it will be migrated to pagure.io before too long, we just didn't have time to do so before this deployment. To me any non fedora/redhat supplied account system is inacceptable, This applies to github, sourceforge, farcebook, nitter, goggle, or else - period. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/20/2015 09:51 AM, Milan Crha wrote: On Wed, 2015-08-19 at 21:45 -0600, Kevin Fenzi wrote: There will likely be oddities and bugs. Please file them in github so we can prioritize them and get them fixed up. https://github.com/fedora-infra/bodhi/issues Hi, I do not have a github account, and I'm currently not going to create any (github is not my favorite site), thus I'm writing here instead (after all, Fedora infrastructure issue = Fedora bugzilla, no?). I share this view. I refuse to create a github account and do not consider using any external account resources for Fedora to be acceptable. I tried to submit an update for Fedora 22 and it just tells me that it wasn't able to submit it with absolutely no reason. My values are: And this as well. I just tried to create an update for F23 and was just told unable to create update. So be it, ... give me a ping when you think bodhi is ready for public usage. ATM it definitely is not. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets
On 08/18/2015 12:04 PM, Miroslav Suchý wrote: BTW this report reveals that we have just 39 active sponsors (during past year). If you are sponsors, please consider sponsoring somebody from the queue: http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html You should understand that sponsoring someone in reality is a tedious and challenging task. Why? 1. You need to find a package submission your feel sufficiently motivated to review. The packages, I am interested already in are in Fedora, which means I am having difficulties to find any more 2. You need to find a package you technically feel qualified to get involved to. Most recent submissions were out of my technical domains. 3. You need to find a non occupied package. Provided we have sponsors; whom I perceive as keen on collecting badges, this has become an ugly rat-race. 4. Reviews take time, esp. on those with NEEDSPONSORS. In recent times, I perceived a lot of low quality submissions, I am not interested in wasting my time on, any more. 5. You cannot push around sponsors. The ability to sponsor packagers is a privilege and not a duty. It's not going to fly to make a volunteer privilege a burdon. That said, I considering your ongoing campaign to be harmful to Fedora. All you are going to achieve is to collect more hyperactive kids and to drive away more of the old and experienced hares. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/20/2015 07:51 PM, Kevin Fenzi wrote: On Thu, 20 Aug 2015 12:33:37 -0500 Michael Cronenworth m...@cchtml.com wrote: On 08/20/2015 12:02 PM, Ralf Corsepius wrote: To me any non fedora/redhat supplied account system is inacceptable, This applies to github, sourceforge, farcebook, nitter, goggle, or else - period. The last time a non-Fedora hosted / closed source service was suggested it was shot down. https://lists.fedoraproject.org/pipermail/devel/2013-October/191012.html Have times changed? Using github is acceptable? For what? :) IMHO, I think projects should be free to choose whatever tools they wish to build their project. Upstreams, yes, but not Fedora. Fedora should be self-hosted. That said, Fedora should not start being rude and push people around to get accounts on other commercial entities and to expose themselves to the risks implied by this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unable to submit update for F22 (was Re: bodhi 2 now live)
On 08/20/2015 12:00 PM, Paul Howarth wrote: On 20/08/15 10:28, Ralf Corsepius wrote: On 08/20/2015 09:51 AM, Milan Crha wrote: On Wed, 2015-08-19 at 21:45 -0600, Kevin Fenzi wrote: There will likely be oddities and bugs. Please file them in github so we can prioritize them and get them fixed up. https://github.com/fedora-infra/bodhi/issues Hi, I do not have a github account, and I'm currently not going to create any (github is not my favorite site), thus I'm writing here instead (after all, Fedora infrastructure issue = Fedora bugzilla, no?). I share this view. I refuse to create a github account and do not consider using any external account resources for Fedora to be acceptable. I tried to submit an update for Fedora 22 and it just tells me that it wasn't able to submit it with absolutely no reason. My values are: And this as well. I just tried to create an update for F23 and was just told unable to create update. So be it, ... give me a ping when you think bodhi is ready for public usage. ATM it definitely is not. I had the same issue trying to create an update for F23. I was able to manage it eventually by using fedpkg update, once I'd updated python-fedora from F21 updates-testing. However, I later needed to edit that update to change the build, and the result is an update with no builds that I can't even access any more. https://github.com/fedora-infra/bodhi/issues/202 Looks like you need to hit enter after typing/pasting in the package NVR into the Candidate Builds field, which was not at all obvious to me. Aha ;() I just somehow managed to push an update - No idea how. While filling out the update form for a second time (The first try had failed with the error above), out of a sudden a large number of popups with checkboxes inside popped up. After checking some of them, the update was reported to have been pushed, except that the BZ, I had added manually seems to have been ignored - Seems to me, as is this popup is not offering BZ's which have been closed rawhide but require further action for fc23. BTW: Something with time stamps of the rpmlint/taskotron checks seem to be wrong, as well. I my case rpmlint reported to have checked the package hours ago, while I had commited the package into git ca. 1/2 hour ago and submitted it minutes ago. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide plans
On 08/20/2015 03:13 PM, Eric Griffith wrote: If you have a bad experience that experience stays with you. Maybe you can get over it, maybe you can't. But a name does have history. I guess, you guys are not aware that other names related to RH/CentOS/Fedora also have ambivalent and polarizing connotations? Actually, I believe rawhide is the least one to worry about, because it doesn't have any connotation to many people, because most users don't even know what rawhide is. Openly said, I wonder where this fuzz about rawhide originates from and which insect might have bitten the folks making this fuzz? IMHO, Fedora has many more serious and urgent problems than to the name rawhide. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide plans
On 08/20/2015 03:42 PM, Zach Villers wrote: Le Mer 19 août 2015 18:22, Rex Dieter a écrit : Kevin Fenzi wrote: * Matt opened a thread on the marketing list about renaming rawhide. It sounds like most people would prefer us to make the changes first, then and only then look at renaming. s/renaming/rebranding/ I personally would prefer the name be preserved if at all possible, but if the marketing gurus feel otherwise, so be it. /I doubt anyone will be fooled by a name change, what matters is the actual state of the repository not naming tricks. No. rawhide is the package pool, dumping ground or what ever wording you prefer, distros are derived from. There is no point in considering a release nor a rolling release. It simply isn't a release, it's just a truck load of packages. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/20/2015 06:24 AM, Ralf Corsepius wrote: On 08/20/2015 06:08 AM, Christopher Meng wrote: On 8/20/15, Kevin Fenzi ke...@scrye.com wrote: Thanks for your patience as we roll out this new bodhi version. This update has reached 3 days in testing and can be pushed to stable now if the maintainer wishes This update has reached 14 days in testing and can be pushed to stable now if the maintainer wishes uh, can someone tell me where to push the updates? I am having the same issue. I am unable to find a way to push packages in the GUI. AFAIS, this morning, the situation seems to have improved. Unlike yesterday, I am now seeing green push to stable buttons for packages which have been in testing for longer times (weeks, months). However, I am not seeing these buttons for packages, which I had submitted in recent past and which received a This update ... if the maintainer wishes notification, dated ~2-3 days ago. E.g.: https://bodhi.fedoraproject.org/updates/libcmpiutil-0.5.7-6.fc23 https://bodhi.fedoraproject.org/updates/spacechart-0.9.5-17.fc23 Could it be the old bodhi was using a 3 days delay time for fc23, while the new bodhi uses 7 days? Could it be that the corresponding bodhi internals have been lost during the transition? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide plans
On 08/20/2015 09:23 AM, Reindl Harald wrote: Am 20.08.2015 um 06:01 schrieb Ralf Corsepius: On 08/20/2015 01:07 AM, Eric Griffith wrote: Personally, if it weren't for the confusion, I think Fedora Next would be the perfect name for this. May-be, you guys are too young to know, but to me Fedora Next, would be a Fedora distribution addressing Steve Job/Apple's NeXt and advertising for Apple. That said, I would not be surprised, if Fedora Next would be subject to trademark conflicts and disputes. the word next in the context what Rawhide is? seriously? Well, I am just trying to raise awareness on a potential problem. A brief and quick of the DPMA's (Deutsches Patent und Markenamt - German Patent and Trademark Authority) on-line database tells NeXT is still a registered trademark, registered for Nice Class 9, by NeXT Computer, Inc., Redwood City Calif., US [1] In other words, there is a potential problem lurking, IMHO. Ralf [1] https://register.dpma.de/DPMAregister/marke/register/2026842/DE https://register.dpma.de/DPMAregister/marke/register/2063015/DE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/20/2015 06:05 PM, Tomasz Torcz wrote: On Thu, Aug 20, 2015 at 10:02:44AM -0600, Kevin Fenzi wrote: Are things like redhat bugzilla, koji and fedocal also slow? Bugzilla is always slow, it's not a good reference ;-) Definitely. But bodhi2 seemed worse :-) What might have interfered this morning, was my ISP. It was reported to have major networking issues, affecting several million customers, but ... I didn't notice any and did not have any networking problems but to fedoraproject.org ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide plans
On 08/20/2015 01:07 AM, Eric Griffith wrote: Personally, if it weren't for the confusion, I think Fedora Next would be the perfect name for this. May-be, you guys are too young to know, but to me Fedora Next, would be a Fedora distribution addressing Steve Job/Apple's NeXt and advertising for Apple. That said, I would not be surprised, if Fedora Next would be subject to trademark conflicts and disputes. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bodhi 2 now live
On 08/20/2015 06:08 AM, Christopher Meng wrote: On 8/20/15, Kevin Fenzi ke...@scrye.com wrote: Thanks for your patience as we roll out this new bodhi version. This update has reached 3 days in testing and can be pushed to stable now if the maintainer wishes This update has reached 14 days in testing and can be pushed to stable now if the maintainer wishes uh, can someone tell me where to push the updates? I am having the same issue. I am unable to find a way to push packages in the GUI. Also, there seem to be pretty nasty connectivity/accessibility issues. Accessibility to bodhi has never been overwhelming, but they now seem to have worsend. I am experiencing page loading times are in the order of several minutes and occasional time outs. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rawhide plans
On 08/19/2015 06:59 PM, Zach Villers wrote: On Wed, 19 Aug 2015 11:18:04 -0400 *Kevin Fenzi ke...@scrye.com* wrote Greetings. We had some nice discussions about rawhide in my friday workshop at flock. I thought I would post here to get input from folks not there, and also allow people who were there to comment more now that it's not after 5pm on a friday of the 3rd day of flock. ;) snip Finally there was mention of the baggage associated with the name rawhide. To this day I see people telling others that rawhide will eat your babies or rawhide is a methlab and will blow up in your face every day. As a relative newcomer (using Fedora since ~F20) the name rawhide does seem to have some implied broken-ness, if that's a word. I would be in favor of a name change/rebrand that makes it a little more approachable. I do not see any sense in changing the name. rawhide is a well established, well-known name, almost a trademark-like, for RH/CentOS/Fedora's unstable package set/repository. Admitted, the name rawhide has some negative connotation, because of the permanent brokenness of its contents, but that's in the nature this repository. Changing the name won't change anything about this. That said, renaming rawhide, to me, doesn't serve anything useful purpose. It only causes confusion and - on the technical side - causes (avoidable) churn. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On 08/14/2015 12:00 PM, Richard Z wrote: I regularly use i686 and have not done a fresh install since years so would not detect this. Maybe fresh installs aren't such a deal for i686 users Well, from my experience, fresh installs on i686 are a major problem w/ Fedora, because Fedora's SW demands have grown, which render it quite likely for i686-users to hit the HW-limitations of their systems, esp. on older i686ers. and the apparent stability is the reason why it gets less testing. Agreed. The hardware is not changing so if fresh bugs appear there is a good chance that something else than just i686 is broken? Definitely. 10/15 years+ ago, devs were working on 32bit platforms, which had caused packages to have problems on 64bit platforms. Since then, the situation has turned into the converse. Also, in those days, devs cared about efficiency. Nowadays, they don't care as much, which causes additional problems on i686ers and other low end archs. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Validity of i686 as a release blocker
On 08/04/2015 05:12 PM, Bill Nottingham wrote: Paul W. Frields (sticks...@gmail.com) said: Here's my perspective as an i686 Fedora user... I have a box (2009-ish) that's in use as a file/backup server. I have 3 i686 boxen. 2 are 2009-ish atom-netbook, one is a 2000-ish PIII-desktop. As such, I don't spend a lot of time futzing with it - it doesn't run rawhide, it rarely runs the prereleases until beta or later time. If something breaks, I'll look at it, send some feedback, update it as necessary, and back off to a working version. And historically, it *hasn't* broken. But, if it did break that hard... would I spend a month digging into the kernel source and bisecting to try and find a fix? Or would I spend the $100-120 to slap a new motherboard in it and install the x86_64 version? I'd like to say I'd do the former. But realisitically it's the latter. And I wonder how much of the i686 Fedora-using community is in the same boat. ACK. I would switch the 2009-atoms to Windows (They are dual boot with Win) and the PIII to a different Linux distro. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [PATCH] Update to 2.0.2
On 08/03/2015 04:37 PM, Kevin Fenzi wrote: On Mon, 3 Aug 2015 01:13:52 +0200 I think posting patches or other issues here is fine as long as theres some reason to involve the larger development community. ... like in this case. Broken upgrade paths and disinterest in fixing them have a long history. They therefore need a wider audience. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Question about profile.d scripts definition in Spec file
On 08/02/2015 08:39 AM, Marcin Haba wrote: Hello, I am trying to make informal review following feature request: https://bugzilla.redhat.com/show_bug.cgi?id=1244353 One from warnings returned by rpmlint is: ossim-data.x86_64: W: non-conffile-in-etc /etc/profile.d/ossim.sh Because ossim.sh is not configuration file but shell script (as usual in profile.d/) I had a doubt about treating this warning. Well, I sense a misinterpretation of %config. In the context of the /etc file hierarchy %config means user-customizable, which means rpm/yum/dnf updates must not destroy any changes a user may have applied and should backup instead. So I asked on fedora-review IRC channel and there I received answer that this warning is acceptable. Well, it's a minor issue, but it definitely is arguable. In the bugzilla task I received answer that for the ossim.sh file should be used %config macro. My question is: what is valid answer for this case? My recommendation is to use %config. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to make .spec Requires for libXXX.so.VER
On 08/01/2015 09:25 PM, Jan Kratochvil wrote: Hi, https://bugzilla.redhat.com/show_bug.cgi?id=1249325 GDB requires some library libXXX.so.3 by dlopen(). Therefore it is not found by rpm automatic requires/provides from DT_NEEDED. Therefore one has to add the libXXX.so.3 by specific BuildRequires and Requires to the .spec file. libXXX is librpm here but that is just a coincidence, it could be libz for example. (1) How to make a dependency on librpm.so.7? librpm.so.7 is in rpm-libs-4.12.90-3.fc24.x86_64 which --provides: librpm.so.7()(64bit) librpmio.so.7()(64bit) rpm-libs = 4.12.90-3.fc24 rpm-libs(x86-64) = 4.12.90-3.fc24 So there is no easy way to Requires: rpm-libs = NVRA How about: R: rpm-libs%{?_isa} = NVRA (2) The other possibility does work: BuildRequires: %{_libdir}/librpm.so.7 I guess you mean Requires: and not BuildRequires: ? That's what I have been using on similar occasions. Actually it's the only way I've found to handle situations, where packages dlopen libs from non-standard (often hard-coded) paths[1]: R: %{_libdir}/somewhere/lib.so.y Ralf [1] IMO, dlopen'ing libs from standard paths is a very questionable design, IMO, because it doesn't provide many advantages over ordinary shared linkage. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: How to make .spec Requires for libXXX.so.VER
On 08/02/2015 09:33 AM, Jan Kratochvil wrote: It was reworked from ordinary DT_NEEDED to this dlopen() approach because librpm.so is (was) the only incompatible shared library dependency between various versions of RHELs/CentOSes and Fedoras. So with dlopen()ed librpm one can take latest Fedora Rawhide rpm build and run the GDB binary in RHEL/CentOS. This makes sense for non-x86* archs where a rebuild of new GDB from sources would take too much time. I still don't get it. If librpm's SONAME changes between Fedora releases, these libs will be call incompatible, no matter if they will be dlopen'ed or linked directly. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Help needed: F23 32-bit kernel issue
On 07/29/2015 11:12 PM, Josh Boyer wrote: On Wed, Jul 29, 2015 at 4:55 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Jul 29, 2015 at 10:36:07AM -0400, Josh Boyer wrote: Secondly, it would be excellent if someone could commit to spinning test ISOs when requested. Turn around time on bugs like this are quite lengthy given that they often require building a new kernel package, and then spinning a custom ISO with that package included. Ideally the ISO content would not change from spin to spin other than the kernel, to eliminate variables. Could qemu-sanity-check[1] help here? It's designed so that you can test if a kernel boots on qemu, in a very simple manner (it was actually designed to be run from kernel.spec so we'd never build and ship a non-working kernel again). No, because the environment on the boot.iso/DVD image is what is triggering the bug. You need a full compose with the kernel. I already mentioned we autotest the kernel in VMs and it doesn't hit this bug. Running it there (or even moreso from kernel.spec) cannot possibly cover all scenarios, so claiming it would prevent shipping a non-working kernel again is inaccurate given that setup didn't catch this. More testing always helps, but nothing will provide the claim you make. FWIW: I locally rebuilt 4.2.0-0.rc4.git2.1 for fc22 and gave the resulting kernel-4.2.0-0.rc4.git2.1.fc22.i686+PAE*rpm a real-world try on my fc22 netbook (w/ Atom N270). AFAICT, so far, it seems to boot (and work) without any apparent immediate issues. So, my wild guess would be on an iso/boot-image composition or tooling issue. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Updates push status - 20150725
On 07/28/2015 07:57 AM, Alexander Ploumistos wrote: Has the issue been resolved? I have pushed three new packages to f22 and f21 updates-testing, but they have yet to appear in my usual local mirrors. I guess no. I am waiting for my updates to get for weeks and am already withholding other followup updates. Folks, please think about the implications this kind of unreliability has on Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About making noarch package arch specific, when contents differ.
On 07/28/2015 10:58 AM, Florian Weimer wrote: On 07/26/2015 04:05 PM, Paulo César Pereira de Andrade wrote: Should I make the doc packages arch specific? No, this is not a reason to make them arch-specific. A lot of packages give different results when built twice in a row, on the *same* architecture. There is an effort under way to change that, called “reproducible builds”. Actually, reproducable builds wrt. docs have been subject to Fedora Packaging since Fedora day #1 and repeatedly have been subject to discussions of details (e.g. doxygen repeatedly had introduced docs breakages) Packages which do not comply to this rule are broken. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: About making noarch package arch specific, when contents differ.
On 07/28/2015 03:34 AM, Dan Callaghan wrote: Excerpts from paulo.cesar.pereira.de.andrade's message of 2015-07-27 00:05 +10:00: Should I make the doc packages arch specific? Rather than trying to make Sphinx spit out bitwise-identical output on every arch (which sounds like fighting a losing battle), could you just build the doc subpackage on only one arch? This is a blatant hack. Packages builds must be reproducable on any supported architecture. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposal: Drop comps
On 07/15/2015 10:20 AM, Vít Ondruch wrote: Description and Summary can be localized in .spec file [1], where supposedly names in comps terminology refers to summary in .spec terminology. Including translations is encouraged in guidelines as well [2, 3], unfortunately without any further details :/ I don't think localized summaries and descriptions are applicable in distributions like Fedora, where packages are maintained by individuals. IMO, making localized summaries/descrs. helpful would require a multilingal team of translators/packagers, whose sole task it would have to be to add translations for a predefined set of languages to maintain them. That said, I don't consider random packagers adding random translations to packages to be useful and to cause more problems than they solve. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving our processes for new contributors.
On 07/15/2015 07:03 PM, Przemek Klosowski wrote: On 07/15/2015 12:05 PM, Michael Schwendt wrote: On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote: I do understand where you're coming from: the Fedora workflow is quite complicated What exactly do you find quite complicated? https://fedoraproject.org/wiki/Package_Review_Process I was responding to Les' comment about the tools that one needs to use in order to package something: RPM, VCS, i18n, lib/autotool, COPR, Bodhi, mock, etc. Don't get me wrong---I am not saying that there's anything wrong with the tools, just that they seem easy to those who already mastered them, but may be intimidating to the uninitiated. Well, I consider knowledge about rpm, VCS, programming language to be elementary basic prerequistes to join as Fedora packager. Of course you don't need to be familiar with everything, but you should understand what you are doing - Assuring this is the aim of package-sponsors process. I agree with you that the Fedora specifics koji, bodhi, Fedora's git, Fedora's web sites leaves much to be desired. Getting into these is a steep entry hurdle. However, making new packagers familiar with this to an extend, which enables them to self-aid then, used to be the job of a new packager's *sponsor* (I prefer to call them mentors). It seems to me as if this aspect has almost be forgotten and packager-sponsors become a passport rubber-stamping duty. This is my point, actually, that it's hard for a packaging pro to appreciate the confusion of a newbie. Some kid-glove treatment, and ELI5 tutoring/mentoring might help. Well, I agree with you wrt tutoring/mentoring, but ... this has always been part of job of the sponsor - seriously, really. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bizarre koji error
Hi I am facing a bizarre f23-koji build breakdown: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366596 The interesting part seems to be hidden in this file: https://kojipkgs.fedoraproject.org//work/tasks/6598/10366598/checkout.log: $ git clone -n git://pkgs.fedoraproject.org/ht /var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht Cloning into '/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht'... fatal: read error: Connection reset by peer Same result, when retrying: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366729 An f24-build succeeded ca. 1/2 hour ago: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366109 WTH? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Bizarre koji error
On 07/15/2015 04:51 PM, Pierre-Yves Chibon wrote: On Wed, Jul 15, 2015 at 04:07:31PM +0200, Ralf Corsepius wrote: Hi I am facing a bizarre f23-koji build breakdown: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366596 The interesting part seems to be hidden in this file: https://kojipkgs.fedoraproject.org//work/tasks/6598/10366598/checkout.log: $ git clone -n git://pkgs.fedoraproject.org/ht /var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht Cloning into '/var/lib/mock/f23-build-3655660-501262/root/tmp/scmroot/ht'... fatal: read error: Connection reset by peer Same result, when retrying: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366729 An f24-build succeeded ca. 1/2 hour ago: http://koji.fedoraproject.org/koji/taskinfo?taskID=10366109 We had a weird SELinux issue that I fixed this morning and that has apparently surfaced again this afternoon. So I re-labeled the tree again and it should be working again. I don't know, whether this SELinux issue was the culprit ;) All I can say, another 3rd build attempt (ca. yet another 1/2 hour later) succeeded: http://koji.fedoraproject.org/koji/taskinfo?taskID=10367098 Let us know if that's not the case Well, ... I really don't know the cause. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Improving our processes for new contributors.
On 07/15/2015 06:05 PM, Michael Schwendt wrote: On Wed, 15 Jul 2015 11:05:40 -0400, Przemek Klosowski wrote: Well, watching all the people that somehow manage to submit new packages into the review queue, the process up to that point can't be too bad, and one can safely assume they would be perfectly capable of submitting them into Copr, too. But do they want that? At least I do not want that, because I do not see much sense in this. Do they want to create a personal repository where users likely don't find the packages? Or do they prefer inclusion of the packages in the official Fedora package collection? The latter. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2015-07-01)
On 07/07/2015 03:54 PM, Chris Adams wrote: Once upon a time, Michael Catanzaro mcatanz...@gnome.org said: For Fedora 24, we've proposed trimming down Anaconda much more, since most of Anaconda's functionality is redundant with our initial setup tool that already handles language, keyboard, and timezone selection: h ttps://listman.redhat.com/archives/anaconda-devel-list/2015 -June/msg7.html Unless the installer is not going to ask any questions or give any information, language and keyboard are needed for input/output during install. It also needs to ask for all kind of installation partitions, where to make room if disk is full, where to install the bootloader and ... should not blindly install a waggon load of packages, a user doesn't want and will have to uninstall manually ;) Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Discontinuing perl-Mail-GnuPG
Hi, I indent to discontinue and remove perl-Mail-GnuPG from Fedora. It FTBFS on rawhide, because it seem to suffer from compatibility issues with gnupg2 = 2.1.5 [1]. AFAIS, nothing in Fedora uses it, so this step probably won't do much harm. Should gnupg2 in Fedora 23 be updated, perl-Mail-GnuPG will rendered dysfunctional there. I could add Requires: gnupg2 2.1.5 there but this is something I'd rather not do. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1234738 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Discontinuing perl-Mail-GnuPG
Hi, I indent to discontinue and remove perl-Mail-GnuPG from Fedora. It FTBFS on rawhide, because it seem to suffer from compatibility issues with gnupg2 = 2.1.5 [1]. AFAIS, nothing in Fedora uses it, so this step probably won't do much harm. Should gnupg2 in Fedora 23 be updated, perl-Mail-GnuPG will rendered dysfunctional there. I could add Requires: gnupg2 2.1.5 there but this is something I'd rather not do. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1234738 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
dnf Failed to synchronize cache for repo 'updates'
Hi, seems to me, as if fedora 22 updates is down: # dnf --refresh update RPM Fusion for Fedora 22 - Free - Updates 12 kB/s | 395 B 00:00 RPM Fusion for Fedora 22 - Nonfree - Updates 552 B/s | 395 B 00:00 RPM Fusion for Fedora 22 - Free 3.5 MB/s | 461 kB 00:00 Error: Failed to synchronize cache for repo 'updates' from 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22arch=i386': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Sorry, if this is the wrong list, but I don't know where to report this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf Failed to synchronize cache for repo 'updates'
On 06/19/2015 04:53 PM, Reindl Harald wrote: Am 19.06.2015 um 16:40 schrieb Ralf Corsepius: seems to me, as if fedora 22 updates is down: # dnf --refresh update RPM Fusion for Fedora 22 - Free - Updates 12 kB/s | 395 B 00:00 RPM Fusion for Fedora 22 - Nonfree - Updates 552 B/s | 395 B 00:00 RPM Fusion for Fedora 22 - Free 3.5 MB/s | 461 kB 00:00 Error: Failed to synchronize cache for repo 'updates' from 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f22arch=i386': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Sorry, if this is the wrong list, but I don't know where to report this that's likely not a DNF issue Who knows? ;-) Of course, you're right, it's likely a master repository, mirrormanager or mirroring issue, or similar. FWIW: I am now also observing a similar issue with yum and f21/updates: # yum update ... Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-21arch=i386 error was 14: HTTPS Error 502 - Bad Gateway updates/21/i386/metalink | 18 kB 00:00:29 updates | 4.9 kB 00:00:00 http://mirror2.hs-esslingen.de/fedora/linux/updates/21/i386/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for updates Trying other mirror. [traversing all EU-mirror but finding one in the end] Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 mass rebuild
On 06/17/2015 04:14 PM, Sérgio Basto wrote: The Perl 5.22 mass rebuild broke po4a I checked in a patch which hopefully fixes po4a, earlier today. (https://bugzilla.redhat.com/show_bug.cgi?id=1230977) It doesn't seem to be on the rawhide mirrors yet, but it's already in Fedora's builders. So, I'd recommend to try rebuilding the po4a-caused failed builds in scratch-builds and to really rebuild them, if the scratch-builds work (I already noticed some po4a-failed packages have further issues). Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)
On 06/12/2015 02:48 PM, Neal Gompa wrote: Soft/weak dependencies are allowed, according to FESCo It doesn't matter much what FESCO says of believes in this case. ATM, neither is the technical infrastructure is in place (it is evolving) nor are impact/consequences clear not are the prototypical use-cases of soft/weak-deps clear. @Thorsten: I do not think, weak/soft-deps are of use in your case. Unfortunatley, I do not have solution, either. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Can soft dependencies help to get the proper kernel-devel packages? (Was: Soft- Re: DKMS is not installing the right kernel-devel package)
On 06/12/2015 03:23 PM, Neal Gompa wrote: On Fri, Jun 12, 2015 at 9:18 AM, Ralf Corsepius rc040...@freenet.de wrote: On 06/12/2015 02:48 PM, Neal Gompa wrote: Soft/weak dependencies are allowed, according to FESCo It doesn't matter much what FESCO says of believes in this case. ATM, neither is the technical infrastructure is in place (it is evolving) nor are impact/consequences clear not are the prototypical use-cases of soft/weak-deps clear. @Thorsten: I do not think, weak/soft-deps are of use in your case. Unfortunatley, I do not have solution, either. What do you mean by the technical infrastructure for it is lacking? E.g. /usr/bin/rpm still lacks the --what* command-line options corresponding to soft/weak deps. This issue was mentioned the rpm maintainer in an FPC meeting (IIRC, 3 weeks ago), when we were discussing soft/weak-deps but nothing seems to have happened since. Therefore I just (I could have done so earlier, but have been on vacation) filed an RFE against rpm: https://bugzilla.redhat.com/show_bug.cgi?id=1231247 Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: f22 screensaver/lockout issue requiring reboot :/
On 06/10/2015 03:45 PM, Przemek Klosowski wrote: On 06/10/2015 09:04 AM, Paul Wouters wrote: Am I the only one who is constantly locked out of their X session on fedora 22? Once the screen locks, it refuses my actual password to unlock. Even killing X with ctrl-alt-backspace doesn't help because it will just startup again in locked screen mode. I basically have to reboot every time my screen locks. And yes, the screensaver preferences even have lock screen after unselected but my screen gets locked anyway. I've seen a similar thing happen in a recent Ubuntu install. Try to 'select other user' and select yourself again. Does the password work then? Not sure if this is the same issue or related to your issues, but I couldn't ssh into machines which were upgraded from f21 to f22. In my case, touch /.autorelabel and rebooting to force an SELinux-relabel helped, which makes me believe SELinux was to blame. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rapid release for security updates
On 05/26/2015 06:22 PM, Stephen Gallagher wrote: On Tue, 2015-05-26 at 15:33 +0200, Ralf Corsepius wrote: On 05/26/2015 12:10 PM, Andrew Haley wrote: Something needs to be done, but I'm not sure exactly what. IMO, all this should not be a problem, if collaborative maintenance works. What I mean, IMO, critical packages should have a sufficient number of co-maintainers, who should be presumed to be sufficiently familiar with a package to provide enough karma, which would allow such packages to pass quickly. That might work for comparatively simple packages, but what about the kernel? Kernel updates have the potential to completely break things (particularly if the security patch comes along with a point release). Well, admitted the kernel is a special case :-) Therefore, I wrote co-maintainers, who should be sufficiently familiar with a package above, and did not write arbitrary packagers or arbitrary users. I am presuming knowledgeable people, who at least are able to estimate the impact of a set of changes in cases of urgent security updates. IMO, arbitrary users' karma are mostly worthless - in general. In most cases, all these karma-votes are telling is update doesn't immediately let my system go up in flames. I'm not trying to disparage the kernel maintainers, but there's absolutely no way they can test all possible hardware before releasing an update. There's still value to the updates-testing repo, even for security updates. Definitely. May-be I wasn't clear enough. I do not want to circumvent updates-testing, but wanted to sketch a route to utilize updates-testing even for urgent security updates. I agree we need to figure out ways to grease the wheels so that important updates get out faster, though. The aspect I was referring to is urgency. In this cases, IMO, it's more than appropriate to ask those people who can be assumed to be best knowledgeable (e.g. co-maintainers and/or a dedicated security team) to team up. Of course, this all presumes critical packages (firefox, thunderbird, kernel, glibc, ssh/ssl etc,) and updates have a team behind and aren't soloist efforts. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22 Dispplay with stripes
On 05/27/2015 05:27 PM, Sergio Belkin wrote: Video card: Slot: 00:02.0 Class: VGA compatible controller Vendor: Intel Corporation Device: 82945G/GZ Integrated Graphics Controller SVendor:Elitegroup Computer Systems SDevice:Device 1b76 Rev:02 Driver: i915 Module: i915 What did you use to get this list? It's different than the lspci output. lspci identifies mine as: Intel Corporation 82865G Integrated Graphics Controller (rev 02) lspci -v -mm -k ;) Nice, isn't it? It's a bit weird I've reenabled the composite in KDE and problem it went away... Hi, any news, ideas, with about this topic, driver is working terrible, I thought that was a KDE issue, but in MATE it happens either... Today, a similar issue happened to me with the Fedora installer, when installing F22 on my old netbook. When the installation started, initially a couple of horizontal strips appeared, which gradually accumulated until the display was entirely unreadable and distorted. Video card: Slot: 00:02.0 Class: VGA compatible controller Vendor: Intel Corporation Device: Mobile 945GSE Express Integrated Graphics Controller SVendor:Micro-Star International Co., Ltd. [MSI] SDevice:Device 0110 Rev:03 Driver: i915 Module: i915 Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Rapid release for security updates
On 05/26/2015 12:10 PM, Andrew Haley wrote: Something needs to be done, but I'm not sure exactly what. IMO, all this should not be a problem, if collaborative maintenance works. What I mean, IMO, critical packages should have a sufficient number of co-maintainers, who should be presumed to be sufficiently familiar with a package to provide enough karma, which would allow such packages to pass quickly. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct