Re: Packages requires /sbin/service.
On Sun, Mar 17, 2013 at 8:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 18.03.2013 01:06, schrieb Nico Kadel-Garcia: On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov lemen...@gmail.com wrote: 2013/3/15 Lukáš Nykrýn lnyk...@redhat.com: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. ... rtpproxy Fixed. This is a bad, bad, bad idea for any packages that are going to remain backwards compatible with RHEL, for compilation under EPEL or other backporting. Either switch to systemd, or stick with the old location and allow initscripts to correctly include the old reference. Do not pick a hallfways fix that isn't backwards compatible at all. * Fedora has done UsrMove with F17 * Now we have F18 * in a short we have F19 * RHEL7 will be base on F18/F19 ANY reference in Fedora to /sbin and /bin is BOGUS it leads to all sorts of troubles it leads to additional symlink reslovement If SysV init style scripts are staying in use, even as a compatibility fallback, don't edit the references to them just to prove something. It breaks backporting and forward porting and cross-compatibility for every existing versoin of RHEL, which are still needed for compatibility because *systemd can't be ported back to RHEL 6 or earlier.* I've tried, it's a dependency and critical component upgrade nightmare. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-03-18 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-03-18 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again tomorrow / today! We should be doing Alpha TC1 this week, so we need to look at the status of current F19 and see what needs to be done to make that happen. We can discuss my criteria revision proposal further, and follow up on last week's KDE Test Day and make plans for this week's GNOME Test Day. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130318 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 19 Alpha status 3. Criteria re-design 4. Test Days 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ 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: dnf installs cron.hourly
On 03/15/2013 12:16 PM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Hi Neal, hi Thread, This is a legit concern yet majority of people appreciates having the metadata handy and only a minority worries about the traffic. An option should be added to /etc/dnf/dnf.conf to turn this off. The default will stay on. I've opened a bugzilla for this: https://bugzilla.redhat.com/show_bug.cgi?id=922664 A move to systemd timer units is also in the pipe (there are still some minor issues to settle first) https://bugzilla.redhat.com/show_bug.cgi?id=878826 What I would like to see at some point, and strongly believe it is the right, generic and simple solution for many similar cases, is to have NetworkManager let user decide what network connections are suitable for tasks like this (but also many others, including regular backups and other syncing tasks) and which are not: https://bugzilla.redhat.com/show_bug.cgi?id=896572 Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/15/2013 04:16 PM, Reindl Harald wrote: and hwat let you come to the conclusion that if you have it to enable in a config makes anything different? have it enabled as DEFAULT is plain stupid did you ever see checksu mismatch from YUM? i saw this once download the metadata from ALL known mirrors resultig in some hundret MB traffic over night in background I will consider a quick-to-give-up routes for the automated makecache runs: https://bugzilla.redhat.com/show_bug.cgi?id=922667 thanks god that i have a) a fast line b) no traffic limit if you pay for traffic over limits such features can ruin you It's not an excuse for DNF or any other application, but bugs and unexpected routes through the download code happen (especially if it's designed not to give up if some partial operation fails). So with expensive connections you are always exposed to this danger as long as you use any software that stays running for long periods of time (or is executed repeatedly like 'dnf makecache') and communicates over the network. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/15/2013 07:13 PM, Luya Tshimbalanga wrote: On 15/03/13 04:16 AM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Why not using systemd Calender Time? https://fedoraproject.org/wiki/Features/SystemdCalendarTimers There are plans to use the systemd timer services: https://bugzilla.redhat.com/show_bug.cgi?id=878826 Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Mon, 2013-03-18 at 09:53 +0100, Ales Kozumplik wrote: What I would like to see at some point, and strongly believe it is the right, generic and simple solution for many similar cases, is to have NetworkManager let user decide what network connections are suitable for tasks like this (but also many others, including regular backups and other syncing tasks) and which are not: https://bugzilla.redhat.com/show_bug.cgi?id=896572 PackageKit already has an option to check for updates on mobile broadband (i.e bandwidth-capped or pay-as-you-use connections). Can't DNF do the same? The proposed system of targets seems extremely complex, for a functionality that is already possible... -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/18/2013 10:08 AM, Mathieu Bridon wrote: PackageKit already has an option to check for updates on mobile broadband (i.e bandwidth-capped or pay-as-you-use connections). How does PackageKit implement this? Can't DNF do the same? The proposed system of targets seems extremely complex, for a functionality that is already possible... It is really not that bad, and the quantity of complexity in it is well hidden from everyone but NM and systemd. And it will give more to the users: they will only decide once what connections are available the regular background network tasks and which are not for, for all the applications. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Mon, Mar 18, 2013 at 9:53 AM, Ales Kozumplik akozu...@redhat.com wrote: On 03/15/2013 12:16 PM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Hi Neal, hi Thread, This is a legit concern yet majority of people appreciates having the metadata handy and only a minority worries about the traffic. Downloading the data *every hour* is overkill though. Once a day should be more then enough. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On Mon, 2013-03-18 at 10:21 +0100, Ales Kozumplik wrote: On 03/18/2013 10:08 AM, Mathieu Bridon wrote: PackageKit already has an option to check for updates on mobile broadband (i.e bandwidth-capped or pay-as-you-use connections). How does PackageKit implement this? By using the NM api I guess? Can't DNF do the same? The proposed system of targets seems extremely complex, for a functionality that is already possible... It is really not that bad, and the quantity of complexity in it is well hidden from everyone but NM and systemd. And it will give more to the users: they will only decide once what connections are available the regular background network tasks and which are not for, for all the applications. But applications can already query NM to get details on the state of the connection. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
Le lundi 18 mars 2013 à 17:42 +0800, Mathieu Bridon a écrit : Can't DNF do the same? The proposed system of targets seems extremely complex, for a functionality that is already possible... It is really not that bad, and the quantity of complexity in it is well hidden from everyone but NM and systemd. And it will give more to the users: they will only decide once what connections are available the regular background network tasks and which are not for, for all the applications. But applications can already query NM to get details on the state of the connection. But the logic of deciding which is which is likely in pk, not in nm. So implementing it everywhere will requires to duplicate the code and logic. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Mon, Mar 18, 2013 at 5:22 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 18.03.2013 08:27, schrieb Nico Kadel-Garcia:
On Sun, Mar 17, 2013 at 8:10 PM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 18.03.2013 01:06, schrieb Nico Kadel-Garcia:
On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov lemen...@gmail.com
wrote:
2013/3/15 Lukáš Nykrýn lnyk...@redhat.com:
After usr move packages should not install files to /sbin. Unfortunately
there is a lot of packages requiring /sbin/service, which was recently
moved
to /usr/sbin/, and these packages were uninstallable. As a workaround I
have
put Provides: /sbin/service in the initscript spec, but I think that we
should do a proper fix.
So if your package is in following list, please change your Reguires to
/usr/sbin/service.
...
rtpproxy
Fixed.
This is a bad, bad, bad idea for any packages that are going to remain
backwards compatible with RHEL, for compilation under EPEL or other
backporting. Either switch to systemd, or stick with the old location
and allow initscripts to correctly include the old reference. Do not
pick a hallfways fix that isn't backwards compatible at all.
* Fedora has done UsrMove with F17
* Now we have F18
* in a short we have F19
* RHEL7 will be base on F18/F19
ANY reference in Fedora to /sbin and /bin is BOGUS
it leads to all sorts of troubles
it leads to additional symlink reslovement
If SysV init style scripts are staying in use, even as a compatibility
fallback, don't edit the references to them just to prove something.
It breaks backporting and forward porting and cross-compatibility for
every existing versoin of RHEL, which are still needed for
compatibility because *systemd can't be ported back to RHEL 6 or
earlier.* I've tried, it's a dependency and critical component upgrade
nightmare
so what - then it needs a lot of if-clauses in the SPEC
it makes pretty no sense to wait 10 years until the
last RHEL version is on systemd and has also UsrMove
to finish this things for fedora
Yes, it means wait 10 years, just as it does for most software using
/bin/rm and /bin/mkdir. Or at least don't aggressively go update
*every single* init script using package in a way that breaks
compatibility with every older distribution for no performance gain.
Switch to systemd instead, which actually gets you an improvement.
There are examples of just how to do that in my Samba 4.0.3 backport
to RHEL 6 work at:
In particular, if you have to backport a systemd written Fedora
package to older Fedora or RHEL, use something like this from
https://github.com/nkadel/samba-4.0.3-srpm/blob/master/samba.spec.
I've somewhat simplified the example below to leave out the more
complex domain controller and winbind examples, but it's solid working
code, and I'd resent having to stuff in another set of conditionals
because the /sbin/chkconfig and /sbin/server paths, which will
remain valid, are simply not mentioned in another more basic RPM.
# Use systemd, not SysV init scripts, as appropriate
%if 0%{?fedora} 15 || 0%{?rhel} 6
%global with_systemd 1
%else
%global with_systemd 0
%endif
# RHEL specific init scripts, in case systemd not available
Source100: nmb.init
Source101: smb.init
%if %with_systemd
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
%else
Requires(post): /sbin/chkconfig, /sbin/service
Requires(preun): /sbin/chkconfig, /sbin/service
Requires(postun): /sbin/chkconfig, /sbin/service
%endif
%if %with_systemd
install -d -m 0755 %{buildroot}%{_unitdir}
%if %with_dc
for i in nmb smb ; do
%else
for i in nmb smb; do
%endif # with_dc
cat packaging/systemd/$i.service | sed -e
's@Type=forking@Type=forking\nEnvironment=KRB5CCNAME=/run/samba/krb5cc_samba@g'
tmp$i.service
install -m 0644 tmp$i.service %{buildroot}%{_unitdir}/$i.service
done
%else
install -d -m 0755 %{buildroot}%{_initrddir}
install -m 0755 %{SOURCE100} %{buildroot}%{_initrddir}/nmb
install -m 0755 %{SOURCE101} %{buildroot}%{_initrddir}/smb
%endif # with_systemd
%post
%if %with_systemd
%systemd_post smb.service
%systemd_post nmb.service
%else
/sbin/chkconfig --add smb
/sbin/chkconfig --add nmb
if [ $1 -ge 1 ]; then
/sbin/service smb condrestart /dev/null 21 || :
/sbin/service nmb condrestart /dev/null 21 || :
fi
%endif # with_systemd
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unhelpful update descriptions
- Original Message - On 03/14/2013 05:02 PM, Rahul Sundaram wrote: On 03/14/2013 04:33 PM, Przemek Klosowski wrote: I didn't realize that my method was 'relying on the kindness of strangers' for including the relevant CVE data in the changelog, but it often gives a quick, direct answer for the specific system you're on. If this was accidental rather than a policy, it'd make sense to codify and preserve the practice of including such security patch status in RPM changelogs, particularly when they are backported but in general case as well. When patches are backported, typically the changelog would cover the reason for doing so but not necessarily when a new update fixes a bunch of issues and security issue happens to be one of them. In some cases, there is no CVE id assigned for the problem either but if you want to request that packaging guidelines recommend this in the general case, file it at https://fedorahosted.org/fpc/ OK, let's see whether others like it too: https://fedorahosted.org/fpc/ticket/267 It's really not as easy as it sounds like as it depends also on how upstream's deal with CVEs and believe me (as I was a part of WebKit upstream security team) - it's a mess. So by requiring such information, users could expect it it's an authoritative source they can trust - but it will never be. For patches or minor update with known CVE, I always include it. For the rest, not sure there's even chance to know what's within the tarball. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 03/18/2013 10:33 AM, drago01 wrote: On Mon, Mar 18, 2013 at 9:53 AM, Ales Kozumplikakozu...@redhat.com wrote: On 03/15/2013 12:16 PM, Neal Becker wrote: I don't think users would expect that install of dnf would without asking (or control) automatically run dnf-makecache. At least, this should be controllable via /etc/sysconfig. Further, I think it's not consistent with Fedora practice to enable this on default by installing the package. Hi Neal, hi Thread, This is a legit concern yet majority of people appreciates having the metadata handy and only a minority worries about the traffic. Downloading the data *every hour* is overkill though. Once a day should be more then enough. Not necessarily, it depends on how quickly are old packages removed from the mirrors, the minimum is not dictated by anyone. The metadata expiry time could be used as the lower bound on this but then there could be repos that have this set to less than an hour for instance. In any case: this value is inspected on every 'dnf makecache' execution so for normal repositories that only expire once a day or so nothing is downloaded 96% of the time. Note that the Fedora update repositories expire every 6 hours. All that said, we shouldn't bother with pathological cases like that and only run the metadata check every six hours or less often. So, basically, you are right. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 18 March 2013 09:21, Ales Kozumplik akozu...@redhat.com wrote: How does PackageKit implement this? We ask NetworkManager (or connman) for the network adaptor type. This seems to work well, unless someone uses their phone as a portable hotspot (i.e. Wifi) and then it fails hard. Code is in https://gitorious.org/packagekit/packagekit/trees/master/src -- see pk-network-stack*.[c|h]. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dnf installs cron.hourly
On 18/03/13 12:39, Richard Hughes wrote: On 18 March 2013 09:21, Ales Kozumplik akozu...@redhat.com wrote: How does PackageKit implement this? We ask NetworkManager (or connman) for the network adaptor type. This seems to work well, unless someone uses their phone as a portable hotspot (i.e. Wifi) and then it fails hard. Code is in https://gitorious.org/packagekit/packagekit/trees/master/src -- see pk-network-stack*.[c|h]. It's all based on an erroneous presumption however, namely that it is only mobile broadband connections which have bandwidth restrictions/costs. A single unit of usage on my VDSL connection is worth 2.5Gb of data during working hours, 50Gb in the evenings or weekends and 1Tb in the early hours of the morning. Not surprisingly therefore I prefer it if updates don't suddenly start downloading during working hours, which is exactly what happened when I upgraded to F18. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?
On Sun, Mar 17, 2013 at 10:07 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kees Cook wrote: AFD was a single specific program doing a very specific task and hardly represents an average workload. I remain extremely disappointed that the default-on state was reverted. Ubuntu has had this feature enabled for YEARS now, and it stopped quite a few exploits cold. Who knows what other applications this extremely surprising and incompatible change breaks? BTW determining this accurately should be fairly doable[1]. Just look for symlink() and link() calls (and recursively through wrapper APIs / language bindings). These syscalls are fairly rare. Mirek [1] Well, fairly doable when compared to the /tmp-on-tmpfs, which is just impossible. It's still man-weeks of work. Pragmatically speaking, It did not break Ubuntu is not a QA technique that makes me happy, but might be good enough anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Fri, 15.03.13 11:07, Dan Mashal (dan.mas...@gmail.com) wrote: On Fri, Mar 15, 2013 at 11:04 AM, Michal Schmidt mschm...@redhat.com wrote: On 03/15/2013 07:00 PM, Dan Mashal wrote: Looks like you guys added provides(service) and fixed the problem. Yes, Lukáš added it. He even mentioned it in the email that started this thread. Still it would be nice to drop legacy provide name after packages stop Requiring it. Michal Well I was reading an IRC discussion on devel. I'm like a horse with blinders. This used to work and doesn't anymore. Which leads me to my next point: What does it hurt to have the command there? In fact you should just rename systemctl service and make it understand service commands. It's annoying over all. Nope, I am pretty sure I won't add code to systemctl itself to manipulate /etc/rc.d/... It's OK to invoke service from systemctl, and that's what we do if we are run for a SysV service. It's also OK to invoke systemctl from service, and that's also what is being done. But merging the codebases, no thank you. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Improving the Fedora boot experience
On Tue, Mar 12, 2013 at 10:31 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, Mar 12, 2013 at 08:01:54AM -0400, Nico Kadel-Garcia wrote: And the main lesson her is don't clutter the user interface with useless graphical eye candy. It makes the boot process require unnecessary system resources. The new Fedora installation setup is currently a *nightmare*. It works very poorly through low bandwidth remote connections, the graphics are poorly labeled and very confusing, and the spoke and hub model is a bit of big vision coneptual weirdness that is actively preventing people from wanting to touch Fedora. It's an *installer*, keeping it as lightweight and simple as possible with minimal graphics means that it will display better on small virtual system or remote KVM displays. But this has been discarded in favor or an overly bulky and complex system that is showing off what are quite fragile graphical features rather than simply doing the *job*. Citation needed. Anaconda has been graphical for ages, and has probably gotten lighter after the rewrite if anything. --CJD There's a reason I've tended to use the linux text option, which has, unfortunately, all but been discarded or been made useless with curses based tools that no longer match the options of the X based GUI's. And lighter or not, the GUI still takes longer to load and to browse around, especially in poor quality graphical environments. We don't all hae a bit screen to play with, some of us are working through virtualization systems or remote KVM's with limited and burdensome graphical tools that the X based installer hinders. Try installing an older or vaguely recent Fedora with pure text mode or a serial console, especially when your remote site can't afford real remote KVM's and has a serial concentrator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Am 18.03.2013 04:32, schrieb Mathieu Bridon: On Sun, 2013-03-17 at 17:31 +0100, Reindl Harald wrote: Am 17.03.2013 17:12, schrieb Sérgio Basto: On Sáb, 2013-03-16 at 19:42 +0100, Reindl Harald wrote: [root@fileserver:~]$ system-config-users The value for the SHELL variable was not found the /etc/shells file This incident has been reported [root@fileserver:~]$ cat /etc/shells /bin/sh /bin/bash /sbin/nologin [root@fileserver:~]$ cat /etc/passwd | grep root root:x:0:0:root:/root:/usr/bin/bash and if both are valid both have to be valid as shell in ANY context or anything changed to the physical location This looks like a serious bug indeed. Can you share the link to the bug report, for those of us interested in CC-ing ourselves? https://bugzilla.redhat.com/show_bug.cgi?id=922527 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Headsup: soname changing ode-double build coming to rawhide and F-19
Hi, When I added the ode-double subpackage I hardcoded the soname, so it is not tracking the regular ode builds soname versioning, which also means that if upstream breaks abi the soname won't change (rhbz#922812) As a result of fixing this, the soname of ode-double is going to change in F-19 and rawhide, this means that alienarena, simspark and techne will need to be rebuild. Note there are no other changes necessary other then a simple rebuild, as all that is changing is the soname, the abi and api is otherwise staying 100% the same. Let me know if you're too busy to do the rebuild yourself and would like me to do it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Reindl Harald wrote: Am 16.03.2013 19:26, schrieb Rex Dieter: Lukáš Nykrýn wrote: After usr move packages should not install files to /sbin. That's not necessarily true. Do our packaging guidelines actually say that anywhere? but WHY are they not saying it clearly? Because blindly doing it breaks stuff (as evidenced by this thread). I was asking a mostly rhetorical question. There's some good reasons the guidelines don't say it (yet). :) -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
- Original Message - Dne 12.3.2013 16:30, Dennis Gilmore napsal(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, F19 has been branched, please be sure to do a git pull --rebase to pick up the new branch, additionally rawhide/f20 has had inheritance cut off from previous releases, so this means that anything you do for f19 you also have to do in the master branch and do a build there. Why was it cut off so soon actually? The reason for disabling inheritance was due to Bodhi updates, which might not go stable, if I remember correctly, but Bodhi is not in action yet I suppose, so the cut of was too soon IMO. Could you please reconsider it? Thank you. Good point at #fedora-devel right now - we are after branching, so Branch Freeze and Bodhi should be required now. Kevin, Dennis - what's the correct handling of Branch Freeze and when it should get in effect? Jaroslav Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Gnome 3.8 Test Day on Thursday
Hi Gnome users, developers and friends! We continue our Test Days ride [0]. You are invited to join Gnome 3.8 Test Day [1] on this Thursday. Gnome 3.8 final will be released on 2013-03-27. You can test new Gnome 3.8 [2] features [3] running from Fedora 19 Live test images and help to make this release better. List of some features: * Gnome Classic mode replaces Fallback mode * new applications: Clocks, Photos * ownCloud integration * Initial Setup * changes in shell: Activities Overview, Message Tray and Integrated Application Search * Privacy Settings and Sharing Settings * changes in applications: Boxes, Web, Documents [0] https://fedoraproject.org/wiki/QA/Fedora_19_test_days [1] https://fedoraproject.org/wiki/Test_Day:2013-03-21_Gnome_3.8 [2] https://live.gnome.org/ThreePointSeven/ReleaseNotes#GNOME_3.8 (preliminary) [3] https://live.gnome.org/ThreePointSeven/Features Join IRC #fedora-test-day on FreeNode and ask QA or developers for help, if you get into trouble. We can try to find workarounds and help you with debugging. Please report all bugs under appropriate component preferably at upstream bugzilla https://bugzilla.gnome.org/ regarding common Gnome 3.8 issues or Red Hat bugzilla http://bugzilla.redhat.com/ if you have problems with Fedora distribution integration. You can also report other Fedora bugs not related to this Test Day. Feel free to ask on IRC, if you don't know against which component or on what bugzilla you should fill the report. See you in Bugzilla! Best Regards, Martin Holec Desktop QE, Red Hat Brno Freenode nick: Martix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using fedup to upgrade to f19
On Sáb, 2013-03-16 at 14:19 -0600, Kevin Fenzi wrote: With pungi of F18 I could build an F19 repo with the images ? I don't know. Possibly. pungi -c f19-fedora.ks --destdir=/home/pungi/fedora --cachedir=/home/pungi/cache --name Fedora --ver 19 --nosource -B --force hangs various times with different problems https://bugzilla.redhat.com/show_bug.cgi?id=922842 https://bugzilla.redhat.com/show_bug.cgi?id=922845 and always end with rpm databases corrupted , and to run pungi again I have to do : rm /home/pungi/fedora/work/x86_64/yumroot/var/lib/rpm/__db.00* but shouldn't someone build images manually for f19 ? the package which most often crash pungi is (265/395) [100%] installing fedup-dracut-plymouth-0.7.2-2.fc19.noarch also appears many times: Non-fatal POSTIN scriptlet failure in rpm package bitmap-fangsongti-fonts-0.3-20.fc19.noarch and fontconfig I hope I could help in something -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Pod-Simple (un)retirement
Package perl-Pod-Simple in Fedora devel has been unretired by limb and is now orphan. To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Pod-Simple -- 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: Fwd: MariaDB replacing MySQL
On 03/15/2013 04:22 PM, James Antill wrote: On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote: However, in scenarios I tested with packages similar to mysql/MySQL/mariadb it turned out, that we never reach the point where we have to choose one of more alternate providers. The reason is that yum chooses right package before going down to [1] (I tracked the code and it never came to the part _compare_providers). Not sure what operation you tested this with, but you probably missed something. When installing a virtual provide, the usual code path would be: yum install 'mysql(x86-64)' = YumBase.install() = YumBase.bestPacakgesFromList() = YumBase._bestPackageFromList() = Depsolve._compare_providers() James, thanks for your response. You're right, it does call _compare_providers() when requesting virtual provide. snip 1. We are mixing a _package name_ mysql with a provide mysql, and another package name that is different only by capitalization MySQL. Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it? 2. We have multiple providers of mysql and an obsolete of mysql (which, again, is based on package name not provides). ...now there are certain parts of yum that will see FOO as a package name before it looks for provides, and thus. will never pick the other random packages that also provide FOO, the relevant ones are that is yum install and yum upgrade both operate this way. Understood, we'd have to introduce new virtual provides different than the former package name, right? However, I don't think it matters in our case, since mariadb is obsoleting mysql and it should also be the default, so it will behave as we wish in that case (i.e. mariadb is chosen by default) -- or do I miss something? The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. It's not obvious what you are doing in yum shell, but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb). I ran remove mariadb and install MySQL, which is probably what swap can do. But given the results I wouldn't be shocked if this was the one that represented what a requires would do. Sorry, I don't get your point here. Can you explain that a bit, please? snip Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things: 1. If all the providers give an = version for the provide, we'll choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x 5.5.x ... thus. MySQL would be preferred. 2. Shortest name (so MySQL will win). I see. However, we could do the following adjustments: 1) use epoch in mariadb's Provides: (mariadb would win in rule #10 at [1]) 2) change the name of the original MySQL package from MySQL to community-mysql -- then it should be safe to assume mariadb will be used before community-mysql. We couldn't use mysql-community because of rule #9 at [1] -- when some package would require mysql, then mysql-community would have better prefix and thus would be chosen before mariadb. So, if we do these two changes and if rules documented in [1] won't change in the future, we should be able to make yum to choose un-ambiguously mariadb before community-mysql. Or is there still some issue? Regards, Honza [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
I'd like to discuss the topic about virtual provides in a general context (not related to MySQL-MariaDB replacement) to find out what actually is a consensus in Fedora about an issue when two packages provide the same (not only) virtual symbol -- particularly what package maintainers could/should depend on. On 03/15/2013 04:22 PM, James Antill wrote: On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote: I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install XYZ and that is provided by FOO and BAR then installing either is correct (even if it's not what you want). That's probably how it should work eventually, but I believe we should also be *sure* what will be installed in case nobody requires either FOO nor BAR explicitly -- something like distribution-wide default. Currently, we can follow the steps how scores of providers are count [1]. However, since you wrote it's documented mostly for information purposes, the question is -- can we depend on it? Let me elaborate that a bit more. If we can depend on it, it means it is defined somehow -- so it would make sense also to re-define that behavior by user if there's a reason for that (i.e. let users to choose one of the provider). The idea I've in my mind is to achieve this by a yum plugin (which would use compare_providers hook), which would basically adjust scores for possible providers according to a config file. In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +1 mariadb -1 which would tell yum to prioritize MySQL. I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand. Any ideas about such tool/plugin? Cheers, Honza [1] http://yum.baseurl.org/wiki/CompareProviders -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hho...@redhat.com wrote: In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +1 mariadb -1 which would tell yum to prioritize MySQL. I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand. Any ideas about such tool/plugin? I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to * Modify the 10 packages that require mysql-server, the 19 packages that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide * Make sure that only mariadb-libs, not Oracle MySQL, Provides: the libmysqlclient soname? That's about 35 packages to touch, and all but one of them trivial modifications. (On the general question: multiple providers are always problematic - the interfaces are usually mostly but not fully compatible, some of the cases won't be tested, etc., so I'm not too enthusiastic about encouraging them.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
python-manuel change of license
The python-manuel and python3-manuel packages are changing from ZPLv2.1 to ASL 2.0 with the release of version 1.7.2. This will affect Rawhide and F-19 only. I don't expect the license change to affect any other packages, since manuel is used only to build documentation, but let me know of any trouble. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On 2013-03-17 20:12, Kevin Kofler wrote: I, for one, never liked Rawhide inheritance and I think it's a good thing that it was dropped. I, for one, used it every single time it was possible and liked how it saved my time as the package maintainer, resources on builders, space on mirrors, and some pointless package updates for end users on distro upgrades (for upgrades where a mass rebuild didn't happen and there was no other reason to inflict updates on end users either). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
Miloslav Trmač (m...@volny.cz) said: On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hho...@redhat.com wrote: In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +1 mariadb -1 which would tell yum to prioritize MySQL. I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand. Any ideas about such tool/plugin? I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to * Modify the 10 packages that require mysql-server, the 19 packages that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide * Make sure that only mariadb-libs, not Oracle MySQL, Provides: the libmysqlclient soname? That's about 35 packages to touch, and all but one of them trivial modifications. This does sound much simpler, IMO. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
On Mon, 2013-03-18 at 18:12 +0100, Honza Horak wrote: On 03/15/2013 04:22 PM, James Antill wrote: 1. We are mixing a _package name_ mysql with a provide mysql, and another package name that is different only by capitalization MySQL. Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it? Kind of ... the rule is that all idempotent operations should match packages without caring about case sensitivity. So yum install Mysql doesn't work, but yum list Mysql does. 2. We have multiple providers of mysql and an obsolete of mysql (which, again, is based on package name not provides). ...now there are certain parts of yum that will see FOO as a package name before it looks for provides, and thus. will never pick the other random packages that also provide FOO, the relevant ones are that is yum install and yum upgrade both operate this way. Understood, we'd have to introduce new virtual provides different than the former package name, right? Yeh. The following table shows what actions (cols) yum chose in different scenarios -- i.e packages installed (rows): installed | # yum install mysql | # yum update | # yum shell (*) | -- --- | mariadb (**)| --- | MySQL | mysql | mariadb | mariadb | MySQL | MySQL | mariadb | MySQL| MySQL | mariadb | --- | mariadb | MySQL | (*) yum shell is needed in order to install MySQL while removing current implementation if any (mysql or mariadb) in one transaction. It's not obvious what you are doing in yum shell, but rawhide/F19 yum also has the swap command (Eg. yum swap MySQL mariadb). I ran remove mariadb and install MySQL, which is probably what swap can do. Right, I see what you mean ... I figured the swap/shell was at the same level as the install/upgrade. But given the results I wouldn't be shocked if this was the one that represented what a requires would do. Sorry, I don't get your point here. Can you explain that a bit, please? What I meant is that given your testcase wasn't hitting compare_providers, and that from what I could see I'd expect compare_providers to choose MySQL over mariadb the shell case might be doing a real compare_providers test (and thus. would be what happens if you upgraded XYZ that depended on a newer mysql). Given that mariadb and MySQL are forks, and will have similar deps. and be on the same arches etc. ... I'd expect compare providers to come down to two things: 1. If all the providers give an = version for the provide, we'll choose the highest provided version (this is not true in el6 atm. ... if this is going to happen there). Given the above packaging data, 5.6.x 5.5.x ... thus. MySQL would be preferred. 2. Shortest name (so MySQL will win). I see. However, we could do the following adjustments: 1) use epoch in mariadb's Provides: (mariadb would win in rule #10 at [1]) 2) change the name of the original MySQL package from MySQL to community-mysql -- then it should be safe to assume mariadb will be used before community-mysql. We couldn't use mysql-community because of rule #9 at [1] -- when some package would require mysql, then mysql-community would have better prefix and thus would be chosen before mariadb. Yeh, with either/both of those changes I'd expect yum to choose mariadb over the other package ... all other things being equal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Mon, 2013-03-18 at 18:30 +0100, Honza Horak wrote: I'd like to discuss the topic about virtual provides in a general context (not related to MySQL-MariaDB replacement) to find out what actually is a consensus in Fedora about an issue when two packages provide the same (not only) virtual symbol -- particularly what package maintainers could/should depend on. On 03/15/2013 04:22 PM, James Antill wrote: On Wed, 2013-03-13 at 18:08 +0100, Honza Horak wrote: I've spent some time deep in yum and it seems to be better than I thought now. First, the magic about choosing one provider from more alternatives is not so dark any more (it was worse few years before) -- it's actually documented at [1] now. It's documented what the current version of yum does, and it's documented mostly for information purposes ... if you want to install XYZ and that is provided by FOO and BAR then installing either is correct (even if it's not what you want). That's probably how it should work eventually, but I believe we should also be *sure* what will be installed in case nobody requires either FOO nor BAR explicitly -- something like distribution-wide default. Doing it as a plugin would be a pretty big fail IMO, doing it in core is fairly simple and we did a PoC a _long_ time ago: http://james.fedorapeople.org/yum/patches/yum-best-providers-metadata.patch ...the main problem was what to do if we committed the patch, how does the data get into the repo. who owns it ... then how do we make it so that spins could have different data (Eg. kdm vs. gdm). It's much like the app. data problem, except there was never the huge extra problem of it being a package too ... so if app. data ever gets in, that might show a way for someone to push this data in too (guess you'd want to talk to dnf maintainer though :). My main point was that the above is informational, and while you can use it to game which packages are installed by default there are no guarantees that it will remain compatible until the end of time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New groups in comps for F19
On 17/03/13 11:17 AM, Kevin Kofler wrote: Adam Williamson wrote: In my experience, nearly all even somewhat mature apps need intltool to compile, so it seems a reasonable thing to install by default in the 'development' group. Only GNOME ones. :-) The only file type it handles that's not GNOME/GTK+-specific is .desktop files, and other projects have other ways to handle these (e.g., KDE runs scripts to sync between .desktop and .po files inside its SCMs). IMHO, it should go into a GNOME Software Development or GTK+ Software Development group. I didn't realize it was that GTK+-specific. If so, that sounds reasonable. -- 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
[389-devel] please review: Ticket 623 - cleanAllRUV task fails to cleanup config upon completion
https://fedorahosted.org/389/ticket/623 https://fedorahosted.org/389/attachment/ticket/623/0001-Ticket-623-cleanAllRUV-task-fails-to-cleanup-config-.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
On Mon, 2013-03-18 at 18:42 +0100, Miloslav Trmač wrote: On Mon, Mar 18, 2013 at 6:30 PM, Honza Horak hho...@redhat.com wrote: In case of MySQL/mariadb (just for demonstration) the config file would contain say: MySQL +1 mariadb -1 which would tell yum to prioritize MySQL. I'm sure that there are several other use cases for such utility. It would bring a bit more complexity on the one hand, but would decrease ambiguity in specific cases on the other hand. Any ideas about such tool/plugin? I'm not following the MySQL/mariadb packaging discussion in full detail - however, if we got to the point of discussing special yum plugins, wouldn't it be much simpler to We, didn't, really. * Modify the 10 packages that require mysql-server, the 19 packages that require mysql, the 3 packages that require mysql-libs (all F18 counts) to require mariadb-* explicitly instead of using the virtual provide This means users can't choose between the mysql's if they want to, so if we do this it'd be much easier to just say we'll only have a single `mysql' in Fedora and then we'd just have to add one more obsolete to mariadb and everything works perfectly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: MariaDB replacing MySQL
Le Lun 18 mars 2013 18:12, Honza Horak a écrit : Now I see it was not the best idea to call it MySQL, but yum sees that as two different packages, doesn't it? Honestly? Capitalized package names are a PITA that break searches and make users miserable. The only reason they're not banned in Fedora (as they are in other distros) is the huge legacy of capitalized perl packages. And even perl packagers are not vicious enough to use a capital as first letter of their names. (people managed to get rid of perl use in livecds but RHL's perl tooling roots still haunt us). Don't use caps in package names. Whatever reason you have, it's wrong. If you think camelcase package names are cool, you're doubly wrong. Like /opt caps use is the mark of horrid proprietary packages where marketing overrode common sense. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Am 18.03.2013 08:27, schrieb Nico Kadel-Garcia: On Sun, Mar 17, 2013 at 8:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 18.03.2013 01:06, schrieb Nico Kadel-Garcia: On Sun, Mar 17, 2013 at 12:36 PM, Peter Lemenkov lemen...@gmail.com wrote: 2013/3/15 Lukáš Nykrýn lnyk...@redhat.com: After usr move packages should not install files to /sbin. Unfortunately there is a lot of packages requiring /sbin/service, which was recently moved to /usr/sbin/, and these packages were uninstallable. As a workaround I have put Provides: /sbin/service in the initscript spec, but I think that we should do a proper fix. So if your package is in following list, please change your Reguires to /usr/sbin/service. ... rtpproxy Fixed. This is a bad, bad, bad idea for any packages that are going to remain backwards compatible with RHEL, for compilation under EPEL or other backporting. Either switch to systemd, or stick with the old location and allow initscripts to correctly include the old reference. Do not pick a hallfways fix that isn't backwards compatible at all. * Fedora has done UsrMove with F17 * Now we have F18 * in a short we have F19 * RHEL7 will be base on F18/F19 ANY reference in Fedora to /sbin and /bin is BOGUS it leads to all sorts of troubles it leads to additional symlink reslovement If SysV init style scripts are staying in use, even as a compatibility fallback, don't edit the references to them just to prove something. It breaks backporting and forward porting and cross-compatibility for every existing versoin of RHEL, which are still needed for compatibility because *systemd can't be ported back to RHEL 6 or earlier.* I've tried, it's a dependency and critical component upgrade nightmare so what - then it needs a lot of if-clauses in the SPEC it makes pretty no sense to wait 10 years until the last RHEL version is on systemd and has also UsrMove to finish this things for fedora signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yum plugin for prioritize providers [was Re: Fwd: MariaDB replacing MySQL]
Am 18.03.2013 20:55, schrieb James Antill: This means users can't choose between the mysql's if they want to, so if we do this it'd be much easier to just say we'll only have a single `mysql' in Fedora and then we'd just have to add one more obsolete to mariadb and everything works perfectly. and why is this not happening instead a lot of workarounds and hacks in SPEC files and mangle sonames which makes anything related to mysql ar whatever fork-name ugly at all? by introduce systemd nobody cared about having another working initd without punish users in the way to early F15 state but now in the case of user-applications it happens in a dirty way? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f19 mass branching
On Mon, 18 Mar 2013 14:42:46 -0600 Kevin Fenzi kfe...@redhat.com wrote: On Mon, 18 Mar 2013 12:31:41 -0400 (EDT) Jaroslav Reznik jrez...@redhat.com wrote: Good point at #fedora-devel right now - we are after branching, so Branch Freeze and Bodhi should be required now. Kevin, Dennis - what's the correct handling of Branch Freeze and when it should get in effect? We are not frozen. We have branched f19 off rawhide. At the alpha change deadline: 2013-04-02 Alpha Change Deadline is when we go into freeze for alpha and start using bodhi. We did the same thing last cycle, although the time between branching and alpha change might have been shorter. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
update of python-markdown
Hi, python-markdown has been updated in rawhide to the latest version 2.3, please check whether your package still works as expected. There are a some backward-incompatible changes, see https://github.com/waylan/Python-Markdown/blob/2.3.final/docs/release-2.3.txt. Affected packages: bodhi-server lastuser python-cheetah ReviewBoard sshuttle timeline transifex -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora release name problem
Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mon, 18 Mar 2013 23:56:28 + Sérgio Basto ser...@serjux.com wrote: Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? I'd rather we fix things to handle this case than paper it over by changing it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote: On Mon, 18 Mar 2013 23:56:28 + Sérgio Basto ser...@serjux.com wrote: Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? I'd rather we fix things to handle this case than paper it over by changing it. I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images. This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up. I'm not sure I want to have to deal with that crap while also trying to fix things we *don't* have a known, straightforward workaround for. I know we want to Fix Things The Right Way and Contribute Upstream and Be Good Engineers and blah, but there's a damn limit. -- 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: fedora release name problem
On Mar 18, 2013, at 6:56 PM, Adam Williamson awill...@redhat.com wrote: This bug just *smells* like one of those which will pop up again and again and again causing carnage wherever it shows up. I think so. I expect we'll find issues with isolinux, grub, livecd-tools, liveusb-creator. It could be hilarious to see how many problems this causes. But I'll bet $3.50 that by week 4 QA people start feeling like the cat in the box, and will be looking for a way to release the gas themselves. I'm not sure I want to have to deal with that crap while also trying to fix things we *don't* have a known, straightforward workaround for. Right. It's always a case of trying to find out where the bodies are buried for each release. This like adding a whole separate cemetery of unknown size and depth. It could be one of those town of 1000 varieties, or it could end up like one in the French Quarter where there's always room for one more. And is fixing this apostrophe issue going to have some clear benefit anywhere else? It's 2013, this is the 19th release of Fedora, and this is the first time it's come up? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: system freezes after loading gdm/gnome
As usual, I have completely forgotten any relevant system/software info, so: This is a Thinkpad T420 with: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I've just sent a mesa-9.1-2 build for koji for F19 that should workaround this, we don't have a proper fix yet, but the chromeos developers had a hack in their tree they pointed me at, and it does appear to let me boot again with RC6 enabled. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
Sérgio Basto sergio at serjux.com writes: For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay? It's not the name that was originally voted for. (I'm not trying to be difficult - I was one of those who voted against having a release name, based on the belief that it was a waste of time, although I didn't imagine that the waste would include QA and developers.) If the release name only needs to apply to the Final release, the name could be temporarily changed to Schrodingers Cat for Alpha if it takes longer to hold the vote. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mon, Mar 18, 2013 at 10:44 PM, Andre Robatino robat...@fedoraproject.org wrote: Sérgio Basto sergio at serjux.com writes: For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay? It's not the name that was originally voted for. (I'm not trying to be difficult - I was one of those who voted against having a release name, based on the belief that it was a waste of time, although I didn't imagine that the waste would include QA and developers.) If the release name only needs to apply to the Final release, the name could be temporarily changed to Schrodingers Cat for Alpha if it takes longer to hold the vote. I suppose Greebo is right off the list? To go along with the Ogg Vrobis, and other Terry Pratchett references? To quote a Terry Pratchett story, the possible staes of a cat in a box are actually alive, dead, or bloody furious, which is what the developers are going to be when they encounter extraneous punction in basic system configuration files. They files are being parsed by /bin/sh in ./configure scripts and Makefiles, not a complex data format. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mar 18, 2013, at 8:44 PM, Andre Robatino robat...@fedoraproject.org wrote: If we do, shouldn't there be another vote asking if it's okay to make this change, in light of the possible release delay? Definitely not. There is equivalent that doesn't require apostrophe or umlaut (diaeresis) characters. Legal will have a far less difficult time with this than flat out incorrect spellings, or new names. It's not the name that was originally voted for. Schrodinger is not the man's name, and is the wrong solution. Schroedinger is as acceptable as Schrödinger. If the release name only needs to apply to the Final release, the name could be temporarily changed to Schrodingers Cat for Alpha if it takes longer to hold the vote. I disagree any duration of the incorrect spelling of a surname is acceptable. For a private/closed project it might be tolerated for internal distribution only, but I'm skeptical. For a public project I don't think it's appropriate. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unable to run mock builds for rawhide on Fedora 18: buildsys-build has no packages to install
Hi folks, I've been having trouble running builds for rawhide on my mock instance recently: [ankur@dhcppc1 SRPMS]$ mock rebuild -r fedora-rawhide-x86_64 pybrain-0.3.1-1.fc18.src.rpm INFO: mock.py version 1.1.29 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run INFO: Start(pybrain-0.3.1-1.fc18.src.rpm) Config(fedora-rawhide-x86_64) Start: lock buildroot Start: clean chroot Finish: clean chroot Finish: lock buildroot Start: chroot init Start: lock buildroot Mock Version: 1.1.29 INFO: Mock Version: 1.1.29 INFO: calling preinit hooks INFO: enabled root cache INFO: enabled yum cache Start: cleaning yum metadata Finish: cleaning yum metadata INFO: enabled ccache Start: device setup Finish: device setup Start: yum update Start: Outputting list of available packages Finish: Outputting list of available packages Finish: yum update ERROR: Exception(pybrain-0.3.1-1.fc18.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 11 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result ERROR: Could not find useradd in chroot, maybe the install failed? The root.log file has this line: DEBUG util.py:264: Warning: Group buildsys-build does not have any packages to install. Any hints on what's going on here? I've reinstalled the mock package to ensure I have the config files in pristine condition, but that hasn't fixed it. -- Thanks, Warm regards, Ankur: FranciscoD Please only print if necessary. Looking to contribute to Fedora? Look here: https://fedoraproject.org/wiki/Fedora_Join_SIG http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Overriding template branch when requesting a new branch for a package in Git?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, When submitting a package change request for a new branch, the new branch is currently instantiated with the revision history of the master (development) branch. When the new branch created is for an EPEL release, this might not be appropriate -- for instance, I just asked for python-psutil to be branched; master is at 0.6.1, el6 is at 0.4.1 and now the new el5 branch is at 0.6.1. Is there an interest in an improvement in which one can specify which commit (or, simpler but less flexible, which branch head) to use when instantiating each particular branch)? (and where should this be filed - - as a rel-eng request in Trac, presumably) Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRR+9tAAoJEEr1VKujapN6IhcIAIrGEHQ1YyCk3h2fw9Mogfan jCovrumnA2WavqxMyXOvk/g2Io8SOZuGnH5YfQ+TvXgu6CEWG58UDKy/p2dfGwC9 pXAe8VIkG9rcz4QEiSboh9AIb+Cg9GFLkwjBd3w5kMnLrPhr2m20mXjvQ0UjIZaX WNic+gYIYToQvVygl7KkN4Xqvr/1obvDQWcx0TcQd423G1wXip0n38nVA4VjnQ7C HbKLLiiOms0b0l6LA+3M5mG+L9dnnRbM5uLidKTTvVTchL4lY/UJKaFpfYF09oLP N5FLYj7l9gA0UZozbYqNtWMLDqZ3+L/6vUfdiLi491a8WmOxyIk2kwa0FLchLxY= =LT4M -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Overriding template branch when requesting a new branch for a package in Git?
On Tue, 2013-03-19 at 11:54 +0700, Michel Alexandre Salim wrote: Dear all, When submitting a package change request for a new branch, the new branch is currently instantiated with the revision history of the master (development) branch. When the new branch created is for an EPEL release, this might not be appropriate -- for instance, I just asked for python-psutil to be branched; master is at 0.6.1, el6 is at 0.4.1 and now the new el5 branch is at 0.6.1. Is there an interest in an improvement in which one can specify which commit (or, simpler but less flexible, which branch head) This can be just as flexible in most cases: specify a very old branch as template, and then just merge up to the commit you wanted. to use when instantiating each particular branch)? (and where should this be filed - as a rel-eng request in Trac, presumably) I think this would be valuable indeed. However, I'd say the request should be opened in the fedora-infrastructure trac, as this is the script which processes the requests: http://git.fedorahosted.org/cgit/fedora-infrastructure.git/tree/scripts/process-git-requests/process-git-requests -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora release name problem
On Mon, Mar 18, 2013 at 05:56:28PM -0700, Adam Williamson wrote: On Mon, 2013-03-18 at 18:34 -0600, Kevin Fenzi wrote: On Mon, 18 Mar 2013 23:56:28 + Sérgio Basto ser...@serjux.com wrote: Hi, For the first time, Fedora release name have non-ascii and pelican characters which https://bugzilla.redhat.com/show_bug.cgi?id=922433 Could we consider change release name from Schrödinger's Cat to Schrodingers Cat or other name that not have this additional problem ? I'd rather we fix things to handle this case than paper it over by changing it. +1 I would very much like that we paper it over right now, unless you propose to discover and fix every single problem it causes by tomorrow, when I want us to start rolling TC images. If by right now you mean until we get TC out (or even until we get alpha out), I wouldn't be opposed to that. These sort of bugs really are something that need to be fixed and this release name is a good candidate for doing so... but the time from alpha to beta is appropriate for fixing bugs so it's okay if we defer fixing them for a little while. -Toshio who's been working on various iterations of a fix for this in the python3 package[1] for a few days Kuratomi .. [1]_: http://bugs.python.org/issue17429 pgpHVbqk9oqN7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Time-Local-1.2300.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Time-Local: 68e1be54c151cf131f9d4168b3e662f9 Time-Local-1.2300.tar.gz -- 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
[perl-Time-Local] Import
commit af2ec26ce1a42b16e7e5944dd442bed091f051cf
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 18 08:18:04 2013 +0100
Import
.gitignore |1 +
perl-Time-Local.spec | 56 ++
sources |1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..d83ea2c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Time-Local-1.2300.tar.gz
diff --git a/perl-Time-Local.spec b/perl-Time-Local.spec
new file mode 100644
index 000..72e7903
--- /dev/null
+++ b/perl-Time-Local.spec
@@ -0,0 +1,56 @@
+Name: perl-Time-Local
+Version:1.2300
+Release:1%{?dist}
+Summary:Efficiently compute time from local and GMT time
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Time-Local/
+Source0:
http://www.cpan.org/authors/id/D/DR/DROLSKY/Time-Local-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(vars)
+# Tests:
+BuildRequires: perl(Test::More) = 0.88
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+#Requires: perl(Carp)
+#Requires: perl(Config)
+
+%description
+This module provides functions that are the inverse of built-in perl functions
+localtime() and gmtime(). They accept a date as a six-element array, and
+return the corresponding time(2) value in seconds since the system epoch
+(Midnight, January 1, 1970 GMT on Unix, for example). This value can be
+positive or negative, though POSIX only requires support for positive values,
+so dates before the system's epoch may not work on all operating systems.
+
+%prep
+%setup -q -n Time-Local-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Mar 15 2013 Petr Pisar ppi...@redhat.com 1.2300-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..8c6f9a8 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+68e1be54c151cf131f9d4168b3e662f9 Time-Local-1.2300.tar.gz
--
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
[perl-Locale-Maketext-Gettext/f19] Add patch to convert gettext %1 to maketext [_1]
commit cbffe79b9866ef13766915695542650239b385c2
Author: Ruediger Landmann r.landm...@redhat.com
Date: Mon Mar 18 17:39:31 2013 +1000
Add patch to convert gettext %1 to maketext [_1]
gettexttomakettext.patch | 14 ++
perl-Locale-Maketext-Gettext.spec |7 ++-
2 files changed, 20 insertions(+), 1 deletions(-)
---
diff --git a/gettexttomakettext.patch b/gettexttomakettext.patch
new file mode 100644
index 000..d6e71e0
--- /dev/null
+++ b/gettexttomakettext.patch
@@ -0,0 +1,14 @@
+diff -ru Locale-Maketext-Gettext-1.27/lib/Locale/Maketext/Gettext.pm
Locale-Maketext-Gettext-1.27-patched/lib/Locale/Maketext/Gettext.pm
+--- Locale-Maketext-Gettext-1.27/lib/Locale/Maketext/Gettext.pm
2009-04-28 03:46:23.0 +1000
Locale-Maketext-Gettext-1.27-patched/lib/Locale/Maketext/Gettext.pm
2013-03-08 12:31:37.166997436 +1000
+@@ -354,6 +354,10 @@
+ # Translated message
+ $strt = substr($content, $off, $len);
+
++# Convert gettext params %1 to maketext params [_1]
++$stro =~ s/\%(\d+)/\[_$1\]/g;
++$strt =~ s/\%(\d+)/\[_$1\]/g;
++
+ # Hash it
+ $_{$stro} = $strt;
+ }
diff --git a/perl-Locale-Maketext-Gettext.spec
b/perl-Locale-Maketext-Gettext.spec
index 6bfbcf6..94bcdbb 100644
--- a/perl-Locale-Maketext-Gettext.spec
+++ b/perl-Locale-Maketext-Gettext.spec
@@ -1,6 +1,6 @@
Name: perl-Locale-Maketext-Gettext
Version:1.27
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Patch0: gettexttomakettext.patch
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Mon Mar 18 2013 Rüdiger Landmann rland...@redhat.com 1.27-11
+- Add patch to convert gettext %1 to maketext [_1]
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.27-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
@@ -78,5 +82,6 @@ rm -rf $RPM_BUILD_ROOT
* Mon Sep 21 2009 Rüdiger Landmann rland...@redhat.com 1.27-2
- added BuildRequires: perl(Test::More) and BuildRequires: perl(Test::Pod)
+
* Mon Sep 07 2009 Rüdiger Landmann rland...@redhat.com 1.27-1
- Specfile autogenerated by cpanspec 1.78.
--
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
File gettexttomakettext.patch uploaded to lookaside cache by rlandmann
A file has been added to the lookaside cache for perl-Locale-Maketext-Gettext: bd16fb000fbf042b220d7a990368c0b2 gettexttomakettext.patch -- 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
[perl-Locale-Maketext-Gettext/f19] Add patch to convert gettext %1 to maketext [_1]
commit 7aca8c25cfae1b0cf2f303b2edaf5f17b9129d41 Author: Ruediger Landmann r.landm...@redhat.com Date: Mon Mar 18 17:41:21 2013 +1000 Add patch to convert gettext %1 to maketext [_1] .gitignore |1 + gettexttomakettext.patch | 14 -- sources |1 + 3 files changed, 2 insertions(+), 14 deletions(-) --- diff --git a/.gitignore b/.gitignore index 0add32c..4b1b4f6 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,2 @@ Locale-Maketext-Gettext-1.27.tar.gz +/gettexttomakettext.patch diff --git a/sources b/sources index 5077cf7..7c6a814 100644 --- a/sources +++ b/sources @@ -1 +1,2 @@ 58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz +bd16fb000fbf042b220d7a990368c0b2 gettexttomakettext.patch -- 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
File Data-Dumper-2.145.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Data-Dumper: b773c875afcca866faf8481adc3464b0 Data-Dumper-2.145.tar.gz -- 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
[perl-Data-Dumper] 2.145 bump
commit b5871e7d38d9936d6635396895bdb9b3d2030d62
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 18 09:25:39 2013 +0100
2.145 bump
.gitignore|1 +
perl-Data-Dumper.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b8acbfb..d54d295 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Data-Dumper-2.136.tar.gz
/Data-Dumper-2.139.tar.gz
/Data-Dumper-2.143.tar.gz
+/Data-Dumper-2.145.tar.gz
diff --git a/perl-Data-Dumper.spec b/perl-Data-Dumper.spec
index e23f4c7..ee0e4e6 100644
--- a/perl-Data-Dumper.spec
+++ b/perl-Data-Dumper.spec
@@ -1,4 +1,4 @@
-%global cpan_version 2.143
+%global cpan_version 2.145
Name: perl-Data-Dumper
Version:%(echo '%{cpan_version}' | tr '_' '.')
Release:1%{?dist}
@@ -24,7 +24,7 @@ BuildRequires: perl(XSLoader)
BuildRequires: perl(Config)
BuildRequires: perl(lib)
BuildRequires: perl(strict)
-BuildRequires: perl(Test::More) = 0.60
+BuildRequires: perl(Test::More) = 0.98
# Optional tests:
BuildRequires: perl(Encode)
%endif
@@ -68,6 +68,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 18 2013 Petr Pisar ppi...@redhat.com - 2.145-1
+- 2.145 bump
+
* Thu Feb 28 2013 Petr Pisar ppi...@redhat.com - 2.143-1
- 2.143 bump
diff --git a/sources b/sources
index d878424..1c2410f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6c02ac5a2da9892667909b1c2f04a7a6 Data-Dumper-2.143.tar.gz
+b773c875afcca866faf8481adc3464b0 Data-Dumper-2.145.tar.gz
--
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 922376] perl-Data-Dumper-2.145 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=922376 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Internal test suite fixes. This release is suitable for F≥19. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=3oWz2kDPl7a=cc_unsubscribe -- 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
[perl-Data-Dumper/f19] 2.145 bump
Summary of changes: b5871e7... 2.145 bump (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Perl-Critic-Pulp-78.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Perl-Critic-Pulp: 85f1c3796c40539ba14aa89a6addf540 Perl-Critic-Pulp-78.tar.gz -- 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
[perl-Perl-Critic-Pulp] 78 bump
commit 58da8a04514cd734173594c575f2e132e6cf259d
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 18 09:36:17 2013 +0100
78 bump
.gitignore |1 +
perl-Perl-Critic-Pulp.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 330513f..83f14ff 100644
--- a/.gitignore
+++ b/.gitignore
@@ -23,3 +23,4 @@
/Perl-Critic-Pulp-75.tar.gz
/Perl-Critic-Pulp-76.tar.gz
/Perl-Critic-Pulp-77.tar.gz
+/Perl-Critic-Pulp-78.tar.gz
diff --git a/perl-Perl-Critic-Pulp.spec b/perl-Perl-Critic-Pulp.spec
index 306b5af..db005aa 100644
--- a/perl-Perl-Critic-Pulp.spec
+++ b/perl-Perl-Critic-Pulp.spec
@@ -1,5 +1,5 @@
Name: perl-Perl-Critic-Pulp
-Version:77
+Version:78
Release:1%{?dist}
Summary:Some add-on perlcritic policies
License:GPLv3+
@@ -92,6 +92,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 18 2013 Petr Pisar ppi...@redhat.com - 78-1
+- 78 bump
+
* Thu Feb 28 2013 Petr Pisar ppi...@redhat.com - 77-1
- 77 bump
diff --git a/sources b/sources
index 8becf0b..12c47cb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-eddb335189ad68b8581a871692831782 Perl-Critic-Pulp-77.tar.gz
+85f1c3796c40539ba14aa89a6addf540 Perl-Critic-Pulp-78.tar.gz
--
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 922376] perl-Data-Dumper-2.145 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=922376 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Data-Dumper-2.145-1.fc ||20 Resolution|--- |RAWHIDE Last Closed||2013-03-18 04:37:58 --- Comment #2 from Petr Pisar ppi...@redhat.com --- Fixed as perl-Data-Dumper-2.145-1.fc19 in F19. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8kXiDzkciKa=cc_unsubscribe -- 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 922443] [abrt] perl-Padre-0.90-6.fc18: wxTimerBase::Notify: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=922443 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||tcall...@redhat.com Component|perl-Padre |perl-Wx Assignee|mmasl...@redhat.com |tcall...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vuY2wVuL6Ra=cc_unsubscribe -- 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 922378] perl-Perl-Critic-Pulp-78 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=922378 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Perl-Critic-Pulp-78-1. ||fc20 Resolution|--- |RAWHIDE Last Closed||2013-03-18 04:53:04 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vKEx8i3I0ra=cc_unsubscribe -- 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
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- 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
[perl-Locale-Maketext-Gettext/f18] Add patch to convert gettext %1 to maketext [_1]
commit 0fa139c3bd4b1aa40c79f8ad6b48c3307dbe35f2
Author: Ruediger Landmann r.landm...@redhat.com
Date: Tue Mar 19 14:46:15 2013 +1000
Add patch to convert gettext %1 to maketext [_1]
.gitignore|1 +
perl-Locale-Maketext-Gettext.spec |6 +-
sources |1 +
3 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0add32c..4b1b4f6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Locale-Maketext-Gettext-1.27.tar.gz
+/gettexttomakettext.patch
diff --git a/perl-Locale-Maketext-Gettext.spec
b/perl-Locale-Maketext-Gettext.spec
index 0cfb8a4..a1a1898 100644
--- a/perl-Locale-Maketext-Gettext.spec
+++ b/perl-Locale-Maketext-Gettext.spec
@@ -1,6 +1,6 @@
Name: perl-Locale-Maketext-Gettext
Version:1.27
-Release:9%{?dist}
+Release:10%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Patch0: gettexttomakettext.patch
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Mon Mar 18 2013 Rüdiger Landmann rland...@redhat.com 1.27-11
+- Add patch to convert gettext %1 to maketext [_1]
+
* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.27-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index 5077cf7..7c6a814 100644
--- a/sources
+++ b/sources
@@ -1 +1,2 @@
58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
+bd16fb000fbf042b220d7a990368c0b2 gettexttomakettext.patch
--
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
[perl-Locale-Maketext-Gettext/f17] Add patch to convert gettext %1 to maketext [_1]
commit 198508458233169e8a9e68606aa5b6c4ba3bfe34
Author: Ruediger Landmann r.landm...@redhat.com
Date: Tue Mar 19 14:51:05 2013 +1000
Add patch to convert gettext %1 to maketext [_1]
.gitignore|1 +
perl-Locale-Maketext-Gettext.spec |6 +-
sources |1 +
3 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0add32c..4b1b4f6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Locale-Maketext-Gettext-1.27.tar.gz
+/gettexttomakettext.patch
diff --git a/perl-Locale-Maketext-Gettext.spec
b/perl-Locale-Maketext-Gettext.spec
index 18f850a..ca6bb08 100644
--- a/perl-Locale-Maketext-Gettext.spec
+++ b/perl-Locale-Maketext-Gettext.spec
@@ -1,6 +1,6 @@
Name: perl-Locale-Maketext-Gettext
Version:1.27
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Joins the gettext and Maketext frameworks
License:GPL+ or Artistic
Group: Development/Libraries
@@ -13,6 +13,7 @@ BuildRequires: perl(Module::Build)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Patch0: gettexttomakettext.patch
%description
Locale::Maketext::Gettext joins the GNU gettext and Maketext frameworks. It
@@ -52,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Mon Mar 18 2013 Rüdiger Landmann rland...@redhat.com 1.27-8
+- Add patch to convert gettext %1 to maketext [_1]
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.27-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 5077cf7..7c6a814 100644
--- a/sources
+++ b/sources
@@ -1 +1,2 @@
58019c37c8ad1c4526476a7fb98b64c6 Locale-Maketext-Gettext-1.27.tar.gz
+bd16fb000fbf042b220d7a990368c0b2 gettexttomakettext.patch
--
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
