Re: RATS: now in production
On 02/21/2012 10:48 AM, Adam Williamson wrote: > > the rats_install test runs an entirely automated test of the Fedora > installer daily, against the daily installer composes provided by > release engineering. It provides detailed logs and pinpoints where > failure occurs if the installation is not successful, and preserves the > complete anaconda logs for debugging. So now we can know, daily, whether > the Branched tree is in an installable state or not. That's awesome. Is it possible to test upgrades? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RATS: now in production
Don't worry, they don't carry diseases. I really just wanted to spread this news out a little more because it's really cool stuff. Thanks to Hongqing Yang and Kamil Paral, one of the long-term goals of the AutoQA project is now a reality: http://autoqa-stg.fedoraproject.org/resultsdb/frontend/search?type=Testcase&terms=rats_install the rats_install test runs an entirely automated test of the Fedora installer daily, against the daily installer composes provided by release engineering. It provides detailed logs and pinpoints where failure occurs if the installation is not successful, and preserves the complete anaconda logs for debugging. So now we can know, daily, whether the Branched tree is in an installable state or not. Those of you with very long memories may recall Will Woods' 'israwhidebroken.com' idea which was one of the starting points of the whole AutoQA effort - the rats_install test finally realizes that glorious, beefy vision. Well, just wanted to give that some publicity - it's always good to be able to show off solid progress on AutoQA. In case anyone wonders why the test is 'failed' for the last four days - the test uses the serial installation interface, and it's hitting https://bugzilla.redhat.com/show_bug.cgi?id=736993 . So the result is correct. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 Alpha status update
Another quick F17 Alpha status update: we now have updates in for all open blockers. However, the fix for the plymouth issue was to add it to comps, and it takes a few hours for that change to be registered before we can do a compose. (All times in the following are PST). The compose should be happening tomorrow morning, so we'll have all of tomorrow and Wednesday morning to get the Alpha tests run ahead of the go/no-go meeting. It shouldn't be too much work, since the set of Alpha tests isn't that large compared to Beta/Final. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some fedora projects are still not using transifex (properly)
Hi guys, It tooks me few hours as this is my first python script :) I've managed to get the whole list of transifex.net projects who appears dead, here they are: (see bellow for the explaination) @devel, if your project is named there, please get in touch with us [D] avahi [D] expendable [M] fedora-desktop-backgrounds [D] fedora-docbook-locales [D] fedora-docsite-publican [D] fedora-elections-guide [D] fedora-preupgrade [D] fedora-readme-burning-isos [D] fedora-rpm-guide [D] fedora-virtualization-guide [D] firstboot [D] hivex [D] iwhd [D] liveusb-creator [D] newt [D] paprefs [D] pavucontrol [D] pulseaudio [D] pulsecaster [D] pykickstart [M] python-meh [D] readahead [M] redhat-menus [D] setuptool [O] sos [M] system-config-bind [D] system-config-boot [M] system-config-firewall [M] system-config-httpd [M] system-config-keyboard [D] system-config-kickstart [M] system-config-lvm [D] system-config-nfs [D] system-config-printer [M] system-config-rootpassword [M] system-switch-java [M] system-switch-mail [O] usermode [D] virttop The script is available on my repo[1], the code is explained in the README file. [O] means no owner specified, __THAT'S REALLY WRONG__ [M] means no maintainers found (default ones removed, could they be the only ones? Need to check) [D] means the source language has not been updated for a long time (set to 4 months). It is against all resources on one project. 4 months is quite revelent. More details are available for rapid checks: http://fpaste.org/AHLK/ I've run this script against all Fedora projects (86), which are under websites, docs, main and uptream. The [D] date is checked against all resources of one project (total of 400 resources) Comment or pull request welcome :) [1] https://gitorious.org/tiny-scripts/transifex/trees/master/is_project_active -- Kévin Raymond (Shaiton) pgp93eDKAaPQK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 Slowness
On Thu, Feb 16, 2012 at 5:59 PM, Josh Boyer wrote: >> But I just had another variant of this idea: could the string "debug" be >> embedded in the release string of the kernel? (and wire this up in the >> specfile so that it's automatically added) >> >> so e.g. >> kernel-3.3.0-0.rc3.git6.2.fc18 >> would become: >> kernel-3.3.0-0.rc3.git6.2.debug.fc18 >> or >> kernel-3.3.0-0.rc3.git6.2.fc18.debug >> >> That way it'd show up everywhere e.g. in uname -a, in >> gnome-system-monitor, on logon, etc, and make it obvious that the debug >> code is enabled. >> >> Not sure if this is a good idea or not > > We actually already do this. Sort of. > > When we're building release kernels, we actually build kernel and kernel-debug > packages. The kernel package has the normal uname and kernel-debug has the > EXTRARELEASE set to the flavor being built (either nothing, PAE, debug, or > PAEdebug). So if you install and boot kernel-debug, your uname will look > like: > > 3.2.3-2.fc16.i686.debug or 3.2.3-2.fc16.i686.PAEdebug > > However, in rawhide (and f17 at the moment) we're building -rcX kernels and we > tend to leave the debug options always on. That means the kernel package has > the options enabled and there is no kernel-debug package being built. Once > per > -rc, we flip the switch so we get both. > > Tacking a .debug into EXTRARELEASE for the usual rawhide case might still be a > good idea. I'll look into that tomorrow. FYI, I committed a changed to do thi this morning. It should be in tomorrow's rawhide and whatever kernel we submit for F17 next. Thanks again for the idea. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Engineering "Open House" IRC Meeting - Thursday, February 23, 2012 - 1800 UTC
Apologies in advance for the wide distribution of this message. The Fedora Engineering team is holding an "Open House" IRC meeting on Thursday, February 23, 2012 at 18:00 UTC (12:00 PM EST). This will be a moderated meeting in which we will briefly present the upcoming projects for the Fedora Engineering team, then take questions, suggestions, and feedback from the Fedora Community. The meeting will take place in #fedora-meeting on irc.freenode.net, and it will be logged. We will be following the Fedora Meeting Protocol, which is documented here: https://fedoraproject.org/wiki/How_to_use_IRC#Meeting_Protocol In case you have not heard of Fedora Engineering, the short answer is that we are the team at Red Hat made up of people who work full-time on improving Fedora and ensuring it has a robust and useful infrastructure. The longer answer can be found here: https://fedoraproject.org/wiki/Fedora_Engineering Our proposed projects and goals for the next year are documented here: https://fedoraproject.org/wiki/Fedora_Engineering/FY13_Plan In the spirit of transparency and community, we would like to encourage all Fedora community members (whether users, testers, writers, artists, translators, ambassadors, packagers, or any other type of contributor) to come and meet the team and learn about our plans for the next year. Thanks, Tom Callaway Fedora Engineering Manager ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 21:25, Nicolas Mailhot wrote: > Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit : >> Le Lun 20 février 2012 21:07, Kay Sievers a écrit : > >>> I couldn't disagree more. >>> >>> /usr/share in our general understanding not to be used for >>> package-private things. >> >> But those files are not package-private! Even ignoring the example I just >> gave, systemd units *will* be installed by different packages that *will* >> need >> to be at least aware of the other units to handle ordering properly. Those >> files are anything but package-private > > (and actually it's quite ridiculous to have systemd people argue today unit > files belong to them alone when they've spent the past years reusing files > that were intended for sysv. Someday something better than systemd will be > proposed and it will have to read 'systemd' files just like systemd had to > read 'sysv' files to handle the transition) It all started with udev 7 years ago, and it still makes sense taking into account all the experience we collected in that time. Find it ridiculous or not, it's what we think is right. Even if we were not sure about it, changing the well-established way we do it would not be justified. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:29 PM, Kay Sievers wrote: > 2012/2/20 Miloslav Trmač : >> On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers wrote: >>> The general rule for $libdir is that it is reserved for shared objects >>> and their directly associated files like pkgconfig files. >> No, that's not at all what the FHS says. > > "Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory." That's the /usr/lib paragraph. The $libdir paragraph is "4.8.1.�Purpose /usr/lib performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib/sendmail and /usr/lib/X11 are not required. [28]" i.e. "equivalent to /usr/lib, no additional restrictions." Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
2012/2/20 Miloslav Trmač : > On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers wrote: >> The general rule for $libdir is that it is reserved for shared objects >> and their directly associated files like pkgconfig files. > No, that's not at all what the FHS says. "Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory." > Please don't claim that any > suggested meaning, however reasonable it may be, is "the general rule" > when it isn't. I do. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit : > > Le Lun 20 février 2012 21:07, Kay Sievers a écrit : >> I couldn't disagree more. >> >> /usr/share in our general understanding not to be used for >> package-private things. > > But those files are not package-private! Even ignoring the example I just > gave, systemd units *will* be installed by different packages that *will* need > to be at least aware of the other units to handle ordering properly. Those > files are anything but package-private (and actually it's quite ridiculous to have systemd people argue today unit files belong to them alone when they've spent the past years reusing files that were intended for sysv. Someday something better than systemd will be proposed and it will have to read 'systemd' files just like systemd had to read 'sysv' files to handle the transition) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers wrote: > The general rule for $libdir is that it is reserved for shared objects > and their directly associated files like pkgconfig files. No, that's not at all what the FHS says. Please don't claim that any suggested meaning, however reasonable it may be, is "the general rule" when it isn't. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 21:07, Kay Sievers a écrit : > On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot > wrote: >> >> Le Lun 20 février 2012 18:50, Kay Sievers a écrit : >>> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote: >> >>> Udev rules and systemd units belong to the installed daemon. This daemon >>> can only exist exactly one single time, and never be installed by multilib >>> packages, hence they do not ever belong into libdir. >> >> Actually, Udev rules and systemd units belong to the package that installed >> them. That's why hiding them in a private lib dir is wrong >> >> When amavisd instaciates clamav using the generic unit shipped with clamav >> but >> using an amavisd-specific conf file the clamav systemd unid is shared with >> amavisd >> >> That's why share is the natural place to share this arch-independant >> configuration and putting it in /usr/lib is grandfathering an exception that >> only existed because /share didn't exist > > I couldn't disagree more. > > /usr/share in our general understanding not to be used for > package-private things. But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers wrote: > /usr/share in our general understanding not to be used for > package-private things. Who is "we"? This is in direct conflict with the FHS: "Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose." > There is no reason to have > /usr/share// and /usr/lib/, even LSB specifies that > only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html . > Even the original distinction between arch-dependent and > arch-independent to support a share/ subdir that can be *shared* > between different machines will break with config like udev and > systemd in share/. This is not a *natural* place at all. What would break in particular? From a quick grep there is not a single mention of "lib64" in any of the configuration/control files in either /lib/systemd or /lib/udev on my F16 system. > We tend to interpret /usr/share as something today, to place stuff > into that is really *shared* on the same host, like icons, man pages, > things that are mere a collection of similar stuff that multiple > packages use. Again, who is "we" here? FHS is pretty explicit about the intended distinction between "lib" and "share". (And FWIW, none my comments above is to be read to be in favor of moving anything just to make things "prettier" or "more consistent".) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi wrote:
> On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
>> On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
>> > This sounds like the unit files belong in %{_libdir} now? However, that
>> > would mean that they can't go into noarch packages. So we probably need to
>> > know a little more about just how architecture dependent these unit files
>> > can be.
>>
>> No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
>> two different versions for 32bit and 64bit. We want just one, hence they
>> belong in /lib unconditionally)
>>
> Okay, so this is one more area where when people mispackage a library and
> a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to
/usr/lib and all packages using libexecdir should use a subdir in
that, and $libdir should not be involved at all, this results in
/usr/lib/udev/cdrom_id, and /usr/lib/systemd/systemd-journald and so
on. This is actually what most distributions do today and what we
envision for the future of a cross-distribution unified Linux.
The general rule for $libdir is that it is reserved for shared objects
and their directly associated files like pkgconfig files.
There are valid cases where shared objects exec() their own helpers,
like when elevated privileges and setuid/capabilities are involved,
that can be a good and valid reason to drop the binary in $libdir if
multilib installation with separate callout helpers need to be
supported; but almost all other packages should not mess there.
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot wrote: > > Le Lun 20 février 2012 18:50, Kay Sievers a écrit : >> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote: > >> Udev rules and systemd units belong to the installed daemon. This daemon >> can only exist exactly one single time, and never be installed by multilib >> packages, hence they do not ever belong into libdir. > > Actually, Udev rules and systemd units belong to the package that installed > them. That's why hiding them in a private lib dir is wrong > > When amavisd instaciates clamav using the generic unit shipped with clamav but > using an amavisd-specific conf file the clamav systemd unid is shared with > amavisd > > That's why share is the natural place to share this arch-independant > configuration and putting it in /usr/lib is grandfathering an exception that > only existed because /share didn't exist I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. There is no reason to have /usr/share// and /usr/lib/, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all. We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use. It's definitely not a place to store system instructions and system plugins. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 18:50, Kay Sievers a écrit : > On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote: > Udev rules and systemd units belong to the installed daemon. This daemon > can only exist exactly one single time, and never be installed by multilib > packages, hence they do not ever belong into libdir. Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 18:18, Nils Philippsen a écrit : > 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. and the java files are there either because they use jni (so not arch-independant) or are remnants of the time gcj was use to native-compile them (and gcj was dropped before it learnt not to require that .jars and generated native code be in the same dir) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
> On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
>
> > On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
> > > On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com)
> > > wrote:
> > >
> > > > I'm a fan of systemd [1]. And although I didn't like the fact that unit
> > > > files were stored in /lib, I understood the rationale since there was no
> > > > /share. However, I've just recently discovered [2] that after UsrMove
> > > > unit
> > > > files will be stored in /usr/lib. Can we not do better than this? And
> > > > I'd
> > > > really rather not work around the problem [3].
> > > >
> > > > Seriously, please don't do this.
> > >
> > > The unit files are in /lib for a couple of reasons. Firstly, before the
> > > /usr merge there was no /share, so we had to place them in
> > > /lib. Secondly I think that /lib is actually the better fit for them,
> > > simply because I consider them closely related to the code they wrap,
> > > and code belongs in lib, libexec or bin. How does that matter? Well, the
> > > unit files are very often dependendent on/closely related to the
> > > architecture, and make little sense to share them between archs. This
> > > applies to a couple of units we ship with systemd itself (for example
> > > the hugepages mount unit), but even more often to unit we don't ship
> > > ourselves (think mcelog). And distributing these unit files among a
> > > number of dirs would seriously suck.
> > >
> > This sounds like the unit files belong in %{_libdir} now? However, that
> > would mean that they can't go into noarch packages. So we probably need to
> > know a little more about just how architecture dependent these unit files
> > can be.
>
> No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
> two different versions for 32bit and 64bit. We want just one, hence they
> belong in /lib unconditionally)
>
Okay, so this is one more area where when people mispackage a library and
a program in the same subpackage, they'll get bitten?
Fair enough.
-Toshio
pgpxXKeMXVU3E.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide/F17 broken dependencies: please stop spamming
On Mon, 20 Feb 2012 19:09 +0100, KK (Kevin) wrote: > Bruno Wolff III wrote: > > The package can still be brought back, but now requires a review. > > This is really silly, why can't we just unretire the 2 or 3 packages which > were noticed the day they were retired and got an interested maintainer now? > (iwidgets was one of them, but I've seen mails about 1 or 2 others here.) > The reason a rereview is required for retired packages is because packages > tend to bitrot if orphaned for a long time, but this is NOT the situation > here. This is just completely pointless red tape making things a PITA for NO > reason whatsoever. Silly or not, apparently there are at least two package maintainers who could join and return the package easily, especially since one is the previous maintainer. And who maintains the "3 packages that are alive"? The same maintainers or additional ones? -- Fedora release 17 (Beefy Miracle) - Linux 3.3.0-0.rc3.git7.2.fc17.x86_64 loadavg: 1.68 1.03 0.48 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 785732] Upgrade to new upstream version
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=785732 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Net-STOMP-Client-1.4-1 |perl-Net-STOMP-Client-1.4-1 |.el6|.el5 --- Comment #7 from Fedora Update System 2012-02-20 14:03:16 EST --- perl-Net-STOMP-Client-1.4-1.el5 has been pushed to the Fedora EPEL 5 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 785732] Upgrade to new upstream version
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=785732 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Net-STOMP-Client-1.4-1 |perl-Net-STOMP-Client-1.4-1 |.fc16 |.el6 --- Comment #6 from Fedora Update System 2012-02-20 14:02:43 EST --- perl-Net-STOMP-Client-1.4-1.el6 has been pushed to the Fedora EPEL 6 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F16 Linux 3.1 soft lockups
2012/2/20 Dave Jones : > On Mon, Feb 20, 2012 at 06:39:54PM +0100, Michał Piotrowski wrote: > > Hi, > > > > W dniu 7 stycznia 2012 16:34 użytkownik Michał Piotrowski > > napisał: > > > Hi, > > > > > > I've noticed some strange soft lockup behaviour on my system (please > > > see the attachment). Soft lockup appears to be caused by kswapd0 > > > process. It seems to me that in both cases this error occured when I > > > used "git fsck --full" or "git gc" commands. > > > > > > > I've got the same problem on 3.2.6-3.fc16. Any ideas what might be > > happening? I turned off the swap partition to see if this help. > > Is this happening inside a virtual guest ? No, this system runs on Intel Atom 330 D945GCLF2. > > Dave > ___ > kernel mailing list > ker...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/kernel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide/F17 broken dependencies: please stop spamming
On 02/20/2012 11:39 PM, Kevin Kofler wrote: > Bruno Wolff III wrote: >> The package can still be brought back, but now requires a review. > > This is really silly, why can't we just unretire the 2 or 3 packages which > were noticed the day they were retired and got an interested maintainer now? > (iwidgets was one of them, but I've seen mails about 1 or 2 others here.) > The reason a rereview is required for retired packages is because packages > tend to bitrot if orphaned for a long time, but this is NOT the situation > here. This is just completely pointless red tape making things a PITA for NO > reason whatsoever. File a ticket with FESCo with your proposed change in the policy. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide/F17 broken dependencies: please stop spamming
Bruno Wolff III wrote: > The package can still be brought back, but now requires a review. This is really silly, why can't we just unretire the 2 or 3 packages which were noticed the day they were retired and got an interested maintainer now? (iwidgets was one of them, but I've seen mails about 1 or 2 others here.) The reason a rereview is required for retired packages is because packages tend to bitrot if orphaned for a long time, but this is NOT the situation here. This is just completely pointless red tape making things a PITA for NO reason whatsoever. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 Linux 3.1 soft lockups
On Mon, Feb 20, 2012 at 06:39:54PM +0100, Michał Piotrowski wrote: > Hi, > > W dniu 7 stycznia 2012 16:34 użytkownik Michał Piotrowski > napisał: > > Hi, > > > > I've noticed some strange soft lockup behaviour on my system (please > > see the attachment). Soft lockup appears to be caused by kswapd0 > > process. It seems to me that in both cases this error occured when I > > used "git fsck --full" or "git gc" commands. > > > > I've got the same problem on 3.2.6-3.fc16. Any ideas what might be > happening? I turned off the swap partition to see if this help. Is this happening inside a virtual guest ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Feb 20, 2012 6:25 PM, "Toshio Kuratomi" wrote:
> This sounds like the unit files belong in %{_libdir} now? However, that
> would mean that they can't go into noarch packages. So we probably need
to
> know a little more about just how architecture dependent these unit files
> can be.
There is some serious confusion going on here with Fedora and libexec, not
only regarding the lib/ vs share/ problem.
The recommended defaults as mentioned in the packaging guidelines are just
plain wrong. The recent bug we opened regarding this was just closed
wontfix.
Udev rules and systemd units belong to the installed daemon. This daemon
can only exist exactly one single time, and never be installed by multilib
packages, hence they do not ever belong into libdir. We support compat arch
only, not multiarch. Multiarch would look completely different anyway, and
compat arch does not need or want to involve libdir here.
The rules and units belong in 'libexecdir' which is upstream, and by LSB,
called and defined as /usr/lib/. Putting anything like that into
libdir is just wrong.
What the Fedora guidlines recommend here is not only wrong, it is also
playing bad with upstream, and as mentioned in the bug, I personally
consider it upstream-unfriendly, upstream-ignorant and against all common
sense in reducing the Linux distro balcanization, and just a bad example
how not to package tools today.
Please stop recommending or installing tools or other non shared objects in
libdir, they almost never belong there. I can see that a few exceptions can
be granted here, because it makes it easier to support binaries, that are
actually exclusively and directly bundled with a shared object, but
everything else just does not belong into libdir.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120212 changes
On Mon, 2012-02-20 at 17:36 +, Sérgio Basto wrote: > On Mon, 2012-02-20 at 11:29 -0600, Mike Chambers wrote: > > > > Is this still failing to compose and/or is there a bug to follow that > > might be covering this until it's fixed? > > In meantime if it helps, we got boot.iso in > http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.RC2/Fedora/x86_64/os/images/ Yea I have that one and the dvd.iso. But I also mirror the tree itself and that is more updated to install against. Although I might try compose it myself as like to learn that anyway. -- Mike Chambers Madisonville, KY "Best little town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 Linux 3.1 soft lockups
Hi, W dniu 7 stycznia 2012 16:34 użytkownik Michał Piotrowski napisał: > Hi, > > I've noticed some strange soft lockup behaviour on my system (please > see the attachment). Soft lockup appears to be caused by kswapd0 > process. It seems to me that in both cases this error occured when I > used "git fsck --full" or "git gc" commands. > I've got the same problem on 3.2.6-3.fc16. Any ideas what might be happening? I turned off the swap partition to see if this help. Feb 20 18:18:47 ozzy kernel: [33356.102007] BUG: soft lockup - CPU#1 stuck for 23s! [kswapd0:36] Feb 20 18:18:47 ozzy kernel: [33356.102008] Modules linked in: smsc47m192 hwmon_vid coretemp i2c_i801 serio_raw iTCO_wdt iTCO_vendor_support r8169 mii sata_si l i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Feb 20 18:18:47 ozzy kernel: [33356.102008] CPU 1 Feb 20 18:18:47 ozzy kernel: [33356.102008] Modules linked in: smsc47m192 hwmon_vid coretemp i2c_i801 serio_raw iTCO_wdt iTCO_vendor_support r8169 mii sata_si l i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Feb 20 18:18:47 ozzy kernel: [33356.102008] Feb 20 18:18:47 ozzy kernel: [33356.102008] Pid: 36, comm: kswapd0 Not tainted 3.2.6-3.fc16.x86_64 #1 /D945GCLF2 Feb 20 18:18:47 ozzy kernel: [33356.102008] RIP: 0010:[] [] _raw_spin_trylock+0x1/0x40 Feb 20 18:18:47 ozzy kernel: [33356.102008] RSP: 0018:88007834bb60 EFLAGS: 0282 Feb 20 18:18:47 ozzy kernel: [33356.102008] RAX: 9d689d68 RBX: 880042762700 RCX: 0014 Feb 20 18:18:47 ozzy kernel: [33356.102008] RDX: 9d68 RSI: 88004271bcc0 RDI: 880042762390 Feb 20 18:18:47 ozzy kernel: [33356.102008] RBP: 88007834bbc0 R08: 880042762ad8 R09: c900 Feb 20 18:18:47 ozzy kernel: [33356.102008] R10: R11: 0002 R12: 88007834bb00 Feb 20 18:18:47 ozzy kernel: [33356.102008] R13: 0282 R14: 88007834bb00 R15: 88007f293780 Feb 20 18:18:47 ozzy kernel: [33356.102008] FS: () GS:88007f28() knlGS: Feb 20 18:18:47 ozzy kernel: [33356.102008] CS: 0010 DS: ES: CR0: 8005003b Feb 20 18:18:47 ozzy kernel: [33356.102008] CR2: 7f4f3961e000 CR3: 01a05000 CR4: 06e0 Feb 20 18:18:47 ozzy kernel: [33356.102008] DR0: DR1: DR2: Feb 20 18:18:47 ozzy kernel: [33356.102008] DR3: DR6: 0ff0 DR7: 0400 Feb 20 18:18:47 ozzy kernel: [33356.102008] Process kswapd0 (pid: 36, threadinfo 88007834a000, task 88007b63c560) Feb 20 18:18:47 ozzy kernel: [33356.102008] Stack: Feb 20 18:18:47 ozzy kernel: [33356.102008] 88007834bbc0 8118ef15 0240 88004271bcc0 Feb 20 18:18:47 ozzy kernel: [33356.102008] 88007834bba0 88004271c140 ff04 88004272d500 Feb 20 18:18:47 ozzy kernel: [33356.102008] 88004272d4dc 880076191800 8800761918e0 Feb 20 18:18:47 ozzy kernel: [33356.102008] Call Trace: Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? shrink_dentry_list+0xa5/0x1e0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] prune_dcache_sb+0x121/0x140 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] prune_super+0x130/0x1a0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] shrink_slab+0x154/0x310 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] balance_pgdat+0x4fa/0x6c0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] kswapd+0x178/0x3d0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? __schedule+0x3d4/0x8c0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? remove_wait_queue+0x50/0x50 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? balance_pgdat+0x6c0/0x6c0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] kthread+0x8c/0xa0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] kernel_thread_helper+0x4/0x10 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? kthread_worker_fn+0x190/0x190 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? gs_change+0x13/0x13 Feb 20 18:18:47 ozzy kernel: [33356.102008] Code: 66 2e 0f 1f 84 00 00 00 00 00 55 48 c7 c2 ff ff ff ff be 01 00 00 00 48 89 e5 e8 8b fe ff ff 5d c3 90 90 90 90 90 90 90 90 90 55 <48> 89 e5 66 66 66 66 90 8b 17 31 c0 89 d1 c1 e9 10 66 39 ca 74 Feb 20 18:18:47 ozzy kernel: [33356.102008] Call Trace: Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? shrink_dentry_list+0xa5/0x1e0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] prune_dcache_sb+0x121/0x140 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] prune_super+0x130/0x1a0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] shrink_slab+0x154/0x310 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] balance_pgdat+0x4fa/0x6c0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] kswapd+0x178/0x3d0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? __schedule+0x3d4/0x8c0 Feb 20 18:18:47 ozzy kernel: [33356.102008] [] ? remove_wait_queue+0x50/0x50 Feb 20 18:18:47 ozzy ke
Re: F-17 Branched report: 20120212 changes
On Mon, 2012-02-20 at 11:29 -0600, Mike Chambers wrote: > On Sun, 2012-02-12 at 11:49 -0600, Mike Chambers wrote: > > On Sun, 2012-02-12 at 11:46 -0600, Mike Chambers wrote: > > > On Sun, 2012-02-12 at 11:25 -0600, Mike Chambers wrote: > > > > On Sun, 2012-02-12 at 10:08 +, Branched Report wrote: > > > > > Compose started at Sun Feb 12 08:15:07 UTC 2012 > > > > > > > > Think this compose worked as now see all the images/efi and everything > > > > else got created. Gonna try a test install to see what happens. > > > > > > > > > > OK , looked through the sub dir's and don't see a netinstall.iso or > > > boot.iso in the images dir like in F16 and later trees. These still > > > missing/still need to be created or is there another method now to > > > create an ISO to do nfs installs and such? > > > > And lemme reply to my own question...I checked i386 side and it does > > have the boot.iso but x86_64 does not (also my system). So guessing > > 64bit side failed to create one for one problem or another? > > Sooo, this problem still exists, or at least still don't see any > boot.iso's being created. > > Is this still failing to compose and/or is there a bug to follow that > might be covering this until it's fixed? In meantime if it helps, we got boot.iso in http://dl.fedoraproject.org/pub/alt/stage/17-Alpha.RC2/Fedora/x86_64/os/images/ -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-17 Branched report: 20120212 changes
On Sun, 2012-02-12 at 11:49 -0600, Mike Chambers wrote: > On Sun, 2012-02-12 at 11:46 -0600, Mike Chambers wrote: > > On Sun, 2012-02-12 at 11:25 -0600, Mike Chambers wrote: > > > On Sun, 2012-02-12 at 10:08 +, Branched Report wrote: > > > > Compose started at Sun Feb 12 08:15:07 UTC 2012 > > > > > > Think this compose worked as now see all the images/efi and everything > > > else got created. Gonna try a test install to see what happens. > > > > > > > OK , looked through the sub dir's and don't see a netinstall.iso or > > boot.iso in the images dir like in F16 and later trees. These still > > missing/still need to be created or is there another method now to > > create an ISO to do nfs installs and such? > > And lemme reply to my own question...I checked i386 side and it does > have the boot.iso but x86_64 does not (also my system). So guessing > 64bit side failed to create one for one problem or another? Sooo, this problem still exists, or at least still don't see any boot.iso's being created. Is this still failing to compose and/or is there a bug to follow that might be covering this until it's fixed? -- Mike Chambers Madisonville, KY "Best little town on Earth!" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
> > On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com)
> > wrote:
> >
> > > I'm a fan of systemd [1]. And although I didn't like the fact that unit
> > > files were stored in /lib, I understood the rationale since there was no
> > > /share. However, I've just recently discovered [2] that after UsrMove unit
> > > files will be stored in /usr/lib. Can we not do better than this? And I'd
> > > really rather not work around the problem [3].
> > >
> > > Seriously, please don't do this.
> >
> > The unit files are in /lib for a couple of reasons. Firstly, before the
> > /usr merge there was no /share, so we had to place them in
> > /lib. Secondly I think that /lib is actually the better fit for them,
> > simply because I consider them closely related to the code they wrap,
> > and code belongs in lib, libexec or bin. How does that matter? Well, the
> > unit files are very often dependendent on/closely related to the
> > architecture, and make little sense to share them between archs. This
> > applies to a couple of units we ship with systemd itself (for example
> > the hugepages mount unit), but even more often to unit we don't ship
> > ourselves (think mcelog). And distributing these unit files among a
> > number of dirs would seriously suck.
> >
> This sounds like the unit files belong in %{_libdir} now? However, that
> would mean that they can't go into noarch packages. So we probably need to
> know a little more about just how architecture dependent these unit files
> can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)
Best way to specify the path is %{_unitdir} however, which points to the
actual unit dir, and has been updated for the /usr merge already.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
> On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com) wrote:
>
> > I'm a fan of systemd [1]. And although I didn't like the fact that unit
> > files were stored in /lib, I understood the rationale since there was no
> > /share. However, I've just recently discovered [2] that after UsrMove unit
> > files will be stored in /usr/lib. Can we not do better than this? And I'd
> > really rather not work around the problem [3].
> >
> > Seriously, please don't do this.
>
> The unit files are in /lib for a couple of reasons. Firstly, before the
> /usr merge there was no /share, so we had to place them in
> /lib. Secondly I think that /lib is actually the better fit for them,
> simply because I consider them closely related to the code they wrap,
> and code belongs in lib, libexec or bin. How does that matter? Well, the
> unit files are very often dependendent on/closely related to the
> architecture, and make little sense to share them between archs. This
> applies to a couple of units we ship with systemd itself (for example
> the hugepages mount unit), but even more often to unit we don't ship
> ourselves (think mcelog). And distributing these unit files among a
> number of dirs would seriously suck.
>
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need to
know a little more about just how architecture dependent these unit files
can be.
-Toshio
pgpaq3J20e4fy.pgp
Description: PGP signature
--
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
File MooseX-MethodAttributes-0.27.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-MooseX-MethodAttributes: bd8c1e4e97cad114dc98cc505cd1ae37 MooseX-MethodAttributes-0.27.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-FormHandler/f17] update to 0.36003
Summary of changes: f76910d... update to 0.36003 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-HTML-FormHandler] update to 0.36003
commit f76910de1142086398dfcf399e50a06ef062842a
Author: Iain Arnell
Date: Mon Feb 20 09:32:18 2012 -0700
update to 0.36003
.gitignore |1 +
perl-HTML-FormHandler.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 79afd17..1bc689c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/HTML-FormHandler-0.36000.tar.gz
/HTML-FormHandler-0.36001.tar.gz
/HTML-FormHandler-0.36002.tar.gz
+/HTML-FormHandler-0.36003.tar.gz
diff --git a/perl-HTML-FormHandler.spec b/perl-HTML-FormHandler.spec
index 8115ded..f87ca77 100644
--- a/perl-HTML-FormHandler.spec
+++ b/perl-HTML-FormHandler.spec
@@ -1,5 +1,5 @@
Name: perl-HTML-FormHandler
-Version:0.36002
+Version:0.36003
Release:1%{?dist}
Summary:HTML forms using Moose
License:GPL+ or Artistic
@@ -83,6 +83,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Feb 20 2012 Iain Arnell 0.36003-1
+- update to latest upstream version
+
* Sat Feb 04 2012 Iain Arnell 0.36002-1
- update to latest upstream version
diff --git a/sources b/sources
index e1042c2..e9e9afd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e2071b069d755e5f38f20315a7bcccbe HTML-FormHandler-0.36002.tar.gz
+20ccce17d96119df7a3c3a6d14512379 HTML-FormHandler-0.36003.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide/F17 broken dependencies: please stop spamming
On Mon, Feb 20, 2012 at 16:56:28 +0100, Patrick Monnerat wrote: > On Mon, 2012-02-20 at 13:01 +0100, Michael Schwendt wrote: > > > *You* could have avoided this by _retiring_ "insight" properly: > > http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > *** This is not a normal end of life: this is an assassination *** > > There's a maintainer (krege) who's OK to take ownership of iwidgets, but > he can't because the package has been deprecated (despite the > requirement from 3 packages that are still alive!) instead of being > simply orphaned. Note that the list of packages being removed and their dependencies was posted at least a month before it happened (probably more, but I don't remember for sure). Packagers really need to read the devel list so that stuff like this doesn't catch them by surprise. The package can still be brought back, but now requires a review. But since there are at least two people interested in this happening, getting the review done shouldn't be too big of a deal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide/F17 broken dependencies: please stop spamming
On Mon, 2012-02-20 at 13:01 +0100, Michael Schwendt wrote: > *You* could have avoided this by _retiring_ "insight" properly: > http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life *** This is not a normal end of life: this is an assassination *** There's a maintainer (krege) who's OK to take ownership of iwidgets, but he can't because the package has been deprecated (despite the requirement from 3 packages that are still alive!) instead of being simply orphaned. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 17 Alpha Go/No-Go Meeting, Wednesday, February 22 @ 17:00 EST
Join us on irc.freenode.net in #fedora-meeting for this important meeting, wherein we shall determine the readiness of the Alpha taste-testing of the Beefy Miracle, better known as Fedora 17. Wednesday, February 22, 2011 @22:00 UTC (17:00 EST/14:00 PST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 17 Alpha Blocker list: http://fedoraproject.org/wiki/Current_Release_Blockers Cheers! -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 13:51, Lennart Poettering wrote: > On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: >> Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : >> >> > Something similar applies to udev rules and similar "almost code" bits. >> > >> > But yeah, I know people will disagree with us on this. >> >> Lennart , you realise, do you, that people are unlikely to fix the historical >> exceptions they've benefited from as part of systemd or usrmove if you're >> championing the creation of new exceptions for your own sake in >> parallel. It's not a new exception, it's the reality for udev since ~6 years. > 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. > > The thing is simply that there are cases where things are clear that > they belong on /lib, and others where it is clear that they belong in > /share. And then there is this huge grey area in the middle of those > files where things aren't super clear. The line between /lib and /share > is blurry. And since about always people then ended up coming to > different conclusions and hence dropped some stuff that you don't think > belongs in /lib into that very dir, and some stuff that others don't > think belongs in /share into that very dir. > > I think a rule of "if in doubt, /lib is preferable" is the safe choice > here though. In the case for unit files we have a couple of good reasons > to consider them arch-specific enough beyond just mere "if in > doubt". (see my earlier mail for them). I second that. >> Systemd unit files are no more cody and app-specific (and in fact quite a lot >> less) than emacs lisp files or java jar files or docbook xslt processing >> rules >> or a lot more stuff I'm forgetting about right now and those have been in >> /usr/share for a *long* time. > > I see a ton of jar files in /usr/lib here actually. > > The world isn't black and white. The separation between /share and /lib > is more complex than simple binary logic. That sounds right. And for the same reason, the udev rules need to stay in lib/ and not move to share/. Udev rules are not meant to be *shared* across anything, not across different machines, not across architectures, not across multiple packages. They only get installed _for_ the udev version that is the primary architecture, and there can only be one udev version installed on a system. The rules get installed by multiple packages, sure; but they do not involve any, and must actually prevent any sort of *sharing*. The very same that is true for udev, is true for sytemd units. Rules and units do not provide any additional or optional data, they influence the actual global system runtime behaviour, they change and extend the system, very much like a service plugin or a shared object. That they are actually text file, is an implementation detail that should not have influence on the installation directory. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Dne 20.2.2012 13:51, Lennart Poettering napsal(a): On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : Something similar applies to udev rules and similar "almost code" bits. But yeah, I know people will disagree with us on this. Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel. 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. No more for Ruby ... Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: > > Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : > > > Something similar applies to udev rules and similar "almost code" bits. > > > > But yeah, I know people will disagree with us on this. > > Lennart , you realise, do you, that people are unlikely to fix the historical > exceptions they've benefited from as part of systemd or usrmove if you're > championing the creation of new exceptions for your own sake in > parallel. 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. The thing is simply that there are cases where things are clear that they belong on /lib, and others where it is clear that they belong in /share. And then there is this huge grey area in the middle of those files where things aren't super clear. The line between /lib and /share is blurry. And since about always people then ended up coming to different conclusions and hence dropped some stuff that you don't think belongs in /lib into that very dir, and some stuff that others don't think belongs in /share into that very dir. I think a rule of "if in doubt, /lib is preferable" is the safe choice here though. In the case for unit files we have a couple of good reasons to consider them arch-specific enough beyond just mere "if in doubt". (see my earlier mail for them). > Systemd unit files are no more cody and app-specific (and in fact quite a lot > less) than emacs lisp files or java jar files or docbook xslt processing rules > or a lot more stuff I'm forgetting about right now and those have been in > /usr/share for a *long* time. I see a ton of jar files in /usr/lib here actually. The world isn't black and white. The separation between /share and /lib is more complex than simple binary logic. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 795117] perl-LWP-Protocol-https-6.03 is available
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=795117 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-LWP-Protocol-https-6.0 ||3-1.fc18 Resolution||NOTABUG Last Closed||2012-02-20 07:34:29 -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : > Something similar applies to udev rules and similar "almost code" bits. > > But yeah, I know people will disagree with us on this. Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel. Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com) wrote: > I'm a fan of systemd [1]. And although I didn't like the fact that unit > files were stored in /lib, I understood the rationale since there was no > /share. However, I've just recently discovered [2] that after UsrMove unit > files will be stored in /usr/lib. Can we not do better than this? And I'd > really rather not work around the problem [3]. > > Seriously, please don't do this. The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck. We need to retain compatibility for the directory from before the /usr merge and I think lib/ is actually a better place for this than share/, hence I think I see little reason to move this. /share is a great place for truly arch independent data that is shared between multiple applications, and which is read by multiple applications (such as icons, man pages, dictionaries and suchlike). But for stuff that is very close to specific bits of code, and is only read by a single tool /lib is the much better place I think. A good way to think about this is maybe "if I remove something in /lib it seriously impacts the control flow of code" vs. "if I remove something in /share it hast little impact on control flow". Something similar applies to udev rules and similar "almost code" bits. But yeah, I know people will disagree with us on this. Maybe a different way to think about this is to think about shell scripts. We ship those in /bin, and not in /share either. And it is good that way. And if that still doesn't convince you, then I hope at least the "keep compat" issue pointed out above matters enough to you. So, no plans to move the unit files to /usr/share. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide/F17 broken dependencies: please stop spamming
On Mon, 20 Feb 2012 11:23:53 +0100, PM (Patrick) wrote: > > Since packages belonging to maintainer that have not changed their > password have been removed, I keep being notified about a broken > dependency in package "insight", depending on "iwidgets". > > "iwidgets" has been deprecated and thus, as long as this situation > remains, "insight" will be broken. > > Consequently, I orphaned "insight" because it is not maintainable > anymore. > > Even since I orphaned it, I receive lots of reports about broken > dependencies for rawhide and F17. > > Please someone: do something to stop this spamming. I do not want to be > constrained to blacklist the buildsys :-( > > Thanks to whoever can take an action. *You* could have avoided this by _retiring_ "insight" properly: http://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life You could take "insight" back to retire it. The reason you receive the Rawhide build report mails is that you're a member of the insight-owner@ mail alias. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.0-0.rc3.git7.2.fc17.x86_64 loadavg: 0.14 0.25 0.19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling?!
Thanks all for a remarkable set of advice including what not to do (Petr M), a hint about what to do (Ralf E) and another hint how it could be done (Aleksandra B). I have been able to update the packaging to only bundle the boost tools subdirectory. I presume that this should make everyone happy. More in the bug (790628, later). Last but not least: I need to apologize to David Timms, who in the bug pointed out that I was bundling while I denied it. To be both wrong and rude, which I was in some comment, is bad manners. I apologize for that. Just in case someone is curious: Aleksandra's package don't build without boost source present, at least not for me. Still, it was an important part of how to solve it. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File HTTP-Negotiate-6.01.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-HTTP-Negotiate: 1236195250e264d7436e7bb02031671b HTTP-Negotiate-6.01.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 795114] perl-HTTP-Daemon-6.01 is available
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=795114 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-HTTP-Daemon-6.01-1.fc1 ||8 Resolution||RAWHIDE Last Closed||2012-02-20 05:31:00 -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F-17 Branched report: 20120220 changes
Compose started at Mon Feb 20 08:15:08 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [Pound] Pound-2.6-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [asterisk] asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaEvt.so.3(OPENAIS_EVT_B.01.01)(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaEvt.so.3()(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaClm.so.3(OPENAIS_CLM_B.01.01)(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaClm.so.3()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [banshee] banshee-meego-2.2.1-3.fc17.x86_64 requires mutter-meego [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [ceph] ceph-0.37-2.fc17.i686 requires libtcmalloc.so.0 ceph-0.37-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) ceph-fuse-0.37-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) [coccinella] coccinella-0.96.20-3.fc17.noarch requires memchan [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [curry] curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dlm] dlm-3.99.0-5.fc17.x86_64 requires libcfg.so.4(COROSYNC_CFG_0.82)(64bit) dlm-3.99.0-5.fc17.x86_64 requires libcfg.so.4()(64bit) [elice] elice-0.323-6.fc17.x86_64 requires ruby(abi) = 0:1.8 [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [fantasdic] fantasdic-1.0-0.9.beta7.fc17.noarch requires ruby(gettext-package) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gdal] gdal-ruby-1.7.3-12.fc17.x86_64 requires libruby.so.1.8()(64bit) [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [geos] geos-ruby-3.3.2-1.fc17.x86_64 requires libruby.so.1.8()(64bit) [gnatcoll] gnatcoll-2011-6.fc17.i686 requires libgnat-4.6.so gnatcoll-2011-6.fc17.i686 requires libgnarl-4.6.so gnatcoll-2011-6.fc17.x86_64 requires libgnat-4.6.so()(64bit) gnatcoll-2011-6.fc17.x86_64 requires libgnarl-4.6.so()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnucash] gnucash-2.4.8-1.fc17.x86_64 requires libgoffice-0.8.so.8()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gphpedit] gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requires libgtkhtml-2.so.0()(64bit) [gpsdrive] gpsdrive-2.11-10.fc17.x86_64 requires libmapnik.so.0.7()(64bit) gpsdrive-2.11-10
rawhide/F17 broken dependencies: please stop spamming
Since packages belonging to maintainer that have not changed their password have been removed, I keep being notified about a broken dependency in package "insight", depending on "iwidgets". "iwidgets" has been deprecated and thus, as long as this situation remains, "insight" will be broken. Consequently, I orphaned "insight" because it is not maintainable anymore. Even since I orphaned it, I receive lots of reports about broken dependencies for rawhide and F17. Please someone: do something to stop this spamming. I do not want to be constrained to blacklist the buildsys :-( Thanks to whoever can take an action. Cheers, Patrick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re : Self introduction
> I'd also like to see OpenCPN packaged in Fedora: > https://bugzilla.redhat.com/show_bug.cgi?id=612224 > I'm part of the upstream team and I already build Fedora packages there. > Seeing it included in Fedora would be much easier for our users. I'll > prepare updated spec & srpm and report asap. A quick followup on this one: I uploaded spec & srpm for latest 2.5.0 http://je.onfray.fr/dl/opencpn.spec http://je.onfray.fr/dl/opencpn-2.5.0-1.fc16.src.rpm Original review request updated. Now I'm looking for a sponsor, my FAS account is sethdart. Awayting comments. Thanks a lot, Jean-Eudes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling?!
Ralf Ertzinger writes: > Hi. > > On Sun, 19 Feb 2012 22:26:20 +0100, Petr Machata wrote > >> Please don't do this. >> >> The main reason being that header code from bundled boost is in >> general not binary compatible with the native code from system >> boost. It might maybe happen to work, but is likely to fail in >> obscure and hard to debug ways if the version of bundled boost >> differs from system boost. > > If I understand the OP right then ASL comes with it's own build > system, and it is the build system that uses the bundled boost > libraries. The ASL itself (the binaries that end up in the RPM) > can be built against the system boost. Ah, that shouldn't be a problem I guess. Thanks, PM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: JPEG_LIB_VERSION in libjpeg-turbo
On Sat, Feb 18, 2012 at 09:46:56PM +0100, Julian Sikorski wrote: > Dear fellow Fedora packagers > > I was trying to get MAME [1] to use system libjpeg [2]. The problem is > that MAME needs jpeg_mem_src, which is only defined if libjpeg-turbo > compiled with --with-jpeg8 switch, which is not the case for the Fedora > package. > Would such change be feasible to introduce? If not, I assume that I have > no other choice as to use the bundled copy (not really relevant here > since MAME is an RPM Fusion package). You can specify your own data sources with the libjpeg shipped with fedora (jped_decompress_struct::src). What is missing is a default implementation for a source reading from memory. libjpeg8 ships one by default, but older libjpeg don't have it. However, the mem source should only be a few functions, so you can probably only bundle a copy of jpeg_mem_src in your package and use the system libjpeg. I did something very similar in spice, but it was for jpeg_mem_dest, not jpeg_mem_src (ie similar functionality, but for compression instead of decompression), see http://cgit.freedesktop.org/spice/spice/tree/server/mjpeg_encoder.c#n95 Hope that helps, Christophe pgp8CiLPIuhA2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
