Re: finish retirement of sysvinit-only packages Re: Schedule for Friday's FESCo Meeting (2016-07-29)
On Wed, Aug 3, 2016 at 8:56 AM, Solomon Peachy wrote: > On Wed, Aug 03, 2016 at 12:15:09AM -0400, Nico Kadel-Garcia wrote: >> Those do get ported. I didn't mean to be confusing. "buildbot", the >> Python based build tool, is unlikely to ever be ported. Not that it's >> a very good tool, but it remains additionally unlikely to be ported >> due to the extra burden of having to provide system admin provided >> systemd integration. > > https://github.com/buildbot/buildbot/blob/master/master/contrib/systemd/buildbot.service > > This commit landed in January, 2014, and sits alongside an example > sysvinit script. Fedora's packages include neither, not even as > exmples -- there's no provided init integration at all. Interesting, and thank you for the pointer. It was not in the tag that I last worked with. > Incidently, I wouldn't consider buildbot an example of a "decades-old" > daemon for which systemd adds nothing; indeed it's one of the most > finiky and brittle tools I've ever used, and systemd's isolation, > logging, and cleanup features are greatly beneficial when trying to > figure out why buildbot has crapped out yet again. Oh, dear lord, I agree it's horrible and does nothing that Jenkins or even Hudson didn't master a decade ago. I'm having some difficulty finding decades old standards that haven't either died, or have finally gained systemd support. Much of the systemd support remains outside the primary source repository for many daemons, including httpd and OpenSSH and Subverison that I mentioned. Buildbot... has surprised me by having enough suckers stuck using it to ever have gotten systemd tools written for it. One of the benefit of a sysvinit script that I've not personally made clear is that it's easier to start it *from the console*, and activate gdb or a graphical debugger around it the running binary. I've never seen anyone get that working for systemd, and activating the daemons in systemd typically requires administrative privileges. It's often easier to activate a daemon with a raw init script, as a local user, without adding the potentially fragile intricacies of running it as a systemd daemon. If it fails once, you get one core file suitable for debugging, and the daemon stays *dead* until manually restarted. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: check-buildroot blows up with a Go binary
On Thu, 4 Aug 2016 12:53:24 -0600 Jerry James wrote: > That error means that the string > "/q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64" appears > in one of the files listed in %files. Grep for BUILDROOT in your > installed file tree to find the culprit(s). Jerry, thanks a lot, this was a key insight. Now all I need is to find parameters for the go compiler that preclude it from packing the debugging information into the binary. Although, now I'm curious how this differs from what C compiler does, and why the debuginfo extraction process can't deal with this binary. -- Pete -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 4, 2016 at 4:08 PM, Adam Williamson wrote: > On Thu, 2016-08-04 at 21:02 +0100, Tom Hughes wrote: >> On 04/08/16 20:48, Adam Williamson wrote: >> >> > >> > The page says that Koji will be modified to run all the per-arch build >> > tasks to completion even if one fails (as opposed to how it behaves >> > now, cancelling all the other arch tasks as soon as any one fails), but >> > a failure of any of them will still constitute a failure of the overall >> > task. >> >> Well that's how I read it at first as well, but if you read on it talks >> about how to deal with subsequent builds seeing different libraries if >> some builds had failed, which implies the task wouldn't be failed and >> the builds had worked would be published. >> >> So currently I think we can only say it's somewhat unclear what the plan >> is... > > It talks about that as a *justification* for not doing it: > > "The issue with not failing all builds when a single arch fails is how > we deal with any builds that are dependent on that package?" > > i.e. it's saying the reason they chose *not* to allow builds to succeed > with some arches failing is because of the problem of dependent > packages then being out of sync across arches. That's already the situation now, anyway. And we're not unique in this. Debian does things similarly with their autobuilder/buildd system. If anything we probably just need some way to track on a per arch level to warn when it happens so that the right people can deal with the situation. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, 2016-08-04 at 21:02 +0100, Tom Hughes wrote: > On 04/08/16 20:48, Adam Williamson wrote: > > > > > The page says that Koji will be modified to run all the per-arch build > > tasks to completion even if one fails (as opposed to how it behaves > > now, cancelling all the other arch tasks as soon as any one fails), but > > a failure of any of them will still constitute a failure of the overall > > task. > > Well that's how I read it at first as well, but if you read on it talks > about how to deal with subsequent builds seeing different libraries if > some builds had failed, which implies the task wouldn't be failed and > the builds had worked would be published. > > So currently I think we can only say it's somewhat unclear what the plan > is... It talks about that as a *justification* for not doing it: "The issue with not failing all builds when a single arch fails is how we deal with any builds that are dependent on that package?" i.e. it's saying the reason they chose *not* to allow builds to succeed with some arches failing is because of the problem of dependent packages then being out of sync across arches. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On 04/08/16 20:48, Adam Williamson wrote: The page says that Koji will be modified to run all the per-arch build tasks to completion even if one fails (as opposed to how it behaves now, cancelling all the other arch tasks as soon as any one fails), but a failure of any of them will still constitute a failure of the overall task. Well that's how I read it at first as well, but if you read on it talks about how to deal with subsequent builds seeing different libraries if some builds had failed, which implies the task wouldn't be failed and the builds had worked would be published. So currently I think we can only say it's somewhat unclear what the plan is... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, 2016-08-04 at 15:56 -0400, Neal Gompa wrote: > On Thu, Aug 4, 2016 at 3:53 PM, Richard W.M. Jones wrote: > > > > On Thu, Aug 04, 2016 at 04:07:31PM +0100, Peter Robinson wrote: > > > > > > [1] > > > https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures > > > > I skimmed all this and I'm still a bit confused. > > > > Will there be one Koji instance compiling for every (current primary + > > current secondary) arch? Or will there be two instances, one for all > > primary and one for all secondary? > > > > From what I can tell, shadow Koji instances are going away entirely. > There will be one Koji system to rule them all. > > > > > Will a build failure on (say) aarch64 prevent my package from > > progressing to Rawhide (x86_64), bodhi etc? > > > > -*- -*- -*- > > That's what Adam Williamson seems to indicate, which I expect to be > quite problematic. The page explicitly states it, under "Will a single arch failure affect the overall build failure?" -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 4, 2016 at 3:53 PM, Richard W.M. Jones wrote: > On Thu, Aug 04, 2016 at 04:07:31PM +0100, Peter Robinson wrote: >> [1] >> https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures > > I skimmed all this and I'm still a bit confused. > > Will there be one Koji instance compiling for every (current primary + > current secondary) arch? Or will there be two instances, one for all > primary and one for all secondary? > From what I can tell, shadow Koji instances are going away entirely. There will be one Koji system to rule them all. > Will a build failure on (say) aarch64 prevent my package from > progressing to Rawhide (x86_64), bodhi etc? > > -*- -*- -*- That's what Adam Williamson seems to indicate, which I expect to be quite problematic. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 04, 2016 at 04:07:31PM +0100, Peter Robinson wrote: > [1] > https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures I skimmed all this and I'm still a bit confused. Will there be one Koji instance compiling for every (current primary + current secondary) arch? Or will there be two instances, one for all primary and one for all secondary? Will a build failure on (say) aarch64 prevent my package from progressing to Rawhide (x86_64), bodhi etc? -*- -*- -*- On the subject of alternate architectures, I'm making available Fedora images available in virt-builder for aarch64, armv7l, ppc64 and ppc64le. There is a complete set for Fedora 23, and a partial set for Fedora 24 (booting problems on ppc64 - will be solved eventually). You can run these up on x86_64 hosts quite easily. For an example of how see: https://rwmj.wordpress.com/2015/04/15/virt-builder-fedora-21-ppc64-and-ppc64le-images/ (The virt-install method is now the recommended one. Don't run qemu directly.) -*- -*- -*- On the subject of RISC-V, I'm still plugging away at this. It's rather slow going, but you can take a look at: http://git.annexia.org/?p=fedora-riscv.git;a=summary There is nothing much usable at the moment, and many stumbling blocks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, 2016-08-04 at 15:44 -0400, Neal Gompa wrote: > > I think the solid way to address this is to make each architecture > independent and don't stop the build for any arch if any other arch > fails. The total failure state can be figured out once all the arches > have completed and based on criteria on which ones are considered > fatal or not, it would make a judgement. This is how it is done in > Youri for Mageia. When we submit packages to build, all architectures > build. However, only a failure in i586 and x86_64 triggers the failed > state. Builds in armv5tl and armv7hl do not. The page says that Koji will be modified to run all the per-arch build tasks to completion even if one fails (as opposed to how it behaves now, cancelling all the other arch tasks as soon as any one fails), but a failure of any of them will still constitute a failure of the overall task. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 4, 2016 at 2:49 PM, Adam Williamson wrote: > On Thu, 2016-08-04 at 11:41 -0700, Adam Williamson wrote: >> On Thu, 2016-08-04 at 16:07 +0100, Peter Robinson wrote: >> > >> > Hi All, >> > >> > We are planning to change the way Alternate Architectures (non x86_64) >> > are handled >> > in terms of "primary" vs "secondary". The definition of what is >> > primary or secondary >> > is already handled more in terms of the build artifact outputs (images, >> > LiveCDs, >> > installers, containers etc) for i686 deliverables. As part of this >> > redefinition >> > this means that the location in "koji instances" of the rpm builds is >> > removed as >> > a part of the definition requirement of what constitutes >> > primary/secondary and the >> > architectures are named "Alternate Architectures" (and Experimental >> > architectures >> > for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a >> > result of this >> > change it is planned to merge the old "secondary" koji instances into a >> > single >> > koji instance along with all the current "Primary" architectures. >> > >> > All the details of the proposal along with FAQ have been put on a wiki >> > page here[1] >> > so please go and read it and ask any questions that aren't answered in >> > the FAQ here. >> >> I do have serious concerns about the impact of this in terms of build >> failures. Reading the reply to " Q: Why do I have to worry about >> s390x/powerpc/aarch64 when I didn't before?", it implies there will be >> no change to koji in terms of build failures: i.e. a failure on *any* >> arch will cause the entire build to be failed. > > Sorry, just saw there was a more specific entry for my concern, > "Q: Will a single arch failure affect the overall build failure?" Still > not 100% sure, but thanks for addressing it. I think the solid way to address this is to make each architecture independent and don't stop the build for any arch if any other arch fails. The total failure state can be figured out once all the arches have completed and based on criteria on which ones are considered fatal or not, it would make a judgement. This is how it is done in Youri for Mageia. When we submit packages to build, all architectures build. However, only a failure in i586 and x86_64 triggers the failed state. Builds in armv5tl and armv7hl do not. -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Pending ACLs
On Thu, Aug 04, 2016 at 04:43:40PM +0200, Fabio Alessandro Locati wrote: > Hi all, > > This morning, during the automation workshop, I had the occasion of > speaking about this with Pingou and Threebean. > Thanks to Pingou hints, I've created a query to get pending ACL from > pkgdb. > What I'd like to share with you all is the list of users that can > approve/deny ACL requests (older than 1 month) but have not done it yet > (the number refers to the number of ACL pending). > > I think that people should take care of the pending ACL they can > approve/deny and actually approve or deny them ASAP. Your email needs a "call to action" link, otherwise no one will know what they are supposed to do about it. In this case it's probably: https://admin.fedoraproject.org/pkgdb/acl/pending/ However I visited the above URL, logged in, and it says: Pending ACLs No pending ACLs for you So I guess this is wrong or perhaps refers to something else: ... > 3 rjones ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: check-buildroot blows up with a Go binary
On Thu, Aug 4, 2016 at 12:24 PM, Pete Zaitcev wrote: > Hi, All: > > I'm trying to package something that's written in Go, and as soon as > I have the compiled binary installed, the rpmbuild blows up like this: > > + /usr/lib/rpm/check-buildroot > Binary file > /q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64/usr/lib/debug/usr/bin/hummingbird.debug > matches > Binary file > /q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64/usr/bin/hummingbird > matches > Found '/q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64' in > installed files; aborting > error: Bad exit status from /var/tmp/rpm-tmp.9NyAWC (%install) > > When I showed this error to people on #fedora-devel, they suspected > that I managed to get the path to buildroot into %files, but it clearly > is not the case. I added the installation of the binary without any > changes to %files. Such build would normally break at the end in such > case, when it complains about unpackaged files found. But this case is > different, as above. > > Does anyone have any guesses about what's going on? That error means that the string "/q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64" appears in one of the files listed in %files. Grep for BUILDROOT in your installed file tree to find the culprit(s). -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, 2016-08-04 at 11:41 -0700, Adam Williamson wrote: > On Thu, 2016-08-04 at 16:07 +0100, Peter Robinson wrote: > > > > Hi All, > > > > We are planning to change the way Alternate Architectures (non x86_64) > > are handled > > in terms of "primary" vs "secondary". The definition of what is > > primary or secondary > > is already handled more in terms of the build artifact outputs (images, > > LiveCDs, > > installers, containers etc) for i686 deliverables. As part of this > > redefinition > > this means that the location in "koji instances" of the rpm builds is > > removed as > > a part of the definition requirement of what constitutes > > primary/secondary and the > > architectures are named "Alternate Architectures" (and Experimental > > architectures > > for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a > > result of this > > change it is planned to merge the old "secondary" koji instances into a > > single > > koji instance along with all the current "Primary" architectures. > > > > All the details of the proposal along with FAQ have been put on a wiki > > page here[1] > > so please go and read it and ask any questions that aren't answered in > > the FAQ here. > > I do have serious concerns about the impact of this in terms of build > failures. Reading the reply to " Q: Why do I have to worry about > s390x/powerpc/aarch64 when I didn't before?", it implies there will be > no change to koji in terms of build failures: i.e. a failure on *any* > arch will cause the entire build to be failed. Sorry, just saw there was a more specific entry for my concern, "Q: Will a single arch failure affect the overall build failure?" Still not 100% sure, but thanks for addressing it. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, 2016-08-04 at 16:07 +0100, Peter Robinson wrote: > Hi All, > > We are planning to change the way Alternate Architectures (non x86_64) > are handled > in terms of "primary" vs "secondary". The definition of what is > primary or secondary > is already handled more in terms of the build artifact outputs (images, > LiveCDs, > installers, containers etc) for i686 deliverables. As part of this > redefinition > this means that the location in "koji instances" of the rpm builds is removed > as > a part of the definition requirement of what constitutes > primary/secondary and the > architectures are named "Alternate Architectures" (and Experimental > architectures > for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a > result of this > change it is planned to merge the old "secondary" koji instances into a single > koji instance along with all the current "Primary" architectures. > > All the details of the proposal along with FAQ have been put on a wiki > page here[1] > so please go and read it and ask any questions that aren't answered in > the FAQ here. I do have serious concerns about the impact of this in terms of build failures. Reading the reply to " Q: Why do I have to worry about s390x/powerpc/aarch64 when I didn't before?", it implies there will be no change to koji in terms of build failures: i.e. a failure on *any* arch will cause the entire build to be failed. The answer...honestly does not convince me. I think the result will be a combination both of an increase in failed builds and the issues caused by them, and an increase in the number of packages which simply disable building on an arch entirely due to a lack of will to deal with build issues (and/or slow build time) on that arch. With secondary koji instances, neither of these are major issues, and secondary arch teams are able to work on build fixes for those arches without the maintainers being bothered by them. Has any consideration been given to the possibility of increasing Koji's flexibility here, by allowing for arches to be designated as non-fatal, so a package build failure on that arch would not cause the task to be considered a failure? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
check-buildroot blows up with a Go binary
Hi, All: I'm trying to package something that's written in Go, and as soon as I have the compiled binary installed, the rpmbuild blows up like this: + /usr/lib/rpm/check-buildroot Binary file /q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64/usr/lib/debug/usr/bin/hummingbird.debug matches Binary file /q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64/usr/bin/hummingbird matches Found '/q/zaitcev/rpms/BUILDROOT/openstack-swift-2.9.0-1.z5.x86_64' in installed files; aborting error: Bad exit status from /var/tmp/rpm-tmp.9NyAWC (%install) When I showed this error to people on #fedora-devel, they suspected that I managed to get the path to buildroot into %files, but it clearly is not the case. I added the installation of the binary without any changes to %files. Such build would normally break at the end in such case, when it complains about unpackaged files found. But this case is different, as above. Does anyone have any guesses about what's going on? Thanks in advance, -- Pete -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On Thu, Aug 4, 2016 at 10:27 AM, Stephen John Smoogen wrote: > On 4 August 2016 at 11:07, Peter Robinson wrote: > >> All the details of the proposal along with FAQ have been put on a wiki >> page here[1] >> so please go and read it and ask any questions that aren't answered in >> the FAQ here. >> >> Regards, >> Peter >> >> [1] >> https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures >> -- > > What is the update for this statement: > > Q: When will the new ARMv7 builders be in place? > > A: Soon! The current plan is mid to late July. This proposal isn't > impacted by this as ARMv7 is already a primary architecture. > > > since we are past July.. is it July 2017 :)? > > That wiki was only setup July 21st (Mid to Late July), so probably go with "Soon!" instead of any approximate date. Setting up a number of m400 aarch64 nodes to provide ARMv7 virtual builders is pretty cool. So I certainly appreciate infra taking their time to get it right. :-) -- -Jon Disnard -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Redefinition of the primary and secondary architectures
On 4 August 2016 at 11:07, Peter Robinson wrote: > All the details of the proposal along with FAQ have been put on a wiki > page here[1] > so please go and read it and ask any questions that aren't answered in > the FAQ here. > > Regards, > Peter > > [1] > https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures > -- What is the update for this statement: Q: When will the new ARMv7 builders be in place? A: Soon! The current plan is mid to late July. This proposal isn't impacted by this as ARMv7 is already a primary architecture. since we are past July.. is it July 2017 :)? > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Redefinition of the primary and secondary architectures
Hi All, We are planning to change the way Alternate Architectures (non x86_64) are handled in terms of "primary" vs "secondary". The definition of what is primary or secondary is already handled more in terms of the build artifact outputs (images, LiveCDs, installers, containers etc) for i686 deliverables. As part of this redefinition this means that the location in "koji instances" of the rpm builds is removed as a part of the definition requirement of what constitutes primary/secondary and the architectures are named "Alternate Architectures" (and Experimental architectures for the likes of MIPs/RISC-V) as opposed to primary/secondary. As a result of this change it is planned to merge the old "secondary" koji instances into a single koji instance along with all the current "Primary" architectures. All the details of the proposal along with FAQ have been put on a wiki page here[1] so please go and read it and ask any questions that aren't answered in the FAQ here. Regards, Peter [1] https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitectures -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Pending ACLs
Hi all, This morning, during the automation workshop, I had the occasion of speaking about this with Pingou and Threebean. Thanks to Pingou hints, I've created a query to get pending ACL from pkgdb. What I'd like to share with you all is the list of users that can approve/deny ACL requests (older than 1 month) but have not done it yet (the number refers to the number of ACL pending). I think that people should take care of the pending ACL they can approve/deny and actually approve or deny them ASAP. 263 cwickert 169 spot 123 bkabrda 114 patches 92 anishpatil 89 devrim 85 chkr 84 salimma 70 laxathom 63 mtasaka 53 sharkcz 50 mmorsi 43 timn 42 huzaifas 41 goldmann 37 ausil 36 willb 33 awjb 33 mmahut 31 dwmw2 31 hvad 30 mebrown 30 sxw 29 dcallagh 27 mclasen 27 dsommers 27 lystor 25 rmeggins 25 nhosoi 25 amigadave 25 pwouters 24 fnasser 24 pbrobinson 24 adev 24 ralph 24 dsd 24 corsepiu 23 steve 23 nkinder 22 brouhaha 22 jcapik 21 mbarnes 21 yyang 21 rishi 21 vcrhonek 21 mfojtik 21 thias 20 nb 20 jsteffan 19 tieugene 19 mharmsen 19 jamielinux 18 geoff 18 gecko-maint 18 ingvar 18 dwalsh 18 apevec 18 ajax 17 sdz 17 dvratil 17 gomix 17 thomasvs 16 jskarvad 16 tomprince 16 otaylor 16 dwalluck 16 smilner 15 caillon 15 kanarip 15 walters 15 nucleo 15 cjb 15 praveenp 14 sgallagh 14 s4504kr 14 flaper87 14 mlichvar 14 gholms 14 jstanley 13 lucilanga 13 rlandmann 13 tagoh 13 stingray 13 jvcelak 13 xavierb 13 spike 12 weli 12 chitlesh 12 melmorabity 12 sophiekovalevsky 12 alcapcom 12 susmit 12 robmv 12 elwell 12 bpepple 12 aalam 12 stransky 12 npmccallum 12 nushio 12 pvoborni 12 elad 12 dcbw 12 kylev 12 whot 12 ssp 11 fkocina 11 tuxbrewr 11 richardfearn 11 madko 11 oron 10 imcleod 10 tdabasin 10 potty 10 zaitcev 10 jamielennox 10 steved 10 fkluknav 10 clalance 10 lmacken 10 giallu 10 dmach 9 jklimes 9 larsks 9 pmatilai 9 elsupergomez 9 uraeus 9 rclark 9 shreyankg 9 tomspur 9 msivak 9 hubbitus 9 mgrepl 9 gemi 9 erikos 9 sundaram 9 stevetraylen 8 petersen 8 jeckersb 8 echevemaster 8 sseago 8 radez 8 puiterwijk 8 averi 8 jaruga 7 timj 7 terminalmage 7 mchehab 7 abo 7 djuran 7 lsm5 7 uwog 7 abbot 6 rmyers 6 rspanton 6 kdudka 6 ewan 6 rcritten 6 lennart 6 anttix 6 rohara 6 mstuchli 6 phatina 6 zeenix 6 bkearney 6 scox 6 matthicksj 6 tonet666p 6 alvesadrian 6 cleech 6 drsmith2 6 wolfy 6 hpejakle 6 radford 6 skottler 6 adrian 6 lzap 6 izhar 6 karsten 6 bentiss 6 ovasik 6 elanthis 6 mjw 6 sadmac 6 renich 6 jgarzik 6 hadess 6 scop 6 twoerner 6 pmachata 6 pfrankli 6 jpo 6 ianweller 6 lberk 6 pravins 6 dbhole 6 peter 6 fche 6 matriux 6 rvokal 6 mhlavink 6 sgrubb 6 ellert 6 nathans 6 myoung 6 jstanek 6 wcohen 6 cerberus 6 tomeu 6 john2583 6 jforbes 6 jistone 6 ivazquez 6 zironid 6 firnsy 5 praiskup 5 kushal 5 strobert 5 nsantos 5 dougsland 5 filiperosset 5 pavlix 5 jcp 5 sayanchowdhury 5 adalloz 5 sejeff 5 alikins 5 somlo 5 mikeb 5 jjh 5 delete 5 ixs 5 ssalevan 5 ndipanov 5 tbreeds 5 van 5 sross 4 rcurtin 4 fabbione 4 rajalakshmi 4 aviso 4 mdomsch 4 than 4 nbecker 4 besser82 4 denisarnaud 4 rakesh 4 kevin 4 nacho 4 aviram 4 sdake 4 davidz 4 toshio 4 herrold 4 daveisfera 4 akurtakov 3 james 3 magcius 3 perex 3 mmuzila 3 zpavlas 3 pjp 3 jbernard 3 johnp 3 dwayne 3 galt 3 nalin 3 meyering 3 rkennke 3 pjones 3 fabiand 3 hhorak 3 alexl 3 pbrady 3 rjones 3 cbb 3 nkumar 3 svashisht 3 marx 3 jcm 3 rharwood 3 jlaska 3 packaging-team 3 shenson 3 yselkowitz 3 clime 3 ffesti 3
Re: Bodhi UI Redesign User Survey
Hi Bjorn, Thanks for the feedback It will be great if you could share your thoughts on improving the interface. It will be useful for incorporating that into our survey which ultimately will benefit the re-design process. Radhika On 08/04/2016 04:41 AM, Björn Persson wrote: rkolathu wrote: I have been working on the Bodhi web UI redesign project and would require your participation to complete the survey given in this email. None of the offered choices match my actual thoughts about the displayed user interface parts. Thus it's impossible for me to give useful answers to the survey. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora 25-20160804.n.0 compose check report
Missing expected images: Workstation live i386 Cloud_base raw-xz x86_64 Xfce raw-xz armhfp Cloud_base raw-xz i386 Atomic raw-xz x86_64 Minimal raw-xz armhfp Workstation live x86_64 Failed openQA tests: 36/81 (x86_64), 5/16 (i386) ID: 27338 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27338 ID: 27339 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27339 ID: 27341 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27341 ID: 27342 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27342 ID: 27343 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27343 ID: 27344 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27344 ID: 27345 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27345 ID: 27351 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27351 ID: 27352 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27352 ID: 27353 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27353 ID: 27356 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/27356 ID: 27359 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27359 ID: 27363 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/27363 ID: 27365 Test: x86_64 Server-dvd-iso server_cockpit_default URL: https://openqa.fedoraproject.org/tests/27365 ID: 27370 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27370 ID: 27381 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/27381 ID: 27383 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/27383 ID: 27384 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/27384 ID: 27385 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/27385 ID: 27386 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/27386 ID: 27387 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/27387 ID: 27388 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/27388 ID: 27389 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/27389 ID: 27390 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/27390 ID: 27391 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/27391 ID: 27392 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/27392 ID: 27394 Test: x86_64 universal upgrade_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27394 ID: 27395 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27395 ID: 27396 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/27396 ID: 27397 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/27397 ID: 27398 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27398 ID: 27399 Test: x86_64 universal upgrade_2_minimal_64bit URL: https://openqa.fedoraproject.org/tests/27399 ID: 27400 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27400 ID: 27401 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/27401 ID: 27402 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/27402 ID: 27403 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27403 ID: 27411 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/27411 ID: 27416 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/27416 ID: 27420 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/27420 ID: 27432 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27432 ID: 27433 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27433 Passed openQA tests: 36/81 (x86_64), 11/16 (i386) Skipped openQA tests: 7 of 97 -- Mail generated by che
Fedora Rawhide-20160804.n.0 compose check report
Missing expected images: Workstation live i386 Cloud_base raw-xz x86_64 Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Minimal raw-xz armhfp Workstation live x86_64 Failed openQA tests: 32/82 (x86_64), 5/16 (i386) ID: 27240 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27240 ID: 27241 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27241 ID: 27243 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27243 ID: 27244 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27244 ID: 27245 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27245 ID: 27246 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27246 ID: 27247 Test: x86_64 KDE-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/27247 ID: 27248 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27248 ID: 27254 Test: i386 KDE-live-iso install_default URL: https://openqa.fedoraproject.org/tests/27254 ID: 27255 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27255 ID: 27256 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27256 ID: 27259 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/27259 ID: 27262 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/27262 ID: 27266 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller URL: https://openqa.fedoraproject.org/tests/27266 ID: 27273 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/27273 ID: 27284 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/27284 ID: 27286 Test: x86_64 universal install_simple_encrypted@uefi URL: https://openqa.fedoraproject.org/tests/27286 ID: 27287 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/27287 ID: 27288 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/27288 ID: 27289 Test: x86_64 universal install_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/27289 ID: 27290 Test: x86_64 universal install_delete_partial@uefi URL: https://openqa.fedoraproject.org/tests/27290 ID: 27291 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/27291 ID: 27292 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/27292 ID: 27293 Test: x86_64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/27293 ID: 27294 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/27294 ID: 27295 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/27295 ID: 27298 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27298 ID: 27301 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27301 ID: 27303 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/27303 ID: 27304 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/27304 ID: 27305 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/27305 ID: 27306 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/27306 ID: 27314 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/27314 ID: 27319 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/27319 ID: 27323 Test: x86_64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/27323 ID: 27335 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27335 ID: 27336 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/27336 Passed openQA tests: 42/82 (x86_64), 11/16 (i386) Skipped openQA tests: 6 of 98 -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bodhi UI Redesign User Survey
rkolathu wrote: > I have been working on the Bodhi web UI redesign project and would > require your participation to complete the survey given in this email. None of the offered choices match my actual thoughts about the displayed user interface parts. Thus it's impossible for me to give useful answers to the survey. Björn Persson pgpHJOMHYbbth.pgp Description: OpenPGP digital signatur -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Orphaning pykka
I've just orphaned pykka (https://admin.fedoraproject.org/pkgdb/package /rpms/pykka/) as I'm no longer using it. Jonathan -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: kernel 4.7 on stable ?
On 08/03/2016 09:57 PM, Bruno Wolff III wrote: On Thu, Aug 04, 2016 at 05:02:56 +0100, Sérgio Basto wrote: Hi, From list of koji builds [1] rawhide and F25 uses pre 4.8. My question is kernel-4.7.0-2 doesn't land on F24 and F23 ? , since kernel 4.6 already have a short live and 4.7 fix my cpu-freq kernel ooops , I vote in have kernel-4.7 in stable releases :). It will probably be there eventually. Usually the .1 or .2 releases make it to released versions of Fedora. You might want to read this blog entry from a member of the Fedora kernel team: http://jwboyer.livejournal.com/51935.html Yes, this is correct. I haven't seen a stable release for 4.7 yet. Once 4.7.1 comes out I'll take a serious look at bringing it in to F24 and F23. 4.7 is in the copr stabilization branch for F24 if you wanted to test that as well https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/ . Thanks, Laura -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: hfsplus-tools executables renamed
Il 03/08/2016 17:07, Chris Murphy ha scritto: On Wed, Aug 3, 2016 at 12:43 AM, Ville Skyttä wrote: On Wed, Aug 3, 2016 at 9:00 AM, Mattia Verga wrote: it seems that the hfsplus-tools package arbitrary renames its executables. This prevents kde-partitionmanager to fully support HFS+. I've opened a bug [1] for this, but I received no answer. Anyone knows why those executables are renamed? Don't know, but I guess that's done to make "mkfs -t hfsplus" and "fsck -t hfsplus" work. See the mkfs and fsck man pages for more info. I'm pretty sure a symlink mkfs.hfsplus -> newfs_hfs and fsck.hfsplus -> fsck_hfs would satisfy all requirements. This is what ntfsprogs does. Thanks, I also think using symlinks instead of renaming executables would be better. I will add a note to the bug report to see if this is possible. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
