Re: Sources file audit - 2010-01-06
On Sun, 2010-01-10 at 00:06 -0700, Kevin Fenzi wrote: > nphilipp:BADURL:system-config-date-docs-1.0.8.tar.bz2:system-config-date-docs > nphilipp:BADURL:system-config-nfs-1.3.49.tar.bz2:system-config-nfs > nphilipp:BADURL:system-config-nfs-docs-1.0.7.tar.bz2:system-config-nfs-docs > nphilipp:BADURL:system-config-samba-1.2.83.tar.bz2:system-config-samba > nphilipp:BADURL:system-config-samba-docs-1.0.7.tar.bz2:system-config-samba-docs > nphilipp:BADURL:system-config-services-docs-1.1.7.tar.bz2:system-config-services-docs > nphilipp:BADURL:system-config-users-docs-1.0.7.tar.bz2:system-config-users-docs I forgot to upload the source tarballs for these, but have done so now. Thanks for the heads up. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT frustrating for users and developers
On Mon, 2010-01-18 at 11:17 +0100, Jan Kratochvil wrote: > On Mon, 18 Jan 2010 09:18:11 +0100, Jiri Moskovcak wrote: > > On 01/17/2010 05:57 PM, Christoph Wickert wrote: > > > 5. Instead of hashes the missing debuginfo packages should be > > > listed with n-v-r, so people can install them manually. > > > > This could be a problem. ABRT determines the required debuginfo > > package using build_id. It calls yum --enablerepo=*debuginfo* > > --quiet provides > > /usr/lib/debug/.build-id/bb/11528d59940983f495e9cb099cafb0cb206051.debug > > and I don't know any other way how to map build_id to package name > > if yum fails. > > yum fails commonly because rpm knows about build-id hashes only in the > debuginfo.rpm archives (not the main .rpm archive). And debuginfo.rpm exists > in repositories only for the single latest release (this is a distro bug!). > > Therefore if the crashed program has been updated in repositories since it > started there is no way to map build-id -> nvr. Chiming in a bit late, but nevertheless: IMO, rather than somehow getting debuginfo packages for older versions, abrt could e.g. ask people to try to reproduce their problem with an up to date set of packages. This will often be the right thing to do: somebody else didn't dawdle and reported the bug right away, the maintainer fixed it and pushed an update. Abrt could then even tell the user "your problem has already been reported and apparently fixed" if it finds the reported Bugzilla ticked is CLOSED/CURRENTRELEASE or .../ERRATA. No need to clog up Bugzilla for that. I agree that sometimes it should generate a backtrace from old debuginfo packages and open a ticket with that, e.g. when the issue is hard to reproduce. However, in that case it even more shouldn't attach an incomplete backtrace, because it's likely missing essential information for the developer: "Hmm, your backtrace is incomplete, can you reproduce it with this and that debuginfo RPM installed?" -- "No." -- "Sorry then." --> CLOSED/INSUFFICIENT_DATA. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
155 more python packages need to be rebuilt for Python 2.7
Hi everybody, a lot of packages were rebuilt for Python 2.7 recently, but unfortunately they've turned out to be not all that needed rebuilding. Essentially, all packages that contain .py files that aren't below /usr/lib(64)/python need to be rebuilt so that their respective pre-built .pyc/.pyo files are built with the new Python version. If the packages aren't rebuilt, python will either attempt to rebuild the .pyc/.pyo files (and fail due to SELinux policy) during runtime (if run as root[1]) or the program will take longer to startup because the python interpreter needs to parse the .py files everytime (and can't just use the respective .pyc/.pyo files since they're invalid). The reason why this hasn't been noticed/why those packages haven't been covered in the mass rebuild is because they don't require "python(abi)" (which was used to find out which packages to rebuild) even though the contained .pyc/.pyo files clearly do. This is because the pythondeps.sh used by rpmbuild only adds that dependency to packages which have modules in the standard paths[2]. Thanks to Kalev Lember who wrote a script identifying the affected packages. Using its output, Dave Malcolm has just mass-filed bugs against the packages which we could identify and he's looking to get these rebuilt en-masse as well. Owners or comaintainers still would need to file update requests so the packages actually end up where the users can get them ;-). For this purpose, I've attached two lists to this mail: one listing the affected packages and their owners and comaintainers, the other listing the affected packages each person owns or comaintains. Please file updates when your packages have been rebuilt and nag us if they don't get rebuilt in time, whatever that means. Thanks for your help, Nils [1]: https://bugzilla.redhat.com/show_bug.cgi?id=621726 - 'SELinux is preventing /usr/bin/python "write" access on /usr/share/system-config-firewall.' [2]: https://bugzilla.redhat.com/show_bug.cgi?id=623233 - 'python(abi) autodetection needed for all .py[co] files, not just those beneath /usr/lib*/python*' -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 Ajaxterm: ruben antlr3: walters (mjakubicek,zoeloelip) anyremote: anyremote audio-convert-mod: firewing (firewing) audit-viewer: mitr backintime: timj bakefile: filiperosset (filiperosset) beagle: nushio (psytux) bibus: alexlan bleachbit: sundaram blueproximity: jsteffan bugzilla: itamarjp (eseyman) chameleon: jortel cricscore-applet: sagarun cycle: linuxdonald (linuxdonald) cyphesis: wart (atorkhov) decibel-audio-player: rishi devhelp: mbarnes dstat: jzeleny eclipse-slide: dsugar edsadmin: ivazquez eina: sundaram ekg2: karlik enemies-of-carlotta: ertzing etoys: gavin (sdz,tuxbrewr) expendable: twaugh fail2ban: athimm (jgu) flumotion: thomasvs freedroidrpg: wart frysk: cagney fuse-gmailfs: turki fvkbd: pbrobinson gcc: jakub gdeskcal: pfj gdesklets: luya (owentl) gdesklets-goodweather: owentl (luya) gdesklet-SlideShow: bioinfornatics gedit: rstrode gedit-plugins: rakesh (dodji) gimp: nphilipp glump: jcollie gnome-schedule: farnold gquilt: bonii (sundaram) gramps: jcollie (jjames) griffith: bonii gtkpod: tmz honeyd: pvrabec ht2html: mjakubicek ibus-pinyin: pwu (i18n-team,phuang,pwu) ibus-table: dchen (i18n-team,phuang) ibus-xkbc: pwu (i18n-team,phuang) inn: npajkovs (npajkovs,ovasik,s4504kr) jabbim: michich jbrout: peter jython: overholt (dmalcolm,jmatthews) kdevelop: than (kkofler,ltinkl,mathstuf,rdieter,rnovacek,tuxbrewr) kexec-tools: nhorman (aarapov,caiqian,nhorman) koffice: awjb (awjb,ltinkl,ltvrdy,rdieter,tuxbrewr) ktorrent: liquidat (nucleo,rdieter,tuxbrewr) libopensync-plugin-moto: awjb lilypond: limb llvm: bos (dmalcolm,jgarzik,salimma) luma: s4504kr mailman: jkaluza Mayavi: rakesh meld: bpepple metromap: fab mftrace: limb mingw32-glib2: rjones (lfarkas,mingwmaint,sailer) mypaint: cwickert (cwickert) olpc-switch-desktop: dsd (cjb,pbrobinson) openlayers: slankes (bochecha) openlierox: jwrdegoede opensips: ivaxer pcapdiff: limb petit: red pinot: drago01 pitivi: (orphan) (company) pony: kushal (kushal) pybliographer: zkota pyicq-t: mfleming (stefansf) pypar2: mxcarron python3: dmalcolm (amcnabb,tomspur) python-psyco: konradm (rnovacek) rhncfg: msuchy rhn-client-tools: msuchy rhnpush: msuchy (stahnma) rpmlint: scop (tmz,wolfy) sagator: ondrejj scons: gemi (fab,supercyper) sectool: pvrabec (jhrozek,mbarabas,mildew) sigul: jkeating (mitr) sk2py: chitlesh smolt: mmcgrath spacewalk-certs-tools: msuchy spacewalk-koan: msuchy sugar-analyze: fab sugar-chat: tuxbrewr (mpg) sugar-clock: fab sugar-connect: fab sugar-distance: fab sugar-finance: fab su
Re: 155 more python packages need to be rebuilt for Python 2.7
On Wed, 2010-08-11 at 17:17 -0400, David Malcolm wrote: > Thanks everyone who've already rebuilt their packages. > > I just kicked off a script that attempts to rebuild everything still > affected; the rebuilds are marked as --background which I believe makes > them lower priority in Koji than other tasks. (i.e. I'm trying not to > denial-of-service Koji). > > I'll try to file updates when the builds succeed; if they fail, I'll > note it in the bug. I've noticed that because the updates are filed by Dave, maintainers won't immediately receive mail about status changes etc. To not forget about these updates, simply grab these builds, give them a whirl (test them), then add a comment to the updates. This gives the update karma and let's you receive status updates from now on, all in one go! Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
On Tue, 2010-08-31 at 20:47 -0400, Matt McCutchen wrote: > On Tue, 2010-08-31 at 17:36 -0700, Roland McGrath wrote: > > Perhaps local and so forth could be given a --dist=foo switch, and these > > sorts of errors could say "can't figure out your dist from git, use --dist > > or fix your repo". > > Or a "branch" file... :D Please don't, a file in the repo which needs to be different between branches would break merging between branches (which is one thing that makes dist-git so much better than dist-cvs). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
On Wed, 2010-09-01 at 09:59 -0400, Tom Lane wrote: > Matt McCutchen writes: > > I personally don't like fedpkg doing magic based on the name of the VCS > > branch I am on and would use a "branch" file. I don't see what the big > > deal is about having the branches identical; I think seeing the > > difference in the "dist" value could actually be a helpful reminder. > > Actually, the branches *can't* be identical, in practically every > nontrivial case, because (if nothing else) the %changelog will diverge. > If you're copying log entries into a branch where those changes did not > actually happen, you are not doing the right thing. >From the view of git, the %changelog is just another bunch of data -- and doing that is called a "rebase", I believe. > As Matt said, this sort of difference shouldn't hurt the ability to > merge or cherrypick diffs from one branch to another. I stand corrected. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 15 or rawhide?
On Tue, 2010-09-14 at 17:13 -0700, John Poelstra wrote: > Shouldn't ABRT be looking to a file like /etc/fedora-release to > determine the release version? r...@rawhide:~> cat /etc/fedora-release Fedora release 15 (Finian) What you say ;-)? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 2010-09-15 at 22:46 -0400, Jon Masters wrote: > Right. I'm not saying Jarod should issue Fedora Arrest Warrants (FAWs?) I like this. We also need black helicopters. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ImageMagick soname bump for F14
On Fri, 2010-09-17 at 12:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > 16.09.2010 18:35, Orion Poplawski wrote: > > Do we really want to do this, especially for a FTBS issue presumably > > against F15? > > > > https://admin.fedoraproject.org/updates/ImageMagick-6.6.4.1-13.fc14 > > > Please excuse me what I did not ask early. Now I call to maintainers of > dependent packages - please rebuild it against new version of ImageMagick. Hi Pavel, please add the rss-glx-0.9.1.p-4.fc14 build to your ImageMagick update in bodhi so they both get updated simultaneously. Thanks. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trouble with building packages in F16: "The moc has changed too much"
On Mon, 2011-08-01 at 19:08 +0100, Richard Hughes wrote: > On 1 August 2011 15:24, Jaroslav Reznik wrote: > > It's not very good idea to ship pre-generated moc files, better to > > autogenerate them during the build-time. PackageKit is using automake, > > so it's a little bit more difficult but possible, check for example [1]. > > Right, I *think* I'm doing the right thing in > https://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-qt/src/Makefile.am > with the only difference being that I'm shipping the moc files in the > tarball. Can I just nuke the moc files in the fedora spec file, and > they'll get regenerated at build time? Or should I remove MOCFILES > from EXTRA_DIST? I'm no authority on qt/kde, but the original issue seems to indicate that moc files should be generated during compilation time (i.e. shouldn't be shipped in the tarball). Other than increasing compilation time, this shouldn't be an issue as moc is part of qt-devel. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange RPM versioning problem in qemu in Rawhide
On Tue, 2011-08-02 at 13:37 +0100, Richard W.M. Jones wrote: > Below are two packages. The first one is installed, the second one is > built for Koji. Yum refuses to upgrade the installed package to the > second one, saying: > > Examining qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: > 2:qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64 > qemu-0.15.0-0.2.2011072859fadcc.fc17.x86_64.rpm: does not update installed > package. > > But I don't understand why, since it seems clear that the second > package has a higher release than the first package. The version comparison method of RPM is a bit quirky and non-obvious: It separates elements at dots (obvious) but also at changes between digits and other characters (non-obvious). Let's look at only the releases of the two packages: 0.2.20110718525e3df.fc16 0.2.2011072859fadcc.fc17 Split up into the elements that RPM compares, these are: 0, 2, 20110718525, e, 3, df, fc, 16 0, 2, 2011072859, fadcc, fc, 17 The third elements cause this evr-comparison to have a result which you don't expect. Bump the second element "2" to "3" and you should be fine :-). BTW, rpmdev-vercmp lets you compare arbitrary [e:]v[-r] combinations on the command line without having to have the affected packages handy. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange RPM versioning problem in qemu in Rawhide
On Tue, 2011-08-02 at 12:12 -0700, Adam Williamson wrote: > On Tue, 2011-08-02 at 11:58 -0700, Adam Williamson wrote: > > > Well, in this case yes, but this problem could emerge again in a case > > where there's no version bump that 'should have' been carried out. The > > fundamental problem here is that git commit IDs are a single hex string, > > but RPM version comparison doesn't do hex, it splits out base-10 > > 'numeric' fields and 'alphabetic' fields. > > I suppose also, of course, git commit IDs don't increment, so even if > RPM spoke hex, they'd be unsuitable for use in version comparison. I > don't know if anyone would argue it's fundamentally 'wrong' for git > commit IDs to be in RPM EVRs, or if it's okay for them to be there as > long as you make sure there's stuff ahead of them which will always > compare correctly. Maybe the RPM team has an opinion. As the part before date/git-hash should have been incremented, I see date and git hash only as being informative to the people dealing with the package and not relevant for correct version comparison. The only issue I see is with the dist tag being after it... Everything else (of relevance) being the same, we do want .fc17 packages to trump over .fc16 packages always, don't we? So rather than the existing release scheme ... ["0"-if-prerelease.]N[.date-scm or "snap"[.snapshot-revision]][.disttag] ... I'd order it most-to-least-significant regarding version comparison: ["0"-if-prerelease.]N[.disttag][.date-scm or "snap"[.snapshot-revision]] Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Strange RPM versioning problem in qemu in Rawhide
On Wed, 2011-08-03 at 10:06 -0700, Toshio Kuratomi wrote: > We can't prevent fc16 packages from trumping over fc17 packages unless we > move the disttag all the way to the first position in the Release tag. > You're supposed to increment "N" in your above when you update to a new > snapshot, so the .fc16 package would still trump .fc17. Right. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: some locales crashes gnome-shell
On Mon, 2011-08-08 at 13:38 +0300, Muayyad AlSadi wrote:
> how can we debug this bug
> https://bugzilla.redhat.com/show_bug.cgi?id=728889
>
> I tried the following js in firebug/firefox
>
> var d=new Date;
> alert(Date.toLocaleFormat());
> alert(Date.toLocaleFormat("%Y-%m-%d"));
>
> we need to test
>
> Shell.util_format_date(format, this.getTime());
>
> I tried gjs and js command lines but I was unable to import Shell
You can evaluate that in the shell, start "Looking Glass" with:
Alt+F2, "lg", Return
Then you can e.g. run:
Shell.util_format_date("%Z", new Date().getTime());
And see what it returns. Press Escape to leave LG.
HTH,
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110823 changes
On Tue, 2011-08-23 at 09:57 -0400, Kaleb S. KEITHLEY wrote: > On 08/23/2011 08:40 AM, Rawhide Report wrote: > > Compose started at Tue Aug 23 08:15:54 UTC 2011 > > > > Broken deps for x86_64 > > -- > > ... > > cloudfs-0.7-6.fc17.x86_64 requires glusterfs = 0:3.2.1 > > ... > > How do I get cloudfs out of rawhide/f17? > > I've retired the package. It's a dead.package in fedora-scm. It's > obsoleted by hekafs. > > What else do I need to do. I guess you need to ask release engineering to block this package from f17 on -- you could untag the f17 builds, but then would probably get the f16 builds inherited into it... HTH, Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Wed, 2011-08-24 at 10:15 +0300, Nicu Buculei wrote: > On 08/23/2011 11:34 PM, Itamar Reis Peixoto wrote: > > On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw wrote: > >> On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists wrote: > >>> > >>> Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ? > >> > >> Is there a specific reason to? The home page states that the whole > >> 2.7.x series should be considered unstable. > > > > is this a good reason ? > > > > http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Working-Single-Window-Mode > > No, that single window mode is not such a good reason, the feature is... > cute but not excessively useful, the real reason is the 2.8 release is > long overdue (expected since last December) and quite a few features > were added: more gegl integration, better usability, linked layers etc. > And we the people using it for real work still remember the times when > Fedora used to be a bleeding edge distro and had such GIMP updated... > happy old times... You're probably referring to the updates 2.2->2.4 in '07 and 2.4->2.6 in '08 but please keep in mind that we're stuck with 2.6.x as the stable branch since then, so there's no reason to be gloomy about the Fedora side just yet. While we mightn't have had an explicit update policy for Fedora in the time, these packages only went in after thorough testing on top of that upstream managed to keep things as backwards-compatible as could be expected -- the built-in scheme interpreter became a bit more strict in 2.6, which was a documented break with 2.4 which could easily be fixed by fixing affected 3rd party scripts. Considering that upstream to a large part isn't interested in working on 2.6 anymore -- the last commit by a core developer to this branch was in February this year -- I don't expect to see another 2.6 bugfix release. As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course (which I already do to a certain extent, I can e.g. confirm that the ufraw gimp plugin built with 2.6 works with a private installation of current git master). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Thu, 2011-08-25 at 11:58 -0400, Genes MailLists wrote: > On 08/25/2011 10:28 AM, Nils Philippsen wrote: > > > As well, installing both stable versions side-by-side isn't an option as > > you can't install them into the same prefix: the libraries have the same > > SONAME, the new ones are expected to be ABI compatible. Therefore I > > don't see a real alternative to rebasing to 2.8 in stable Fedora > > releases when it finally is available, after thoroughly testing it of > > course > > > I really wish developers would not do that - every app should be > installable in /app-name-version - and then we use something like > the alternates system (soft links) to get the version we want to run ... > we should require this of every app in my view ... Side-by-side means into the same prefix. You can only have one gimp version installed into the /usr prefix, you're free to install a different one into /opt/gimp-x.y or somewhere into your home if you're an ordinary user. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Thu, 2011-08-25 at 21:29 -0400, Matthew Miller wrote: > On Tue, Aug 23, 2011 at 05:34:00PM -0300, Itamar Reis Peixoto wrote: > > is this a good reason ? > > http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Working-Single-Window-Mode > > That's a great example of what shouldn't happen _inside_ a release. New > releases come out twice a year -- we shouldn't release updates with huge UI > changes to the already-out versions. The single window mode is optional, but not the default. > It might be time to start working on getting the update into rawhide, > targetted for F16 or F17. F17 is my guess. Despite any possible (minor) UI changes, I'll probably have to rebase in F-15/6 then if we want to get bugfixes because (core) upstream pretty much ignores the 2.6.x branch. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On Mon, 2011-08-29 at 15:03 +0300, Nicu Buculei wrote: > On 08/25/2011 05:28 PM, Nils Philippsen wrote: > > > > You're probably referring to the updates 2.2->2.4 in '07 and 2.4->2.6 in > > '08 but please keep in mind that we're stuck with 2.6.x as the stable > > branch since then, so there's no reason to be gloomy about the Fedora > > side just yet. > > I remember how we tracked the 2.3-2.4 development in Rawhide, which > allowed me at the time to write articles (previews, tutorials) based on > our official packages and, of course, allowed the entire community to > contribute with testing and feedback. We didn't track development at that time, these were release candidates of 2.4, see the RPM changelog: ... * Wed Oct 24 2007 Nils Philippsen - 2:2.4.0-1 ... * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc3.2 ... * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc3.1 ... * Fri Sep 07 2007 Nils Philippsen - 2:2.4.0-0.rc2.2 ... * Tue Sep 04 2007 Nils Philippsen - 2:2.4.0-0.rc2.1 ... * Thu Aug 16 2007 Nils Philippsen - 2:2.4.0-0.rc1.1 ... * Fri Jul 13 2007 Nils Philippsen - 2:2.2.17-1 ... These versions already used the same file names as proper 2.4.x did, right now I know that much of this _will_ change when 2.8 is released, which incidentally impacts packaging the most (rather than normal code changes). > > While we mightn't have had an explicit update policy for Fedora in the > > time, these packages only went in after thorough testing on top of that > > upstream managed to keep things as backwards-compatible as could be > > expected -- the built-in scheme interpreter became a bit more strict in > > 2.6, which was a documented break with 2.4 which could easily be fixed > > by fixing affected 3rd party scripts. > > Testing is the "magic" word, we want to test it. Foremost, I want to have packages tested that actually have a more than even chance of ending up in the stable release. Right now I don't feel as confident about getting 2.8 in time for F-17 as I felt about 2.4 for F-8. If you look at the development schedule on http://tasktaste.com/projects/Enselic/gimp-2-8 you'll notice some fairly sizable tasks left which account for 15-18 workdays of people who'll likely do this in their spare time, which is projected right now for about 81 realtime days from now. I haven't seen much activity on the listed topics though in the last time (not critiquing upstream devs here, I'm a bit surprised to see only 2 real tasks left on that schedule), so this might slip even a bit more. "It's ready when it's ready" and all that. Rest assured that I'll push packages when we get to a point where inclusion is probable. > > Considering that upstream to a large part isn't interested in working on > > 2.6 anymore -- the last commit by a core developer to this branch was in > > February this year -- I don't expect to see another 2.6 bugfix release. > > As well, installing both stable versions side-by-side isn't an option as > > you can't install them into the same prefix: the libraries have the same > > SONAME, the new ones are expected to be ABI compatible. Therefore I > > don't see a real alternative to rebasing to 2.8 in stable Fedora > > releases when it finally is available, after thoroughly testing it of > > course (which I already do to a certain extent, I can e.g. confirm that > > the ufraw gimp plugin built with 2.6 works with a private installation > > of current git master). > > In the meantime I feel there is some duplicate effort wasted here: the > maintainer (Nils) is doing his own testing in private, another > contributor (Luya) is struggling (and hitting walls) with building an > external repo, people don't know what and from where to use. I'll think about making "gimp-beta" packages and putting them on fedorapeople, but their relevance for testing in Fedora will be rather limited as they have to be installed into a different prefix (e.g. /opt), so all 3rd party stuff won't work without user intervention (i.e. symlinks into /usr/...). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, 2011-08-30 at 08:40 +0200, drago01 wrote: > On Tue, Aug 30, 2011 at 8:36 AM, Felix Miata wrote: > > On 2011/08/30 15:06 (GMT+1000) Chris Jones composed: > > > >> I can't see any reason for floppies these days considering their extreme > >> price per data unit as opposed to usb memory. > > > > For some people the price of floppies is a sunk cost, or was never a cost at > > all (e.g. me, who has over a hundred empty ones acquired 5, 10 or 20 years > > ago, some at 0 price). > > > > Unlike USB chips in most budgets, each floppy is cheap enough to be > > disposable after one use or dedicated to one small file. > > > > Floppies have enough room on them to write down something legible about > > their > > content (e.g. DOS boot with FDISK; Memtest86+ v.whatever; BIOS flash for xyz > > brand AMI BIOS; etc.) which won't interfere with insertion or removal from > > its reader. > > > > Floppies are large enough to be much less likely than a USB stick to get > > lost > > between couch cushions or fit through a pocket hole. > > > > Not everyone uses hardware with installed and functional OM, bootable USB > > or PXE. > > > > A rude installer might unset a bootable flag or fail to install boot code in > > the MBR of the only available internal storage, leaving the primary boot > > device unbootable, and a floppy the only available device to boot from > > without opening up the machine, if opening up is even any option at all. > > CD/DVD ? "Write Once Read Many"? Wait... "Write Once Read Once" in this case. Not cheap enough for that. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
So you want to test an unstable GIMP...
...or so I've heard[1]. Here we go: Herewith I announce the officially unofficial unstable GIMP for Fedora repository! I've held off making packages of the 2.7.x series for a long time, but thankfully Luya Tshimbalanga has offered his own versions of these on his fedorapeople repository, compensating for my slackness in that regard in the meantime. However, since I whined about testing on what will eventually become official packages (and because I'm a stickler for having signed packages in publicly available repos[2] -- I'm looking at you, spot), I've decided to bite the bullet and wrap up some packages by myself. Here's the gist (in no particular order): - Don't bother if you (or your spouse/kids/dog) are offended by having to look at a caged Wilber dominated by a goat in garters every single time you start the program. The rest of you may discuss the sheer brilliance of this metaphor. - Save early, save often and don't overwrite originals. - The packages are for Fedora 15, 16 and Rawhide (14 is missing dependencies all over the place -- gtk2, glib2, babl, gegl) and are signed with my GnuPG key[2]. Its fingerprint is in my email signature since a few years, I guess that'll have to do. - No patches anymore since everything is upstreamed. Woot! - External and third party plugins and scripts should work with this version. If GIMP warns you about these using deprecated interfaces, report this to the author(s) of the plugin in question. Crashes should be reported upstream to both GIMP and the plugin author(s). - These packages contain configuration which kicks ABRT in the shin so it won't generate reports for GIMP executables. If you run into bugs which are related to packaging, send me an email, otherwise report them to the upstream Bugzilla[3]. No tickets on bugzilla.redhat.com for these, please. - No delta RPMs (yet) as I'm too lazy to download the old versions for three distro versions and two architectures right now. - I'll probably throw in git snapshots when I feel like it. - The packages are called as they stable ones are (no "unstable" or "beta" in their names) and override the official Fedora packages. No way to install both stable and unstable packages at the same time. - Saving only saves to GIMP's native image format XCF. Nowadays you export to formats like JPEG, PNG, GIF. - If you want to use the new single window mode, you need to activate it in the "Windows" menu once. It's not the default. - GIMP will migrate settings from stable releases. If you want to start with a clean slate, move away or remove the ~/.gimp-2.6 folder (or that of any older stable GIMP version) before starting this GIMP version for the first time. Here's how you get this: - Download a release file for this repository (e.g. [4]) and install it. - Update your packages if you have gimp installed already, "yum install gimp gimp-help-browser" otherwise. Here's how you get rid of this and get the stable version back. - "rpm -e fedora-gimp-unstable-release" - "yum downgrade gimp\*" It's probably a good idea to not enable both Luya's and my repository at the same time. To switch between them, disable the repo configuration of the used repo, "yum downgrade gimp\*" to get back to the official versions, then enable the new one and "yum update". As soon as Fedora carries official packages, these will supersede the unstable versions. At that time you should uninstall the fedora-gimp-unstable-release package, or else installing/updating packages may fail when I remove the repository (as I'll probably forget to tell you about it then). Have fun and don't let it bite you. Nils [1]: http://lists.fedoraproject.org/pipermail/devel/2011-August/156160.html [2]: http://repos.fedorapeople.org/repos/nphilipp/gimp-unstable/RPM-GPG-KEY-nphilipp [3]: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP&version=2.7.3 [4]: http://repos.fedorapeople.org/repos/nphilipp/gimp-unstable/fedora-15/x86_64/fedora-gimp-unstable-release-2.7-1.fc15.noarch.rpm -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
It seems one always forgets something... well, better this than leaving the stove on. On Thu, 2011-09-01 at 12:45 +0200, Nils Philippsen wrote: > Here's the gist (in no particular order): - GIMP 2.7 and later is licensed as "GPLv3+ and LGPLv3+" (executables, libraries) - This makes it incompatible with poppler's license (GPLv2 only, inherited from xpdf at the time). The xpdf license has since been amended to "GPLv2 or GPLv3" in version 3.03 and poppler will follow suit in version 0.20. In the meantime, I'll build GIMP without poppler, falling back to using the postscript plugin for importing PDF files. As soon as poppler packages with the new license are available, I'll revert to using it again. In this case the GIMP will have a file-pdf plugin again which will be licensed as "GPLv2 or GPLv3" (as it's an exe of its own). Legal question: is it better to put this in its own subpackage to be able to specify this individual license, or would GIMP better have "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GIMP vs. poppler licensing, was: So you want to test an unstable GIMP...
On Sat, 2011-09-03 at 23:17 +0200, Kevin Kofler wrote: > Nils Philippsen wrote: > > Legal question: is it better to put this in its own subpackage to be > > able to specify this individual license, or would GIMP better have > > "GPLv3+ and LGPLv3+ and (GPLv2 or GPLv3)" as its license? > > Not an actual answer to your question, but wouldn't the license of the PDF > plugin be GPLv3 only rather than (GPLv2 or GPLv3), considering that GIMP is > GPLv3+? Yes, indeed it would. Thanks, Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:02 -0700, Adam Williamson wrote: > On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: > > * As a maintainer it's easy to have a env that gets out of sync with > > what a QA or end user would use. Ie, you make 20 iterations of a > > package to test something, tweak configs to check something, and get > > it all working, but perhaps your machine is no longer setup the way a > > fresh install or upgrade of your package would be. Or you tested a > > version and then changed just 'one little thing' and pushed that and > > it turned out to break it. > > Both hughsie and myself, and I think everyone else in favour of > maintainer +1s, suggested maintainers should test *in a vanilla > environment*, with the actual package they were submitting, before > +1ing. +1ing on the basis of a test build or in a dirty environment > would be a no-no and could lead to the removal of +1 privileges if > repeated. I think we should define what a "vanilla environment" is then. One could argue that either of the following could be described as "vanilla": - A fresh system without any modifications or unstable updates other than that being tested. Pro: makes testing comparable. Contra: You essentially need a special VM for testing which needs to be installed freshly for each tested update. Makes tests comparable ;-), i.e. reduces the amount of different environments in which an update is tested. I do actually want testing to be done on systems that aren't just "minimal install plus updates plus a user beside root". - A system in good condition (packages verify well, no dupes) that's used normally, i.e. what you would see being used by normal persons without any fancy hacks in configuration, or worse, non-config files owned by packages. Pro: Easy to test as you don't need to do anything fancy, just yum --enablerepo=updates-testing update ; I'm also guilty of +1ing my updates, but only for Fedora releases where I actually tested the updated package(s). And my system is "in good condition" as per what I described above, I keep code to be tested in separate hierarchies, usually in subdirectories in my home. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: > I don't think a maintainer can realistically replace wide-spread user > based testing in a variety of environments. I didn't argue that this would be the case, but rather that persons who are developers/package maintainers can also wear a tester's hat as long as they can keep these roles separate. > In light of that, we can > either accept a maintainer +1 as "I tested this as I would use it and > it worked" (which should be implied by them submitting the update ^^ > already anyway), or we can disallow it as the policy says. ^ No, implicitly assuming that the final package was tested just because a maintainer submitted it is wrong in my eyes. To me, a maintainer submitting an update simply means "I've built (a) new package(s) which should fix these problems, now it/they can be tested." It shouldn't make a shred of difference if a person testing an update package is a maintainer or not in this process. > I don't think adding more definitions or steps to the existing policy > is really going to improve anything. Yet making a special case of testing by a maintainer makes the process more complicated. The policy regarding testing done by maintainers shouldn't be longer than one or two paragraphs and be summed up in "keep development and testing separate, ensure that your testing environment isn't negatively affected by your developing." Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs
On Mon, 2011-09-12 at 13:39 +0200, Kevin Kofler wrote: > Clyde E. Kunkel wrote: > > Didn't say like, said similar. Don't you test your changes somehow? Or > > do you just toss the mods over the wall and hope for the best? I don't > > think so. Share your test cases for those packages that should just > > work--not all packages. Forget that the changes are for rawhide and > > forget "that Rawhide is NOT suitable for any sort of > > production use and that it WILL break. (Not "may", "will"!)" I bet > > every developer and maintainer has pride in their work and products and > > really don't want to put untested changes into any distro. > > Testing is exactly what we have Rawhide users for. Oh please... you're always talking about making life of developers/maintainers easier, so your apparent lack of regard for the people doing the testing seems a teeny weeny bit hypocritical. Don't you think that testers would rather not stumble over bugs which were easy to avoid in the first place had the maintainer spared a thought or two more on what he did? I'd rather have testers spend their time on spotting harder to find issues than on needlessly repairing their systems. Yes, Rawhide by its nature will break things eventually, but that's a matter of probability because it is the place where new (untested!) things get introduced. It shouldn't be a matter of carelessness on behalf of developers/maintainers. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: openssh: no pre-release sanity check? [Re: ssh-to-rawhide hangs
On Mon, 2011-09-12 at 13:37 +0200, Kevin Kofler wrote: > Rahul Sundaram wrote: > > If you continue to consider it a feature, it justifies (in your mind) > > pushing broken packages into the repository but it does affect release > > versions as well because we have to catch and fix bugs much later. If > > you maintain any of the critical path packages, it would be very useful > > to test them more instead of just a mad version number chase. > > That's exactly why we should go back to just untagging broken packages > instead of requiring pointless Epoch bumps in Rawhide. Then the breakage > will just get downgraded away before any release. We shouldn't revert to untagging broken packages in Rawhide just to make it less consequential for people to break stuff. We should revert to untagging broken packages because bumping epoch is costlier in the long run as epoch is often disregarded. People using Rawhide should probably use "yum distro-sync" rather than "yum update". Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, 2011-09-09 at 07:06 -0400, Josh Boyer wrote: > On Fri, Sep 9, 2011 at 4:13 AM, Nils Philippsen wrote: > > On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: > >> I don't think a maintainer can realistically replace wide-spread user > >> based testing in a variety of environments. > > > > I didn't argue that this would be the case, but rather that persons who > > are developers/package maintainers can also wear a tester's hat as long > > as they can keep these roles separate. > > > >> In light of that, we can > >> either accept a maintainer +1 as "I tested this as I would use it and > >> it worked" (which should be implied by them submitting the update > >^^ > >> already anyway), or we can disallow it as the policy says. > > ^ > > > > No, implicitly assuming that the final package was tested just because a > > maintainer submitted it is wrong in my eyes. To me, a maintainer > > submitting an update simply means "I've built (a) new package(s) which > > should fix these problems, now it/they can be tested." It shouldn't make > > a shred of difference if a person testing an update package is a > > maintainer or not in this process. > > I meant that it should be implied that the package maintainer already > did some amount of testing on the package before they submitted it as > an update. A basic minimum touch test that it doesn't break things, > etc. This is entirely outside the updates process and just common > sense good practice. And this is just what you get when I submit an update, but don't confuse that with a +1 karma -- I'll only give that to actual packages which I have tested on a live system. In reverse, most times only updates for the distro I've running at the moment will get this, unless I bother to fire up a different VM for testing. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Fri, 2011-09-09 at 12:22 +0200, Vít Ondruch wrote:
> Sorry, you are mixing two things:
>
> 1) One is testing environment and it can be probably well defined,
> clean, etc.
And thus incomparable to real-life environments. Mind, I'm not arguing
against some testing (e.g. automated regression tests, AutoQA) being
done in defined environments. But I doubt that it's enough if all
testing is done under these conditions, because this implicates we need
to define, and test against, all (or at least the majority of)
environments under which our software could be run, which frankly is
unrealistic. Therefore I'd rather have people also test in their
"naturally grown" environments to better cover real life situations that
deviate from defaults.
> 2) The other thing is maintainer mindset. You can try to convince
> yourself to take a different look but I doubt it will work. It reminds
> me like if you do patch review of your patches, which doesn't make
> sense. You, as a developer, are not able to spot weak points.
This is quite condescending, and a straw man to boot. Testing a piece of
software in the way we do it is on no way comparable to reviewing
patches: In the one case I'd be using the software _like any other user
or tester_, try out some functionality, partly related to what was
intended to be fixed, partly a few basic functionality ("smoke") tests,
in the other case I'd be looking at code changes which I worked on for
let's say the last few hours or even days. I grant you that the latter
case invites say a less skeptical approach than is warranted when
reviewing patches, but it's also much harder to do and much less well
defined (thus much easier to trick yourself into biased behavior) than
the former: with testing it's clear what you have to do (to a maintainer
or developer possibly even more than John Random Tester) and it's clear
how results should be interpreted. Either it does what it's supposed to
do, or it doesn't. If it doesn't, and it did before, it's a regression.
If I can describe to a tester how something should be tested, I can test
it myself.
> And it is
> expected that every developer delivers well tested and well behaving
> code from his side (i.e. automatic +1 karma from his side).
And that's wrong either way how I look at it: If I submit an update only
after I've done testing in the way I described above, I've wasted
precious time in which others could have tested as well. If submitting
an update would automatically imply that level of testing, I couldn't
submit updates for Fedora releases which I don't use.
When I submit an update it usually means that I've tried out the code
(not necessarily the package, probably rather from a checked out source
tree), checked it against bugs supposed to be fixed and done minimal
smoke tests. Nothing more.
> If there is
> not enough karma for his package to bring it into the stable, then there
> is probably time to ask somebody (probably on fedora-devel), to test
> this package.
We have a default of +3 karma for automatic pushes to stable, so a +1
from the maintainer by itself isn't enough to push an update to stable
already. Non-critical-path updates can be pushed to stable within 7 days
of them having been pushed to testing, without any karma at all, which
seems a much lower hurdle if I wanted to dump broken software onto
people.
> BTW no policy can stop some "evil maintainer" who will create other
> Fedora accounts and give karma to his packages under different
> identities.
And that's supposed to mean... what?
> You can even add karma without Fedora identity, but I am not sure if
> that counts.
It doesn't.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Mon, 2011-09-12 at 15:22 -0700, Adam Williamson wrote: > On Mon, 2011-09-12 at 17:56 +0200, Nils Philippsen wrote: > > > > If there is > > > not enough karma for his package to bring it into the stable, then there > > > is probably time to ask somebody (probably on fedora-devel), to test > > > this package. > > > > We have a default of +3 karma for automatic pushes to stable, so a +1 > > from the maintainer by itself isn't enough to push an update to stable > > already. > > That's only a default, though; you can lower it to 1 when you submit the > update. Also, once a critpath update hits the required threshold - +1 > from a proventester, +1 from anyone else (PT or no) - you can manually > push it to stable, whatever auto-push threshold you set. Well, I never really understood why we're able to lower the stable karma threshold. To me that's much more "gaming the system" than a maintainer +1ing his update after testing it (with the default threshold). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Thu, 2011-09-15 at 14:32 -0400, Genes MailLists wrote: >-- > (i) Server. >-- > > These run all the time - reboots are most often in maintenance > window (or evenings / weekends for home servers) primarily if not soely > for kernel updates. > >*** boot time pain more occasional fsck costs and not service startup > >Pain caused by O/S updates - rolling release model would be ideal > for these. When I was dabbling with HA clustering (which was admittedly a long time ago), there were environments with cold standby nodes (cold as in "off"). If the hot node went down, the cluster management software switched these standby nodes on, which booted normally then. In that case, a small boot time would have been very appreciated. I'm not sure if such scenarios are used nowadays. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote: > What's wrong with all that broken deps? Is this just a missing rebuild > against opencv and other libs or what's the reason for all this > "mess". I mean the release of F16 is not that far away and the amount > of broken deps is quite big imho. > I would be glad helping out if this is due to some orphaned packages. Some of these seem to be a case of "new library version was built and pushed as an update without the rebuilds of dependent components". It seems to be unclear who is responsible for the dependents to be rebuilt and included in the same update as the library being updated. Currently I only see mails of maintainers who plan updating the library, but the rest of it pretty much depends on the maintainers of the depending components rebuilding them quickly enough, and the original maintainer to include them in the F-16 branched update. I'd like to see a discussion about how we can ensure -- within reasonable limits -- that e.g. bumping a library's SONAME is followed by dependent components being rebuilt and included with the providing component in one update. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On Mon, 2011-09-19 at 18:11 +0200, drago01 wrote: > On Mon, Sep 19, 2011 at 5:46 PM, tim.laurid...@gmail.com > wrote: > > On Mon, Sep 19, 2011 at 1:00 PM, Kevin Kofler > > wrote: > >> Matthew Garrett wrote: > >>> Debian policy is that any virtual dependencies must also have an > >>> explicit dependency. In your case it would be something like > >>> > >>> Requires: phonon-backend-gstreamer | phonon-backend > >> > >> Unfortunately, RPM does not support this idiom. > >> > > > > Why don't you just replace rpm, with deb too, while you are at it ? > > > > Well as long as the tools we are talking about > 1) Do use rpm > 2) Do valid dependency resolution (i.e not --nodeps or something like that) > > I don't see why we shouldn't allow them. > > lets say > > yum install foo does: > foo, bar1, baz1 > > $nonyumtool install foo does: > foo, bar2, baz2 > > Both bar1/baz1 and bar2/baz2 are valid deps for foo (both statify the > dependency). > > So why would it matter what in the end? I guess the discussion is more about if you extend your scenario this way (and I'm picking DEs only as an example here, please don't start a flamefest about it, there are worthier causes): - bar1/baz1 are GNOME providers of bar/baz - bar2/baz2 are KDE/XFCE/other DE providers of bar/baz - GNOME is installed on the machine, but not KDE/XFCE/other DE In that case, you really want bar1/baz1 to be installed over the others (which would pull in KDE/XFCE/other DE base libraries), even though the other solution is correct dependency-wise. A much trickier scenario would be if a (say multi-user, terminal server) machine had both GNOME and KDE/XFCE/other DE installed: it may be desirable to install both bar1/baz1 and bar2/baz2 so users of each DE got their own native providers of bar/baz. I don't think we can describe this intended outcome in ways of RPM requirements today, and it'd probably be pretty hard even with Suggests/Recommends because it partly depends on policy, i.e. what the admin wants. Nothing in the system can tell the package manager right now if which of these options should be used in this case. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 16:06 +0200, Nicolas Chauvet wrote: > 2011/9/20 Nils Philippsen : > > On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote: > >> What's wrong with all that broken deps? Is this just a missing rebuild > >> against opencv and other libs or what's the reason for all this > >> "mess". I mean the release of F16 is not that far away and the amount > >> of broken deps is quite big imho. > >> I would be glad helping out if this is due to some orphaned packages. > > > > Some of these seem to be a case of "new library version was built and > > pushed as an update without the rebuilds of dependent components". It > > seems to be unclear who is responsible for the dependents to be rebuilt > > and included in the same update as the library being updated. Currently > > I only see mails of maintainers who plan updating the library, but the > > rest of it pretty much depends on the maintainers of the depending > > components rebuilding them quickly enough, and the original maintainer > > to include them in the F-16 branched update. > I'm the maintainer of opencv here. > > quick answear: I have no right to submit a bodhi update for packages I > do not own. Given that I'm no in the provenpackager group. > So as I cannot expect every single maintainers to respond in time, the > consequence is that I depend on a provenpackager to do the whole task > of "administrative rebuilt of dependent packages". > Unfortunately it became a way more complicated task with the collapse > of two bodhi tickets and others unexpected behaviour. I wasn't picking on you, or anyone for what it's worth. It's just a situation I've seen often enough so that I think it deserves some kind of a solution, at least for the majority of cases where this shouldn't be too much of a hassle. With "responsible" I didn't mean that this person needs to do all of the work either. Ordinary (non-proven-)packagers need to be part of the picture. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 16:07 +0200, Ralf Corsepius wrote: > On 09/20/2011 03:47 PM, Bruno Wolff III wrote: > > On Tue, Sep 20, 2011 at 15:01:06 +0200, > >Nils Philippsen wrote: > >> > >> I'd like to see a discussion about how we can ensure -- within > >> reasonable limits -- that e.g. bumping a library's SONAME is followed by > >> dependent components being rebuilt and included with the providing > >> component in one update. > > > > This should be easier to do now with the (relatively) new way to set up > > build overrides. > > These are hardly applicable, if several maintainers are involved or if > non-trivial technical difficulties arise. Well, easy build overrides are helping getting the technical side done without involving rel-eng. Several maintainers being involved and non-trivial technical difficulties are exactly the topics that need to be sorted out, but they don't have a thing to do with who sets up the build overrides. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote: > Of course, the accounts system _still_ doesn't have groups, five years > later, so provenpackager is the big hammer we have. We could get groups > any day now, that'd be just fine. Do you mean "groups of groups", like in "provenpackager-kde", "provenpackager-gnome", and "provenpackager" means all of these? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: > On 09/20/2011 03:01 PM, Nils Philippsen wrote: > > On Tue, 2011-09-20 at 13:53 +0200, Johannes Lips wrote: > >> What's wrong with all that broken deps? Is this just a missing rebuild > >> against opencv and other libs or what's the reason for all this > >> "mess". I mean the release of F16 is not that far away and the amount > >> of broken deps is quite big imho. > >> I would be glad helping out if this is due to some orphaned packages. > > > > Some of these seem to be a case of "new library version was built and > > pushed as an update without the rebuilds of dependent components". It > > seems to be unclear who is responsible for the dependents to be rebuilt > > and included in the same update as the library being updated. > > When you have a closer look, you'll notice that such "mass rebuilts" > were being delayed by QA's "delay queue" and now are stuck. I didn't want to (re)start that particular discussion ;-). We need some guidelines who should drive rebuilds in such a situation, regardless of whether it happens in Rawhide or Branched or wherever. Otherwise we'll end up with nobody doing the driving. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 11:45 -0400, Doug Ledford wrote: > - Original Message - > > So when _is_ a good time to do binary-incompatible changes to > > libraries? > > > > * It's not after beta freeze, because they are unwanted at that time > > > > * It's not 14 days before beta freeze, because they won't get out of > > updates-testing in time > > > > * It's not 14 days + 3 (4?) weeks before beta freeze - even if the > > library gets out of updates-testing in time, its users may not be > > rebuilt because the maintainer is on vacation. > > > > * What if there are two layers of users that need to be rebuilt? > > > > The delays just pile one upon another... > >Mirek > > I'd like to expand on my previous email (the one where I played > devil's advocate) and pick up where Mirek left off here. > > I'm fine with our new early branched methodology, to a point. I think > it's a good idea that we do an early branch and separate our upcoming > release from rawhide. However, I think the process we use to get > packages from updates-testing into the actual GA candidate tree is the > problem. > > I think we are gating package updates on the wrong thing: testing. I > say this because the *real* testing happens with the alpha/beta/rc > candidate install images, not with individual testers pulling packages > from updates-testing. And when trying to stabilize a product for GA, > you want *everyone* testing the updates, not just a few. > > Instead, I think we ought to revamp the process like this: > > Maintainer A builds new package B > Maintainer A files a bodhi ticket for package B > In that ticket, the maintainer is responsible for list each item of > change from the previous package already in the compose tree. For > example, did the upstream source get bumped, did any new patches get I'd like to mention that an upstream source getting bumped doesn't mean anything per se, so we should rather have criteria agnostic of arbitrary parameters like this. For instance, it shouldn't make a shred of difference whether I apply a patch in the spec file, or upstream, all other things being the same (i.e. if tarball-1.0 + patch == tarball-1.1 + changes we want to have anyway like updated translations). > applied, did any old patches stop being applied, are the changes > verified bug fixes as tested in rawhide, are the changes isolated or > are there feature additions as well, will this update create > dependency problems from things such as an soname bump, will other > packages need to be rebuilt. ^^ This. > Finally, the bodhi update should be reviewed by people from release > engineering, and if the ticket meets the requirements of a reasonable > change at this late stage of the game, the ticket should be approved > and the package pushed to stable. > > The point of this process is that when stabilizing the product for GA, > we want to minimize unnecessary or risky churn, and that doesn't need > testing, that needs a human to make a judgement call. Then, once the > judgement call is made, we need as much testing as possible to make > the release as good as possible. Holding things up in updates-testing > and then releasing them later throws away untold instances of testing, > wasting those resources on a package that may never be on the final > product. We need to make that judgement call, put the package in if > we are going to, test the hell out of it, and fix any breakage we > find. We need this iterative "test, report breakage, fix, retest" > process to be as fast as possible, and our current process moves at > the speed of a salt coated slug. > > That's my proposed process for our early branched release. Thoughts? Looks like it would get things done. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 12:21 -0400, Adam Jackson wrote: > On 9/20/11 11:43 AM, Nils Philippsen wrote: > > On Tue, 2011-09-20 at 11:33 -0400, Adam Jackson wrote: > >> Of course, the accounts system _still_ doesn't have groups, five years > >> later, so provenpackager is the big hammer we have. We could get groups > >> any day now, that'd be just fine. > > > > Do you mean "groups of groups", like in "provenpackager-kde", > > "provenpackager-gnome", and "provenpackager" means all of these? > > I don't see any real reason to do that instead of just unix-style > groups, but either one would be an improvement. Hmm, it seems I don't quite get what you mean with "the accounts system _still_ doesn't have groups" -- while provenpackager among others is a group. Would you please elaborate? TIA, Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: > Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME > in F17. Because rel-engs refused to provide dedicated build root, the > upgrade will be performed in F17 directly. > > That means Perl, Pyhon and other default-build-root packages will > disable support for GDBM temporarily. So if your package needs GDBM > support in those languages, please wait until new GDMB and other > packages (Perl, Python and similar) get recompiled again against this > new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: > On 09/20/2011 05:52 PM, Nils Philippsen wrote: > > On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: > > >> When you have a closer look, you'll notice that such "mass rebuilts" > >> were being delayed by QA's "delay queue" and now are stuck. > > > > I didn't want to (re)start that particular discussion ;-). > > > > We need some guidelines who should drive rebuilds in such a situation, > > regardless of whether it happens in Rawhide or Branched or wherever. > a) These situation can only happen in release branches. Uhm, no. A library SONAME bump can happen in Rawhide as well as in branches and if dependent packages don't get built with the new version, things are broken. Waiting for dependent components to be built at their maintainers leisure or whenever a mass rebuild comes around isn't a solution, not if we want to have a "more stable Rawhide". Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 11:29 +, Petr Pisar wrote: > On 2011-09-21, Nils Philippsen wrote: > > On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: > >> Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME > >> in F17. Because rel-engs refused to provide dedicated build root, the > >> upgrade will be performed in F17 directly. > >> > >> That means Perl, Pyhon and other default-build-root packages will > >> disable support for GDBM temporarily. So if your package needs GDBM > >> support in those languages, please wait until new GDMB and other > >> packages (Perl, Python and similar) get recompiled again against this > >> new GDBM. > > > > Have you tried building gdbm, creating the buildroot in bodhi, then > > untagging gdbm from f17 instead? > > > Bodhi and F17? Why not, you're not trying to submit an update, are you ;-)? As of buildroot overrides, bodhi isn't used solely for updates anymore (even though the URL ends in /updates/). The buildroot override document[1] doesn't mention that this would be limited to branches. Nils [1]: http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, 2011-09-21 at 13:53 +0200, Vít Ondruch wrote: > Dne 21.9.2011 13:45, Honza Horak napsal(a): > > I understand that buildroot override in bodhi works for f16 and lower > > only, am I wrong? I wanted to create a new target to make it safe, but > > after a discussion with rel-engs it appears to be too big hammer for > > such a few of packages. A temporary perl built without gdbm seems to be > > fine enough for this purpose. > > > > Honza It seems that you're right, I got this when I tried to submit a buildroot override for the current Rawhide dcraw package: Error: Could not determine release for dcraw-9.10-1.fc17 with tags ['f17'] It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as > Its strange to me. There are concerns to have Rawhide usable but at the > end, if somebody wants to prevents problems using dedicated build root, > it is denied by Rel-Engs, because it is probably to much work. This is > disappointing. It shouldn't really involve rel-eng at all, Bodhi buildroot overrides should just do this as it does with branched releases. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Responsibility for rebuilding dependent components, was: F-16 Branched report: 20110920 changes
On Wed, 2011-09-21 at 15:51 +0200, Ralf Corsepius wrote: > On 09/21/2011 01:25 PM, Nils Philippsen wrote: > > On Tue, 2011-09-20 at 22:25 +0200, Ralf Corsepius wrote: > >> On 09/20/2011 05:52 PM, Nils Philippsen wrote: > >>> On Tue, 2011-09-20 at 15:19 +0200, Ralf Corsepius wrote: > >> > >>>> When you have a closer look, you'll notice that such "mass rebuilts" > >>>> were being delayed by QA's "delay queue" and now are stuck. > >>> > >>> I didn't want to (re)start that particular discussion ;-). > >> > > >>> We need some guidelines who should drive rebuilds in such a situation, > >>> regardless of whether it happens in Rawhide or Branched or wherever. > >> a) These situation can only happen in release branches. > > > > Uhm, no. A library SONAME bump can happen in Rawhide as well as in > > branches and if dependent packages don't get built with the new version, > > things are broken. > Right. They break in rawhide, where issues are inevitable and can be > addressed within short terms because maintainers are not being forced to > play "10 days per package update" "you wait for me/I wait for you" delay > ping-pong. And that's always fine and dandy if these issues are resolved in a reasonable amount of time. Right now Rawhide has packages with dependencies broken since pre-F15. This isn't acceptable. > Or am I misunderstanding? Are you referring to points in time when > "stable fedoras" are being sync'ed and inherit "broken deps" during this > fork? If this happens, something would be very defective with Fedora's > rel-eng's procedures. I'm not talking about branched Fedora vs. Rawhide at all. I thought I made myself clear on that. > > Waiting for dependent components to be built at their > > maintainers leisure or whenever a mass rebuild comes around isn't a > > solution, not if we want to have a "more stable Rawhide". > > To we want this? I don't. To me, rawhide is the "big package dumping > ground" for the bleading edge". Certainly, it should be as little broken > as possible, but "its brokenness" is part of its working principle and > inevitable to me. That said, I find a stable "rawhide" to be > nonrealisting and inapplicable. You're twisting my words a bit. I wasn't opting for a stable, but a more stable release. If somebody wants to test something in Rawhide they shouldn't have to debug other parts of the distribution. This means that changes should be done with enough circumspection that breakage is reduced to a minimum. People who actually run Rawhide (and I know their number is low) would thank us for that. Right now this is not the case: a substantial number of components is broken due to unsatisfied dependencies alone, meaning that everybody who wants to test Rawhide in conjunction with anything on that list is simply out of luck right now. I admit that the impact of being broken is not the same for every component in the distribution: some stuff more on the fringe is sufficiently isolated that it will only affect few testers if it doesn't work (ideally the ones fixing the breakage), so it won't hurt many if these are broken for a longer time, but other components are central enough that they can't afford that luxury. It would certainly help here if buildroots could be created for Rawhide so that breakage can be resolved in isolation there. In this case they'd need to be created before the first package is built however, so it doesn't break unrelated builds. This is because we don't file Bodhi updates for Rawhide packages (nobody in their right mind would want that). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 08:49 -0600, Kevin Fenzi wrote: > On Wed, 21 Sep 2011 13:32:59 +0200 > Nils Philippsen wrote: > > > On Wed, 2011-09-21 at 11:29 +, Petr Pisar wrote: > > > On 2011-09-21, Nils Philippsen wrote: > > > > On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: > > > >> Jan Horak (hhorak) is going to upgrade GDBM to version with new > > > >> SONAME in F17. Because rel-engs refused to provide dedicated > > > >> build root, the upgrade will be performed in F17 directly. > > > >> > > > >> That means Perl, Pyhon and other default-build-root packages will > > > >> disable support for GDBM temporarily. So if your package needs > > > >> GDBM support in those languages, please wait until new GDMB and > > > >> other packages (Perl, Python and similar) get recompiled again > > > >> against this new GDBM. > > > > > > > > Have you tried building gdbm, creating the buildroot in bodhi, > > > > then untagging gdbm from f17 instead? > > > > > > > Bodhi and F17? > > > > Why not, you're not trying to submit an update, are you ;-)? As of > > buildroot overrides, bodhi isn't used solely for updates anymore (even > > though the URL ends in /updates/). The buildroot override document[1] > > doesn't mention that this would be limited to branches. > > It is. Bodhi doesn't operate on rawhide at all... and a buildroot > override makes no sense related to rawhide. When you build a package in > rawhide it's automatically added to the buildroot the next time it's > generated. Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Remaining F16 blockers and F16 planning (2011-10-26)
On Thu, 2011-10-27 at 14:53 +0200, Phil Knirsch wrote: > On 10/27/2011 12:57 AM, Adam Williamson wrote: > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=668282 "PackageKit yum > > backend uses incorrect encoding for dynamic category names, makes them > > show up with '?' characters in KPackageKit" > > > > Nils reported that he would complete work on this today, but has not > > checked in today at all. This leaves us somewhat stuck, as only Richard > > Hughes and Nils are really qualified to work on this. Richard is away > > this week. > > > > Just heard from Nils that that should be resolved by now, see > https://bugzilla.redhat.com/show_bug.cgi?id=668282#c49 Yep, it's waiting for a proventester to test and karma it. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 heads up: gnome-shell for everyone!
On Fri, 2011-11-04 at 14:10 +, Ian Malone wrote: > It's frustrating to be stuck on > overview mode on a four core machine while gnome-shell is doing > /something/ but you don't know what. If it worked fluidly it would be > okay. Actually, the responsiveness issue isn't limited just to > overview, but that's where it's most annoying because it completely > cuts you off. (And ten seconds to get the applications list, really?) I hate that, too -- the shell deserves some tuning to not always show up with about 5%-10% CPU consumed, in the top 3 of top (ha!) -- but to be fair, opening the GNOME 2 panel application menu for the first time wasn't quicker (at least for me). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Package
On Mon, 2011-04-04 at 22:07 -0500, Mike McGrath wrote: > python-meld3 > supervisor Taken. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Calling autoconf in a spec.
On Sun, 2011-07-03 at 13:31 -0400, Tom Lane wrote:
> Sam Varshavchik writes:
> > To add to that: I never recall a single instance where I couldn't fix any
> > breakage in someone else's canned configure/makefile scripts without having
> >
> > to rerun autoconf and automake.
>
> > If there was a problem in the configure script, rather than patching
> > configure.ac or configure.in, I simply patched the configure script itself.
> >
>
> Yeah, and the question is why that's a good idea at all, let alone so
> superior as to be policy. To me it sounds exactly like arguing that you
> should fix a code bug by patching the emitted assembler code, instead of
> touching the C code. Or fixing a grammar problem by patching bison's
> output file instead of the input .y file. It just seems uselessly stone
> age. And it certainly does not yield a patch that you are going to be
> able to submit to upstream.
Here's my 2 cents: I just change things in Makefile.am, configure.ac,
etc. -- making changes upstreamable -- then run autoreconf and generate
a patch that brings the original configure, Makefile.in, etc. files to
the state I got after running autoreconf -- which makes builds (better)
repeatable.
I'd really love to be able to re-run current auto-tools on old
Makefile.am/configure.{in,ac} files and the results to work in all
cases, but right now that seems utopian to me.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
On Tue, 2011-06-21 at 10:39 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Today or in next few days I'll plan update ImageMagick in rawhide to > version 6.7.0-8. And we're still waiting... ;-) Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Calling autoconf in a spec.
On Mon, 2011-07-04 at 15:07 +0200, Kevin Kofler wrote:
> Nils Philippsen wrote:
> > I'd really love to be able to re-run current auto-tools on old
> > Makefile.am/configure.{in,ac} files and the results to work in all
> > cases, but right now that seems utopian to me.
>
> Yet the competition ( http://www.cmake.org/ ) manages that very thing just
> fine…
Convincing each and every upstream to dump auto-tools for something else
seem equally utopian to me. Not that I think cmake would solve all
issues auto-tools has ;-).
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Now ImageMagick built against new gcc. Great, thanks! Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update ImageMagick
On Mon, 2011-07-04 at 16:33 +0200, Nils Philippsen wrote:
> On Mon, 2011-07-04 at 18:10 +0400, Pavel Alexeev (aka Pahan-Hubbitus)
> wrote:
> > Now ImageMagick built against new gcc.
>
> Great, thanks!
Now that I've rebuilt rss-glx against the new ImageMagick version I see
that it has the same library versions, libMagick{Core,Wand}.so.4 -- it
this rebuilding of our packages really necessary?
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: > On 07/04/2011 10:53 PM, Paul Wouters wrote: > > It would be nice if we could upload/commit the .asc or .sig file, and have > > the rpmbuild script > > automatically check the tar ball. > > Hm, yes. It would be nice to see Koji support checking source sigs. OBS > already does so. Seeing as Debian has done this for years with the > source .deb including a signature file, RPM >4.9 could support sigs for > the Source0 file. Making Source0 a special case sounds rather dirty to me, if at all such functionality should be available for all source files (and patches eventually). Furthermore, just having a signature file doesn't help a bit if you can't be sure who created the signature... and I suspect if we were to restrict ourselves to upstream packages that a) have gpg signatures b) from keypairs not more than a certain "distance" (web-of-trust-wise) away from a known good keypair, we'd be able to trim down the package repositories substantially ;-). So for the time being I guess we should stick with letting package maintainers check this (of there is anything to check). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v2] Retiring packages in F-16
On Tue, 2011-07-12 at 17:10 -0400, Bill Nottingham wrote: > Each release, before branching, we block currently orphaned packages. > It's that time again for Fedora 16. > > New this go-round is that we are also blocking packages that have > failed to build since before Fedora 14. > > The following packages are currently orphaned, or fail to build. If > you have a need for one of these packages, please pick them up. > > This list has been fixed to properly show all orphaned packages. It's > a lot longer. [...] > Orphan: libgnomecanvasmm26 > ardour requires libgnomecanvasmm26-devel = 2.26.0-3.fc15 > ardour requires libgnomecanvasmm-2.6.so.1 > flowcanvas requires libgnomecanvasmm26-devel = 2.26.0-3.fc15 > flowcanvas requires libgnomecanvasmm-2.6.so.1 > flowcanvas-devel requires libgnomecanvasmm26-devel = 2.26.0-3.fc15 > gcdmaster requires libgnomecanvasmm-2.6.so.1 > referencer requires libgnomecanvasmm-2.6.so.1 As I use ardour regularly, I've taken this one (in Fedora, not EPEL) but would be glad to have comaintainers, e.g. from people maintaining the depending packages. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Support for separate /usr, was: Moving lspci and setpci from /sbin to /usr/sbin?
Coming a bit late here, but anyway... On Mon, 2010-02-01 at 11:16 -0600, Chris Adams wrote: > Once upon a time, Ralf Corsepius said: > > IMO, you are facing a hen-and-egg problem: You've never seen such a > > complaint, because using a separate /usr partition has never worked on > > RH-based distros. > > Please stop repeating this untrue statement. As I told you already, I > have used separate /usr since RHL 3.0.3. You two are talking cross-purposes: Ralf means that not every binary in /bin,/sbin works without /usr and Chris means he's not stumbled upon such an issue in years. IMO, the more dire problem is that /sbin/sulogin links against libfreebl3.so which is on /usr. That's just recently prevented me from interactively running fsck on my root partition which had errors without a rescue image. Somebody wants a bug for that or will it be closed WONTFIX right away because separate /usr is officially not supported? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Glade woes, was: Purging the F13 orphans
On Thu, 2010-02-04 at 14:24 -0800, Jesse Keating wrote: > Unblocked orphan glade2 I'll take that at least for the time being, because glade3 on F-12 (glade3-3.6.7-2.fc12.x86_64) e.g. doesn't correctly understand my legacy glade2 files. - I've not found any open bugs for it, so I don't expect too much work ;-). - I understand that upstream is working on glade3 and ignoring glade2, but this tool needs to stay until glade3 properly understands legacy glade2-generated files, doesn't have obvious problems like https://bugzilla.redhat.com/show_bug.cgi?id=519426 "Wrong orientation default for VBox". AFAIK this is essential so that people can sensibly convert their existing glade projects to gtkbuilder. Having to do UIs from scratch is not a viable option. If there are other, more robust glade2 to gtkbuilder converters I'd like to know about it. - The current F-12 version spits out meters of warnings on the command line, without even loading a file. - How quick we can expect fixes in glade3 is a good question, the last upstream version 3.6.7 is from June 09. The aforementioned BZ ticket is open since August 09 without maintainer reaction, it seems that the maintainer has changed in the meantime, I've reassigned the bug to the current BZ maintainer. - If so desired, I'll put a warning in the glade2 package and issue and update so that people don't use it for new projects. - I know that we want people to convert their stuff to GtkBuilder and that glade2 living longer doesn't help with that. As long as glade3 has these problems, projects which have legacy glade files need to somehow stay afloat. Feel free to comment. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
> On Sat, 2010-02-06 at 10:53 +, Leigh Scott wrote:
> > IMO ABRT isn't that useful as a lot of the reports don't include steps
> > to reproduce (I just close the bugs after a month if they don't respond
> > to the "needinfo" request).
>
> You can do it even sooner. If backtrace is unusable and there is no
> description whatsoever, then *this* user is not likely to bother
> to do anything to help you.
>
> > I believe ABRT shouldn't file a bug report unless it is filled in
> > properly.
>
> Sadly, this is impossible to achieve. Sure, we can
>
> if (description == "") yell("Fill the description dammit!");
>
> but then user might well enter description consisting of
> "I dont care" (or worse).
You're contradicting yourself here. First you say we should close bugs
without a description even sooner (like, immediately?), then you don't
want abrt to not file a report without a description. I don't see why we
should manually do the work abrt fails to do automatically -- while it
is automatable.
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:
1. Check if the bug has been reported yet (via that abrt BZ id thingy).
If yes, ask user to review the description (in their browser?) and
eventually add any additional details (see below in step 3a. for hints
abrt could provide for that), then stop here. Otherwise continue.
2. Check that all debuginfos can be installed etc, then continue. If
not, tell the user that "important debugging data" can't be assembled
right now and a) if they would like to postpone the bug report, if you
assume that it's a temporary problem or b) "there's an update for
package(s) ... which are used by your application, would you like to
install them?", as this seems to be the most common case of debuginfos
not being available.
3a. Display wizard window. Ask users (politely!) for a description of
what they did before the crash happened:
"Please describe what you did before the application crashed. Provide as
much detail as you can, this is important for the person getting the bug
report to help you. If this is too much work for you right now, you can
make some notes about details that are hard to remember in this field,
click on "Postpone report" below
_Hints for filling out this form_
...
[Cancel report] [Postpone report] [Back] [Forward]"
The buttons would be visible on any page in the wizard, [Back] would be
insensitive here because it's the first step. "_Hints for filling out
this form_" would be a link which would open a help page going into much
more detail, e.g.:
"... If you didn't use the app for a long while, state that, but try to
remember what you did when you last used it. Please also describe what
else you did immediately before the crash. ..."
Also provide examples of good and bad descriptions in this.
3b. While the user fills out the description, abrt loads debuginfo
packages in the background. If the user is ready before all are
downloaded, display the usual progress bar.
4. Next wizard page. Display backtrace, ask for review and removal of
sensitive data like passwords. "You don't need to understand most of
this, but if you see data )like passwords) you would not like to be put
into the bug report (which may be seen by anybody), please replace it
with a placeholder (like '')."
5. Last wizard page. Get confirmation for filing the bug report. "You
can review what will be submitted by using the Back and Forward buttons
at the bottom of this dialog." Fields for Bugzilla username and
password, pre-filled if we have that information already. "[ ] Remember
this information" checkbox.
If the user postponed this, they must have a means of continuing this,
so the applet may not be hidden in this case. While I'm at it, the
applet shouldn't flash forever, this breaks energy-saving measures (if
the user ignored it for a minute, they'll ignore it for an hour -- maybe
wake up it screensaver gets active, then inactive/unlocked).
In my opinion this would be much less intimidating to users and give us
bug reports where we can actually help instead of having to tell most of
them "sorry, too few info, can't help" right away.
Those who don't care enough to fill out the description probably won't
care enough to create a BZ account in the first place. If there are
trolls who would put nonsense into the description or worse, well those
could do that
Re: ABRT unusable again
On Fri, 2010-02-12 at 10:42 +0100, Till Maas wrote: > 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. I guess the normal all-in-one dialog is simple enough that it can be kept as an option. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: intent to retire: kudzu
On Tue, 2010-04-13 at 16:45 -0400, Bill Nottingham wrote: > Bill Nottingham (nott...@redhat.com) said: > > I'd like to retire kudzu for F-13. > > > > Why? > > - There are places where it almost certainly does not work with current > > kernels > > - It's so deprecated that one of its replacements (HAL) has since been > > frozen and deprecated > > - Given that, its upstream is very dead > > > > However, it is still being required by two programs: > > - hwbrowser > > - fwfstab > > > > If someone wants to keep it limping along for thsese two programs I can > > orphan it. But I'd really rather just retire it. > > I just noticed I hadn't actually done this yet. I've retired it for > F-14/rawhide; it can remain in F-13, although it's unlikely to see any > useful updates there. I've retired hwbrowser in Rawhide/F-13 as well, it doesn't make sense to keep it around as it can't handle much of the the new hardware, i.e. anything kudzu doesn't know. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote: > In either case, as per the discussion at > http://lists.fedoraproject.org/pipermail/devel/2011-October/157712.html > I plan to provide the 1.2.x libpng shared library (and only the library, > not its devel support files) in a libpng-compat subpackage for the time > being. So existing programs that depend on 1.2.x will continue to work, > but it won't be possible to rebuild a package that has source-level > dependencies on 1.2.x until those are fixed. I think this is enough > to avoid needing a special build tag for staging the rebuilds. Any reason why the compat package ships the libpng-1.2.pc pkg-config file? This made one of my packages use 1.5 headers, then later on attempt to link to libpng12.so which failed. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upgrading libpng: shall we move to 1.4.x or 1.5.x?
On Wed, 2011-11-09 at 10:42 -0500, Tom Lane wrote: > Nils Philippsen writes: > > On Fri, 2011-11-04 at 13:12 -0400, Tom Lane wrote: > >> I plan to provide the 1.2.x libpng shared library (and only the library, > >> not its devel support files) in a libpng-compat subpackage for the time > >> being. > > > Any reason why the compat package ships the libpng-1.2.pc pkg-config > > file? > > Yeah: I tried it without first, and found that I couldn't rebuild > anything. There are boatloads of packages that have pkgconfig(libpng12) > as an RPM-visible dependency, so if the compat package doesn't supply > it, those packages won't install and you can't rebuild any of their > dependencies. I have no idea why it was considered a good thing for RPM > to track this type of dependency, but it does. Yuck :-/. > > This made one of my packages use 1.5 headers, then later on > > attempt to link to libpng12.so which failed. > > I doubt that's coming from the libpng12 pkgconfig; more likely, you have > some other package you're depending on that needs to be rebuilt first, > because its pkgconfig file currently says to use -lpng12 in link commands. Not really, I should have described it in more detail: the package specifically asked pkg-config for libpng12 -- and since it exists, it went building happily (with the 1.5 headers, from -devel) and only failed when trying to link -lpng12. I'd have liked it to fail early on ;-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Announcing the release of Fedora 16.
On Wed, 2011-11-16 at 10:23 +0100, Gerd Hoffmann wrote: > On 11/15/11 18:23, Andre Robatino wrote: > > Gerd Hoffmann wrote: > > > >> For developers like me which have a F16 repo for mock builds anyway it > >> is quite useful though. A large fraction of the stuff in Packages/ is > >> on my disk already, and with a jigdo I could save quite a bit on > >> bandwidth and download time over my not-exactly-fast internet link ... > > > > Rsync should save almost exactly the same amount of bandwidth, since due > > to the way its algorithm works it will avoid downloading unchanged > > packages and download changed packages in full, just like jigdo. In > > addition you don't have to download a jigdo template file. > > Hmm? How will rsync compose me a .iso out of a bunch of rpms? I take it that Andrea meant to rsync the new iso over the old one (or a copy of it). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rethinking proventester and critpath
On Mon, 2011-11-21 at 10:32 -0800, Adam Williamson wrote: > red_alert (sandro mathys): critpath packages should have detailed test plans Hm. The list of (implicitly labeled) critpath packages seems to have proliferated recently: a few days ago I submitted an update for sane-backends and then found out that it's on critpath, probably by way of critical-path-gnome -> control-center -> colord -> sane-backends-libs. On the one hand it would probably be a good idea to notify maintainers of such packages being implicitly pulled in (in this case when BR: colord-devel was added to control-center). On the other hand, sane-backends is a particularly nasty case and a detailed test plan would probably start with this: 0. Have a lot of scanners handy, or at least models affected by the changes. Not even I get past that point in most cases: I have one USB scanner in the office, and two rather ancient SCSI models at home. The only thing I can meaningfully test is these models/their drivers and the HW-independent parts of the package, and I don't expect more from the testers. With the package being critpath now, I fear that updates for sane-backends might never see the light of day, depending on the HW affected, unless Bruno's proposal (two weeks of wait for critpath without needed and no negative karma) or enough (proven)testers are content with only cursory testing :-/. Don't get me wrong: I'd really like sane-backends to get as much testing as possible before turning updates loose on the unsuspecting public. I just don't see how it can be done right at the moment. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changing kernel API / Breaking VirtualBox - update criteria violation?
On Mon, 2011-11-21 at 21:46 +0100, Reindl Harald wrote: > > Am 21.11.2011 21:32, schrieb Till Maas: > > Hi, > > > > a recent kernel update[0] broke Fedora's ability to be a VirtualBox > > host, because asm/amd_iommu.h was removed. The removal of the file was > > noticed during testing, but it seems nobody noticed that this affects > > VirtualBox. Is this kind of change sanctioned by the > > current update criteria? > > virtualbox is not part of fedora > and vmware is running great after some changes of version.checks > but vmware is also not part of fedora > > better breaking some non-distribution-stuff than as happened with > F14 that current intel machiens with sandy-bridge was not supportted > and forced eople with new hardware way too early to F15/systemd This is a non-argument: kernels 2.6.40.x/3.x broke dual head/xrandr[1] and WLAN[1] for me (on Intel hardware, FWIW). Nils [1]: https://bugzilla.redhat.com/show_bug.cgi?id=731296 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=732592 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rethinking proventester and critpath
On Tue, 2011-11-22 at 07:42 -0700, Ken Dreyer wrote: > On Tue, Nov 22, 2011 at 6:06 AM, Nils Philippsen wrote: > > Hm. The list of (implicitly labeled) critpath packages seems to have > > proliferated recently > > Why not impose a self-restriction on the number of critpath packages? > Make a rule like "The ratio of proventesters to critpath packages must > be x or higher". When the critpath numbers start creeping up, drop a > few other packages from critpath. This will help focus testing > efforts, and allow it to expand along with the growth of the > community. But that wouldn't really help, would it? I assume packages are explicitly labeled critpath for a reason: if they break, the system might not boot up, or users might not be able to log in (or several other reasons). I think the current system is a bit too simplistic when it comes to the packages upon which critpath components depend, however. For instance (picking this example because it affects me), I don't think that logging in should fail because of problems the scanner library may have. Or because (drawing examples from a hat) the desktop background can't be set, or there's an issue with the camera in your laptop. Yet, by way of simply following package dependencies, we do as if that were the case. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: epel 6 fedpkg build or koji scratch builds failing — I'm stumped
On Thu, 2011-11-24 at 17:26 +0100, Jim Meyering wrote:
> config.h:
> rm -f $@ $@-t;
> \
I'd rather not remove the target right at the beginning...
> { \
> echo '/* text added by Makefile target config.h */'; \
> echo '#define PPTP_LINUX_VERSION "$(VERSION)$(RELEASE)"'; \
> echo '#define PPPD_BINARY "$(PPPD)"'; \
> echo '#define IP_BINARY "$(IP)"'; \
> } > $@-t && chmod a-w $@-t && mv $@-t $@
... shouldn't a "mv -f ..." do the trick here?
Non-destructiveness and all that.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Heads-up: GIMP 2.7/2.8 in Rawhide, license change to (L)GPLv3+
Hi, I just finished with the Fedora 17 feature page for GIMP 2.8[1] and built gimp-2.7.4 into Rawhide. GIMP changed its licensing to GPLv3+ (app, included plugins) and LGPLv3+ (libraries) from the 2.7 development versions on. I've checked dependent packages and found that all are listed with compatible licenses in their spec files (CeCill v2, GPLv2+, GPLv3+, Public Domain). One minor licensing issues was introduced with this change, namely with poppler, used for importing PDFs and GPLv2 only. For the moment, GIMP packages from 2.7.x on won't use poppler, but the PostScript plugin for importing PDFs. This is a workaround until the next stable version poppler 0.20 which will be based off xpdf-3.03 (or later), thusly GPLv2/GPLv3 dual-licensed and compatible again. While APIs used by external plugins should be backwards-compatible, I'll rebuild packages using GIMP libraries (i.e. having GIMP plugins) against the current (not yet stable) version 2.7.4 and against the stable version when it's there, just to be on the safe side. These are the affected (source) packages: GREYCstoration: deebs gimp-fourier-plugin: fabiand gimp-lqr-plugin: slankes gimp-resynthesizer: ewan gimpfx-foundry: rvinyard gutenprint: twaugh - jpopelka mathmap: rnorwood ufraw: nphilipp xsane: nphilipp I plan to do the first round of rebuilds tomorrow, so if there's any reason why I shouldn't rebuild one of these, or you want to rebuild a package by yourself, speak up ;-). Nils [1]: https://fedoraproject.org/wiki/Features/GIMP_2.8 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads-up: GIMP 2.7/2.8 in Rawhide, license change to (L)GPLv3+
On Fri, 2011-12-16 at 13:40 +0200, Nicu Buculei wrote: > On 12/16/2011 12:09 PM, Luya Tshimbalanga wrote: > > Quoting Nils Philippsen wrote: > > > >> > >> GREYCstoration: deebs > > > > > > GREYstoration[1]is dead and superseded by GMIC[2] awhile ago. That package > > should be retired and replaced. > > Unfortunately G'MIC is an usability nightmare, an app inside the app, > duplicating in a crammed interface a lot of existing GIMP functions, > instead of GREYCStoration simple filter for noise reduction. I've patched GREYCstoration (it was FTBFS previously since we bumped libpng) so it shouldn't be an issue for a while (as long as someone maintains it). Might be some work though when GIMP cuts off legacy APIs (e.g. for high bit depths). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-4.7.0-0.1.fc17
On Sat, 2011-12-31 at 12:56 +0100, Jakub Jelinek wrote: > Hi! > > As part of preparations to switch GCC in F17 to GCC 4.7.0, I've performed > a test mass rebuild of rawhide (December 23th package list) using > gcc-4.7.0-0.1.fc17 on x86_64, and for those packages that failed also > rebuilt the same package with gcc-4.6.2-1.fc16 to quickly remove from the > list packages that fail for non-gcc related reasons. > Out of the 11270 packages I've built, 10056 packages built fine with > gcc-4.7.0-0.1.fc17 and 845 packages failed to build also with > gcc-4.6.2-1.fc16, so I'm ignoring those from any analysis. I've attached a list of packages and (co)maintainers, to easily find if one of your packages is affected or not. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 3Depict: mycae 4ti2: tremble activemq-cpp: stevetraylen adanaxisgpl: jwrdegoede alliance: chitlesh - chitlesh,tnorth alure: guidograzioli - julian anthy: tagoh aplus-fsf: s4504kr apt: athimm - pmatilai aqsis: kwizart - pmachata aria2: sundaram armacycles-ad: limb arpage: verdurin asc: jwrdegoede audacious-plugins: mschwendt - atkac aunit: landgraf avr-gcc: tnorth - ndim,trondd bangarang: jreznik barry: gnat - gnat bes: orion - pertusus bibletime: deji - deji binutils: nickc - aoliva,jakub,jankratochvil,nickc blahtexml: jasper blender: s4504kr - kwizart,roma blobby: sundaram - ankursinha bluez: hadess - dwmw2 boolstuff: konradm - pertusus boost141: robert boost: bkoz - denisarnaud,pmachata bowtie: verdurin btanks: bruno - bruno cairo-java: orphan calf: oget cantor: than - jreznik,kkofler,ltinkl,rdieter,rnovacek cegui: jwrdegoede - bruno,mpreisle ceph: josef - boodle,jdieter,ke4qqq,steve,stingray clamav: ensc - nb(?) ClanLib: jwrdegoede clisp: jjames - green,jjames clucene: deji - jreznik(?),rdieter cmake: orion - jreznik,pertusus,rdieter codeblocks: sharkcz code-editor: ilyes Coin2: corsepiu conexus: rvinyard coot: timfenn cppad: bradbell cppcheck: jussilehtola - scop CriticalMass: jwrdegoede cryptkeeper: hicham cryptopp: sundaram - nucleo CTL: kwizart curblaster: limb cyphesis: wart - bruno dbus-cxx: rvinyard dcmtk: mrceresa dopewars: jussilehtola eigen2: rdieter - kkofler elfutils: roland - aoliva,fche(?),jakub,mjw,pmachata ember: bruno - bruno,wart esteid-browser-plugin: kalev ETL: lkundrak fastx_toolkit: verdurin fatrat: jvcelak faust: oget fawkes: timn - rmattes festival: davidz - ajax,alexl,caillon,caolanm,hadess,johnp,jrb,mattdm,mbarnes,mclasen,rhughes,rnorwood,rstrode,ssp,timn Field3D: hobbes1069 fife: cassmodiah - bruno filezilla: kwizart florist: landgraf flush: avienda fmt-ptrn: mikep freeciv: limb freefem++: rathann - itamarjp freenx-client: athimm frepple: jdetaeye frysk: cagney - kasal,mjw,pmuldoon fusecompress_offline1: toshio - lkundrak,lmacken fwbuilder: ertzing gccxml: ellert gdisk: terjeros gearbox: rmattes gearmand: derks - derks gfan: konradm - jjames gforth: adrian gigolo: kevin ginac: rakesh - rakesh git: chrisw - atkac(?),jbowes,npajkovs(?),tmz givaro: mycae - jjames glest: bruno glob2: bruno - cheese(?) glom: hguemar gnash: hicham - jreznik,pertusus gnatcoll: landgraf gnome-commander: mtasaka gnomeradio: rathann - itamarjp gnome-schedule: sundaram gnome-subtitles: belegdol gnuplot: pschiffe gnuradio: mmahut - jskarvad gnustep-back: s4504kr gnustep-base: s4504kr gnustep-examples: s4504kr gnustep-gui: s4504kr goldendict: helloworld1 gorm: s4504kr gource: siddhesh gprbuild: landgraf grantlee: rdieter - rdieter,than grass: devrim - devrim(?),oliver(?),pertusus,rezso(?),volter grub2: pjones - ausil,pjones gsmartcontrol: brouhaha gst123: siddhesh gtkmathview: uwog guimup: th0br0 gwenhywfar: notting hamster-applet: maxx hercstudio: sharkcz hotssh: walters hugin: bpostle - denisarnaud icc_examin: kwizart ice: hguemar icu: erack - ajax,alexl,caillon,davidz,erack,hadess,johnp,jrb,mbarnes,mclasen,rhughes,rnorwood,rstrode,ssp incron: ruben inkscape: lkundrak - duffy,lkundrak Inventor: corsepiu isomd5sum: anaconda-maint - clumens,rvykydal,skvidal(?) iwhd: meyering - clalance,zaitcev jaffl: mmorsi java-1.6.0-openjdk: dbhole - dbhole,jvanek,omajid java-1.7.0-openjdk: dbhole - jvanek,omajid jffi: mmorsi jnr-ffi: mmorsi k3d: corsepiu kaffeine: kkofler - mef,rdieter kaya: s4504kr kdebase-workspace: than - jreznik,kkofler,ltinkl,nucleo,rdieter,rnovacek,rrix,svahl kdegames: than - jreznik,kkofler,ltinkl,rdieter,rnovacek,rrix,svahl kdelibs3: than - kkofler,ltinkl,rdieter kdelibs: than - jreznik,kkofler,ltinkl,rdieter,rnovacek,rrix kdemultimedia: than - jreznik,kkofler,ltinkl,rdieter,rnovacek kdenetwork: than - jreznik,kkofler,ltinkl,nucleo,rdieter,rnovacek kdepim3: rdieter - ovasik,rnovacek kdepim: than - jreznik,kkofler,ltinkl,rdieter,r
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
For the sake of completeness: On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > after a yum upgrade you can verify that the most important > things are fine BEFORE reboot (bootloader-config, > package-cleanup --problems, ), optimize/correct things > you know are not fine after the upgrade (active services > after transition to systemd as example) and then you reboot > ONCE in a clean starting system instead a boot in the blue ... as can be done on VC2 after updating with anaconda. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: > > Am 26.01.2012 14:08, schrieb Nils Philippsen: > > For the sake of completeness: > > > > On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > >> after a yum upgrade you can verify that the most important > >> things are fine BEFORE reboot (bootloader-config, > >> package-cleanup --problems, ), optimize/correct things > >> you know are not fine after the upgrade (active services > >> after transition to systemd as example) and then you reboot > >> ONCE in a clean starting system instead a boot in the blue > > > > ... as can be done on VC2 after updating with anaconda > > while the system and services are running? > show me how you will do this! This not what I wrote. > you are missing the point that "yum distro-sync" is running > while the system is up and can be distributed after testing > AUTOMATICALLY to 10,20,30,100 machines followed by a 30 > seconds reboot I am well aware of the differences between doing an upgrade with anaconda and doing it with yum in a live system. I've done enough of the latter to at least shut down critical processes (e.g. MTA, database server software) before doing a yum upgrade, because stuff tends to hick-up if you pull the rug from underneath it (e.g. if files get moved around, renamed, dynamically loaded modules are replaced by newer versions with new API, data formats change, ...). What you described sounds too non-deterministic for my taste. Granted, you reduce the amount of planned downtime with this scheme, but you trade that in for a heightened risk of unplanned downtime should stuff break in the process. And testing only buys you a limited sense of security here. > shutdown the VM, insert the ISO and boot anaconda takes much > longer as the whole upgrade via yum - our machines needed > between 4 and 6 minutes each server for the whole F14->F15 > upgrade, so in an hour you have all machines updated with > nearly zero downtime If all goes well. The move of pretty much every basic user space building block from / to /usr has enough potentially disruptive qualities that I'd rather have the patient not be the surgeon in this round of open heart surgery. In less colorful words, anaconda is self-sufficient, it brings everything it needs with it, i.e. its libc, loader and so forth won't magically move to a different place so the installer won't suddenly break because stuff it uses is removed, or in a different place or format than expected. So if something breaks badly during the upgrade I have a working shell and a small set of essential tools that continue to work regardless, with which I can fix things. This gives me enough warm fuzzy feelings that I'll happily spend the little more planned downtime on it this time. > a change which damages this capabilities has to be fixed For the situation we're discussing, I'll take safety over speed any time. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 15:49 +0100, Reindl Harald wrote: > > Am 26.01.2012 15:07, schrieb Nils Philippsen: > > On Thu, 2012-01-26 at 14:19 +0100, Reindl Harald wrote: > >> > >> Am 26.01.2012 14:08, schrieb Nils Philippsen: > >>> For the sake of completeness: > >>> > >>> On Thu, 2012-01-26 at 03:22 +0100, Reindl Harald wrote: > >>>> after a yum upgrade you can verify that the most important > >>>> things are fine BEFORE reboot (bootloader-config, > >>>> package-cleanup --problems, ), optimize/correct things > >>>> you know are not fine after the upgrade (active services > >>>> after transition to systemd as example) and then you reboot > >>>> ONCE in a clean starting system instead a boot in the blue > >>> > >>> ... as can be done on VC2 after updating with anaconda > >> > >> while the system and services are running? > >> show me how you will do this! > > > > This not what I wrote. > > you did - you wrote "as can be done" Then, this is not what you wrote :-). I was referring to what I quoted above: "after a yum upgrade you can verify that the most important things are fine BEFORE reboot..., optimize/correct things... and then you reboot..." Nowhere in the quoted text did you mention services that keep running, which I grant is a huge difference between upgrades done in yum and anaconda. Whether keeping services running while the world changes around them is a good idea, however, I doubt it. > > I am well aware of the differences between doing an upgrade with > > anaconda and doing it with yum in a live system. I've done enough of the > > latter to at least shut down critical processes (e.g. MTA, database > > server software) before doing a yum upgrade, because stuff tends to > > hick-up if you pull the rug from underneath it (e.g. if files get moved > > around, renamed, dynamically loaded modules are replaced by newer > > versions with new API, data formats change, ...). What you described > > sounds too non-deterministic for my taste. Granted, you reduce the > > amount of planned downtime with this scheme, but you trade that in for a > > heightened risk of unplanned downtime should stuff break in the process. > > And testing only buys you a limited sense of security here. > > we build critical server packages usually on our own infrastructure > and do version changes sepearted from the dist-upgrade as also > the automatic restart on update is removed from all packages > > as example we had MySQL 5.5 on F13 > > there is no limited sense of security > each machine has a clone for backup-reasons > this clones are updated first > so after that i know the exactly behavior In a strict sense, no, you don't. Assuming that your servers have users that keep on using them while they're being upgraded (everything else is pointless), their actions are a big unknown -- you can't know ahead of time what they'll do during the machine is upgraded, and this may trigger behavior in the running software which you did not test before. > there is ALWAYS the internal build/repo-cache server between > and that is why anaconda is unuseable and it would be > a shame damage this capabilities First, upgrading with yum never was fully supported[1], probably to cater for situations like this one. Second, as you described it above it seems you're not running Fedora, but your own forked off distribution (a "Fedora Remix"[2] if you want to give it a nice-sounding moniker). You could even forego UsrMove in your fork -- though that'd be a lot of work: right now in F16/x86_64, there are 261 affected packages, so you probably don't want to do that. Anyway, I wonder what the drama is all about (and this goes to larger parts of the audience)... I think a lot of this is based on misunderstandings and conjecture: You already need to do certain preparatory steps before doing a yum upgrade (e.g. install repository GPG keys, disable and remove SELinux policy from F-13 to F-14). This time you have additional steps[3] in order to run a script which moves stuff about, preparing the system in a way which can't sanely be done in RPM/YUM (re headless: AIUI this doesn't really need physical presence in front of the box, and regardless: a serial console or similar is a good thing to have). Then you do the upgrade as usual. What's the big deal here again? Nils [1]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Upgrading_Fedora_using_yum_directly [2]: https://fedoraproject.org/wiki/Remix [3]: http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17 -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 14:51 +, Peter Robinson wrote: > On Thu, Jan 26, 2012 at 2:43 PM, Harald Hoyer wrote: > > Am 25.01.2012 23:48, schrieb Peter Robinson: > >> Hi All, > >> > >> So I saw a rpm update and a number of other builds today when dealing > >> with various packaging bits. Checking the update [1] and reading the > >> attached bug [2] I was a little shocked to find that "yum upgrade" > >> between releases would be explicitly broken due to this feature. > > > > Not really true. "yum upgrade" will be supported, but it needs a little help > > with a special initramfs and an additiona > > So why isn't it documented as such? It is, the feature page mentions the script, the tentative preparation steps on the yum upgrade page describe the details. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UsrMove feature breaking "yum upgrade" upgrades from older releases to F17?
On Thu, 2012-01-26 at 23:53 +0100, Kevin Kofler wrote: > Toshio Kuratomi wrote: > > https://fedorahosted.org/fpc/ticket/118#comment:7 > > Well, IMHO if this is not safe to do in a %pretrans, it is not safe to do at > all. You seem to imply doing things in %pretrans is somehow safer than somewhere else. I don't think so -- as Panu said: "The whole %pretrans thing is a scary hack that's best seen as a last resort to do the minimal required tweak that just cannot be done elsewhere..." > I don't understand why we absolutely HAVE to change directories to symlinks > when we KNOW RPM doesn't support this, and that in directories as essential > as /bin etc. We could wait until you have convinced people, maintainers and users alike, to fix their packages and scripts all in one go over to using the new paths, so we get by without compat symlinks. But I don't think we want to wait for that. Agreed, it'd be a whole lot nicer if RPM could handle symlink <-> non-symlink transitions without crutches like this one, but right now it can't. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote: > - append “selinux=0” for now, because the relabeling in a converted F16 > system > does not seem to work properly at this moment Have you checked "enforcing=0" instead? If this worked, you'd not need to relabel the whole system, but only the parts affected by the move. Or so I'd like to believe ;-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? -> about the future
On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: > Let me put it this way, then: Fedora is released on a six month cycle, > which is far faster than is usually considered desirable for server > usage. It has a 13 month lifetime, which is far shorter than is usually > considered desirable for server usage. Its key values and goals are > assuredly not compatible with typical server usage - e.g. "First - We > believe in the power of innovation and showing off new work in our > releases. Since we release twice a year, you never have to wait long to > see the latest and greatest software, while there are other Linux > products derived from Fedora you can use for long-term stability. We > always keep Fedora moving forward so that you can see the future first." > There are numerous practical policies derived from these values which > are clearly not optimal for server usage, such as the short freeze > times, relatively low barrier of entry to disruptive features, and QA > focus on installation and basic desktop use (we do virtually no QA on > any kind of server usage). Finally, there are *several* Linux > distributions available which have none of the above 'shortcomings' (so > far as server usage is concerned). I'd say the same 'shortcomings' also hurt the end user case. The non-technical people I deal with loathe how we often introduce new features and break stuff (or just their way of doing things) in the process, even in updates -- I've stopped counting the "Oh, updates. I wonder what you guys have broken now."-style comments by my wife. To me, Fedora is much better suited to be run on servers than by end users -- admins usually can help themselves in these situations. Don't take this as being against the slew of features Fedora introduces: personally I'm much in favor of systemd, the /usr move, pulseaudio and all that stuff -- there's no point in just treading water and being on the forefront of things is where Fedora is supposed to be. But let's not kid ourselves into thinking that with a life-cycle of only 13 months and the amount of change we introduce in each new release (especially on the desktop) we're somehow catering to end users who don't have a technically skilled spouse, relative or friend in the background to help if things don't work as expected. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CGAL license change to (L)GPLv3+
On Mon, 2012-02-13 at 15:29 +0100, Laurent Rineau wrote: > Le mardi 07 février 2012 14:21:53 Laurent Rineau a écrit : > > From release 4.0, the CGAL libraries will be released under LGPLv3+ for the > > foundations, and GPLv3+ for the high level packages (instead of LGPLv2 and > > QPL respectively). > > In the CGAL.spec file, I mentionned "License: LGPLv3+ and GPLv3+". Could not > I > simplify that into: "License: GPLv3+"? You should probably ask this question on the fedora-legal mailing list (on Cc). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? -> about the future
On Mon, 2012-02-13 at 09:28 -0800, Adam Williamson wrote: > On Mon, 2012-02-13 at 14:47 +0100, Nils Philippsen wrote: > > On Fri, 2012-02-10 at 11:08 -0800, Adam Williamson wrote: > > > Let me put it this way, then: Fedora is released on a six month cycle, > > > which is far faster than is usually considered desirable for server > > > usage. It has a 13 month lifetime, which is far shorter than is usually > > > considered desirable for server usage. Its key values and goals are > > > assuredly not compatible with typical server usage - e.g. "First - We > > > believe in the power of innovation and showing off new work in our > > > releases. Since we release twice a year, you never have to wait long to > > > see the latest and greatest software, while there are other Linux > > > products derived from Fedora you can use for long-term stability. We > > > always keep Fedora moving forward so that you can see the future first." > > > There are numerous practical policies derived from these values which > > > are clearly not optimal for server usage, such as the short freeze > > > times, relatively low barrier of entry to disruptive features, and QA > > > focus on installation and basic desktop use (we do virtually no QA on > > > any kind of server usage). Finally, there are *several* Linux > > > distributions available which have none of the above 'shortcomings' (so > > > far as server usage is concerned). > > > > I'd say the same 'shortcomings' also hurt the end user case. The > > non-technical people I deal with loathe how we often introduce new > > features and break stuff (or just their way of doing things) in the > > process, even in updates -- I've stopped counting the "Oh, updates. I > > wonder what you guys have broken now."-style comments by my wife. To me, > > Fedora is much better suited to be run on servers than by end users -- > > admins usually can help themselves in these situations. > > > > Don't take this as being against the slew of features Fedora introduces: > > personally I'm much in favor of systemd, the /usr move, pulseaudio and > > all that stuff -- there's no point in just treading water and being on > > the forefront of things is where Fedora is supposed to be. But let's not > > kid ourselves into thinking that with a life-cycle of only 13 months and > > the amount of change we introduce in each new release (especially on the > > desktop) we're somehow catering to end users who don't have a > > technically skilled spouse, relative or friend in the background to help > > if things don't work as expected. > > That also, at least arguably, isn't Fedora's aim (if it was, we'd be > doing a terrible job of it, I agree). To cite the Board again: > > https://fedoraproject.org/wiki/User_base > > "Voluntary Linux consumer > Computer-friendly > Likely collaborator > General productivity user" > > Those four - especially 'computer-friendly' and 'likely collaborator' - > don't scream 'end user' to me. My personal take has always been that > Fedora is not the friendly desktop operating system of today, but a > *prototype* of the friendly desktop operating system of tomorrow. A > constantly moving prototype - so it never sits still and becomes the > friendly desktop operating system of today. :) Of course :-). In the light of that however, I don't really understand the "Fedora is not for servers" arguments brought forth every so often... Fedora is not well-suited if what you want is longevity, full stop. Disregarding that point, Fedora on a server is quite hassle-free :-). Nils > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove? -> about the future
On Thu, 2012-02-16 at 17:49 +, "Jóhann B. Guðmundsson" wrote: > On 02/16/2012 05:33 PM, "Jóhann B. Guðmundsson" wrote: > >> > > > > complete -r if memory serves me correct then again I'm getting old and > > fragile... > > "set disable-completion on" into /etc/inputrc or ~/.inputr to disable it > across logout/reboots This disables normal non-programmable tab-completion for me. Also, if you want the (other) default settings, you need to "$include /etc/inputrc" on the first line of ~/.inputrc. It would really help if we shipped documentation for this file :-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
inputrc, was: /usrmove? -> about the future
On Fri, 2012-02-17 at 16:23 +, John5342 wrote: > On Fri, Feb 17, 2012 at 13:54, Nils Philippsen wrote: > > This disables normal non-programmable tab-completion for me. > > > > Also, if you want the (other) default settings, you need to > > "$include /etc/inputrc" on the first line of ~/.inputrc. It would really > > help if we shipped documentation for this file :-). > > man readline. man bash has a bit of information from a bash perspective too. *slowly extracts foot from mouth* I wonder if we could make that a bit more clear if people as slow on the uptake like me look for it -- to me it's only obvious that inputrc is related to readline now you told me, as the inputrc file is owned by the setup package, not readline. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 2012-02-20 at 13:51 +0100, Lennart Poettering wrote: > This isn't really a "new" exception for me. There's a ton of files > that > are not strictly arch dependent in bin, lib, libexec. Shell scripts, > Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB > symlinks, Java files, Ruby files, yadda yadda yadda. Not that it matters much, but just before somebody gets the wrong ideas: pkg-config files are arch-dependent because of multilib. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: User session printing
On Mon, 2012-03-05 at 12:02 -0500, Bill Nottingham wrote: > Tim Waugh (twa...@redhat.com) said: > > For things like cloud printing, where the print server is a hosted > > service somewhere out in the Internet, I think the applications should > > be talking directly to it (via the print dialog). > > > > For a plain network printer, where the printer might not be able to > > accept the job while it's busy processing others, you might have to > > queue the job and retry it later. So if you are doing that as a user > > process, how should that work when you log out, and when the machine is > > restarted? > > It waits until you log in again. I wonder if that works with longer print jobs: - User: "I'll kick that one off before the weekend, it might take a while, so that I won't disturb others." - (User's) cupsd: queues the job in user's home, starts printing onto the printer. - User logs off after 15 pages of 300 are printed. - systemd kills off all processes in user session cgroup, including cupsd. - User: "Aiiieh!", heads off into the weekend as he has to catch a bus, forgets about it. - User returns after the weekend, logs in again, cupsd picks up the still queued print job from user's home, starts printing the remaining 285 pages. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Sat, 2012-03-03 at 15:46 -0800, Scott Doty wrote: > On 03/03/2012 03:22 PM, Miloslav Trmač wrote: > > On Sun, Mar 4, 2012 at 12:03 AM, Scott Doty wrote: > >> How about allowing all printer management of local printers (including > >> adding a network printer, as Linus& his daughter were dealing with) with > >> two factors: > >> > >> 1) user password > >> 2) physical access > >> > >> ...because PolKit already knows when the user is sitting at the console, > >> right? > > "Sitting at the console" is not equivalent to "unrestricted physical > > access" allowed, e.g. in any university computer lab. > > Agreed. Since we're talking two use case though -- home user and lab > user -- it would make sense to have another rpm that would be installed > to give the desired behavior to one of the cases (the other case being > the default). > > I'm not sure about the demographics of Fedora installations, but I would > suspect that most lab administrators will be more cognizant of what goes > into their lab machines. Thus, I suggest there be added a new package > to alter the behavior for lab machines (and similar use cases), > something like polkit-i-am-a-lab, or whichever. > > What do you think? I think that having RPM packages installed (or not) is not a suitable means for switching on and off certain (sets of) configuration. Beyond that (and I'm not through the thread completely, so forgive me if that's been stated elsewhere already), I think it'd be worthwhile to think about usage profiles like this which come with a set of configuration defaults tailored to a particular use case, overridable/extensible by the admin. We just shouldn't come up with some kind of OO-monster for which admins will hate us. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what means is defined in DSO /lib64/libz.so.1
On Tue, 2012-03-06 at 17:10 +, Sérgio Basto wrote: > Hi , I found this error > > /usr/bin/ld: > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../lib64/libgpac_static.a(base_encoding.o): > undefined reference to symbol 'deflate' > > /usr/bin/ld: note: 'deflate' is defined in DSO /lib64/libz.so.1 so try > adding it to the linker command > line > > /lib64/libz.so.1: could not read symbols: Invalid > operation > collect2: error: ld returned 1 exit status > > > Could someone help me , to understand what happens ? AIUI, it looks like the code you try to compile uses the deflate() function from libz, and doesn't link it directly (i.e. the "-lz" compiler option) but indirectly (i.e. links a library which uses libz). You need to explicitly link all libraries that you use, you may not depend on other libraries pulling these in. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what means is defined in DSO /lib64/libz.so.1
On Tue, 2012-03-06 at 18:21 +0100, Fabian Deutsch wrote: > Am Dienstag, den 06.03.2012, 17:10 + schrieb Sérgio Basto: > > Hi , I found this error > > > > /usr/bin/ld: > > /usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../../lib64/libgpac_static.a(base_encoding.o): > > undefined reference to symbol 'deflate' > > > > /usr/bin/ld: note: 'deflate' is defined in DSO /lib64/libz.so.1 so try > > adding it to the linker command > > line > > > > /lib64/libz.so.1: could not read symbols: Invalid > > operation > > collect2: error: ld returned 1 exit status > > DSO is something like an auto-symbol-resolver (so linking in libraries > that are used by other directly-linked libraries, google for with with > fedora). > DSO is deactivated on fedora, therefor you need to pass each library > required to the linker. "DSO" means "dynamic shared object" and is more or less just another word for "shared library". > In the above case you need to additionally pass -lz to the linked (e.g. > using LDLAGS=-lz), as suggested by gcc (which says: is defined in) Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Wed, 2010-11-17 at 14:50 -0500, Tom "spot" Callaway wrote:
> rpm %post and %postun scripts have been added for the following
> important pieces of GNOME3 technology: GSettings, gdk-pixbuf loaders,
> GTK3 modules, and GIO modules:
>
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GSettings_Schema
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#gdk-
> pixbuf_loaders
> https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#GTK.2B_modules
This scriptlet snippet seems to have suffered from a copy-paste mistake:
--- 8< ---
%postun
gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
%post
if [ $1 -eq 1 ] ; then
# For upgrades, the cache will be regenerated by the new package's %postun
gio-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
fi
--- >8 ---
I guess that the %post part should use "gtk-query-immodules-..." instead
of "gio-...".
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 02:52 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote: > > > > environment variables are normally inherited when forking/execing. We > > > want to make sure that only the process we actually start ourselves > > > parses and handles LISTEN_FDS. We want to avoid that if this daemon > > > might spawn some other process, it might get confused into handling > > > LISTEN_FDS, although that env var wasn't actually intended for it. > > > > > > And hence we say that LISTEN_PID should be verified first, and only if > > > it matches LISTEN_FDS should be handled. > > > > If you are mandating behavior in daemons, wouldn't it be simpler to > > mandate the daemon unsets LISTEN_FDS ? > > Yes, our reference implementation actually does that. But we didn't want > to rely on that, simply because handling the environ[] array is so messy, > since memory allocation is not clear and the whole thing is not > thread-safe. In many case environ[] should probably be considered a > read-only data structure during runtime. I beg to differ, at least if we're talking about languages where you are able to just let a single thread run (not sure about Java): Simply document that the daemon should read and unset LISTEN_FDS (using unsetenv() instead of messing with environ manually) while there is only a single thread. That is, if you really must use environment variables for passing that information... Others have mentioned it already: The environment is for information that is meant to be long-lived and shared between processes, it should be feasible to pass this information via a command line option instead. Even more so if handling of the environment is so messy. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: > > > This suggests to me that environment variables isn't the right way to do > > this. > > Environment variables are good for parameters that should be available to > > many > > processes. Command line parameters are better when the parameter is only > > meant > > for one specific process. I can see how looking up two environment > > variables > > may be a smaller patch than adding a parameter to the program's command > > line > > parser, but I still think it should be done with command line > > parameters. > > This is a valid point and we have pondered this for a while and in the > end decided to use environ[] instead of argv[], simply because this > allows us to use the same code for handling it in all daemons, while > handling --listen-fds=xxx in argv would work for some daemons, but not > for others. (i.e. some don't do long getopt, others do it with one dash > only). Also, quite a few projects (rsyslog for example) implement socket > handling in loadable modules, where we have no access to argv[] but do > have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't be rocket science. > > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the > > original daemon is restarted but its children live on, then later some > > descendant process may get the same PID as the original daemon, and may try > > to > > handle LISTEN_FDS. The risk may be low, but I always prefer a solution that > > is > > guaranteed to work over one that mostly works. > > Well, this is purely theoretical, since LISTEN_FDS should normally only > be set for daemons that can actually handle this and hence as long as > these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: > On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: > > > This suggests to me that environment variables isn't the right way to do > > this. > > Environment variables are good for parameters that should be available to > > many > > processes. Command line parameters are better when the parameter is only > > meant > > for one specific process. I can see how looking up two environment > > variables > > may be a smaller patch than adding a parameter to the program's command > > line > > parser, but I still think it should be done with command line > > parameters. > > This is a valid point and we have pondered this for a while and in the > end decided to use environ[] instead of argv[], simply because this > allows us to use the same code for handling it in all daemons, while > handling --listen-fds=xxx in argv would work for some daemons, but not > for others. (i.e. some don't do long getopt, others do it with one dash > only). Also, quite a few projects (rsyslog for example) implement socket > handling in loadable modules, where we have no access to argv[] but do > have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't rocket science. > > LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the > > original daemon is restarted but its children live on, then later some > > descendant process may get the same PID as the original daemon, and may try > > to > > handle LISTEN_FDS. The risk may be low, but I always prefer a solution that > > is > > guaranteed to work over one that mostly works. > > Well, this is purely theoretical, since LISTEN_FDS should normally only > be set for daemons that can actually handle this and hence as long as > these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2010-05-27 x86_64
On Mon, 2010-05-31 at 12:43 -0500, Matt Domsch wrote: > nphilipp: gegl,gtkimageview,ufraw these all built fine as scratch, probably affected by the segfaulting pkgconfig -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: webkitgtk abi bump
On Fri, 2010-07-02 at 10:36 -0400, Matthias Clasen wrote: > gimp-help-browser rebuilt gimp -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: concept of package "ownership"
On Sat, 2010-07-03 at 03:34 +0200, Kevin Kofler wrote: > Ralf Corsepius wrote: > > We need groups, with "grouped privileges/acls" etc. It's essentially > > what e.g. the "perl-sig" originally was meant to be. > > Yes, group ACLs are definitely needed, but in addition to that technical > feature, we also need to make sure that the SIG actually gets commit access > to ALL packages related to the SIG. ALL perl-* packages should be > committable to by the Perl SIG. That's what a SIG is for. And it'd have > prevented this whole "why were X and Y added as maintainers to my perl-* > packages" fiasco, it would just have been the SIG's decision to add the > people to the SIG and this should automatically give commit access to all > perl-* packages. > > Similarly, all packages using Qt should be committable to by the KDE SIG > etc. AIUI, a SIG are more people than those who actually work on related packages as maintainers, or are competent and responsible enough to not break things in the process of updating packages with which they're not familiar (otherwise they'd be (co-)maintainers, wouldn't they?). If we ever get group ACLs, I think we should have $SIG-packager groups, consisting of SIG members who fulfill the above, who get that kind of access. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 2010-07-07 at 16:29 -0400, Tom "spot" Callaway wrote:
> [nphilipp] gimp: 2:gimp-libs-2.6.9-5.fc14.x86_64
fixed in 2.6.10-2.fc14
> [nphilipp] xsane: xsane-common-0.997-8.fc14.x86_64
fixed in 0.997-9.fc14
> [nphilipp] extremetuxracer: extremetuxracer-common-0.4-3.fc12.noarch
> [nphilipp] ufraw: ufraw-common-0.17-1.fc14.x86_64
False positives, possibly tripped up by non-obvious use of RPM macros:
...
Requires: extremetuxracer-common = %{?epoch:%{epoch}:}%{version}-%{release}
...
...
%if %{with splitpackage}
Requires: ufraw-common = %{?epoch:%{epoch}:}%{version}-%{release}
...
%files %{?spkg:common} -f %{name}.lang
%defattr(-, root, root, -)
%doc COPYING README
...
Did you check spec files or generated binary RPMs? I guess checking the
latter would avoid most of the false positives.
Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
n...@redhat.com nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer: Deji Akingunola (fas: deji)
On Sat, 2014-07-26 at 11:17 -0600, Kevin Fenzi wrote: > The following packages are looking for a new point of contact on at > least one branch: > > babl > gegl I've taken these two. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gcc5 C++11 ABI rebuilds and FTBFS packages
On Mon, 2015-05-04 at 13:09 +0200, Kalev Lember wrote: > extremetuxracer: http://koji.fedoraproject.org/koji/taskinfo?taskID=9650861 > jack-audio-connection-kit: > http://koji.fedoraproject.org/koji/taskinfo?taskID=9651019 Fixed. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 23 mass rebuild
On Tue, 2015-06-16 at 22:58 -0500, Dennis Gilmore wrote: > the list of current failures can be found at > http://alt.fedoraproject.org/pub/alt/mass-rebuild/f23-failures.html If someone else happens to have their build fail on find-debuginfo.sh ...: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 1000 --dwz-max-die-limit 5000 /builddir/build/BUILD/gimp-help-2.8.2 RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.vrrhQp (%install) Bad exit status from /var/tmp/rpm-tmp.vrrhQp (%install) ... check if you install executable JPEG files into your buildroot: find-debuginfo.sh runs the file command on all executable files, and file-5.22-3.fc23 contains a bug causing it to exit with a non-zero exit code on certain JPEG files, cf.: https://bugzilla.redhat.com/show_bug.cgi?id=1201630 Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unexpected find of the week: Pagure & Dist Git Watch List
Hi everybody! We were discussing getting CCs for bugs of components which you no longer maintain over in #fedora-admin, and I figured that Pagure should be able to tell me what components I'm watching, just in case I wanted to remove myself preemptively, before my inbox gets clogged up. Turns out that the "Pagure Watch List" was news to other people, too, so here are the links in case you missed the memo, too! ;) - Dist Git: https://src.fedoraproject.org/dashboard/watchlist - Pagure.io: https://pagure.io/dashboard/watchlist Ciao, Nils -- Nils Philippsen"Those who would give up Essential Liberty to Software Engineer purchase a little Temporary Safety, deserve neither Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D old: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: systemd: Can Type=simple be used with a wrapper script?
On Mon, 2012-04-16 at 10:24 -0500, Richard Shaw wrote: > I'm working on a package that uses a wrapper script to start the > daemon, so as the subject says: > > Can I use Type=simple if the daemon uses a wrapper script or am I > stuck with Type=forking? AIUI yes, but you have to exec the real binary, i.e. the PID of your daemon mustn't change lest systemd thinks your daemon died. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: changelog in spec file, was Re: Stop the git abuse
On Sun, 2012-05-20 at 20:02 -0400, Paul Wouters wrote: > On Fri, 18 May 2012, Richard W.M. Jones wrote: > > > On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote: > >> And definitvely, for me, (and probably only for me), git is really > >> not a good tool for spec maintenance. > > > > Not duplicating the changelog would help. There's little reason to > > have a changelog in git which is then manually copied into %changelog. > > Agreed. changelog and version field conflicts are 90% of my cherry-pick > conflicts. > > I would be in favour of no longer maintaining a changelog in the spec file Maybe I'm a bit late, but with all the schemes I've seen in this (sub-)thread that generate %changelog from SCM commits, how would I go about amending old changelog entries? Also I don't see how NVR for changelog entries can be safely determined from the SCM commits -- often I build from the commit in which I bump the release, but sometimes I make mistakes which I then need to fix and the build is from 3 commits later -- the the guidelines are quite adamant that you either need to merge all changelog entries leading to a build into one, or that each entry is labeled correctly. In my opinion, the cleaning out of mass-rebuild etc. entries for other branches is a bit of optimization in the wrong place -- who looks at the RPM changelog and can't put these things into proper perspective? The changes relevant for end users are what you write when you submit an update to bodhi. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
