Re: Two FAS accounts for the same person - permitted?
On Tue, Feb 02, 2010 at 09:47:13AM -0600, Mike McGrath wrote: > On Tue, 2 Feb 2010, Till Maas wrote: > > > On Tue, Feb 02, 2010 at 09:01:25AM -0600, Mike McGrath wrote: > > > > > It's not automatically enforcable that's true but we catch you doing it > > > (and we have) and we'll do something about it. Turns out the honor system > > > wasn't enough to keep people honorable so we had to make a rule. > > > > IIRC this change was not announced, was it? > > > > It's been in place for years so I don't know if it was announced or not. > Consider it announced. According to the wiki, the change was 17 months ago: https://fedoraproject.org/w/index.php?title=Account_System&diff=48371&oldid=48039 Regards Till pgpCI10I9gmJC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote: > I am sorry, but I do not see a real need for special guideline for the > fipscheck checksums. The policy where these checksums should/will be > placed should be decided by the fipscheck package itself. Of course I As soon as multiple packages are affected, there should be a guideline to document how something needs to be done to work, e.g. if someone wants to package a new software that contains fips checksums. Regards Till pgpH0W92gI7Fd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (05/2010)
On Tue, Feb 02, 2010 at 07:59:38PM +, Richard Hughes wrote: > On 2 February 2010 15:44, Till Maas wrote: > > While you are fixing PackageKit dependencies, can you also remove the > > PackageKit-yum-plugin dependency from PackageKit? The plugin seems not > > to be necessary, as it can be disabled in > > /etc/yum/pluginconf.d/refresh-packagekit.conf and still the gnome applet > > indicates when there are new updates. > > You still need the plugin if you intend to use yum on the command line. I always use yum on the command line and the applet is the only item from PackageKit I use, but only in the way that I notice it, when there are updates. I still use yum to update then. Iirc, with the plugin enabled, then PackageKit blocks yum, if I run it too fast twice in a row. Regards Till pgp8M9QzucSyA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FC12: Hidden files in /usr/bin/*
On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote: > On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote: > > On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote: > > > > > I am sorry, but I do not see a real need for special guideline for the > > > fipscheck checksums. The policy where these checksums should/will be > > > placed should be decided by the fipscheck package itself. Of course I > > > > As soon as multiple packages are affected, there should be a guideline > > to document how something needs to be done to work, e.g. if someone > > wants to package a new software that contains fips checksums. > > Huh, shouldn't reading documentation in fipscheck package be > sufficient? Afaik, it would be the first packaging documentation that's in a package instead of the wiki. It would probably not be indexed by search engines and not as easy reachable by people building packages for Fedora, who do not run Fedora themselves. But maybe these reasons are not that applicable for fipscheck, because there is only a limited set of packages that make use of it. Regards Till pgp7Yu1K04g4w.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
On Thu, Feb 04, 2010 at 09:20:12AM +0100, Kevin Kofler wrote:
> Nicolas Mailhot wrote:
> > That would probably avoid the koji display problem but is sure to
> > introduce packaging bugs. The macro call has been put in this particular
> > place because experience shows that reduces human mistakes. It's never
> > easy to do back and forths between two parts of the same file, but in
> > this case they are compounded by the kind of syntax forced on us by the
> > use of a macro. Everything needs to be cramed on a single line. Any
> > syntax error and things fail without proper error messages (I've tried
> > to add some debug output. I caused mock build to stop dead). You can not
> > do as many calls as you want (like you can for %doc) or rpm will
> > complain of multiple %posts or %files for the same subpackage (without
> > telling you exactly which subpackage fails)
> >
> > The choice that was made was to minimize human error risk at the expense
> > of some prettiness in koji. I'd do the same choice today in a blink. We
> > are severely limited what the tools can do, but trying to accomodate
> > tools at all costs results in undue human burden and lots of bad
> > packages. Humans have limits too.
>
> Sorry, but the decision has been made, you have to put the macro where it
> belongs. Something which expands to scriptlets and %files sections needs to
> go where the scriptlets and %files sections belong, NOT in the Summary where
> it will be wrong in the SRPM. The problem is that it's not only within Koji
> that the unexpanded macros show up, but also in the shipped SRPMs!
Why can't the following be used?
%{?_font_pkg:%_font_pkg -f %{fontconf}.conf AccanthisADFStd-*.otf}
Since the macro is not really part of the Summary, there is no missing
information if it does not expand.
Btw. the guidelines looks incomplete. This is the second sentence:
| Because SRPMs are built without the package's BuildRequires installed,
| depending on macros defined outside of the spec file can easily lead to
| this issue.
But there is no real explanation of "the issue", e.g. the problem that
macros that are not really intended to build the packages description
are shown unexpanded in the description.
Regards
Till
pgpD16AnkvZGU.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
On Fri, Feb 05, 2010 at 10:13:52AM -0500, Toshio Kuratomi wrote:
> On Fri, Feb 05, 2010 at 08:59:52AM +, Richard W.M. Jones wrote:
> > On Wed, Feb 03, 2010 at 02:29:18PM -0500, Toshio Kuratomi wrote:
> > > SRPM Buildtime macros
> > > https://fedoraproject.org/wiki/SRPM_Buildtime_macros
> >
> > Did we consider fixing the bug in RPM/the packaging system instead of
> > pushing more work on packagers?
> >
> This is not a response to a bug in rpm. This addresses people trying to put
> macros into %descriptions when those macros aren't defined at the time of
> build.
Imho this is only what the guidelines say and it sounds to apply to use
cases like:
%description
This is a PyYAML for Python: %{python_version}
So the macro is part of what is going into the package's description.
Especially the case that it does not only mention %desription, but also
Summary make this very likely to be understood like this. E.g. why would
someone put a macro into the Summary tag, if not to make it appear in
the Summary tag?
> Nicolas's argument is that rpm does not automatically detect when he wants
> to end his %description and therefore he should be excluded from the
> requirement.
The argument is, that the macro is not used to create the %description
afaics. Imho this is a valid way, because using his macros before
%description seems not to work (I believe I tried). So for this case,
there is really a bug or annoyance in rpm: It's not possible to use
external macros at a good visible place within the SPEC that does not
end up in the %description if it is not expanded.
I also agree that fixing rpm should be at least the long goal and
that the issue should also be tracked, before there is an official
Guideline to work around this deficiency.
Regards
Till
pgpi7WZapHaqa.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
simple build system for personal repos?
Hiyas, is there a simple build system for personal repos available? E.g. give it an srpm and then it will build it for several mock configs, ask to sign the rpms, move them to typical repositories and ask to sign the repository? Regards Till pgpmWVFpOEP6O.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging Committee Meeting Summary (2010-02-03)
On Sat, Feb 06, 2010 at 12:14:22AM +0100, Kevin Kofler wrote: > By the way, the whole concept of this kind of macros has been frowned upon > and FESCo already recommended that the MinGW packagers simply paste their > debuginfo logic directly into the specfiles instead of using this kind of > macros. I guess the same recommendation can be given to the font packagers. Why is code duplication considered good practice here, while it is considered to be bad practice everywhere else, e.g. in the no duplicate system libraries guidelines? Regards Till pgpy2X3Miql4F.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Sat, Feb 06, 2010 at 12:23:31PM +0100, Kevin Kofler wrote: > Ralf Corsepius wrote: > > However, I went one step further: I removed ABRT from my systems, not > > because of issues I would have with it as a Fedora package maintainer, > > but because of usability issues I am having with it on the user-side and > > because of other issues I am having with it as sys-admin. > > > > Worse, in this case, I feel the Fedora community is being abused to > > evaluate a semi-functional piece of SW's "yet uncooked" concepts. > > +1. ABRT is just broken in so many ways it's not even funny and should never > have been shipped in its current state. For yum related python backtrace bugs, it worked pretty well here and made bug reporting a lot easier. So maybe it should only be activated for cases where additional debuginfo is not needed. Regards Till pgpyTNT62rdxt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
On Wed, Jan 27, 2010 at 05:03:51PM -0800, Jesse Keating wrote: > Unblocked orphan perl-MooseX-Traits-Attribute-CascadeClear This package is only orphaned in devel and the perl-sig is watching it, so maybe it should be retired instead of orphaned. Regards Till pgpRU13h5W5iz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
Hi, here is another update of packages that are afaik going to be removed from F13 tomorrow. I started to collect some end user feedback and until now for these packages interest has been shown: https://admin.fedoraproject.org/pkgdb/packages/name/muine https://admin.fedoraproject.org/pkgdb/packages/name/showimg https://admin.fedoraproject.org/pkgdb/packages/name/gnome-applet-netspeed https://admin.fedoraproject.org/pkgdb/packages/name/sbackup https://admin.fedoraproject.org/pkgdb/packages/name/python-pgsql https://admin.fedoraproject.org/pkgdb/packages/name/k3d Also I noticed that someone was using gtranslator on Fosdem: https://admin.fedoraproject.org/pkgdb/packages/name/gtranslator My end user feedback is collected here: http://forums.fedoraforum.org/showthread.php?s=ff79a327b127063e971c8fe7fc1e1fc6&t=240180 http://lists.fedoraproject.org/pipermail/users/2010-February/366164.html Unblocked orphan DMitry https://admin.fedoraproject.org/pkgdb/packages/name/DMitry Unblocked orphan apt-mirror https://admin.fedoraproject.org/pkgdb/packages/name/apt-mirror Unblocked orphan bauble https://admin.fedoraproject.org/pkgdb/packages/name/bauble Unblocked orphan bottlerocket https://admin.fedoraproject.org/pkgdb/packages/name/bottlerocket Unblocked orphan cohoba https://admin.fedoraproject.org/pkgdb/packages/name/cohoba Unblocked orphan cowbell https://admin.fedoraproject.org/pkgdb/packages/name/cowbell Unblocked orphan dbxml https://admin.fedoraproject.org/pkgdb/packages/name/dbxml Unblocked orphan dbxml-perl https://admin.fedoraproject.org/pkgdb/packages/name/dbxml-perl Unblocked orphan gdevilspie https://admin.fedoraproject.org/pkgdb/packages/name/gdevilspie Unblocked orphan gfeed https://admin.fedoraproject.org/pkgdb/packages/name/gfeed Unblocked orphan glade2 https://admin.fedoraproject.org/pkgdb/packages/name/glade2 Unblocked orphan gmfsk https://admin.fedoraproject.org/pkgdb/packages/name/gmfsk Unblocked orphan gnome-applet-netspeed https://admin.fedoraproject.org/pkgdb/packages/name/gnome-applet-netspeed Unblocked orphan gtk-qt-engine https://admin.fedoraproject.org/pkgdb/packages/name/gtk-qt-engine Unblocked orphan gtk-sharp https://admin.fedoraproject.org/pkgdb/packages/name/gtk-sharp Unblocked orphan gtranslator https://admin.fedoraproject.org/pkgdb/packages/name/gtranslator Unblocked orphan halberd https://admin.fedoraproject.org/pkgdb/packages/name/halberd Unblocked orphan ircd-hybrid https://admin.fedoraproject.org/pkgdb/packages/name/ircd-hybrid Unblocked orphan isight-firmware-tools https://admin.fedoraproject.org/pkgdb/packages/name/isight-firmware-tools Unblocked orphan jna-posix https://admin.fedoraproject.org/pkgdb/packages/name/jna-posix Unblocked orphan k3d https://admin.fedoraproject.org/pkgdb/packages/name/k3d Unblocked orphan keyjnote https://admin.fedoraproject.org/pkgdb/packages/name/keyjnote Unblocked orphan libFoundation https://admin.fedoraproject.org/pkgdb/packages/name/libFoundation Unblocked orphan libipoddevice https://admin.fedoraproject.org/pkgdb/packages/name/libipoddevice Unblocked orphan mediawiki-InputBox https://admin.fedoraproject.org/pkgdb/packages/name/mediawiki-InputBox Unblocked orphan mediawiki-Renameuser https://admin.fedoraproject.org/pkgdb/packages/name/mediawiki-Renameuser Unblocked orphan muine https://admin.fedoraproject.org/pkgdb/packages/name/muine Unblocked orphan muine-scrobbler https://admin.fedoraproject.org/pkgdb/packages/name/muine-scrobbler Unblocked orphan nhpf https://admin.fedoraproject.org/pkgdb/packages/name/nhpf Unblocked orphan nssbackup https://admin.fedoraproject.org/pkgdb/packages/name/nssbackup Unblocked orphan onesixtyone https://admin.fedoraproject.org/pkgdb/packages/name/onesixtyone Unblocked orphan oooqs2 https://admin.fedoraproject.org/pkgdb/packages/name/oooqs2 Unblocked orphan pdumpfs https://admin.fedoraproject.org/pkgdb/packages/name/pdumpfs Unblocked orpha
Re: Purging the F13 orphans
On Mon, Feb 08, 2010 at 11:35:35PM +0100, Kevin Kofler wrote: > Till Maas wrote: > > https://admin.fedoraproject.org/pkgdb/packages/name/showimg > > The big problem with this one is that it's dead upstream (since 2006!) and > stuck at KDE 3 (which also implies that its kipi-plugins support no longer > works because we ship only the KDE 4 kipi-plugins these days, as all the > other stuff using the Kipi framework has moved on to KDE 4). And it's not > like its featureset is unique (it's just an image viewer). I'd recommend > that users of ShowImg migrate to Gwenview or some other actively maintained > image viewer. This sounds like it should have been retired instead of only orphaned. Do you happen to know, why it wasn't retired? Regards Till pgp84t4OLOpl8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
On Tue, Feb 09, 2010 at 12:43:31AM +0100, Kevin Kofler wrote: > Till Maas wrote: > > This sounds like it should have been retired instead of only orphaned. > > Do you happen to know, why it wasn't retired? > > Because the Fedora maintainer for the package was AWOL and didn't bother > retiring it. It will be retired now if nobody picks it up. Afaik, it will only be blocked in Koji, so it won't be distributed with F13. A proper retirement would also require to add a dead.package to CVS with an explanation why it is retired. Regards Till pgp8JU4a4AmUv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
On Tue, Feb 09, 2010 at 12:43:31AM +0100, Kevin Kofler wrote: > Till Maas wrote: > > This sounds like it should have been retired instead of only orphaned. > > Do you happen to know, why it wasn't retired? > > Because the Fedora maintainer for the package was AWOL and didn't bother > retiring it. It will be retired now if nobody picks it up. Unluckily this information is not really available in the PackageDB, but who was this maintainer? According to the RPM changelog[0], the last non-rebuild change is from Rex Dieter and the package is only orphaned for devel and F12, but not for F11, where Aurelien Bompard is the maintainer. And he also owns some other packages. Regards Till [0] http://cvs.fedoraproject.org/viewvc/rpms/showimg/devel/showimg.spec?revision=1.32&view=markup pgpsDvPxWjTnF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Where are the libplist updates?
On Tue, Feb 09, 2010 at 09:06:47PM +0100, Alain Portal wrote: > The last available version of libplist is 0.13-2. > I get the last libplist spec file which say that libplist should be 1.2-1 > versioned. > Where is the problem? You probably need to wait a little more, afaics the builds are only 5 days old, so maybe the package maintainer did not get to create an update, yet. He is cc'ed on this mail. Btw. in general it is best to directly ask the maintainers. They can be reached at -ow...@fedoraproject.org Regards Till pgpXZfFTvD9MZ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote: > For yum related python backtrace bugs, it worked pretty well here and > made bug reporting a lot easier. So maybe it should only be activated > for cases where additional debuginfo is not needed. This time it did not catch the bug: https://bugzilla.redhat.com/show_bug.cgi?id=563368 Regards Till pgp56zNeelHtx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote: > I think I did catch it (if ABRT was running), but ordinary users can't > see other user's crashes (the command from this bz has to be run under > root) unless root doesn't change this behaviour in abrt's config file. What do I have to change? The manpage (man abrt.conf) or default config (/etc/abrt/abrt.conf) does not give me a hint. Btw. can you maybe use PolicyKit to determine whether abrt-gui and the crashed program are run by the same person in case both happens via the local console? Regards Till pgpXgfNhPu89M.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Wed, Feb 10, 2010 at 10:58:03AM +0100, Jiri Moskovcak wrote: > You need to add this to the respective analyzer's configs: > > InformAllUsers = yes > > CCpp.conf - C/C++ xrashes analyzer > Python.conf - python analyzer > Kerneloops.conf - kerneloops (already has this enabled) > > But this applies only to new crashes, the old ones will still be > invisible for ordinary users. > Working on updating the man-pages and wiki right now. Thank you, after adding this to the Python.conf file and running service abrtd restart it now catches the python crash. Regards Till pgpYabEctW4fO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: simple build system for personal repos?
On Sun, Feb 07, 2010 at 10:29:55PM +, Richard W.M. Jones wrote: > On Fri, Feb 05, 2010 at 08:29:00PM +0100, Till Maas wrote: > > Hiyas, > > > > is there a simple build system for personal repos available? E.g. give > > it an srpm and then it will build it for several mock configs, ask to > > sign the rpms, move them to typical repositories and ask to sign the > > repository? > > You might want to look at smock, which is the tool (wrapper around > 'mock') that we initially used to build the mingw tree. One nice > feature is that it sorts out dependencies and can build for multiple > Fedora distros and architectures in one go. > > It doesn't sign packages though, but it's probably easy to add that. > > http://git.annexia.org/?p=fedora-mingw.git;a=tree;f=smock;hb=HEAD Thank you, this looks very helpful. I'll see if I can produce some perl code to add the signing. Regards Till pgpfvO96JSOUo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Minutes/summary for 2010-02-09 FESCo meeting
On Wed, Feb 10, 2010 at 09:20:35PM +0530, Parag N(पराग़) wrote: > https://fedoraproject.org/wiki/UnderstandingDSOLinkChange, its > written that "To fix, add -lrpmio to the gcc command for any binaries > that use librpmio." So What's wrong if I modify CFLAGS in iok.spec and > build log can show its added to gcc command and build got successful? If you workaround the bug via CFLAGS, the bug will still persist at upstream and other distributions. If you fix it properly, everyone will benefit from it. For reference, see: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects Regards Till pgpN2gpI7C2Sx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/gpscorrelate/devel gpscorrelate-1.6.0-stdc++.patch, NONE, 1.1 gpscorrelate.spec, 1.3, 1.4
On Wed, Feb 10, 2010 at 06:12:06PM +0100, Ralf Corsepius wrote: > This patch is wrong. > > The actual bug this package suffers from is using "gcc" to link c++ code. > > C++ code MUST be linked with "g++", using "gcc" is not right. The fact > your package might compile without complaint with -lstdc++ is just a > lucky random coincidence, but is not a real fix. I am impressed, that you spotted this. The fix is added to gpscorrelate-1_6_0-6_fc13. Thanks Till pgpi5uu1AdlcD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Final (hopefully) privilege escalation policy draft
On Wed, Feb 10, 2010 at 12:48:39PM -0800, Adam Williamson wrote: > I have now adjusted the draft - > https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy > - to reflect all feedback from this list and from FESco. It will be reviewed > again by FESco next week. Please raise any potential issues or further > suggestions for adjustments before then. Of course, even if the policy is > accepted by FESCo it will not be set in stone and changes and exceptions can > be added in future as appropriate, but I'd like to have it as good as > possible at first :) thanks all! I added /dev/shm to the list of directories a user may write to. I believe there was also an item about writing to user mounted file systems, e.g. if a usb device is mounted at /media/disk, but it seems to be gone. Regards Till pgpXHVGiVX6vK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: berlios.de compromised since 2005
On Wed, Jan 13, 2010 at 12:23:15PM -0500, Seth Vidal wrote: > till:fatsort:http://fatsort.berlios.de/ Upstream compared the contents of the current tarball with a old working copy. Since there is only one developer, it's probably safe to assume, that the code is clean. Regards Till pgp2X6CpGxdu6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT frustrating for users and developers
On Mon, Jan 18, 2010 at 09:58:21PM -0800, Adam Williamson wrote: > On Sun, 2010-01-17 at 15:12 +0100, Christoph Wickert wrote: > > > I doubt this very much. Many people don't report the bugs when the app > > crashes but later, many reports in a row. Most of my reports read "I > > have no idea what I was doing when foo crashed", even if they > > submitted > > it straight after the crash. Only 2 out of ~40 contained the > > information > > I needed to reproduce the crash reliably (as a site note: both are > > fixed, so the number of crashes fixed it 4 but not 3 as I wrote in my > > initial mail. 4/40 is still a bad percentage) > > 'Bad' in what way? it's probably 4 - almost certainly 2 or 3 - more than > you would have fixed if abrt didn't exist. This is not a fair calculation or statement. Also without abrt bugs about crashes have been reported. Regards Till pgpGgjs6PJpXC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: documentation on Bugzilla bug lifecycle/developer procedures?
On Thu, Feb 11, 2010 at 10:42:04PM -0800, Eric Smith wrote: > Matt Domsch wrote: > > However, check if unifdef is really needed. The kernel team knew it > > was going to be orphaned, and said "that's OK, as the kernel tree has > > its own copy that's maintained there." or somesuch. If not, letting > > it stay dead is fine - desireable in fact. > > > What is the criteria for whether a Fedora package is "really needed" and > for which staying dead is "desirable"? I picked it up because I use it > myself; I had no idea that it had anything whatsoever to do with the > "kernel team", and I don't have any use for a "copy that's maintained > there". If you need/use it and want to maintain it, you are free to do so. If the kernel team knows a better alternative that you should consider, then the package should be retired instead of just orphaned and an explanation about why it was retired should be added to a dead.package file in the CVS devel branch. Usually the latter is not done, so you can only ask the previous maintainers. Nevertheless, having a "copy that's maintained there" sounds like bad packaging practice. Regards Till pgpi6uk3lhO8Z.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Fri, Feb 12, 2010 at 03:15:39AM +0100, Nils Philippsen wrote: > What strikes me as very puzzling is why abrt has this humongous dialog > instead of leading the user step-by-step through this... I know you just > changed the UI in a stable release. But doing it twice is twice fun ;-), > so why not use a wizard (taking the user by the hand, doing it step by > step...) and do it like this: For me the dialog works pretty well and I suspect a wizard would only slowdown it. So if there is some wizard added, please make it optional. Regards Till pgpR70vPdyLb4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
man-db vs. man
Hiyas, according to the man-db[0] homepage all/most other major distributions use a more actively developed manpage suite called man-db, while we only ship this: http://primates.ximian.com/~flucifredi/man/ In a package of mine, "man -l" is used to create a plaintext version of the manpage, which seems to only work with man-db. Could this be a Feature for F14 to use man-db instead of man or are there major reasons not to do this? Btw. I cc'ed man-ow...@fpo. Regards Till [0] http://man-db.nongnu.org/ pgph4MSFOwdQx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-02-10 x86_64
On Sat, Feb 13, 2010 at 09:50:29AM -0600, Matt Domsch wrote: > gpscorrelate-1.6.0-4.fc13 (build/make) till fixed in release 6 by using g++ for linking. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Some Packages
On Sat, Feb 13, 2010 at 09:21:58PM +0100, Alain Portal wrote: > Hi, > > Le samedi 13 février 2010 20:34:16, Brian Pepple a écrit : > > Hey all, > > > > I'm orphaning the following packages: > > I think it should be nice, when a Fedora packager say he orphaned some > packages, he tells why he orphans its: > - no time to package > - no use it any more > - lack of communication with upstream > - too many bugs reported he can't fix > - application is obsolete > - etc. > > That could be help to find a new Fedora maintainer, or clearly decide to > remove > the package from Fedora. I agree totally. Regards Till pgpP59V58eWz0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git 1.7 and git push?
On Mon, Feb 15, 2010 at 11:38:40AM -0600, Bruno Wolff III wrote: > I don't control the remote repository. That would be fedorahosted in the > case I am asking about. I am pretty sure that the repositories on fedorahosted are bare so that the changes here do not apply or maybe only apply if you want to remove the master branch remotely: http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt Regards Till pgpC1vx8iOsD1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for 2010-02-16 FESCo meeting
On Tue, Feb 16, 2010 at 02:14:24PM -0700, Kevin Fenzi wrote: > * Fedora Engineering Services (nirik, 20:43:55) > * LINK: https://fedoraproject.org/wiki/FES (nirik, 20:44:52) Is there any reason not to rename that page to "Fedora Engineering Services", because with this acronym, it won't be found by the wiki search engine when searching for "fedora engineering services": https://fedoraproject.org/wiki/Special:Search?search=fedora+engineering+services&go=Go Regards Till pgplSHic4B9n4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 10:44:10AM +0100, Christoph Wickert wrote: > And what about the updates that don't have a custom tag? If the update is big enough, that a lot of packages require a rebuild, using a custom tag seems to be the best approach, so if there is none, ask of it. If there is no need for one, then the buildroot overwrite approach seems to be good enough. Or what is the specific problem you are seeing? The advantage of using a custom tag is also, that it does not touch the buildroots of all packages and therefore makes it possible to still push updates for the affected dependent packages, if they are required to fix a bug. Afaik currently kde does not use a custom tag, and therefore if one wants to update a kde/qt dependent package, it would be build with a incompatible kde/qt version and therefore cannot be pushed to stable. Regards Till pgp83Pfc7F7Vl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote: > Both approaches have their ups and downs, but both slow down > development: > * Asking rel-eng for overwrites takes time. > * Asking rel-eng for a tag takes some time too. And I'm afraid > that with an inflationary number of tags things get unclear for > other maintainers. They don't know what to build their packages > against or when to use which tag. It requires a lot of > coordination between the different parties. Usually when some of mine packages need to be rebuild because of updated dependencies, the communication is usually one-way. I get informed that the packages needs to be rebuild and then it happens soon afterwards, therefore I do not even have to know how the tag is called. There are also scripts that help to do this easily afaik. This is also the advantage of using a tag, because then I can still create bugfixes by myself without being disturbed my the buildroots. Off course then the package also needs to be rebuilt in the staging tag, but this can be easily automated and already might be. > So we both agree about the advantages of custom tags, but we are talking > about the development versions here and not about stable releases. In > the branches that are under development we would not do a bugfix against > the "stable" tag. Instead, all updates are supposed to target > development. If we really needed a bugfix in a development branch, this > could easily be done with early branching. I am confused here, since there is no early branching, because branching already happened and F-13 is now stabilizing and afaik should be treated more like it was stable than like it is rawhide. E.g. major updates should now break rawhide first and if the fallout is handled, then it could be done for F-13. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote: > Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas: > > On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote: > > > > > ... > > > > Usually when some of mine packages need to be rebuild because of updated > > dependencies, the communication is usually one-way. I get informed that > > the packages needs to be rebuild and then it happens soon afterwards, > > You are lucky. In the past people broke my package without further > notice and I had to take care of fixing them. On the other hand there > are maintainers, that announce changes in advance and ask me if I'm fine > with them rebuilding my packages or if I want to take care of this > myself. This is how it should be but only proven packagers will be able > to do this. I guess a recommended procedure for this is not really documented in the wiki, but since I was never in the situation to rebuild a bunch of dependent packages, I do not really know. > Take KDE for example: Although the KDE SIG is doing a great job in > avoiding breakdowns, I doubt that each and every maintainer of a QT or > KDE app is always aware of the changes before they happen. If things > still seem to be working in F-13 or rawhide, he might not even be aware > of the custom tag. Yes, I know, because I co-maintain a package using qt and I recently read something from the maintainer that he can not push a bugfix update to stable, because a qt override is in the buildroot. > > therefore I do not even have to know how the tag is called. There are > > also scripts that help to do this easily afaik. This is also the > > advantage of using a tag, because then I can still create bugfixes by > > myself without being disturbed my the buildroots. Off course then the > > package also needs to be rebuilt in the staging tag, but this can be > > easily automated and already might be. > > Honestly, I don't recall automated updates of my packages except for the > mass rebuilds from rel-eng. If the people that break things and/or > requested the custom tag will take care of this, we are fine, bug FWIW > it's not like this in rawhide. Let's see how it turns out in F-13. I remember this for python and openssl and I believe the haskell or ocaml SIG did this for their packages, too. > > and F-13 is now stabilizing and afaik should be treated > > more like it was stable than like it is rawhide. E.g. major updates > > should now break rawhide first and if the fallout is handled, then it > > could be done for F-13. > > I think we still need to be able to treat F-13 different than in the > released branches, at least before beta freeze. If we need to do things > in rawhide first and only push these changes to F-13 afterwards, a > feature with a tight schedule like Xfce 4.8 is lost. That's just what I > said. It would be sad to loose the feature, only because of the schedule, but I guess there will always be some feature that needs to be postponed because of missing some deadline shortly. Nevertheless it would be good to speed up procedures to get as much features as possible. So maybe you can already request the tag you will need once Xfce 4.8 is released to start building it as soon as it is released. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Tue, Feb 16, 2010 at 08:10:17PM -0800, Jesse Keating wrote: > That's right folks, we are now branched for Fedora 13. What does this > mean to you? Well that depends on who "you" are, here are some "you"s > that we wrote about: > https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan#Use_Cases > > The real take away here is explained at > https://fedoraproject.org/wiki/Branch_Freeze_Policy Is the branch freeze a week late or is it now the same as the alpha freeze? In the "Important Release Milestones" wiki page[0], the branch was scheduled for 2010-02-09, but on the F13 Schedule[1], the "Alpha Freeze" links to the "Alpha Freeze Policy", which redirects to the "Alpha Milestone", that then says the "Branch Freeze Policy" has to be followed. The schedule itself does not say anything about branching. It would help a lot to avoid duplicating content in the wiki, because it only leads to out-of-sync contents and makes it harder to update it. Regards Till [0] https://fedoraproject.org/wiki/Important_Release_Milestones [1] https://fedoraproject.org/wiki/Releases/13/Schedule -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote: > The branched repo config is the fedora.repo file. Mirrormanager will be > making sure that goes to the right place. There is an updated Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for mirrormanager? I have to ask, because it does not contain any hint, that it is. If it is, it seems not to know F13, because F13 is not on the list. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 07:36:00AM -0800, Jesse Keating wrote: > On Wed, 2010-02-17 at 16:33 +0100, Till Maas wrote: > > Is the branch freeze a week late or is it now the same as the alpha > > freeze? In the "Important Release Milestones" wiki page[0], the branch > > was scheduled for 2010-02-09, but on the F13 Schedule[1], the "Alpha > > Freeze" links to the "Alpha Freeze Policy", which redirects to the > > "Alpha Milestone", that then says the "Branch Freeze Policy" has to be > > followed. The schedule itself does not say anything about branching. > > It would help a lot to avoid duplicating content in the wiki, because it > > only leads to out-of-sync contents and makes it harder to update it. > > We are trying to track down the duplication and make canonical linkings. > > The branch freeze happens at the branch event, which is a week after > Feature freeze. It's no longer an "Alpha Freeze" per se, because the > tree remains "frozen" even after alpha. So how is the package set determined that builds the Alpha release? Is it everything which is pushed to F13 in Bodhi for 2010-02-24 at 20:00 UTC, which is the time of the GO/NOGO meeting? Or is the Alpha release first composed and then it is decided, whether it will be synced to the mirrors? > Unfortunately we're going to have some rough times with documentation as > most of the documentation in the wiki isn't updated for how things work > with no frozen rawhide, but we're working on it. If you find more > places that need updating, please add them to > https://fedoraproject.org/wiki/No_frozen_rawhide_announce_plan thanks! I added the differences between the F13 Schedule and the key milestones there. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 11:52:57AM -0600, Matt Domsch wrote: > On Wed, Feb 17, 2010 at 04:40:33PM +0100, Till Maas wrote: > > On Wed, Feb 17, 2010 at 06:11:58AM -0800, Jesse Keating wrote: > > > > > The branched repo config is the fedora.repo file. Mirrormanager will be > > > making sure that goes to the right place. There is an updated > > > > Is this http://mirrors.fedoraproject.org/publiclist/Fedora/ the url for > > mirrormanager? I have to ask, because it does not contain any hint, that > > it is. If it is, it seems not to know F13, because F13 is not on the > > list. > > http://mirrors.fedoraproject.org/publiclist/Fedora/13/ > shows 80 mirrors right now... When I wrote the mail, it did not appear in the "Mirror list filter" list, but it does now. Btw. I opened a ticket about mirrormanager not identifying itself in trac: https://fedorahosted.org/mirrormanager/ticket/25 Thanks Till pgpvYVgmlJGbc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Thu, Feb 18, 2010 at 12:24:45AM +0100, Sven Lankes wrote: > On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote: > > >> Yes, I know, because I co-maintain a package using qt and I recently > >> read something from the maintainer that he can not push a bugfix update > >> to stable, because a qt override is in the buildroot. > > > The solution there is to talk to us, we can get the Qt 4.6 stuff off the > > buildroot for a while so he can build his bugfix update. That's what > > #fedora-kde is for. (IRC is the best communication method for this stuff > > because it's real time, please use it!) > > I'm assuming that Till is talking about my comment > https://bugzilla.redhat.com/show_bug.cgi?id=549717#c2 on merkaartor > (which he co-maintains). > > So nothing to see here - please move on. This is about not being able to > do a scratch build of an svn-snapshot of merkaartor. Nothing that I > would ever push to a stable release. Yes, this was the comment I meant. Since it seems to be easily possible to push an updated merkaartor package, I am more in favor to push it. The bug is already two months old and renders the Fedora package for the reporter useless. Also merkaartor upstream provides windows binary releases based on snapshots: http://www.merkaartor.org/ Regards Till pgpr8iCfj8o1D.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 11:40:15PM +0100, Kevin Kofler wrote: > Till Maas wrote: > > > On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote: > > > >> Take KDE for example: Although the KDE SIG is doing a great job in > >> avoiding breakdowns, I doubt that each and every maintainer of a QT or > >> KDE app is always aware of the changes before they happen. If things > >> still seem to be working in F-13 or rawhide, he might not even be aware > >> of the custom tag. > > > > Yes, I know, because I co-maintain a package using qt and I recently > > read something from the maintainer that he can not push a bugfix update > > to stable, because a qt override is in the buildroot. > > The solution there is to talk to us, we can get the Qt 4.6 stuff off the > buildroot for a while so he can build his bugfix update. That's what > #fedora-kde is for. (IRC is the best communication method for this stuff > because it's real time, please use it!) I'll remember this. But why don't you use a special tag for this instead of a buildroot override? I believe this question is not answered and I even might have asked it once in IRC. ;-) Regards Till pgpIsEVXSG2hG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Thu, Feb 18, 2010 at 04:30:31AM +0100, Kevin Kofler wrote: > If every grouped update did that, Koji would be littered with special tags. > * problems with merging from the special tags (what if dist-f12-kde440 and > dist-f12-someotherlib123 both carry their own rebuilds of, say, compiz? It > might not even get noticed if they're on different special tags. Depending > on which of the builds "wins", one or the other dependency will be broken) KDE grouped updates are usually a lot bigger than most of the other grouped updates, e.g. this has 60 packages in it: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-1850 Sometimes I create also a grouped update, which only contains two packages, a library and the only package depending on it. So there is a huge range that obviously needs to handled differently. If all packages in an update set are maintained by the same group, there is no harm in using a buildroot override. But as soon as several different maintainers and there are a lot of packages to be updated and the buildroot override is there for a long time, then using custom tags seem to be appropriate for me. Regards Till pgpbuGa0HB8GN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Wed, Feb 17, 2010 at 07:44:30PM -0800, Jesse Keating wrote: > You're in Austria right? Rex wakes up before I do, which is why he's > hitting them before me. Finding somebody on the other side of the pond > who's interested in doing releng work would help. I volunteer to help with buildroot overrides assuming that it does not take that much time. I am located in CET/UTC+1, too. Is there maybe a schedule about how well the timeslots are covered? Regards Till pgpIGbFd6vYCw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 has been branched!!
On Thu, Feb 18, 2010 at 07:36:09AM -0800, Jesse Keating wrote: > We don't really have a coverage list, but most of the people who have > been doing tagging are all in the US time zones, so anything outside of > that is welcome. Ok. > https://fedoraproject.org/wiki/Buildroot_override_SOP is the working SOP > we have for this, although I notice it doesn't say what to do with the > tickets. We typically assign the ticket to ourself, whoever is doing > the tag, so that when the reporter says the build is done we see it and > can do the untag and close the ticket. I updated it to mention the ticket handling. I just wonder, is there no verification done one the request, e.g. is everybody allowed to request a build override or is it restricted to package (co)maintainers and provenpackagers? I only found this regarding verification: | Buildroot overrides usually means that something is soname bumping. Be | sure this is a sane update to do in Fedora How is this handled? > https://fedorahosted.org/rel-eng/report/3 can help you somewhat see the > open tickets, if there is a tag request ticket assigned to rel-eng@ that > means it likely hasn't been operated on. This query only reports tickets assigned to rel-eng@ in the component koji, I guess it is more accurate or are there many tag requests that are not in the koji component? https://fedorahosted.org/rel-eng/query?status=new&status=assigned&status=reopened&component=koji&owner=rel-eng%40lists.fedoraproject.org&order=priority I added this to the SOP as well. Regards Till pgpSdLGrkJOEB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Read this if your package BuildRequires qt(4)-devel!!!
On Tue, Feb 23, 2010 at 08:41:59PM +0100, Kevin Kofler wrote: > I wrote: > > for all maintainers of packages which BuildRequire qt4-devel (or qt-devel, > > but the versioned virtual Provides is preferred): please, when you plan to > > push updates for your packages, ALWAYS CHECK what version of Qt your > > package got built against and DO NOT PUSH your update to stable before > > that version of Qt goes stable! A package built against Qt 4.6 WILL NOT > > WORK AT ALL with Qt 4.5!!! (This is always the case, Qt is backwards- but > > not forwards- compatible.) > > FYI, while the above is still sane advice (it's always a good idea to verify > that you aren't building against a newer Qt from a buildroot override!), Qt > 4.6.2 is now queued for the stable updates (it was decided in today's KDE > SIG meeting to push the big Qt 4.6.2 / KDE 4.4.0 / SIP 4.10 update set out), > so this particular version bump should no longer be a source of trouble. Now that I know the command to do this, here it is: $ koji latest-pkg dist-f12-build qt | grep override If this returns something, the package must only be moved to stable together with the big qt update. Regards Till pgp0yTEjDfqU7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Tue, Feb 23, 2010 at 09:10:03PM +0100, Richard Zidlicky wrote: > I have one of these netbooks that need "hdparm -B high_value" to avoid > unhealthy > frequent head parking. From some archived mails I had the impression that it > was > planned that gnome power manager and similar would take care of such issues - > which > does not appear to happen in my case. > > What is the state of this - is some package responsible for this or is it up > to > the user to do it manualy? You have to set it manually at bootup (add it to /etc/rc.local), but after suspend/hibernate the values are normally restored by pm-utils (eventually this might happen in the kernel). In the past some devices needed a manual override in /etc/pm-utils-hd-apm-restore.conf But this might not be needed anymore. Regards Till pgpJF0VZxLkKb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Thu, Feb 25, 2010 at 01:10:10AM +0800, Chen Lei wrote: > This is not a big problem, you can use pm-utils to solve this bug by throwing > srcipts to /etc/pm/sleep.d and /etc/pm/power.d. > Anyone who cares high frequency of load/unload cycles on some hard disks can > refering > http://wiki.archlinux.org/index.php/Pm-utils to hack the pm-utils. The hook in sleep.d is not required in Fedora, because it should be already handled. I just wrote a mail to pm-utils devel mailinglist to decide whether the Fedora hook should be included in the upstream release. Regards Till pgplSqYXLGUW9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Alpha Go/No-Go Meeting RESCHEDULED: 2010-02-25 @ 19:00 UTC (14:00 EST)
On Wed, Feb 24, 2010 at 01:57:02PM -0800, Adam Williamson wrote: > IMPORTANT NOTE: we are rescheduling the Go/No-Go meeting for Fedora 13 > For more details about this important meeting see: > https://fedoraproject.org/wiki/Engineering_Readiness_Meetings IMHO it would help a lot if there weren't always at least two names for every event or task. E.g. on http://poelstra.fedorapeople.org/schedules/f-13/f-13-all-tasks.html there are the "Alpha Go/No-Go Meeting (20:00 EST)" and the "Alpha Project Wide Release Readiness Meeting" Now also using "Engineering Readiness Meetings" is very easy to confuse with the other meeting, especially because both happen within about 24 hours or not. Regards Till pgp9LfyBMdoVU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: hdparm -B for netbooks
On Thu, Feb 25, 2010 at 08:19:22AM +0100, Thorsten Leemhuis wrote: > Matthew Garrett wrote on 24.02.2010 22:59: > > Further, it loses the settings over suspend/resume. Can we stop blaming > > this on distributions now? > > Then why do a lot of drive load and unload frequently when running a > linux-distribution but do not when running the operating system the > Verndor pre-loaded? That's afaics what a lot of people seem to see. I Another possible explanation might be that the access pattern of the OS is different, e.g. maybe the drive is not idle long enough to unload. But since there is afaik no proper documentation about this issue, everything is just guessing. Regards Till pgpRCZKiBkkmT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pypolicyd-spf
On Thu, Feb 25, 2010 at 11:15:35AM +, Mark Watts wrote: > a) Does anyone have any objections to it being packaged? If it is useful for you, just package it. :-) > b) How would I get it included, assuming I package it to Fedora's > packaging standards? Here are the docs: https://fedoraproject.org/wiki/PackageMaintainers/Join Regards Till pgp9kLzYxTKq8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: creating file in koji allowed?
On Thu, Feb 25, 2010 at 11:01:28PM +0100, Thomas Spura wrote: > I'll use that now. But would be still interesting, if the other > possibility would be allowed... It is not allowed: http://fedoraproject.org/wiki/Packaging/Guidelines#Scriplets_are_only_allowed_to_write_in_certain_directories Regards Till pgpW7wEiNbUiv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Thu, Feb 25, 2010 at 05:05:38PM -0500, James Antill wrote: > $releasever just changes the variable, so the URLs are all the same ... > just with different variables. Specifically: > > mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch > > ...is never going to == > > https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch It seems that it would be enough to rename the repo from rawhide to fedora-rawhide in MirrorManager, so that one can use --releasever=rawhide Regards Till pgpvQSpnGKzFT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote: > Am I missing something? Do people think this would be better, or worse? It makes it harder to run repoquery against rawhide, because one would need to adjust the releasever value everytime rawhide is branched. But if --releasever=rawhide worked, then this would be better than having to install the rawhide-release package. Regards Till pgpTibxsXWxpS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: > I would like to collect feedback on this issue. If you want to disable > direct stable pushes, why? Could there be a less radical solution to that > problem (e.g. a policy discouraging direct stable pushes for some specific > types of changes rather than a blanket ban)? On the other hand, if (like me) > you DON'T want that feature to go away, please provide valid use cases. Imho it takes too long to get packages into updates-testing, if people are really interested in testing packages, they often seem to get packages directly from Koji, e.g. on this update I got 3 positive Karma points (one of them was anonymous) within 76 minutes after submitting the update: https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0604 It did not seem very useful to delay this update that also fixed several very annoying bugs any further. Regards Till pgpfupgEkrBg7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 08:20:10AM -0500, Josh Boyer wrote: > On Fri, Feb 26, 2010 at 08:14:13AM -0500, Marcela Maslanova wrote: > >My packages are rarely tested and I forget them in testing phase for a > >long time. Also fixing BR don't need testing. I simply need push > >immediately the new/fixed package. > > If nobody is testing your packages sitting in updates-testing, then maybe the > users of that package aren't hitting whatever you're fixing or aren't > otherwise > having other issues. What is the benefit of pushing an update if nobody > cares? I already got feedback from a user who wanted a fixed package, but did not want to test in in updates-testing. Also it is imho enough if the package maintainer cares about the update. And as long as there is a bug report that can be closed with an update, there is enough proof that someone else cares about the bug. But it still does not mean that they would use updates-testing or bodhi. Regards Till pgpoakL6A4Cxc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 08:36:41AM -0500, Josh Boyer wrote: > On Fri, Feb 26, 2010 at 02:23:33PM +0100, Till Maas wrote: > >On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: > > > >> I would like to collect feedback on this issue. If you want to disable > >> direct stable pushes, why? Could there be a less radical solution to that > >> problem (e.g. a policy discouraging direct stable pushes for some specific > >> types of changes rather than a blanket ban)? On the other hand, if (like > >> me) > >> you DON'T want that feature to go away, please provide valid use cases. > > > >Imho it takes too long to get packages into updates-testing, if people > >are really interested in testing packages, they often seem to get > >packages directly from Koji, e.g. on this update I got 3 positive Karma > >points (one of them was anonymous) within 76 minutes after submitting > >the update: > >https://admin.fedoraproject.org/updates/F12/FEDORA-2010-0604 > > > >It did not seem very useful to delay this update that also fixed several > >very annoying bugs any further. > > You've just illustrated the bodhi process working AS IT IS SUPPOSED TO. You > had testers giving karma, and they all had positive feedback, which means that > THE PACKAGE WAS TESTED BEFORE IT WENT TO STABLE. Imho it is more a perversion of how it is meant to be. This package was tested before it went to updates-testing and therefore went straight to stable. But the majority of packages goes to updates-testing and is not tested by someone else but the maintainer/does not get any karma, but still is pushed to stable after some time. Regards Till pgpFEAD8dCyWO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting Summary/Minutes for (2010-01-19) FESCo meeting
On Thu, Jan 21, 2010 at 02:51:46PM -0700, Kevin Fenzi wrote: > On Thu, 21 Jan 2010 17:34:50 +0100 > Till Maas wrote: > > Maybe the meetbot could be patched to only accept a topic change > > after a #agreed command was used (or some other command except the > > #action command, that creates a helpful notice in the logs). For the > > init process, something like "x of y Fesco members present" and list > > of absent members could be used. > > Possibly. Patches welcome. I just took a look into upstream's dev code and it should not be that hard. I also proposed this feature and some more on their irc channel as suggested in their docs, but it seems that nobody is currently around. Do you know how long it would take to get the feature form their dev repo into the setup used by Fedora? Is there a way to speed things up once the feature is included in their repo? Regards Till pgpZJlOsNZwet.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote: > New: > yum --releasever= upgrade > > Am I missing something? Do people think this would be better, or worse? Is the releasever option a yum F13 feature? On F12 it complains that it is not a valid option. Also repoquery returns F12 results but accepts --releasever: $ repoquery --releasever=rawhide --repoid=fedora kernel kernel-0:2.6.31.5-127.fc12.x86_64 Regards Till pgppzKqZesfCB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 10:20:00AM -0600, Bruno Wolff III wrote: > While people using Fedora may want the latest stuff, I doubt that most of > them care about time scales less than a month (I assume I am an exception) > unless there is a bug they care about. In which case they can use the bug > report as a way to find an update more promptly. Imho this also depends on the upstream of the package. E.g. for too complex packages like KDE, that also get rewritten with previous features removed, the new releases are not necessarily good, e.g. basic features like printing or encrypted instant messaging does not work reliable. But there are also smaller projects that usually only improve with each release. Then it is very frustrating to hit a bug only to find out that it is fixed in a newer upstream release. And even more frustrating is to find out, that the bug is fixed in upstream SCM, but there is no new release including the fix. > I think Fedora would be helped by an increase in the quality of packages > that are in stable more than shaving a week or so off when normal updates make > it into stable. If upstream already creates high quality releases, then it is usually best to follow upstream closely to avoid that Fedora users even hit bugs that are already fixed. Regards Till pgpZ3yOI6cb0F.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote: > direct relationship. Maybe something in the Fedora Engineering Services > initiative could be to spend some time smoke testing updates-testing > stuff. Something I am dreaming about is to have some infrastructure to automatically test packages, so mabye they could build that first and then write tests for packages. Regards Till pgpeveYpvpFoY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: VCS key in spec files and some scripts
On Fri, Feb 26, 2010 at 02:03:49AM +, Colin Walters wrote: > So recently I found myself desiring to update a .spec file for a > snapshot of a git tree in an automated fashion. As you may or may not > know, this actually has a surprising number of flaming hoops through > which you must jump. > > The first one, when scripting such a thing, is pulling the source tree > and packing it into a source file. To this purpose, I propose we > begin adding the following key to .spec files: > What am I using them for? Automating gnome-shell stack snapshots for F12: > > $ fedpkg-pull-build-chain --arch=i386 --arch=x86_64 --release=F-12 > --resultdir=_repo gobject-introspection gir-repository gjs clutter > mutter gnome-shell Thanks, this looks useful. I will try to use them, too. From their description they should be helpful to just check whether the current SPEC would still build the current upstream SCM version. Regards Till pgp71FapuHipC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Fri, Feb 26, 2010 at 01:12:53PM -0500, James Antill wrote: > On Fri, 2010-02-26 at 17:14 +0100, Till Maas wrote: > > On Thu, Feb 25, 2010 at 04:29:31PM -0500, Bill Nottingham wrote: > > > > > New: > > > yum --releasever= upgrade > > > > > > Am I missing something? Do people think this would be better, or worse? > > > > Is the releasever option a yum F13 feature? On F12 it complains that > > it is not a valid option. > > > > Also repoquery returns F12 results but accepts --releasever: > > $ repoquery --releasever=rawhide --repoid=fedora kernel > > kernel-0:2.6.31.5-127.fc12.x86_64 > > Yes, it's a 3.2.26+ feature. It's likely that F12 will get a yum update > eventually ... and you can get a 3.2.26+ yum from rawhide now. So for > ideas about changing how rawhide works, that's not a big requirement is > it? Yes, it is not a big requirement. Nevertheless I can wonder why it does not work in repoquery, even though it is in the --help output. So if it is expected not to work, it is imho a bug in repoquery to say that it supports it. Regards Till pgpSqk09ODnuD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 10:01:56AM -0800, Jesse Keating wrote: > On Fri, 2010-02-26 at 18:56 +0100, Till Maas wrote: > > > > Something I am dreaming about is to have some infrastructure to > > automatically test packages, so mabye they could build that first and > > then write tests for packages. > > The AutoQA project is in full swing, developing just that, a framework > to test packages in an automated fashion. Ah, that's great. I thought it was only supposed to test packages metadata etc, but not the behaviour of programs inside them. Is it already possible to write a test that installs each packages that contains a binary and ensures that it does not segfault when it is called without arguments or with -h,--help,-? ideally for different locales? Regards Till pgpjLJY61oMpQ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 06:58:28PM +, Matthew Garrett wrote: > On Fri, Feb 26, 2010 at 07:42:16PM +0100, Patrice Dumas wrote: > > On Fri, Feb 26, 2010 at 05:07:24PM +, Jesse Keating wrote: > > > > > > It'll require some enhancements to how bodhi is used for people > > > consuming testing updates, and it may require a more active role on part > > > of the maintainer to seek out somebody to at least give the update a > > > smoke test. > > > > For many specialized software, this is asking too much to the > > maintainers. > > If you can't find anyone who can test the software, why does it need to > be updated? 1) to fix a bug or add a feature the maintainer experienced/uses 2) As already told several times, not having people to test something does not mean that the package is not used 3) It allows new users of the package not to find/debug the bugs again that are already fixed upstream 4) It is not made easy to test packages, e.g. normal uses normally do not have a test environment set up and most likely do not want to mess their own system. Maybe providing one-click access (e.g. via VNC) to a test system with the package to be tested would help here. Regards Till pgpYkn5QKp0bL.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 08:16:18PM +0100, Richard Zidlicky wrote: > On Fri, Feb 26, 2010 at 01:49:00PM -0500, Orcan Ogetbil wrote: > > On Fri, Feb 26, 2010 at 12:34 PM, drago01 wrote: > > > On Fri, Feb 26, 2010 at 6:27 PM, Mike McGrath wrote: > > >> [...] > > >> Though, in theory, fewer updates means a higher percentage of them can be > > >> tested which means quality goes up. > > > > > > Even if this might start another flamewar ... I like the idea of > > > having less updates. > > > > > > The "the version number changed so we need to update the fedora > > > package" attitude needs to stop. > > > > May I ask why? Can you elaborate on why there is such a "need"? Who > > "need's this? I hope people who are not the targeted audience of Fedora, because the four foundations of Fedora (“Freedom, Friends, Features, First”) include "first. > lots of people. Some want to review changes manually and udpate only > "important" > things, Imho it is easier to review small changes than big changes. > Others don not have gigabit internet access all around the clock. I am trying > to update > my Netbook over a mobile connection as I write this. But why do you want to update your Netbook anyhow? And with yum-presto the demand for high speed internet access is not that big. Regards Till pgpUxCJreJ5TU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 07:18:58PM +, Matthew Garrett wrote: > On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote: > > > 1) to fix a bug or add a feature the maintainer experienced/uses > > If nobody is complaining about the bug, then fixing the bug can wait > until the next Fedora release. Why even fix the bug in Fedora at all then, if the maintainer needs to create his own sub-distro with updated packages? Also why is the maintainer always nobody? > > 2) As already told several times, not having people to test something > > does not mean that the package is not used > > If they're not complaining, they're presumably happy with the current > state of the package? Please come back to reality. They can also be too frustrated to report the bug in Fedora, if it is already fixed upstream. And why should people hit bugs again in Fedora that are already fixed upstream? > > 3) It allows new users of the package not to find/debug the bugs again that > > are already fixed upstream > > If they're willing to debug, why are they not willing to test? Since the users are new, they are not yet there to test a package. But I would also not be interested to test old packages just to find out that the bugs I found are fixed in a newer release. And this already hit me several times. I wanted to do something, installed the Fedora package, found a bug, and realise that the bug is fixed in a new upstream release. The only benefit of Fedora in this case is that I can easier build the new package for me, because the spec is already there. Regards Till pgpJqFNrSK4B7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 07:56:02PM +, Matthew Garrett wrote: > On Fri, Feb 26, 2010 at 08:41:07PM +0100, Till Maas wrote: > > On Fri, Feb 26, 2010 at 07:18:58PM +, Matthew Garrett wrote: > > > On Fri, Feb 26, 2010 at 08:15:43PM +0100, Till Maas wrote: > > > > > > > 1) to fix a bug or add a feature the maintainer experienced/uses > > > > > > If nobody is complaining about the bug, then fixing the bug can wait > > > until the next Fedora release. > > > > Why even fix the bug in Fedora at all then, if the maintainer needs to > > create his own sub-distro with updated packages? Also why is the > > maintainer always nobody? > > The maintainer's convenience is significantly less important than that > of the end-users. The maintainer is also a end-user. Also since I am not paid for being a maintainer, my motivation is to provide useful packages to others, i.e. with bugs fixed, and get useful packages from others in return. > > > > 2) As already told several times, not having people to test something > > > > does not mean that the package is not used > > > > > > If they're not complaining, they're presumably happy with the current > > > state of the package? > > > > Please come back to reality. They can also be too frustrated to report > > the bug in Fedora, if it is already fixed upstream. And why should > > people hit bugs again in Fedora that are already fixed upstream? > > Propose a mechanism that allows you to ensure that new upstream releases > do not include any new bugs. We *know* that there are users who are > frustrated because it's difficult to follow a stable Fedora release > without things breaking. What we're discussing is a mechanism to reduce > the pain there, not one that makes it impossible for people to get their > hands on newer versions of software if the maintainer has packaged them. There is no way to ensure that there are no bugs except for maybe using a specification that does not provide any usefulness. > > > > 3) It allows new users of the package not to find/debug the bugs again > > > > that > > > > are already fixed upstream > > > > > > If they're willing to debug, why are they not willing to test? > > > > Since the users are new, they are not yet there to test a package. But I > > would also not be interested to test old packages just to find out that > > the bugs I found are fixed in a newer release. And this already hit me > > several times. I wanted to do something, installed the Fedora package, > > found a bug, and realise that the bug is fixed in a new upstream > > release. The only benefit of Fedora in this case is that I can easier > > build the new package for me, because the spec is already there. > > I'm confused now. If the maintainer hasn't uploaded a newer version, > then requiring testing for updates makes no difference. If the > maintainer has, why would the new user be testing an old version? The original question was why to update packages, even if there are no testers using it. Maybe the confusion goes away if to remember this. Regards Till pgpH9dvZ71zDf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 11:36:41AM -0800, Jesse Keating wrote: > On Fri, 2010-02-26 at 20:26 +0100, Till Maas wrote: > > First”) include > > "first. > > I take this to mean the first to include something in a release, as we > develop it, not the first one to throw it over the wall at our users of > a stable Fedora release. This just made me aware that this is also another category of packages instead of the complex and simple ones: Packages where Fedora is mostly upstream. Updates to these kind of packages cannot really compared to packages developed by a separate upstream, that has also his own people already doing some testing. This is maybe a problem in all these discussions about update frequency, everybody only the kind of packages that he worries about. Regards Till pgp7iHwbTIPrj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 01:16:43PM +0100, Kevin Kofler wrote: > I would like to collect feedback on this issue. If you want to disable > direct stable pushes, why? Could there be a less radical solution to that > problem (e.g. a policy discouraging direct stable pushes for some specific > types of changes rather than a blanket ban)? On the other hand, if (like me) > you DON'T want that feature to go away, please provide valid use cases. I just have another idea: Add the karma value to the repository metadata and write a yum plugin to only install packages with a certain amount of karma. I just checked that stable packages may still receive karma, so then everyone can pre-select packages based on the karma. And people for whom the current system works good enough, can disable it. And security updates could still be installed using the yum-security plugin. Regards Till pgpvv2F1HXeE4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 11:27:45AM -0600, Mike McGrath wrote: > Though, in theory, fewer updates means a higher percentage of them can be > tested which means quality goes up. This does not take testing & bugfixing at upstream and other distributions into account. And I am pretty sure, that there is more manpower than in Fedora alone. Regards Till pgpVgJ7ctHpno.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 03:46:39PM -0500, Bill Nottingham wrote: > Till Maas (opensou...@till.name) said: > > I just have another idea: Add the karma value to the repository > > metadata and write a yum plugin to only install packages with a certain > > amount of karma. I just checked that stable packages may still receive > > karma, so then everyone can pre-select packages based on the karma. And > > people for whom the current system works good enough, can disable it. > > And security updates could still be installed using the yum-security > > plugin. > > Given the interdependencies between updates, I'm not sure that's really > practical. What happens when (theoretically) new thunderbird is +3 > but the new xulrunner it depends on is -3? Off course all dependencies need positive karma, too. Afaik --skip-broken would take care of this. Regards Till pgptoeTWbQzKG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 09:08:38PM +0100, drago01 wrote: > And a packagemaintainer should be able to judge whether the package is > worth pushing or not. > "It has a higher version number" can't be the reason for that. (and I > don't see how anyone can disagree with this but well ...) This leads to the question why did upstream create a new release? If it is a complex software without proper testing at upstream and it handles important data like mail, then the decision is completely different to some other simple software that does many releases with small changes that can easily be tested. Regards Till pgpFwha0Fv53L.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 04:14:37PM -0500, James Antill wrote: > ...and as in all threads about this that I can remember, the obvious fix > to the above is having two repos. and let everyone who wants a giant > firehose of mostly working stuff can enable this second repo. if only we > could create this "testing of the updates" repo. surely everyone would > be happy. It seems more like we need three repos then. The current situation works well enough for me and I do not remember that I ever wanted to downgrade something except that I am still missing kpdf/kprinter, but both went away in a distribution upgrade. But I was more often hit by not up to date packages in Fedora. Regards Till pgpZ4wblnxXgo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 11:22:25PM +0100, Till Maas wrote: > On Fri, Feb 26, 2010 at 04:14:37PM -0500, James Antill wrote: > > > ...and as in all threads about this that I can remember, the obvious fix > > to the above is having two repos. and let everyone who wants a giant > > firehose of mostly working stuff can enable this second repo. if only we > > could create this "testing of the updates" repo. surely everyone would > > be happy. > > It seems more like we need three repos then. The current situation > works well enough for me and I do not remember that I ever wanted to > downgrade something except that I am still missing kpdf/kprinter, but > both went away in a distribution upgrade. But I was more often hit by > not up to date packages in Fedora. Since we have already two stable releases, this could also be solved by further restricting the updates for FN-1 when FN is released. Regards Till pgpsQwPKBVfnS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 03:11:50AM +0100, Kevin Kofler wrote: > Till Maas wrote: > > I do not remember that I ever wanted to downgrade something except that I > > am still missing kpdf/kprinter, but both went away in a distribution > > upgrade. > > kprinter is still available in the kdebase3 package. (Of course, it's still > the same old KDE 3 stuff, but it's expected to work as well as it always > did.) Ah, that's useful. > For KPDF, it has been replaced by Okular which is a perfectly fine > replacement for me. Is there any specific KPDF feature you're missing in > Okular? Yes, the printing from okular, e.g. this bug report: https://bugs.kde.org/show_bug.cgi?id=181290 Basically I miss every difference in the UI behaviour between kprinter and the printing dialog in okular. E.g. the dialog does not remember to always show the options and it is not possible to save the several complex options that I want to use, e.g. how many pages per sheet, how to duplex, etc. This made me already create a lot of wasted prints. Regards Till pgpeN7OPGhwUA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 12:52:53AM -0500, James Antill wrote: > On Sat, 2010-02-27 at 01:36 +0100, Kevin Kofler wrote: > > , those users have very few choices > > And, again, you are wrong. > Rawhide and Debian unstable are both the obvious choices, Gentoo is > still used by some I think. A little more work with a little more > stability then gives you Debian testing and now moving to the latest > Fedora pre-releases. > Yes, those options are less stable than Fedora release should be ... > but you appear to be trying to move Fedora release down to that level > rather than help move them up. > I've known people who want exactly what you seem to profess to want and > use one of the above options. Why don't you? People who want to have Rawhide already could use it, so it is pretty unreasonable to assume that they want the same for Fedora. E.g. there are updates that certainly should happen only in Rawhide, e.g. if they require manual intervention. Afaik this is required regularly for postgres updates, because the format of the database files changes. Regards Till pgpgVy4ojHtlD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On Fri, Feb 26, 2010 at 03:54:02PM -0700, Kevin Fenzi wrote: > b. Given a, I would say people should stop posting to this thread. If > you have a better updates policy in mind, perhaps you could draft up a > proposal for what you think it should be? Or wait for a real proposal > to comment on? Since AutoQA is supposed to to behaviour testing of packages eventually, how about a policy that says: A stable update to Fedora must pass all AutoQA tests. Then the granularity of stability can be adjusted by adding tests to AutoQA. And I hope that only reasonable tests will be added to AutoQA, e.g. a test that just ensures that a packages stays at version X would not be one. But if it ensures that e.g. "yum-builddep foo.src.rpm" installs all build deps of foo, it would be a useful test. > - I think educating our maintainers to be more carefull or get more > testing feedback has not worked so far, nor is it likely to moving > forward. We simply seem to lack the communications channel to do so. If the maintainer receive more testing feedback, they probably won't ignore it. > - I think perhaps a more lifecycle like thing could help our users know > what to expect. Currently, they don't. They could get a major version > bump at any time, in a older "stable" release. I have talked to users > who are are f11 still because they think it will be "most stable" but > then are dismayed with how many updates they get. Pushing less updates to F(current-1) is probably something many maintainers can live with. But I have also heard of people using F(current-1) and feeling like secondary users, because they did not get the updates that F(current) got. > - Perhaps we could look at ways to make rawhide more day to day > friendly. I think the autoqa stuff might help here. If those people > that needed the very newest version of everything could use rawhide, > perhaps we could target the stable releases more to those that want > them. There will always be updates in Rawhide that are not meant to be consumed directly or without manual intervention. Regards Till pgpnh11xlZwK9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Fri, Feb 26, 2010 at 05:28:26PM -0800, Adam Williamson wrote:
> On Fri, 2010-02-26 at 19:53 +0100, Till Maas wrote:
> > On Fri, Feb 26, 2010 at 10:01:56AM -0800, Jesse Keating wrote:
> > > On Fri, 2010-02-26 at 18:56 +0100, Till Maas wrote:
> > > >
> > > > Something I am dreaming about is to have some infrastructure to
> > > > automatically test packages, so mabye they could build that first and
> > > > then write tests for packages.
> > >
> > > The AutoQA project is in full swing, developing just that, a framework
> > > to test packages in an automated fashion.
> >
> > Ah, that's great. I thought it was only supposed to test packages
> > metadata etc, but not the behaviour of programs inside them. Is it
> > already possible to write a test that installs each packages that
> > contains a binary and ensures that it does not segfault when it is
> > called without arguments or with -h,--help,-? ideally for different
> > locales?
>
> In addition to Jesse's reply, AutoQA is a framework for tests. You can
> theoretically run almost any type of test through AutoQA. Essentially
> it's just a little machine for running a bunch of arbitrary commands at
> specified times, and saving the results somewhere. It's by nature very
> flexible, and there's not a lot of restrictions on what the tests you
> can run within the AutoQA framework actually *do*.
Ok, maybe the question should be then: How much does AutoQA support me
writing these tests? E.g. this test is pretty simple, but afaics there
is no easy support for the common tasks that are needed to run the test,
but not really part of the test, e.g. installing the package or setting
up a machine.
The Writeing AutoQA Tests wiki page[0] says:
| I'll say it again: Write the test first. The tests don't require
| anything from autotest or autoqa. You should have a working test before
| you even start thinking about AutoQA
But this is not really supportive, because if I want to test a packages,
I need a framework that creates the initial environment, e.g. a system
of the Fedora version to be tested with the package installed and there
needs to be a way to interact with the programs.
Or is this really a test I can easily integrate into AutoQA currently?
Say we start without locales and commandline arguments, then the test
would be:
Input: Package to be tested as ${PACKAGE}
for binary in $(rpm -ql ${PACKAGE} | grep bin); do ${binary} 2>&1 | grep
"Segmentation fault" && echo "test failed" ; done
Regards
Till
[0] https://fedoraproject.org/wiki/Writing_AutoQA_Tests
pgpfJzvG9ajdN.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora-release-rawhide, et. al.
On Sat, Feb 27, 2010 at 03:00:39PM +0200, Ville Skyttä wrote: > On Friday 26 February 2010, Till Maas wrote: > > On Fri, Feb 26, 2010 at 01:12:53PM -0500, James Antill wrote: > > > On Fri, 2010-02-26 at 17:14 +0100, Till Maas wrote: > > > > > Also repoquery returns F12 results but accepts --releasever: > > > > $ repoquery --releasever=rawhide --repoid=fedora kernel > > > > kernel-0:2.6.31.5-127.fc12.x86_64 > > > > > > Yes, it's a 3.2.26+ feature. It's likely that F12 will get a yum update > > > eventually ... and you can get a 3.2.26+ yum from rawhide now. So for > > > ideas about changing how rawhide works, that's not a big requirement is > > > it? > > > > Yes, it is not a big requirement. Nevertheless I can wonder why it does > > not work in repoquery, even though it is in the --help output. > > It did not work with yum 3.2.26 installed either. Fixed in git now (should > work with yum >= 3.2.24 installed). \o/ Thank you, with this patch it works in F12: http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=f0bee60c3fc81325e547d0f8bf42591368d18ee4 Regards Till pgplWrDVeZ2qo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 09:44:11AM -0600, Mike McGrath wrote: > On Sat, 27 Feb 2010, Mike McGrath wrote: > > > On Sat, 27 Feb 2010, Kevin Kofler wrote: > > > > > Chris Adams wrote: > > > > IMHO you're developing the wrong distro. It is statements like yours > > > > that contribute to the "Fedora is a rolling beta" perception (and I > > > > don't think that's a good perception to have). If you want to target > > > > rawhide with rolling releases of KDE, have fun. Once a release is out > > > > the door, try not to just throw a new kitchen sink in for the hell of > > > > it. > > > > > > Some people actually LIKE rolling releases, indeed some distros use > > > completely rolling releases (e.g. Arch Linux). We are currently somewhere > > > inbetween (partly release-based, partly rolling), and IMHO this compromise > > > is working great. We get the advantages from a rolling release model, but > > > with a lot less surprise breakage as in a true rolling model because > > > disruptive changes like libata go only into new releases. > > > > > > > If only we had some sort of rolling release, that tracked as closely with > > upstream as possible, where the users of said release understood they were > > drinking from the firehose. Meanwhile, along side that release we could > > have periodic stable releases that don't move so quickly. That way you get > > what you want and I get what I want. Oh wait! That's the world we live > > in today. Next time a user tells you "I want a newer X" tell them > > "Upgrade to rawhide". > > > > > > Or to put it another way, why aren't you doing this and telling others to > do this? If someone is on F11 still, why do you think they want the > latest and greatest software? If they did, they'd upgrade to f12. And > further still, why wouldn't they be running rawhide? The rolling update > release exists. Why force rolling updates on people that haven't chosen > to run rawhide? Did you read what he wrote? I feel tempted to just copy the paragraph Kevin wrote again, because it already answers your question: Rawhide is not partly rolling as Fedora is. And a typical reason not to upgrade from F(current-1) to F(current) is because the major updates may make systems unusable, e.g. X not working anymore. But this does not mean that the same person does not want bugfixes for e.g. yum-builddep installing build dependencies again. Regards Till pgpL2CZg2MOO7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 10:45:49AM -0600, Mike McGrath wrote: > On Sat, 27 Feb 2010, Till Maas wrote: > > Did you read what he wrote? I feel tempted to just copy the paragraph > > Kevin wrote again, because it already answers your question: Rawhide is > > not partly rolling as Fedora is. > > And a typical reason not to upgrade from F(current-1) to F(current) is > > because the major updates may make systems unusable, e.g. X not working > > anymore. But this does not mean that the same person does not want > > bugfixes for e.g. yum-builddep installing build dependencies again. > > > > This doesn't make sense. They either update at the end of a release or > the begining or middle, still, they have to update or live with an > unsupported system. It's not like you can not upgrade to F current for > very long. It allows to fix the bug in F(current) for 7 months until the user needs to upgrade from F(current-1). And then he could also skip one release and have a higher chance of the bug being fixed. Nevertheless, this is just a description of the situation. I like it more to have bugs fixed in F(current) at the cost of not fixing that much bugs in F(current-1) to keep it stable. > So instead of choosing when to make their system unstable, parts of it > become unstable throught the release without any coordination. I wake up, > go to work, suddenly I've got a different version of KDE then I had > yesterday. And you guys think that makes me think more highly of Fedora > and not less? Afaik the KDE updates work very well and I know a fanatic KDE user who cannot expect to wait for the next KDE update, because he knows of bugs that are fixed in it. Usually he does not even need to report them, because they are already in the KDE upstream bug tracker. So this "release becoming unstable" is imho a little exaggerated, because nobody is proposing to track unstable upstream releases/upstream SCM with updates. Regards Till pgpnuX77seRAX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 08:43:58PM +0100, Till Maas wrote: > I like it more to have bugs fixed > in F(current) at the cost of not fixing that much bugs in F(current-1) > to keep it stable. This should read as "to have more bugs fixed in F(current)" (even at the cost of maybe introduce regressions). Regards Till pgp9W9nGzjj2k.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 03:48:08PM -0600, Mike McGrath wrote: > I'm sure that guy loves it. Me? I don't like not being able to predict > what my desktop looks like tomorrow. Just so I'm clear, if we had > implemented what you are proposing... Fedora 11, Fedora 12, Fedora 13 > branched and rawhide would all be identical right now as far as package > version numbers go? No, because there are updates that, e.g. require manual intervention, or are more likely to break a lot of stuff. These would make the difference between the releases. E.g. an update from KDE3 to KDE4 should only happen from a Fedora release to another, but an update from KDE 4.x.y to 4.x.y+1 would be ok. Maybe even from 4.x.y to 4.x+1.z, but I am not that familiar with KDE upgrades. Or postgres updates are a kind of updates that afaik require manual intervention, therefore they should also only happen from release to release. There was a good list about criteria for good updates somewhere in the thread, I can try to find it again if you want. Regards Till pgpfCabgWkH5Y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 05:05:54PM -0500, Orcan Ogetbil wrote: > About rawhide: rawhide could/should contain more experimental stuff, > such as beta releases or cvs snapshots of actively and frequently > developed software. Such a repo would be nice, but it won't work for Rawhide as it is, because there needs to be a usable, newer release available within less than six months. Regards Till pgpGDZ4p4Ck7o.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 11:28:28PM +0100, Michael Schwendt wrote: > On Sat, 27 Feb 2010 17:05:54 -0500, Orcan wrote: > > > About rawhide: rawhide could/should contain more experimental stuff, > > such as beta releases or cvs snapshots of actively and frequently > > developed software. > > Why? And what would be the benefit? It would help to (to have such a repo, not necessarily to replace Rawhide with it) to catch FTBFS bugs directly when the commit was done upstream instead of just after they created a release. E.g. if Rawhide contains the new gcc that is more strict, than it would be nice to know that it breaks the current upstream SCM version of a package I maintain directly, so it can be fixed sooner. Regards Till pgpKZnNGZshfE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Sat, Feb 27, 2010 at 05:47:18PM -0500, Orcan Ogetbil wrote: > On Sat, Feb 27, 2010 at 5:28 PM, Michael Schwendt wrote: > > Where to start and where to stop with upgrade madness? > > This is exactly what we should be debating on. How can we draw a > borderline? Example: My proposal: If it passes all AutoQA tests and matches the criteria by Kevin Koffler[0], then the update is ok, except that critical path packages should be inspected more carefully. Regards Till [0] http://lists.fedoraproject.org/pipermail/devel/2010-February/131570.html pgpruvvB3gBQu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Directory ownership bugs
On Mon, Mar 01, 2010 at 03:57:06PM +0100, Jaroslav Reznik wrote: > see bug footer - This is autogenerated bugzilla, I'm sorry if the problem is > already fixed or reported. Additionally I apologize if that directory > ownership > was requested earlier by some bugzilla (some directories were probably added > into filesystem package later, so your package should no longer own that > directory). > If it's already fixed - then feel free to close it. Yet the bug entry is missing important information, the NVR of the tested package and also IMHO this is not something that should checked in a stable release, but Rawhide or maybe branched-Rawhide, because this simple change does imho not justify a package update. Regards Till pgpS9oMTmDHpU.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 01, 2010 at 01:30:18PM -0500, Seth Vidal wrote: > > > On Mon, 1 Mar 2010, Will Woods wrote: > > So I think it would be shortsighted for FESCo to refuse to even discuss > > a policy about what manual testing is currently required, since any plan > > for improving the quality of the distribution will always require some > > amount of manual testing. > > agreed. What kind of tests need to be done always manually? The only ones I can think are tests for the appearance of applications or tests that require specific hardware. But in the general case, I do not think that for every package manual testing will always be required, except while creating new automatic tests. E.g. if you have a library package with good unit test and behaviour test coverage and tests for RPM metadata, what do you want to test manually? Regards Till pgpblmGdpFSYu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
On Mon, Mar 01, 2010 at 08:05:00PM +0100, Josephine Tannhäuser wrote: > how can I use fedora-cvs on these machines? It seems that fedora-cvs > want to use the local username. How can I change this behavior with > editing a configfile in my home-dir? I don't want to edit the > fedora-cvs package-files. Which files do you mean here? Afaik, cvs needs to know the CVSROOT and when I joined as a package maintainer, the wiki suggested to export the CVSROOT variable in .bashrc. It would be this one for you: export CVSROOT=:ext:tannhau...@cvs.fedoraproject.org:/cvs/pkgs But I wonder, how do you access CVS without this? > Currently i have a alternate user on my private pc, but this is not a > good solution. :-) I still have a separate user, that has a different name than my FAS account, because I do not want to use a global CVSROOT variable for my normal account to avoid problems with other projects using CVS. Regards Till pgppMcmO4wG0k.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OT: fas-username vs. local username for fedora-cvs
On Mon, Mar 01, 2010 at 09:09:08PM +0100, Alexander Boström wrote: > mån 2010-03-01 klockan 20:13 +0100 skrev Till Maas: > > > But I wonder, how do you access CVS without this? > > You shouldn't need it. What happens if you don't have it? It still seems to work. :-) > CVS records the root location in the checked out copy, so you only need > to supply a CVS root when doing cvs checkout and even then you don't Just wondering, can I also make CVS record which CVS_RSH to use? For Fedora I use a special one to keep the SSH connection open to speed up things[0]. It probably works for other CVS projects, too, but luckily I do not need to use any currently. > need to set CVSROOT, you can just do "cvs -d :ext:f...@bar:/baz checkout > gazonk". The fedora-cvs tool does set CVSROOT but it could just as well > use -d instead. Thanks, I did not know about fedora-cvs before, which also explains my previous mail to this thread. :-) Regards Till [0] http://blogs.23.nu/till/2008/12/ssh-via-cvs-with-automatic-control-socket-support/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Refining the update queues/process [Was: Worthless updates]
On Tue, Mar 02, 2010 at 11:05:23PM -0800, Jesse Keating wrote: > On Wed, 2010-03-03 at 08:02 +0100, Kevin Kofler wrote: > > Why? Because you say so? We aren't doing that stuff now and things are > > working just fine, thank you very much! We don't HAVE to change anything at > > all! > > > > This I believe to be the crux of the problem. When multiple updates go > out that break large or important segments of our user base, many of us > see a problem. You however seem to think it's "just fine". Many of us > would rather put out a better operating system, and to do that, we need > change. Your "just fine" isn't good enough. Are there even any metrics about how many bad updates happened? For me bug that can be fixed issuing an update are a lot more than regressions with updates or new bugs introduced with updates. If updates are slowed down, this will get even worse. Especially because the proposal is to use time instead of test coverage as the criterion to push an update to stable. Regards Till pgpuKfMIZ9keg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Tue, Mar 02, 2010 at 09:07:29PM -0500, Seth Vidal wrote: > > > On Tue, 2 Mar 2010, Jesse Keating wrote: > > Ok... removing deprecated uses is a questionable at best update, but > > here is the kicker. The perl in F11 is perl-5.10.0-82.fc11. So these > > functions aren't actually deprecated in F11. So... why is this update > > going out? What possible benefit does the user get from this? Does > > anybody see this as a reasonable update to publish on F11? > > > > the suggestion I had made at fudcon went something like this: > > 1. all packages being put in as updates would need to be marked as per > the type of update. the default is 'trivial'. Options might include: new > pkg, trivial, feature, bugfix, security > > 2. We would issue security updates whenever they happened. Issue bugfix > updates once every 2 weeks. Everything else once a month. How about we keep updates and updates-testing more like they are and add another repo like updates-stable that follows your policy and is the only updates repo enabled by default. Regards Till pgpbBYdWQf47R.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Mon, Mar 01, 2010 at 01:46:20PM -0500, Seth Vidal wrote: > On Mon, 1 Mar 2010, Till Maas wrote: > > What kind of tests need to be done always manually? The only ones I can > > think are tests for the appearance of applications or tests that require > > specific hardware. But in the general case, I do not think that for > > every package manual testing will always be required, except while > > creating new automatic tests. E.g. if you have a library package with > > good unit test and behaviour test coverage and tests for RPM > > metadata, what do you want to test manually? > > I have a series of basic functionality tests that I run before each yum > release to make sure that there is nothing unforeseen in an update. > > I don't think such a set of tests is ridiculous, but I do admit it is > complicated. I assume that you have a checklist of tests and run them manually. Is it not possible to run the tests automatically because of there nature? Or is it only because the framework is missing? The advantage of automated tests would be, that together with rpm VCS support (scripts), you could even run after each commit to even faster spot bugs: 1) commit upstream 2) build new rpm 3) apply AutoQA to the rpm Regards Till pgpmqAMLwuH6n.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 03, 2010 at 12:33:40AM -0500, James Antill wrote: > You keep saying that 7 days is "enough" but I haven't seen you provide > _any_ evidence to support it. Noting that it will often take 3-4 days > before a package in testing can be seen by all users. So maybe you are So there is an easy way to get around 25% (two week stay in testing) to 50% (one week stay in testing) more time to test packages without negative impact: make them faster available to the users. Regards Till pgp7EJcFZLn9K.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Refining the update queues/process [Was: Worthless updates]
On Wed, Mar 03, 2010 at 08:42:57AM -0500, Seth Vidal wrote: > On Wed, 3 Mar 2010, Till Maas wrote: > > Are there even any metrics about how many bad updates happened? For me > > bug that can be fixed issuing an update are a lot more than regressions > > with updates or new bugs introduced with updates. If updates are slowed > > down, this will get even worse. Especially because the proposal is to > > use time instead of test coverage as the criterion to push an update to > > stable. > > Actually the proposal is time AND test coverage. I mind have misunderstood it, but afaics it only says that it will be tested, because it spent time in updates-testing, but this is not even true nowadays, even if packages stay long in updates-testing. Regards Till pgpKiC2Gc7PvW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote: > On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote: > > No, because updates may depend on previous updates to work properly. We > > can't possibly test or support all possible combinations of updates. > > We can't _now_ ... because of packagers like you who want to release > lots of updates with no or almost no testing! Afaics, nobody objected to test updates more. But afaics they only support so far is %check in SPEC builds, which is not much support after all. But with AutoQA this will become better. > If we had less updates, that changed less things and required more > testing before pushing them to users ... this would be entirely > possible. Less updates mean more changes per update or you have more buggy packages, because updates usually fix bugs. Regards Till pgpMsakSmFxAW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, Mar 03, 2010 at 10:50:22AM -0600, Garrett Holmstrom wrote: > On 3/3/2010 2:51, Till Maas wrote: > > On Tue, Mar 02, 2010 at 09:07:29PM -0500, Seth Vidal wrote: > > How about we keep updates and updates-testing more like they are and add > > another repo like updates-stable that follows your policy and is the > > only updates repo enabled by default. > > Splitting the updates repos into "updates-testing," > "updates-probably-stable," "updates-stable," "updates-really-stable," or > whatever doesn't solve the problem. Not only would the choice of what > is on by default remain the only distinction of significance, but it > would also subdivide Fedora releases in a way that prevents bugs that > are fixed with version upgrades from reaching most users. Bug avoiding regressions at all costs is what some are willing to take. With the repo split there can be at least better co-operation as e.g. splitting the distribution. At least for me as a FOSS believer getting upstream bugfixes fast (especially if I submitted them upstream) into the distro is a key feature. > If we want to go down that road we might as well write a yum plugin that > installs updates only if they meet a user-set karma threshold. At least > then we wouldn't have repo proliferation. This would work for me, too, and was suggested in some other mail. But this would also need repo adjustments to keep the old packags with enough karma. Regards Till pgpopGDxFQuXb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, Mar 03, 2010 at 05:37:14PM +0100, Kevin Kofler wrote: > Till Maas wrote: > > How about we keep updates and updates-testing more like they are and add > > another repo like updates-stable that follows your policy and is the > > only updates repo enabled by default. > > That's essentially what Adam Williamson and Doug Ledford (both inspired by > Mandriva) already proposed. \o/ this seems to be the road to a consensus then. ;-) > Out of the proposals for more conservative updates, it's the one I consider > least unacceptable, though I'd argue it's still worse than the status quo > because it doubles the amount of package streams to maintain, and > maintaining the conservative stream could become quite painful if done > right. (Backporting security fixes is a PITA, and you can't just upgrade to, > say, KDE 4.4.1 if you've been shipping 4.2.2 (the version in F11 GA) all > this time. (Note that I'm not aware of any security issue being addressed by As far as I understood, there is no need to backport security fixes. One could just copy the package with the security fix with all needed dependencies to the stable repo imho. Regards Till pgpiLmofd6yod.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Worthless updates
On Wed, Mar 03, 2010 at 05:45:02PM +0100, Patrice Dumas wrote: > On Wed, Mar 03, 2010 at 05:37:14PM +0100, Kevin Kofler wrote: > > actually works (i.e. if it doesn't lead to maintainers only caring about > > the > > conservative stream). > > Packagers would then have the choice, I think this can only be a good > thing. Right now they have the choice, but the user cannot know what > the packager choosed. If somebody wants more stable updates or more > uptodate package than what the maintainer want, this could be a scenario > where co-maintaining is a good option with different co-maintainers caring > more about one or the other stream. This came to my mind, too. Regards Till pgp2wP6P7g1jT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)
On Wed, Mar 03, 2010 at 11:48:18AM -0500, James Antill wrote: > On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote: > > On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote: > > > If we had less updates, that changed less things and required more > > > testing before pushing them to users ... this would be entirely > > > possible. > > > > Less updates mean more changes per update or you have more buggy > > packages, because updates usually fix bugs. > > As I would assume any programmer knows: Not all bugs are created equal. > Trading "no regressions" for "some minor bugs still remain" is a trade > lots of users are happy to make (see: every customer of every piece of > commercial software, ever). But this is why I am not using a commercial version of Fedora (RHEL), but a FOSS distribution. And here the relationship differs a lot than the relationship between non-FOSS vendors and clients, so the Microsoft / Windows User relationship does not hold. Is there even a way to report bugs to Microsoft? At least there is no way to submit patches. And I am pretty sure that minor bugs usually remain in commercial software, because the vendor does not care to put money/effort into fixing them. This also happens in FOSS, but then often patches are accepted. Regards Till pgpFBAMpCh4Y2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Refining the update queues/process [Was: Worthless updates]
On Wed, Mar 03, 2010 at 11:07:27AM -0500, Seth Vidal wrote: > > > On Wed, 3 Mar 2010, Till Maas wrote: > > > On Wed, Mar 03, 2010 at 08:42:57AM -0500, Seth Vidal wrote: > > > >> On Wed, 3 Mar 2010, Till Maas wrote: > > > >>> Are there even any metrics about how many bad updates happened? For me > >>> bug that can be fixed issuing an update are a lot more than regressions > >>> with updates or new bugs introduced with updates. If updates are slowed > >>> down, this will get even worse. Especially because the proposal is to > >>> use time instead of test coverage as the criterion to push an update to > >>> stable. > >> > >> Actually the proposal is time AND test coverage. > > > > I mind have misunderstood it, but afaics it only says that it will be > > tested, because it spent time in updates-testing, but this is not even > > true nowadays, even if packages stay long in updates-testing. > > Having more time opens us up to more testing days and in the near future > autoqa to help us bounce obviously bad things. This statement fails to address that packages that stays long in updates-testing are subject to testing. Btw. I am also pretty sure that most of the manual testing time is better spent writing automated tests, unless you consider just updating to updates-testing and see if something bad happens sufficient testing. But this is not even enough to find regressions, because one needs to investigate how to reproduce it and then also test the update/release version of the package to know, whether it is a regression or just a bug that was not triggered before. Regards Till pgpLc3IYcBxnt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
