Re: Looking for testers: RPM 4.9 alpha
On Sun, 28 Nov 2010, Simo Sorce wrote:
On Sun, 28 Nov 2010 12:15:52 +0200 (EET)
Panu Matilainen pmati...@laiskiainen.org wrote:
On Sun, 28 Nov 2010, Kevin Kofler wrote:
Panu Matilainen wrote:
The draft release notes are at http://rpm.org/wiki/Releases/4.9.0
1. This change:
| Packages with no files can now omit the %files section and still
have | packages generated.
is going to make it a PITA to conditionalize the building of
subpackages, and it's going to break several existing KDE specfiles
very badly (and with no warning!): RPM will silently generate empty
subpackages where none is wanted.
More precisely, when we wanted to conditionalize or comment out the
creation of a subpackage (e.g. in kde-l10n for languages which are
currently not available), what we did so far was to %if out only
the %files section for the subpackage, not %package or things like
%post, and this would reliably omit the subpackage. Now we'll have
to %if out ALL sections referring to the subpackage: %package to
prevent the subpackage from being built, and all other sections
referring to it because they'll error out if the %package is not
there.
This change can be reconsidered.
Wouldn't it be better instead to create a specific directive to disable
unwanted subpackages ?
Something like:
%suppress subpackagename
This would make it clear what the author of the RPMs wants to do w/o
relying on hacks like suppressing the %files section.
Bonus if it checks the suppressed package %files for installed files
that need to be skipped even if not packaged so as to not error out.
Not a bad idea at all, although I'd guess a better syntax would be a
boolean enable/disable tag similar to AutoReq etc. That'd allow nice
integration with build conditionals, such as
%bcond_without foo
...
%package foo
BuildRequires: bar-devel
Summary: ...
BuildPkg: %{with foo}
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
old_testing_critpath notifications
Hello, Few days ago I started to get very usefull notifications that my critical package, mingetty-1.08-6.fc13, `has been in 'testing' status for over 2 weeks, and has yet to be approved.' I doubt such mails help me as the package maintainer, because according current Updates policy https://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages, I can only wait to some (proven) testers to test my package. I think better place to send such allerts is proven-testers mailing list / alias (does not exist amazingly) or test-annou...@lists.fedoraproject.org mailing list. I'd like to request persons reposnsible for forcing and implementing Update Policy and bodhi notification system to re-eavaluate current configuration in spot of this concerns and to make package update process more friendly for all involved people. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning licq
On 11/27/2010 12:15 AM, François Cami wrote: On Fri, Nov 26, 2010 at 1:51 PM, Jiri Moskovcakjmosk...@redhat.com wrote: I'm no longer interested in this package, so I'm going to orphan in it. IMHO there is not much users anyway, so how about removing it entirely? I'd like to take it if you orphan it, if you don't mind. I've released the ownership, feel free to take it. J. François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: Hello, Few days ago I started to get very usefull notifications that my critical package, mingetty-1.08-6.fc13, `has been in 'testing' status for over 2 weeks, and has yet to be approved.' I doubt such mails help me as the package maintainer, because according current Updates policy https://fedoraproject.org/wiki/Updates_Policy#Updates_to_.27critical_path.27_packages, I can only wait to some (proven) testers to test my package. I think better place to send such allerts is proven-testers mailing list / alias (does not exist amazingly) or test-annou...@lists.fedoraproject.org mailing list. I'd like to request persons reposnsible for forcing and implementing Update Policy and bodhi notification system to re-eavaluate current configuration in spot of this concerns and to make package update process more friendly for all involved people. Proven testers do get copies of these emails (dozens of them) and its also summarised in the updates-testing report for all to see. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introducing wicked
On Fri, Nov 26, 2010 at 10:24:34AM +0100, Olaf Kirch wrote: On Thursday 25 November 2010 21:29:30 Richard W.M. Jones wrote: On Thu, Nov 25, 2010 at 05:24:37PM +0100, Olaf Kirch wrote: You may ask, don't we have enough of those already? Don't we have NetworkManager, connman, netcf, and a few more? Indeed ... You don't explain how it's better than netcf. That's because I'm not a huge fan of introducing my code by dissing other people's projects :-) Okay, so here's where I see the significant differences netcf, from what I have seen so far, converts between sysconfig files and XML using a combination of augeas and XSLT. To bring up and shut down interfaces, it continues to rely on ifup/ifdown scripts. Is that an accurate description? Fairly accurate. The goal of netcf is *not* to be a general networking management service. It is to provide a stable library ABI for reading and writing network configuration files. It it thus positioned to sit underneath network manager or any other end user networking management service that requires use of network config files. This has a number of problems, I believe 1. ifcfg files are dead That's not a strictly problem given the scope of netcf, if there are no config files, then there's no need to use netcf. 2. Why a daemon, not a library netcf isn't intended to be a general service, solely a tool for reliably reading writing the configuration files. 3. Why not NetworkManager? Netcf is intended to be used by NM, rather than to replace it. Any app which needs to read/write network config files would use it. Regards, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101129 changes
Compose started at Mon Nov 29 08:15:05 UTC 2010 Broken deps for x86_64 -- beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit) gedit-vala-0.10.2-2.fc15.i686 requires libvala-0.10.so.0 gedit-vala-0.10.2-2.fc15.x86_64 requires libvala-0.10.so.0()(64bit) ghemical-2.99.2-16.fc15.x86_64 requires libopenbabel.so.3()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-gmail-notifier-0.10.1-1.fc14.x86_64 requires libnotify.so.1()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gnome-rdp-0.2.3-6.fc12.x86_64 requires mono(Mono.Data.SqliteClient) = 0:2.0.0.0 gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) gshutdown-0.2-6.fc12.x86_64 requires libnotify.so.1()(64bit) gsql-0.2.1-4.fc12.i686 requires libnotify.so.1 gsql-0.2.1-4.fc12.x86_64 requires libnotify.so.1()(64bit) gyachi-plugin-libnotify-1.2.10-3.fc14.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libnotify.so.1()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ibus-fbterm-0.9.1-10.fc15.x86_64 requires libibus.so.2()(64bit) intellij-idea-9.0.1.94.399-12.fc15.x86_64 requires commons-collections ircp-tray-0.7.4-1.fc14.x86_64 requires libnotify.so.1()(64bit) java-gnome-4.0.16-3.fc14.x86_64 requires libnotify.so.1()(64bit) libnotifymm-0.6.1-8.fc14.i686 requires libnotify.so.1 libnotifymm-0.6.1-8.fc14.x86_64 requires libnotify.so.1()(64bit) log4net-1.2.10-13.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Data) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 log4net-1.2.10-13.fc13.x86_64 requires mono(System.Web) = 0:1.0.5000.0 mars-sim-2.84-6.fc14.noarch requires commons-collections maxima-runtime-clisp-5.22.1-5.fc15.x86_64 requires libsigsegv.so.0()(64bit) meego-panel-devices-0.2.4-4.fc15.x86_64 requires libdevkit-power-gobject.so.1()(64bit) meego-panel-devices-0.2.4-4.fc15.x86_64 requires libnotify.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Drawing) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Windows.Forms) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(mscorlib) = 0:1.0.5000.0 mono-ndoc-1.3.1-8.fc13.x86_64 requires mono(System.Xml) = 0:1.0.5000.0 nagios-plugins-snmp-disk-proc-1.2-6.fc13.x86_64 requires libnetsnmp.so.20()(64bit) 1:nant-0.85-34.fc13.x86_64 requires mono(ICSharpCode.SharpZipLib) = 0:0.84.0.0 network-manager-netbook-1.7.1-0.1.fc14.x86_64 requires libnotify.so.1()(64bit) nntpgrab-gui-0.6.90-3.fc15.x86_64 requires libnotify.so.1()(64bit) padevchooser-0.9.4-0.11.svn20070925.fc13.x86_64 requires libnotify.so.1()(64bit) pcmanx-gtk2-0.3.9-6.20100618svn.fc14.i686 requires libnotify.so.1 pcmanx-gtk2-0.3.9-6.20100618svn.fc14.x86_64 requires libnotify.so.1()(64bit) pidgin-gfire-0.9.2-2.fc15.x86_64 requires libnotify.so.1()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
Re: old_testing_critpath notifications
On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: Proven testers do get copies of these emails (dozens of them) and its also summarised in the updates-testing report for all to see. Oh, I thought t...@l.f.o. described as `For testers of Fedora development releases' concerns alpha and similar (pre-)releases only. In that case, only one issue remains: to stop spamming package maintainer. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, Nov 29, 2010 at 1:36 PM, Petr Pisar ppi...@redhat.com wrote: On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: Proven testers do get copies of these emails (dozens of them) and its also summarised in the updates-testing report for all to see. Oh, I thought t...@l.f.o. described as `For testers of Fedora development releases' concerns alpha and similar (pre-)releases only. In that case, only one issue remains: to stop spamming package maintainer. Well it advises the package maintainer that their update is old. I have no problems with it and I maintain around 120 packages. Filter it if you don't like it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 11/29/2010 02:46 PM, Peter Robinson wrote: On Mon, Nov 29, 2010 at 1:36 PM, Petr Pisar ppi...@redhat.com wrote: On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: Proven testers do get copies of these emails (dozens of them) and its also summarised in the updates-testing report for all to see. Oh, I thought t...@l.f.o. described as `For testers of Fedora development releases' concerns alpha and similar (pre-)releases only. In that case, only one issue remains: to stop spamming package maintainer. Well it advises the package maintainer that their update is old. I have no problems with it and I maintain around 120 packages. Filter it if you don't like it. Peter Great, so I will filter all messages from koji, but not these, which contains -1. Wouldn't be easier don't bother with spam? Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 1:36 PM, Petr Pisar ppi...@redhat.com wrote: On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: Proven testers do get copies of these emails (dozens of them) and its also summarised in the updates-testing report for all to see. Oh, I thought t...@l.f.o. described as `For testers of Fedora development releases' concerns alpha and similar (pre-)releases only. In that case, only one issue remains: to stop spamming package maintainer. Well it advises the package maintainer that their update is old. And I am supposed to be reminded every day. My sclerosis is no so bad yet. have no problems with it and I maintain around 120 packages. Filter it if you don't like it. Are you interrested in such notifications? I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On 11/26/2010 12:20 PM, Panu Matilainen wrote: It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on. The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual. The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35 Note that the current SRPM is missing gstreamer plugin, cups driver and automatic devel-symlink dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc). P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint) - Panu - Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Thank you, Marcela -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days. I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great! Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
upstart and /var/{lock,run} on tmpfs in Rawhide
Hello,
upstart (upstart-0.6.6-3.fc15) now includes tmpfiles job
(/etc/init/tmpfiles.conf) which looks
for /var/{lock,run}/* directories configured via /etc/tmpfiles.d/* files and
tries to create them
if they don't exist.
It allows to switch to upstart without tmpfs on /var/{lock,run} even if some
packages were
already installed on system with systemd/tmpfs feature.
You can also use /var/{lock,run} on tmpfs in similar way as is configured with
systemd. You will
only need to add following lines to /etc/fstab:
tmpfs /var/run tmpfs rw,noexec,nosuid,nodev,mode=755
0 0
tmpfs /var/lock tmpfs rw,noexec,nosuid,nodev,mode=775,gid=54
0 0
Petr
--
Petr Lautrbach, Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: biosdevname hitting rawhide
On 11/29/2010 08:27 PM, Matt Domsch wrote: On Mon, Nov 29, 2010 at 12:17:22AM -0600, Matt Domsch wrote: I've just pushed biosdevname-0.3.1 into rawhide. This is not yet installed by default as part of @base, nor is it used by anaconda, but those changes will come over the next few days. I've pushed the comps change to pull biosdevname into @base by default. And I've posted a patch to anaconda-devel-list to pull biosdevname into the installtime environment. Cross your fingers, this is gonna be great! Can you expand the release notes section of http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming Please include the benefits in that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 11/29/2010 08:04 PM, Petr Pisar wrote: I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. I am sorry but somebody does not did his job? It is not the job of anyone to test packages for you. They are merely helping out and we will get more help if we express gratitude instead of a sense of entitlement. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On 2010-11-29, Rahul Sundaram methe...@gmail.com wrote: On 11/29/2010 08:04 PM, Petr Pisar wrote: I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. I am sorry but somebody does not did his job? It is not the job of anyone to test packages for you. They are merely helping out and we will get more help if we express gratitude instead of a sense of entitlement. I do not accuse anybody not duing his job. I just complain the mails are absolutly irrelevant from point of view of package maintainer who pushed the package. You can replace the `job' with `expected duty' or `role'. I could worry about my packages not being stabilized, however that would be all I could do and it would have no effect. Frankly, I don't care about stable-status of my packages as that are Fedora rules that draw line between packager and tester `duties' in package update. I could become proven tester to test (not only) my own packages, however such cheating would be silly. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable and PM enhanced dependency extration system. Documentation is scarce at the PM moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup: ghc 7 lands in rawhide
On Sun, 2010-11-28 at 21:43 -0500, Jens Petersen wrote: - Adam Williamson awill...@redhat.com wrote: Agreed. I really don't see a reason to break so many packages, even if it is 'only Rawhide'. Was there a reason all these rebuilds could not be completed in the tag? Well mostly me being a slacker (I only rebuilt 50+ packages) If you set off a process which requires a ton of work to be done, and you only do 500kg of work, then you're still creating a problem, even though you did a lot of work. :) and hoping to engage some of the rest of the Haskell SIG to help with the rebuilds. But I will try to coordinate better next time and make sure all packages get rebuild in the -ghc tag to avoid any broken deps. thanks, that'd be great. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Wed, 24 Nov 2010, Toshio Kuratomi wrote: And when are the files and dirs created? Only when the system is booted? Yes. But then after installing an package that requires files to be created by tmpfiles.d the system needs to be rebooted before it can be used. Or will rpm call something that parses the appropriate tmpfiles.d file when the package is installed / updated? Hmm, it has been suggested that we should make it possible to create these dirs in the .spec files by invoking the systemd-tmpfiles tool directly from the scriptlets. I guess we should add a nice interface for that. In the meantime it should be sufficient to simply place th right mkdir -p -m ... in the scriptlet. Of course it would be desirable if we have a single place where the dirs to create are encoded. A question I'd have when looking over a proposed packaging guideline would be: why %ghost the directories? Why not include the directories as normal but add the tmpfiles.d step in addition? So with all of this, as a package maintainer, I will have to make sure the dirs exist in the init scripts anyway. In which case one can wonder why bothering with tmpfiles.d files (or %ghost). Just to cleanup a volatile directory in case a package is uninstalled after start? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, 2010-11-29 at 14:34 +, Petr Pisar wrote: I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. Your packager duties include aiding in ensuring testing of your packages takes place. It is not true that there is nothing you can do. You can contact proven testers and ask them to test your package, you can contact people who use your package (I would hope you know some!) and ask them to become proven testers to ensure that your updates are pushed in timely fashion in future. QA is not 'someone else's problem', it's a collaborative effort. Fedora is a community-based volunteer-driven project; neither Red Hat nor The Fedora Project has a thousand minimum-wage Fedora test slaves in a room somewhere ready to do all the testing we could ever desire. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010 10:15:47 -0600 Jason L Tibbitts III ti...@math.uh.edu wrote: PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable PM and enhanced dependency extration system. Documentation is scarce PM at the moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. It's working now. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Please Help Test 389 Directory Server 1.2.7.1
389-ds-base-1.2.7.1 is now in Testing. This release has some key fixes for bugs in 1.2.7. Please help us test. The sooner we can get this release tested, the sooner we can push it to Stable and make it generally available. There is also a new 389-admin-1.1.13 package. Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base 389-admin # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base 389-admin setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 12, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 12 and provide feedback. * 389-ds-base-1.2.7.1 ** EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.el5 ** Fedora 12 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc12 ** Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc13 ** Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.7.1-1.fc14 scroll down to the bottom of the page, and click on the Add a comment link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning licq
On Mon, Nov 29, 2010 at 11:04 AM, Jiri Moskovcak jmosk...@redhat.com wrote: On 11/27/2010 12:15 AM, François Cami wrote: On Fri, Nov 26, 2010 at 1:51 PM, Jiri Moskovcakjmosk...@redhat.com wrote: I'm no longer interested in this package, so I'm going to orphan in it. IMHO there is not much users anyway, so how about removing it entirely? I'd like to take it if you orphan it, if you don't mind. I've released the ownership, feel free to take it. Taken, thank you. You might want to remove yourself from bugzilla CCs :) François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010, Marcela Mašláňová wrote: On 11/26/2010 12:20 PM, Panu Matilainen wrote: It's that time of year again, although there seems to be an off-by-one bug in the calendar system causing some inconsistency in the timing wrt last year :P http://lists.fedoraproject.org/pipermail/devel/2009-November/042339.html Anyway, before going to beta and starting the inevitable Fedora Feature process, we'd like some extra preliminary testing to catch out any major issues early on. The alpha isn't supposed to eat your system alive or anything, but proceed with appropriate cauting, backing up the rpmdb etc, as usual. The draft release notes are at http://rpm.org/wiki/Releases/4.9.0 and Fedora compatible SRPM(s) can be found at http://laiskiainen.org/rpm/srpms/ In particular, I'm interested in feedback on the new, pluggable and enhanced dependency extration system. Documentation is scarce at the moment but some background and examples can be found here: http://laiskiainen.org/blog/?p=35 Note that the current SRPM is missing gstreamer plugin, cups driver and automatic devel-symlink dependency generation, on purpose: the highly application-domain specific gstreamer + cups bits can now be fully moved out of rpm to gstreamer-devel etc, eliminating the need for embedding python inside /bin/sh scripts and such to avoid extra dependencies. The devel-symlink generation will stay in rpm but will probably change somewhat, it can be handled in a more generic fashion now. Please report any oddities found, preferably to rpm.org Trac at http://rpm.org/newticket or rpm-maint list (or here for fedora-specific discussions/suggestions etc). P.S. Pjones, before you ask ;) The much wanted ordering-only feature is not in the alpha, but is likely to make it into beta. The patch itself is fairly trivial and non-intrusive, we're just trying to figure sane spec syntax for it (discussion ongoing on rpm-maint) - Panu - Hello, I tried rebuild RPM on F-14. New RPM doesn't find all provides as it should. Example: RPM 4.9.alpha rpm -qp --provides perl-CGI-3.50-1.fc14.noarch.rpm perl-CGI = 3.50-1.fc14 RPM from koji: rpm -qp --provides perl-CGI-3.50-1.fc15.noarch.rpm perl(CGI) perl(CGI::Apache) = 1.01 perl(CGI::Carp) = 3.45 perl(CGI::Cookie) perl(CGI::Fast) perl(CGI::Pretty) = 3.46 perl(CGI::Push) perl(CGI::Switch) = 1.01 perl(CGITempFile) perl(CGI::Util) = 3.48 perl(Fh) perl(MultipartBuffer) perl(utf8) perl-CGI = 3.50-1.fc15 I suppose RPM was looking for all strings 'package' in source code. Could you look at it? As test SRPM you can use: http://mmaslano.fedorapeople.org/review/perl-CGI-3.50-1.fc14.src.rpm Yeah, that seems fairly broken. I'll have a look, thanks for testing and reporting - this is just the kind of stuff I want to find out /before/ this hits rawhide :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Looking for testers: RPM 4.9 alpha
On Mon, 29 Nov 2010, Jason L Tibbitts III wrote: PM == Panu Matilainen pmati...@laiskiainen.org writes: PM In particular, I'm interested in feedback on the new, pluggable and PM enhanced dependency extration system. Documentation is scarce at the PM moment but some background and examples can be found here: PM http://laiskiainen.org/blog/?p=35 Unfortunately laiskiainen.org isn't responding for me at the moment, so I can't check the actual packages, but could you comment on whether rpm-builds dependency list will be changing as a result of this? Because if so we'll have to work through a round of build failures as things which used to be in the buildroot purely due to rpm-build might no longer be there. I'm thinking of perl in particular. I don't expect changes to rpm-build's dependencies for the time being. The pluggability just makes it /possible/ to add new things without dragging them in as dependencies or jumping through nutty hoops to avoid them. At some point (maybe for F16, I dunno) we might want to look at pushing some of the current dependencies like perl out to perl-related packages etc, but that's not an immediate goal. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On 11/23/2010 04:32 PM, Lennart Poettering wrote: On Tue, 23.11.10 16:12, Doug Ledford (dledf...@redhat.com) wrote: On 11/23/2010 03:48 PM, Lennart Poettering wrote: Heya! I hereby want to let everybody know that in the next days I will turn on /var/run and /var/lock on tmpfs on Rawhide/F15. This is in accordance with the following accepted F15 feature: https://fedoraproject.org/wiki/Features/var-run-tmpfs Will the tmpfs mounts be available in the initramfs, or only on the running system? Since /var/run is a subdir of /var which might be separate file system it is difficult mounting /var/run before /var. That means that it won't be available in the intird. (Yes, one can do stuff with show-through mount hierachies, that would allow replacing /var later on, but I am not a fan of such hackery.) Hackery is in the eye of the beholder. Also note that by now it's somewhat standard that code that needs to be run as part of early boot creates a subdir in /dev, such as /dev/.udev or /dev/.systemd. Not super-pretty, but I guess it's too late to complain about that. Those places all exist *because* no one took the time to create an initrd managed writable /var/run or /var/lock. Using their existence to justify continuing down a path that places files where they don't belong is faulty logic. I took a *major* beating by the upstream mdadm maintainer over the fact that we are putting files in /dev/ that don't belong there. And he's right, we *shouldn't* be putting those files there. Continuing a band aid hack because someone did it initially is not the right course of action. Ideally the FHS would have never specified that /var/run and /var/lock would lie beneath /var, but I guess that's too late now. One failed specification isn't really a good reason to justify creating a de facto second failed specification. -- Doug Ledford dledf...@redhat.com GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
John Reiser wrote: This patch (with .rpms for x86_64 and i686) enables glibc optionally to detect, diagnose, and work around overlap in memcpy/mempcpy: http://bitwagon.com/glibc-memlap/glibc-memlap.html The option to check is controlled by an environment variable MEMCPY_CHECK_ which influences choices made by __init_cpu_features and the STT_GNU_IFUNC mechanism for choosing alternate implementations at runtime. This does not work where the memcpy is inlined (which glibc can do in several cases). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
Rahul Sundaram wrote: I am sorry but somebody does not did his job? It is not the job of anyone to test packages for you. They are merely helping out and we will get more help if we express gratitude instead of a sense of entitlement. But this is exactly why the current policy which REQUIRES testing is broken. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, Nov 29, 2010 at 09:33:46AM -0800, Adam Williamson wrote: On Mon, 2010-11-29 at 14:34 +, Petr Pisar wrote: I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. Your packager duties include aiding in ensuring testing of your packages takes place. Note that this is not explicit. What is explicit is that maintainers are expected to: Deal with reported bugs in a timely manner http://fedoraproject.org/wiki/Package_maintainer_responsibilities I think one source of the feelings on some maintainers' parts is that the new update criteria get in the way of timey manner in the quest to prevent regressions. It is not true that there is nothing you can do. You can contact proven testers and ask them to test your package, you can contact people who use your package (I would hope you know some!) and ask them to become proven testers to ensure that your updates are pushed in timely fashion in future. QA is not 'someone else's problem', it's a collaborative effort. Fedora is a community-based volunteer-driven project; neither Red Hat nor The Fedora Project has a thousand minimum-wage Fedora test slaves in a room somewhere ready to do all the testing we could ever desire. Actually, what you say here is both true and untrue. If you look at Fedora as a product to be delivered, then QA is a problem for everyone delivering that product to worry about. However, if you look at Fedora as an open source project then you'll find that tasks are divided among contributor interest rather than end-product. It is the problem of the people who care about QA to worry about QA -- the people who have an itch to scratch have the responsibility to scratch it for themselves. These ideas are not diametrically opposed, rather they're two different ways to look at this problem and try to understand that an ideal solution encompasses both viewpoints. On the one hand, convincing everyone to care about QA and make sure that packages they care about are tested to prevent regressions, and on the other hand, giving maintainers the ability to make judgements about the risk vs benefit of the update that they want to push and getting the high benefit packages into users hands asap. -Toshio pgpF5k8gZP9YT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, 29 Nov 2010 16:11:37 + (UTC), Petr wrote: On 2010-11-29, Rahul Sundaram wrote: On 11/29/2010 08:04 PM, Petr Pisar wrote: I do not get the idea why I should filter some irrelevant mails if better is to not sent them. Especially if I cannot solve the subject of the mail. Well, rest assured that there are members in the proventesters group, who ignore/filter those nag mails, too. They are not messages you'd like to process repeatedly. F-12 is a sinking ship, F-13 is being abandoned by more users, because F-14 is current. Yeah, the subject is somobody does not did his job. I cannot imagine the knowledge would help me in my packager duties. I am sorry but somebody does not did his job? It is not the job of anyone to test packages for you. They are merely helping out and we will get more help if we express gratitude instead of a sense of entitlement. I do not accuse anybody not duing his job. I just complain the mails are absolutly irrelevant from point of view of package maintainer who pushed the package. There are other messages sent by bodhi, which are irrelevant and just noise. All testers, who have left a comment, receive the notification that an update is 7 days old. And they receive that notification repeatedly as long as the maintainer forgets to push the package to stable. You can replace the `job' with `expected duty' or `role'. That point of view is too demanding. Testing every critpath update, including updates for old dists, is not anything like a duty for testers or proventesters. For *any* tester who wants to help, even if only occasionally, joining the proventesters group has become a necessity due to the update acceptance criteria. Else the ordinary tester's karma would be less worth in the new system. I could worry about my packages not being stabilized, however that would be all I could do and it would have no effect. Frankly, I don't care about stable-status of my packages as that are Fedora rules that draw line between packager and tester `duties' in package update. I could become proven tester to test (not only) my own packages, however such cheating would be silly. Which is why the current testing requirements are infeasible and insane. Packagers ought to retain the freedom to decide what's most appropriate for their updates … and only lose bits of that freedom when they take their responsibilities too lightly and cause damage. As one of the responsibilities, it may be important for packagers to disable bodhi karma automatism. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On 11/28/2010 03:36 PM, Nicholas Miell wrote: On 11/28/2010 03:13 PM, John Reiser wrote: The option to check is controlled by an environment variable MEMCPY_CHECK_ which influences choices made by __init_cpu_features and the STT_GNU_IFUNC mechanism for choosing alternate implementations at runtime. If you're going to control it via an environment variable, why not just make a LD_PRELOADed shared library which intercepts memcpy() in the usual manner? Doing it that way has the added benefit that anybody could use it immediately, without needing to replace their glibc with a patched version that will never get merged upstream. Using LD_PRELOAD is a good option in many cases. Having a built-in tool can be more convenient, easier to use, and more likely to be used. Using LD_PRELOAD often involves a trip through two PLTs (Program Linkage Tables), each with an indirect JUMP. Often such a JUMP takes many cycles. A builtin solution that enables using only one indirect JUMP can be faster, enough to make a difference. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On 11/29/2010 01:46 PM, Kevin Kofler wrote: John Reiser wrote: This patch (with .rpms for x86_64 and i686) enables glibc optionally to detect, diagnose, and work around overlap in memcpy/mempcpy: http://bitwagon.com/glibc-memlap/glibc-memlap.html The option to check is controlled by an environment variable MEMCPY_CHECK_ which influences choices made by __init_cpu_features and the STT_GNU_IFUNC mechanism for choosing alternate implementations at runtime. This does not work where the memcpy is inlined (which glibc can do in several cases). Right. However, specifying the flag -fno-builtin-memcpy at compilation disables gcc inlining of memcpy, thus exposing calls to memcpy that can be checked. Also, a survey of recent versions of gcc indicates that the inlining always copies in ascending address order (of both source and destination.) While the details of inlining are subject to change, copying in ascending address order is the order that is assumed by all violators of the no-overlap requirement. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
What is the mass addition of commented curly braces for? It is
distracting from the substance of the patch.
diff --git a/sysdeps/x86_64/multiarch/strcmp.S
b/sysdeps/x86_64/multiarch/strcmp.S
index 1859289..e014283 100644
--- a/sysdeps/x86_64/multiarch/strcmp.S
+++ b/sysdeps/x86_64/multiarch/strcmp.S
@@ -21,7 +21,7 @@
#include sysdep.h
#include init-arch.h
-#ifdef USE_AS_STRNCMP
+#ifdef USE_AS_STRNCMP /*{*/
/* Since the counter, %r11, is unsigned, we branch to strcmp_exitz
if the new counter the old one or is 0. */
# define UPDATE_STRNCMP_COUNTER\
(etc.)
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On Mon, Nov 29, 2010 at 6:35 PM, John Reiser jrei...@bitwagon.com wrote: While the details of inlining are subject to change, copying in ascending address order is the order that is assumed by all violators of the no-overlap requirement. All violators? Citation needed. I'm sure lurking somewhere there are ovelap copies which have no 'assumption' at all— some bad luck with arithmetic makes it ovelap during some rare alignment of the stars... though cases like that aren't going to be the ones that get inlined by GCC. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On 11/29/2010 03:44 PM, Matt McCutchen wrote:
On Sun, 2010-11-28 at 15:13 -0800, John Reiser wrote:
This patch (with .rpms for x86_64 and i686) enables glibc optionally
to detect, diagnose, and work around overlap in memcpy/mempcpy:
http://bitwagon.com/glibc-memlap/glibc-memlap.html
What is the mass addition of commented curly braces for? It is
distracting from the substance of the patch.
-#ifdef USE_AS_STRNCMP
+#ifdef USE_AS_STRNCMP /*{*/
/* Since the counter, %r11, is unsigned, we branch to strcmp_exitz
if the new counter the old one or is 0. */
# define UPDATE_STRNCMP_COUNTER \
Those comments enable parenthesis matching in some text editors.
The scoping of conditional compilation in sysdeps/x86_64/multiarch/strcmp.S
was complicated enough that I needed help figuring it out.
Indeed, it was complicated enough to help conceal a bug.
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: preventing md5 mismatch errors from compression changes
Andre Robatino robatino at fedoraproject.org writes: 2) is easy enough. To get F14 to use the new compression unconditionally, I downloaded the Rawhide version of several packages and then used yum shell with the commands config gpgcheck 0 install xz-compat-libs-5.0.0-4.fc15.x86_64.rpm update xz-5.0.0-4.fc15.x86_64.rpm xz-libs-5.0.0-4.fc15.x86_64.rpm deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm deltaiso-3.6-0.4.20100708git.fc15.x86_64.rpm python-deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm run and to reverse the process (necessary so yum-presto will work), yum shell again with the commands remove xz-compat-libs downgrade xz xz-libs deltarpm deltaiso python-deltarpm run The old and new versions of deltarpm use the old and new compression unconditionally, resp. I'm wondering why the new xz isn't pushed to F14 and below. With xz-compat-libs providing liblzma.so.0, yum-presto works normally. It's only if deltarpm/deltaiso are updated to the F15/Rawhide versions that it breaks. Would anything else break - other than the fact that command-line xz would compress differently? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: headsup: ghc 7 lands in rawhide
- Adam Williamson awill...@redhat.com wrote: On Sun, 2010-11-28 at 21:43 -0500, Jens Petersen wrote: - Adam Williamson awill...@redhat.com wrote: Agreed. I really don't see a reason to break so many packages, even if it is 'only Rawhide'. Was there a reason all these rebuilds could not be completed in the tag? Well mostly me being a slacker (I only rebuilt 50+ packages) If you set off a process which requires a ton of work to be done, and you only do 500kg of work, then you're still creating a problem, even though you did a lot of work. :) Who said there were a hundred packages - we're not there yet... Having said with the new hask metadata ghc dependency breakage will get even more noisy noisy going forward? :-/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Clutter 1.5.8 in rawhide
Just a quick heads up - I'm currently building Clutter 1.5.8 into rawhide. Supposedly this is 100% compatible with Clutter 1.4, but there are a lot of internal changes in the backend parts so there's a possibility of bugs/regressions. (I was waiting to upgrade in Rawhide until we got the necessary bugs fixed to make it work well with GNOME Shell; 1.5.8 achieves that.) If you run into anything, just file it in bugzilla and I'll take care of investigating and upstreaming as necessary. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memcpy overlap: quickly detect, diagnose, work around
On Mon, 2010-11-29 at 16:08 -0800, John Reiser wrote: On 11/29/2010 03:44 PM, Matt McCutchen wrote: What is the mass addition of commented curly braces for? It is distracting from the substance of the patch. Those comments enable parenthesis matching in some text editors. The scoping of conditional compilation in sysdeps/x86_64/multiarch/strcmp.S was complicated enough that I needed help figuring it out. Indeed, it was complicated enough to help conceal a bug. I see. Still, you could split the patch into one that just adds commented curly braces to existing code and a second with the substantive changes, which would be easier for anyone interested to review. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: preventing md5 mismatch errors from compression changes
On Tue, Nov 30, 2010 at 12:15:25AM +, Andre Robatino wrote: Andre Robatino robatino at fedoraproject.org writes: 2) is easy enough. To get F14 to use the new compression unconditionally, I downloaded the Rawhide version of several packages and then used yum shell with the commands config gpgcheck 0 install xz-compat-libs-5.0.0-4.fc15.x86_64.rpm update xz-5.0.0-4.fc15.x86_64.rpm xz-libs-5.0.0-4.fc15.x86_64.rpm deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm deltaiso-3.6-0.4.20100708git.fc15.x86_64.rpm python-deltarpm-3.6-0.4.20100708git.fc15.x86_64.rpm run and to reverse the process (necessary so yum-presto will work), yum shell again with the commands remove xz-compat-libs downgrade xz xz-libs deltarpm deltaiso python-deltarpm run The old and new versions of deltarpm use the old and new compression unconditionally, resp. I'm wondering why the new xz isn't pushed to F14 and below. With xz-compat-libs providing liblzma.so.0, yum-presto works normally. It's only if deltarpm/deltaiso are updated to the F15/Rawhide versions that it breaks. Would anything else break - other than the fact that command-line xz would compress differently? Commandline xz would compress differently and other random apps that we don't know of would as well. This may not cause any difficulties... OTOH, it could be that people *are* depending on the compression being the same. breaking that assumption is something we can do at the Fedora release boundary... not so easily within a Fedora release. Beyond this, there's the fact that there's not a compelling reason to update on F14 and that the present plan for the compat libs package is that it will go away before rawhide becomes F15. -Toshio pgp73FbDqOnbl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide
On Mon, Nov 29, 2010 at 12:21:08PM -0500, Paul Wouters wrote: On Wed, 24 Nov 2010, Toshio Kuratomi wrote: And when are the files and dirs created? Only when the system is booted? Yes. But then after installing an package that requires files to be created by tmpfiles.d the system needs to be rebooted before it can be used. Or will rpm call something that parses the appropriate tmpfiles.d file when the package is installed / updated? Hmm, it has been suggested that we should make it possible to create these dirs in the .spec files by invoking the systemd-tmpfiles tool directly from the scriptlets. I guess we should add a nice interface for that. In the meantime it should be sufficient to simply place th right mkdir -p -m ... in the scriptlet. Of course it would be desirable if we have a single place where the dirs to create are encoded. A question I'd have when looking over a proposed packaging guideline would be: why %ghost the directories? Why not include the directories as normal but add the tmpfiles.d step in addition? So with all of this, as a package maintainer, I will have to make sure the dirs exist in the init scripts anyway. In which case one can wonder why bothering with tmpfiles.d files (or %ghost). Just to cleanup a volatile directory in case a package is uninstalled after start? There's a few different things we'd like to achieve: * after a reboot, the application is able to startup and write to a directory in /var/run and/or /var/lock. * The sysadmin would like to be able to see who owns the directories and lock files in /var/run and/or /var/lock so rpm -qf /var/run/foo/ should tell them that. corner cases: * After installation but before reboot, the application is able to startup and write to a directory in /var/run and/or /var/lock * After removal but before reboot, the directories that aren't needed are cleaned up from /var/run and /var/lock The first of these corner cases is much more important than the second of them. So with all this, we know a few things: 1) The rpm metadata has to carry information about the directories (and should for files as well) inside of /var/run and /var/lock. To me we should just put the directories in per normal and %ghost any files (which is what we should be doing already but probably aren't always). 2) The act of installing the rpm should create the necessary directories. Alternately, the program (or as you say, the init script) can create the necessary directories. Note that I don't believe that systemd gives you the flexibility to do that sort of thing (there's no script in its init stuff) so you'd need a wrapper script for the program itself or write a patch to the program itself to achieve this where the program doesn't create the directory already and if we don't do this from within the rpm payload. 3) We have to use tmpfiles.d to create the directories on reboot. Of these, only %ghosting of files (not directories) is only about cleaning up the directories. The rest can cause the service to fail to startup. -Toshio pgpcv0GqmvNZ6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning awstats
Hi all, I'm orphaning awstats, a web log file analyzer. If anyone's interested... Aurélien -- http://aurelien.bompard.org Jabber : abomp...@jabber.fr In God we Trust. All others must submit an X.509 certificate. signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: old_testing_critpath notifications
On Mon, 2010-11-29 at 14:34 +, Petr Pisar wrote: On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 1:36 PM, Petr Pisar ppi...@redhat.com wrote: On 2010-11-29, Peter Robinson pbrobin...@gmail.com wrote: On Mon, Nov 29, 2010 at 9:56 AM, Petr Pisar ppi...@redhat.com wrote: have no problems with it and I maintain around 120 packages. Filter it if you don't like it. Are you interrested in such notifications? Discussion about filtering/blocking mentioned messages is about how to fix consequence but... The discussion should search for improving source of the problem. What about source of this? I could count e.g.: - missing reaction of QA - missing approval for the package to be moved to stable - missing additional action of developer I've got a lot messages due to one package (needs modem for testing). I contacted some concerned people directly and I'm glad to say this situation has no more repeated with this package. This works fine. I believe only a little portion of packages are related to this problem. Well, I'm convinced better is ask for action then to discuss what should/shouldn't happen. Skalnik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 652158] Use of :locked is deprecated
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=652158 --- Comment #12 from Fedora Update System upda...@fedoraproject.org 2010-11-29 16:38:13 EST --- perl-Net-SNMP-6.0.1-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 652158] Use of :locked is deprecated
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=652158 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Net-SNMP-6.0.1-1.fc14 Resolution||ERRATA Last Closed||2010-11-29 16:38:17 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658298] New: [abrt] perl-Padre-0.64-1.fc14: main_arena: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] perl-Padre-0.64-1.fc14: main_arena: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=658298 Summary: [abrt] perl-Padre-0.64-1.fc14: main_arena: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) Product: Fedora Version: 14 Platform: x86_64 OS/Version: Unspecified Status: NEW Status Whiteboard: abrt_hash:a9efce4f6e42c901ab77e3a64878faa045f90679 Severity: medium Priority: low Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: gatlinsulli...@yahoo.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/perl /usr/bin/padre comment: It fails on initialization. component: perl-Padre crash_function: main_arena executable: /usr/bin/perl kernel: 2.6.35.6-48.fc14.x86_64 package: perl-Padre-0.64-1.fc14 rating: 3 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1291068822 uid: 500 How to reproduce - 1. I attempted to run padre from the command line interface. 2. 3. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 658298] [abrt] perl-Padre-0.64-1.fc14: main_arena: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=658298 --- Comment #1 from gat gatlinsulli...@yahoo.com 2010-11-29 17:18:16 EST --- Created attachment 463596 -- https://bugzilla.redhat.com/attachment.cgi?id=463596 File: backtrace -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
