aggregation of gnome tools
In the meanwhile, several tools have been developed for the management of my gnome or gnome3 desktop (gui or not gui based), but each time I need to use them I have to think about what tool to use: gnome-tweak-tool gconf-editor dconf-editor gconftool-2 gnome-session-properties ... It seems there is a tendency for creating more and more such tools. It would be very helpful for the user if such tools could be aggregated to a *homogenous* and gui based tool so I have not to think about which one to use. All comments are welcome. Kind regards -- Joachim Backes http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
submitters +1ing their own packages
Kevin Fenzi scrye.com> writes: > * As a maintainer you should only be pushing an update you feel > works/fixes something anyhow. Shouldn't that be an implied +1 always > from the maintainer? Well, there's actual testing, vs. being convinced based on the apparent simplicity of a patch that it doesn't need to be tested. I've seen a number of non-working "fixes" that obviously fell into the second category, given that they failed in a 100% reproducible, environment-independent way, and would have only taken a minute or two to actually test. > * As a maintainer it's easy to have a env that gets out of sync with > what a QA or end user would use. Ie, you make 20 iterations of a > package to test something, tweak configs to check something, and get > it all working, but perhaps your machine is no longer setup the way a > fresh install or upgrade of your package would be. Or you tested a > version and then changed just 'one little thing' and pushed that and > it turned out to break it. > > * Even the best of us would like another pair of eyes to confirm > something is really fixed/working. Obviously packagers may have more trouble doing objective testing than outsiders, but it's possible. My opinion is that packagers should be allowed to +1 their own packages after a certain delay (1 week, maybe?) if it hasn't gotten sufficient karma from others by then, and they do actual testing in a non-custom environment (for example, maintain a VM with close to default settings). If a packager repeatedly submits +1 for updates which turn out later couldn't possibly have worked in actual testing, then their karma privileges could be revoked. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: > On Wed, 07 Sep 2011 12:15:56 -0700 > Adam Williamson wrote: > > > On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > > > On 7 September 2011 01:02, Adam Williamson > > > wrote: > > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > > > case-by-case enforcement of this policy? > > > > > > I'm guilty of this too; when I file an update that's not getting > > > enough karma (after a few weeks) then I give it a spin in a *fresh* > > > VM and test it out like any normal user would do. If this is wrong, > > > consider my wrists slapped, but otherwise I think it makes sense and > > > gets things moving. > > > > It's against the current policy. I've argued along the same lines as > > you in past threads on this list, but I was on the minority side of > > the debate at the time, it seemed; more people were worried that > > maintainers would +1 their updates without bothering to test them > > properly. > > As someone on the other side of this (although not strongly, I could > be convinced), I don't think thats my concern at all... > > * As a maintainer you should only be pushing an update you feel > works/fixes something anyhow. Shouldn't that be an implied +1 always > from the maintainer? I've probably responded to those before, but oh well: this is a bit of a 'physics experiment land' point, for me. In theory? Sure. In practice? Not really. We have this system because maintainers *do* push updates which don't work, after all. Sometimes they 'don't work' in a way the maintainer wouldn't have been able to catch, but often they 'don't work' in a way the maintainer really should have caught if they'd tested the package: viz, say, glibc -6, which prevented all systems from booting properly. I know *I've* submitted updates on spec, or with very minor testing, occasionally, and I'm a QA person. =) > * As a maintainer it's easy to have a env that gets out of sync with > what a QA or end user would use. Ie, you make 20 iterations of a > package to test something, tweak configs to check something, and get > it all working, but perhaps your machine is no longer setup the way a > fresh install or upgrade of your package would be. Or you tested a > version and then changed just 'one little thing' and pushed that and > it turned out to break it. Both hughsie and myself, and I think everyone else in favour of maintainer +1s, suggested maintainers should test *in a vanilla environment*, with the actual package they were submitting, before +1ing. +1ing on the basis of a test build or in a dirty environment would be a no-no and could lead to the removal of +1 privileges if repeated. > * Even the best of us would like another pair of eyes to confirm > something is really fixed/working. Yes, indeed, in a perfect world. But it seems quite plain that, so far, the bodhi system is working pretty well but not perfectly, and we may have to take pragmatic changes to our beautiful, beautiful Physics Experiment Land model (where there's no friction, and there are always 100 proventesters running Fedora 14...) in order to keep everything flowing smoothly. > anyhow, just thought I would toss that out there... > > kevin -- 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: submitters +1ing their own packages
On Wed, 07 Sep 2011 12:15:56 -0700 Adam Williamson wrote: > On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > > On 7 September 2011 01:02, Adam Williamson > > wrote: > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > > case-by-case enforcement of this policy? > > > > I'm guilty of this too; when I file an update that's not getting > > enough karma (after a few weeks) then I give it a spin in a *fresh* > > VM and test it out like any normal user would do. If this is wrong, > > consider my wrists slapped, but otherwise I think it makes sense and > > gets things moving. > > It's against the current policy. I've argued along the same lines as > you in past threads on this list, but I was on the minority side of > the debate at the time, it seemed; more people were worried that > maintainers would +1 their updates without bothering to test them > properly. As someone on the other side of this (although not strongly, I could be convinced), I don't think thats my concern at all... * As a maintainer you should only be pushing an update you feel works/fixes something anyhow. Shouldn't that be an implied +1 always from the maintainer? * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. * Even the best of us would like another pair of eyes to confirm something is really fixed/working. anyhow, just thought I would toss that out there... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yum-builddep (Re: Compiling 32bit on 64bit Fedora)
Hi All, On a related but different note. How hard would it be to get yum-builddep to take an --arch arg to that we can esily get the 32-bit builddeps on a 64-bit system? Yours Tony -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, Sep 07, 2011 at 07:20:19PM +0200, Michael Schwendt wrote: > On Wed, 7 Sep 2011 11:00:57 +1000, PH (Peter) wrote: > > > sometimes a +1 after weeks in testing is the only or at least easy way to > > nudge a package into stable. > > > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > > even with my +1 still not there, and this isn't the only package I've done > > this for. > > | Details > |Don't corrupt memory if the server sends unknown classes in > XIQueryDevice. > > # rpm -qi libXi|grep -A2 ^De > Description : > X.Org X11 libXi runtime library > > # rpm -qd libXi > /usr/share/doc/libXi-1.4.3/COPYING > > # rpm -ql libXi > /usr/lib64/libXi.so.6 > /usr/lib64/libXi.so.6.1.0 > /usr/share/doc/libXi-1.4.3 > /usr/share/doc/libXi-1.4.3/COPYING > > No bug ticket number either. > Your own +1 in bodhi is without a comment. > Assuming I wanted to test this, what would I do? ok, fair call, should've created a bug for this. This bug is triggered with new features added in the next X server version (that's not even upstream). Corruption happens when the XIQueryDevice reply includes input classes that are not recognised by Xlib. You can't trigger this bug without having the right git trees, but you can verify that the fix doesn't break anything by running "xinput list" or pretty much any application that uses XI2. fwiw, the reason I pushed this in now is because I didn't want anyone to have that library still around when the X server patches hit rawhide. plus, there's the odd chance that proprietary extensions can trigger this, though I don't think any of these exist. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Module-Metadata] Created tag perl-Module-Metadata-1.000007-1.fc17
The lightweight tag 'perl-Module-Metadata-1.07-1.fc17' was created pointing to: 1b83f0c... Update to 1.07 -- 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-Module-Metadata] Update to 1.000007
commit 1b83f0cbec2db3fbea660fd425163e28dce2dc39
Author: Paul Howarth
Date: Wed Sep 7 22:52:25 2011 +0100
Update to 1.07
- New upstream release 1.07
- Apply VMS fixes backported from blead
perl-Module-Metadata.spec |6 +-
sources |2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/perl-Module-Metadata.spec b/perl-Module-Metadata.spec
index dbd7625..3f83560 100644
--- a/perl-Module-Metadata.spec
+++ b/perl-Module-Metadata.spec
@@ -1,5 +1,5 @@
Name: perl-Module-Metadata
-Version: 1.06
+Version: 1.07
Release: 1%{?dist}
Summary: Gather package and POD information from perl module files
License: GPL+ or Artistic
@@ -51,6 +51,10 @@ make test TEST_FILES="t/*.t xt/*.t"
%{_mandir}/man3/Module::Metadata.3pm*
%changelog
+* Wed Sep 7 2011 Paul Howarth - 1.07-1
+- Update to 1.07
+ - Apply VMS fixes backported from blead
+
* Sun Sep 4 2011 Paul Howarth - 1.06-1
- Update to 1.06
- Support PACKAGE BLOCK syntax
diff --git a/sources b/sources
index f6cf8f0..75501db 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a9b445f7aac0230015f9e193ecfa6f04 Module-Metadata-1.06.tar.gz
+411d62f242c09ecee6ccaf558f516cc8 Module-Metadata-1.07.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
File Module-Metadata-1.000007.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Metadata: 411d62f242c09ecee6ccaf558f516cc8 Module-Metadata-1.07.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: "Baseurl" download source for now?
On Wed, 2011-09-07 at 23:22 +0200, Jos Vos wrote: > On Wed, Sep 07, 2011 at 01:55:53PM -0700, Jesse Keating wrote: > > > See https://fedoraproject.org/wiki/Anaconda/Kickstart#repo for specific > > instructions on how to supply a mirror list in kickstart. > > But isn't it so that yum/anaconda stay with the same mirror once one > is selected? No. If an update includes package foo-1.0-1.fc16, and the initially selected repo doesn't have that package, yum cycles through other repos on the list until it finds one which does have the package. It only fails if it can't find any repo with the package. -- 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: "Baseurl" download source for now?
On Wed, Sep 07, 2011 at 01:55:53PM -0700, Jesse Keating wrote: > See https://fedoraproject.org/wiki/Anaconda/Kickstart#repo for specific > instructions on how to supply a mirror list in kickstart. But isn't it so that yum/anaconda stay with the same mirror once one is selected? My problem was that --mirrorlist didn't work because the selected mirror probably had an inconsistent repo (I tried 2 or 3 installs that all failed) and I had to specify a well-known mirror with --baseurl to solve this problem. -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Sep 7, 2011, at 1:37 PM, Josh Boyer wrote: > On Wed, Sep 7, 2011 at 3:31 PM, Adam Williamson wrote: >> On Wed, 2011-09-07 at 16:28 +0200, Jos Vos wrote: >>> On Wed, Sep 07, 2011 at 10:22:48AM -0400, seth vidal wrote: >>> Broken how? If the mirror is not functional yum should switch to the next mirror in your mirrorlist from mirrormanager. >>> >>> Well, I have had broken (kickstart) installs more than once, because >>> packages couldn't be found etc. I had to solve this by specifying a >>> well-known mirror as base url. >>> >>> If a mirror is accessible, but has a broken repository, you're lost. >> >> Sounds like anaconda could do with cribbing yum's code for falling back >> to alternate mirrors when it can't find a file on the first mirror it >> tries. > > I'm pretty sure anaconda already uses yum for this. IIRC, giving a > repo to anaconda via kickstart is like specifying baseurl to yum, > which also doesn't fall back. You need mirrorlist for that > functionality. > > josh See https://fedoraproject.org/wiki/Anaconda/Kickstart#repo for specific instructions on how to supply a mirror list in kickstart. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, Sep 7, 2011 at 3:31 PM, Adam Williamson wrote: > On Wed, 2011-09-07 at 16:28 +0200, Jos Vos wrote: >> On Wed, Sep 07, 2011 at 10:22:48AM -0400, seth vidal wrote: >> >> > Broken how? If the mirror is not functional yum should switch to the >> > next mirror in your mirrorlist from mirrormanager. >> >> Well, I have had broken (kickstart) installs more than once, because >> packages couldn't be found etc. I had to solve this by specifying a >> well-known mirror as base url. >> >> If a mirror is accessible, but has a broken repository, you're lost. > > Sounds like anaconda could do with cribbing yum's code for falling back > to alternate mirrors when it can't find a file on the first mirror it > tries. I'm pretty sure anaconda already uses yum for this. IIRC, giving a repo to anaconda via kickstart is like specifying baseurl to yum, which also doesn't fall back. You need mirrorlist for that functionality. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
cherokee-1.2.x for EL5 [WAS]: Re: howto build for EL5 on F15 in mock?
Michał Piotrowski píše v Út 06. 09. 2011 v 20:27 +0200: > 2011/9/6 Itamar Reis Peixoto : > > 2011/9/6 Michał Piotrowski : > >> Hi, > >> > >> I'm trying to build cherokee-1.2.1 for EL5 on my F15 system and I'm > >> getting an error > >> DEBUG util.py:250: cherokee > >> ## > >> DEBUG util.py:250: error: unpacking of archive failed on file > >> /builddir/build/SOURCES/01-drop-privileges.patch;4e664eb5: cpio: MD5 > >> sum mismatch > >> > >> AFAICS I can build this package for F15. I will be grateful for any hint. Hello there is another problem with cherokee and EL5. Cherokee wants to use openssl 1.0 but there is only 0.9.8e version on RHEL5 I've tried create it with openssl built staticly, you can try it. http://ftp-hk.tmapy.cz/tmapy-twist/centos/5/testing/SRPMS/cherokee-1.2.98-1.el5.src.rpm But I don't know if it is working, you can try it on my web https://ftp-hk.tmapy.cz/ it seams it returns nothing when html page is big. I don't know how to debug it. Can you help me? Pavel > >> -- > >> Best regards, > >> Michal > >> > >> http://eventhorizon.pl/ > > > > download the sources. > > > > fedpkg clone cherokee > > cd cherokee > > fedpkg local > > I cloned this tree > git://pkgs.fedoraproject.org/cherokee.git > with git, I guess that "fedpkg clone cherokee" does the same. > > Thanks! > > > > > > > > > > -- > > > > > > Itamar Reis Peixoto > > msn, google talk: ita...@ispbrasil.com.br > > +55 11 4063 5033 (FIXO SP) > > +55 34 9158 9329 (TIM) > > +55 34 8806 3989 (OI) > > +55 34 3221 8599 (FIXO MG) > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > > > -- > Best regards, > Michal > > http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 7, 2011 at 2:35 PM, Adam Williamson wrote: > it's worth noting a 'cleaner' way to do this than messing up your main > system with 32-bit packages is to use mock: you can use mock -r > fedora-16-i386 --shell to give yourself interactive access to a nice > clean 32-bit buildroot, then install all the devel packages and > compilers you need, and build your code. Might not be what you want, but > I thought it was worth mentioning. I don't think yum will run inside the chroot by default so make sure you install everything you need on the front end. I usually do it like this (some steps may be able to be combined, but it works, so I haven't experimented). mock -r --init mock -r --install mock -r --shell The first two lines are also useful if you run into a situation where you're working on a review request which has dependencies that are not in the repos yet (i.e., may also be under review). Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, 2011-09-07 at 11:52 -0400, Nathaniel McCallum wrote: > "gcc -m32 -o foo foo.c" gives me: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file > or directory > > If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package > into the right place and run the command above again I get: > /usr/bin/ld: cannot find crt1.o: No such file or directory > /usr/bin/ld: cannot find crti.o: No such file or directory > /usr/bin/ld: skipping > incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when > searching for -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for > -lc > /usr/bin/ld: cannot find -lc > /usr/bin/ld: skipping > incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when > searching for -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > /usr/bin/ld: cannot find crtn.o: No such file or directory > collect2: ld returned 1 exit status > > Hrm... > > Am I doing something wrong? Or is this a packaging bug? I can't think of > any reason why I shouldn't be able to compile at least a basic C program > with no deps as 32bit on 64bit. it's worth noting a 'cleaner' way to do this than messing up your main system with 32-bit packages is to use mock: you can use mock -r fedora-16-i386 --shell to give yourself interactive access to a nice clean 32-bit buildroot, then install all the devel packages and compilers you need, and build your code. Might not be what you want, but I thought it was worth mentioning. -- 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: "Baseurl" download source for now?
On Wed, 2011-09-07 at 16:28 +0200, Jos Vos wrote: > On Wed, Sep 07, 2011 at 10:22:48AM -0400, seth vidal wrote: > > > Broken how? If the mirror is not functional yum should switch to the > > next mirror in your mirrorlist from mirrormanager. > > Well, I have had broken (kickstart) installs more than once, because > packages couldn't be found etc. I had to solve this by specifying a > well-known mirror as base url. > > If a mirror is accessible, but has a broken repository, you're lost. Sounds like anaconda could do with cribbing yum's code for falling back to alternate mirrors when it can't find a file on the first mirror it tries. -- 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: Did gtkhtml2 package disappear?
On Tue, 2011-09-06 at 15:34 -0400, Daniel J Walsh wrote: > On 09/06/2011 01:49 PM, Michael Schwendt wrote: > > On Tue, 06 Sep 2011 13:00:21 -0400, DJW (Daniel) wrote: > > > >> I guess what I really need is gnome-python2-gtkhtml2, has this > >> been replaced? > > > > What I could find is a request to drop it (it's a > > gnome-python2-extras subpackage): > > > > Disable Python bindings for gtkhtml2 (dead package) > > https://bugzilla.redhat.com/731307 > > > Well I will drop the lockdown booleans package from > policycoreutils-gui. I don't have time to figure out an alternative > and I don't believe many/any people use this gui. The standard alternative seems to be webkit, quite a few packages I've noticed have migrated from gtkhtml to webkit. AFAICT, gtkhtml3 doesn't appear to have Python bindings. -- 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: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On Sat, 2011-09-03 at 15:46 +0200, Reindl Harald wrote: > the alpha was release and http://fedoraproject.org/wiki/Features/SysVtoSystemd > is at 0% - why will F16 released WITHOUT making the system clean which > should have been done for F15 > > How many releases will this dirty mix of systemd/sysvinit(lsb in the > distribution exist until the OS can be called as "clean" like before > F15? The feature page has not been edited since June. It's often the case that you can't entirely rely on those completion %ages. The tracker bug - https://bugzilla.redhat.com/show_bug.cgi?id=713562 - is a better place to monitor progress in this case. -- 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: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
On Mon, 05 Sep 2011 19:50:53 +0200 Hans de Goede wrote: > Jonathan, can you give bluez-4.96-3.fc17 a spin? It should fix your > mouse + keyboard issue. Will do, but not before the weekend - I forgot to bring the desktop system to LPC :) Thanks for addressing this, jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Marking zapped bugs
On Sat, 2011-09-03 at 10:45 +0200, Matej Cepl wrote: > Dne 2.9.2011 22:54, Adam Williamson napsal(a): > > Hum, I didn't realize our resolutions were so customized, I thought they > > were the upstream ones; this is what I've been told when discussing > > custom resolutions in the past. It's certainly something you could > > propose as an enhancement by filing a bug against Bugzilla, then. > > If we had upstream’s UNCONFIRMED we wouldn't have to play with the > Triaged keyword (although the meaning is subtly different). More than subtly. We explicitly *don't* require triagers to confirm bugs on their own systems. -- 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: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: > On 7 September 2011 01:02, Adam Williamson wrote: > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > > case-by-case enforcement of this policy? > > I'm guilty of this too; when I file an update that's not getting > enough karma (after a few weeks) then I give it a spin in a *fresh* VM > and test it out like any normal user would do. If this is wrong, > consider my wrists slapped, but otherwise I think it makes sense and > gets things moving. It's against the current policy. I've argued along the same lines as you in past threads on this list, but I was on the minority side of the debate at the time, it seemed; more people were worried that maintainers would +1 their updates without bothering to test them properly. -- 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: Compiling 32bit on 64bit Fedora
On Wed, 7 Sep 2011 12:04:06 -0400, NM (Nathaniel) wrote: > That was what I thought... Sot it was the first thing I tried (note, > this is F16): > $ sudo yum install glibc-devel.i686 > Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, > remove-with-leaves, rpm-warm-cache, show- > : leaves, versionlock > Loading mirror speeds from cached hostfile > * fedora: www.gtlib.gatech.edu > * updates: mirrors.servercentral.net > * updates-testing: mirror.fdcservers.net > Setting up Install Process > No package glibc-devel.i686 available. > Error: Nothing to do The full show, please. "yum list glibc-devel" at least. Plus any attempts at pruning your Yum plugins and querying the repositories. http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/development/16/x86_64/os/Packages/glibc-devel-2.14.90-4.i686.rpm -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.49 0.23 0.15 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
Am 07.09.2011 20:00, schrieb Michael Cronenworth: > Genes MailLists on 09/07/2011 12:57 PM wrote: >> Seems pretty useful for users to see what changed - curious why not? > > Users are not programmers. Commits may range from "merge from branch > such-n-such" to "ran indent to clean up formatting" which has extremely > little value to users. +1 from me. Well, it would be convenient to automate the rpm changelog creation in some way. But we need *our* changelog for *our* changes to the package. Most packages ship a NEWS file anyway, which includes the changes to the software itself. Best Regards, Mario -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
Genes MailLists on 09/07/2011 12:57 PM wrote: > Seems pretty useful for users to see what changed - curious why not? Users are not programmers. Commits may range from "merge from branch such-n-such" to "ran indent to clean up formatting" which has extremely little value to users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
On 09/07/2011 01:50 PM, Michael Cronenworth wrote: > Rich Megginson on 09/07/2011 12:44 PM wrote: >> git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat >> >> the | cat (or | more) is needed because git log will truncate lines > > This is not what I meant. > > Upstream may have had 20-30 commits inbetween tags. I wouldn't want to > see 20-30 lines of RPM changelog. Seems pretty useful for users to see what changed - curious why not? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
Rich Megginson on 09/07/2011 12:44 PM wrote: > git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat > > the | cat (or | more) is needed because git log will truncate lines This is not what I meant. Upstream may have had 20-30 commits inbetween tags. I wouldn't want to see 20-30 lines of RPM changelog. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
On 09/07/2011 11:12 AM, Michael Cronenworth wrote: > Genes MailLists wrote: >> Would a git-shortlog suffice for %changelog ? > It would need to be "git-short-shortlog" (hypothetically) as filling a > rpm changelog with hundreds of lines of commits is not very helpful. > > I've always considered the rpm changelog to be a changelog of the spec > itself and a very brief summary of any upstream changes. git log --oneline TAG-OF-PREVIOUS-RELEASE.. | cat the | cat (or | more) is needed because git log will truncate lines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 7 September 2011 01:02, Adam Williamson wrote: > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > case-by-case enforcement of this policy? I'm guilty of this too; when I file an update that's not getting enough karma (after a few weeks) then I give it a spin in a *fresh* VM and test it out like any normal user would do. If this is wrong, consider my wrists slapped, but otherwise I think it makes sense and gets things moving. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/07/2011 12:42 PM, Josh Boyer wrote: > On Wed, Sep 7, 2011 at 12:32 PM, Genes MailLists wrote: >> On 09/07/2011 09:57 AM, Josh Boyer wrote: >> >> >>> >>> %changelog isn't for developers. It's for users to see what the >>> developers changed in the package. >>> >> >> Would a git-shortlog suffice for %changelog ? Assuming appropriate >> comments are required for fedora's git repo. > > No... users can access %changelog for the RPMs on their system via > rpm. Making them go to a git repository elsewhere to figure out what > changed isn't exactly friendly. > > Unless of course you meant "have fedpkg automatically stick a > git-shortlog into the %changelog section of the spec file on commit" > or something. Then.. maybe. The installer team has been doing this for anaconda for a while now. The RPM changelog block is automatically generated for us when we make a new release. When we do a "make release", this script (among other things) is run: http://git.fedorahosted.org/git/?p=anaconda.git;a=blob_plain;f=scripts/makebumpver;hb=HEAD And we have a commit log format we follow: http://git.fedorahosted.org/git/?p=anaconda.git;a=blob_plain;f=docs/commit-log.txt;hb=HEAD It works well for us. > And yes, this assumes in all cases that developers are actually > putting useful information in both %changelog and commit logs. -- David Cantrell Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 7 Sep 2011 11:00:57 +1000, PH (Peter) wrote: > sometimes a +1 after weeks in testing is the only or at least easy way to > nudge a package into stable. > > e.g: https://admin.fedoraproject.org/updates/libXi-1.4.3-2.fc15 > even with my +1 still not there, and this isn't the only package I've done > this for. | Details |Don't corrupt memory if the server sends unknown classes in XIQueryDevice. # rpm -qi libXi|grep -A2 ^De Description : X.Org X11 libXi runtime library # rpm -qd libXi /usr/share/doc/libXi-1.4.3/COPYING # rpm -ql libXi /usr/lib64/libXi.so.6 /usr/lib64/libXi.so.6.1.0 /usr/share/doc/libXi-1.4.3 /usr/share/doc/libXi-1.4.3/COPYING No bug ticket number either. Your own +1 in bodhi is without a comment. Assuming I wanted to test this, what would I do? -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.17 0.06 0.06 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm changelog (was Re: Notice of intent: patching glibc)
Genes MailLists wrote: > Would a git-shortlog suffice for %changelog ? It would need to be "git-short-shortlog" (hypothetically) as filling a rpm changelog with hundreds of lines of commits is not very helpful. I've always considered the rpm changelog to be a changelog of the spec itself and a very brief summary of any upstream changes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 7, 2011 at 1:04 PM, Kevin Fenzi wrote: > On Wed, 7 Sep 2011 12:23:11 -0400 > Nathaniel McCallum wrote: > >> I don't appear to have any i[356]86 packages in any of the repos on my >> F16 box. Is there an rpm I'm missing? > > No, it should show them out of the box. > > Does: > > yum --noplugins list glibc-devel.i686 > > work? Yes, It does! Which plugin would filter those out? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, 7 Sep 2011 12:23:11 -0400 Nathaniel McCallum wrote: > I don't appear to have any i[356]86 packages in any of the repos on my > F16 box. Is there an rpm I'm missing? No, it should show them out of the box. Does: yum --noplugins list glibc-devel.i686 work? do you have any excludes= in /etc/yum.conf or /etc/yum.repos.d/* ? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
Nathaniel McCallum wrote: > I don't appear to have any i[356]86 packages in any of the repos on my > F16 box. Is there an rpm I'm missing? How are you making this determination? At first glance, this mirror[1] has 32-bit and 64-bit binaries. [1] http://mirror.hiwaay.net/pub/fedora/linux/development/16/x86_64/os/Packages/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/07/2011 12:42 PM, Josh Boyer wrote: > > > Unless of course you meant "have fedpkg automatically stick a > git-shortlog into the %changelog section of the spec file on commit" > or something. Then.. maybe. Yah I meant this one .. :-) > > And yes, this assumes in all cases that developers are actually > putting useful information in both %changelog and commit logs. > Indeed .. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Wed, Sep 7, 2011 at 12:32 PM, Genes MailLists wrote: > On 09/07/2011 09:57 AM, Josh Boyer wrote: > > >> >> %changelog isn't for developers. It's for users to see what the >> developers changed in the package. >> > > Would a git-shortlog suffice for %changelog ? Assuming appropriate > comments are required for fedora's git repo. No... users can access %changelog for the RPMs on their system via rpm. Making them go to a git repository elsewhere to figure out what changed isn't exactly friendly. Unless of course you meant "have fedpkg automatically stick a git-shortlog into the %changelog section of the spec file on commit" or something. Then.. maybe. And yes, this assumes in all cases that developers are actually putting useful information in both %changelog and commit logs. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate provides for provides for perl(DynaLoader)
On Wed, Sep 7, 2011 at 6:32 PM, Richard Hughes wrote: > On 7 September 2011 16:31, Jesse Keating wrote: >> It is intentional that both the base perl package and the split off package >> provide the same things, they are expecting n-v-r ordering to sort it out. > > Sure, but I couldn't see why something that is involved with creating > makefiles would provide a common C-loader-into-perl interface. > > DynaLoader - Dynamically load C libraries into Perl code > ExtUtils::MakeMaker - Create a module Makefile > > Either way, it's probably a bug in my code that it's issuing the > warning, and I'll see what I can do to reproduce it in a test case. > Thanks. There's definitely an error in the perl-ExtUtils-MakeMaker sub-package, though; it shouldn't be providing perl(DynaLoader). File a bug against perl so we don't forget about it. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On 09/07/2011 09:57 AM, Josh Boyer wrote: > > %changelog isn't for developers. It's for users to see what the > developers changed in the package. > Would a git-shortlog suffice for %changelog ? Assuming appropriate comments are required for fedora's git repo. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate provides for provides for perl(DynaLoader)
On 7 September 2011 16:31, Jesse Keating wrote: > It is intentional that both the base perl package and the split off package > provide the same things, they are expecting n-v-r ordering to sort it out. Sure, but I couldn't see why something that is involved with creating makefiles would provide a common C-loader-into-perl interface. DynaLoader - Dynamically load C libraries into Perl code ExtUtils::MakeMaker - Create a module Makefile Either way, it's probably a bug in my code that it's issuing the warning, and I'll see what I can do to reproduce it in a test case. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 7, 2011 at 12:15 PM, Ricky Zhou wrote: > On 2011-09-07 12:04:06 PM, Nathaniel McCallum wrote: >> That was what I thought... Sot it was the first thing I tried (note, >> this is F16): >> $ sudo yum install glibc-devel.i686 >> Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, >> remove-with-leaves, rpm-warm-cache, show- >> : leaves, versionlock >> Loading mirror speeds from cached hostfile >> * fedora: www.gtlib.gatech.edu >> * updates: mirrors.servercentral.net >> * updates-testing: mirror.fdcservers.net >> Setting up Install Process >> No package glibc-devel.i686 available. >> Error: Nothing to do > Strange - just tried a yum clean all followed by yum install > glibc-devel.i686 libgcc.i686 on Kevin's F16 test machine - maybe > whatever issue with glibc-devel in the repos has been fixed now? I don't appear to have any i[356]86 packages in any of the repos on my F16 box. Is there an rpm I'm missing? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Strange rpath issue with F-16 and F-17
Hi, I just noticed a strange rpath issue with my PyQwt package. Building the latest git version on F-16 and F-17 results in "-rpath,/usr/lib64" being appended to the g++ compiler options. Build logs of scratch builds are here: https://koji.fedoraproject.org/koji/getfile?taskID=3332309&name=build.log https://koji.fedoraproject.org/koji/getfile?taskID=3332685&name=build.log However, building the latest git version on F-15 doesn't exhibit this problem. See build log: https://koji.fedoraproject.org/koji/getfile?taskID=3332430&name=build.log What has changed between F-15 and F-16 so that "-rpath,/usr/lib64" gets appended to g++ options? What is the best way to fix this? Regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On 2011-09-07 12:04:06 PM, Nathaniel McCallum wrote: > That was what I thought... Sot it was the first thing I tried (note, > this is F16): > $ sudo yum install glibc-devel.i686 > Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, > remove-with-leaves, rpm-warm-cache, show- > : leaves, versionlock > Loading mirror speeds from cached hostfile > * fedora: www.gtlib.gatech.edu > * updates: mirrors.servercentral.net > * updates-testing: mirror.fdcservers.net > Setting up Install Process > No package glibc-devel.i686 available. > Error: Nothing to do Strange - just tried a yum clean all followed by yum install glibc-devel.i686 libgcc.i686 on Kevin's F16 test machine - maybe whatever issue with glibc-devel in the repos has been fixed now? Thanks, Ricky pgpbR5Q3MUw7Q.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 7, 2011 at 12:04 PM, Nathaniel McCallum wrote: > On Wed, Sep 7, 2011 at 11:56 AM, Ricky Zhou wrote: >> On 2011-09-07 11:52:58 AM, Nathaniel McCallum wrote: >>> "gcc -m32 -o foo foo.c" gives me: >>> /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file >>> or directory >>> >>> If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package >>> into the right place and run the command above again I get: >> I don't think you should need to copy files manually like that - just >> install glibc-devel.i686 and libgcc.i686. > > That was what I thought... Sot it was the first thing I tried (note, > this is F16): > $ sudo yum install glibc-devel.i686 > Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, > remove-with-leaves, rpm-warm-cache, show- > : leaves, versionlock > Loading mirror speeds from cached hostfile > * fedora: www.gtlib.gatech.edu > * updates: mirrors.servercentral.net > * updates-testing: mirror.fdcservers.net > Setting up Install Process > No package glibc-devel.i686 available. > Error: Nothing to do Could this be related to the recent events surrounding glibc that caused RPMs to be pulled from the repo? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 7, 2011 at 11:56 AM, Ricky Zhou wrote: > On 2011-09-07 11:52:58 AM, Nathaniel McCallum wrote: >> "gcc -m32 -o foo foo.c" gives me: >> /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file >> or directory >> >> If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package >> into the right place and run the command above again I get: > I don't think you should need to copy files manually like that - just > install glibc-devel.i686 and libgcc.i686. That was what I thought... Sot it was the first thing I tried (note, this is F16): $ sudo yum install glibc-devel.i686 Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, remove-with-leaves, rpm-warm-cache, show- : leaves, versionlock Loading mirror speeds from cached hostfile * fedora: www.gtlib.gatech.edu * updates: mirrors.servercentral.net * updates-testing: mirror.fdcservers.net Setting up Install Process No package glibc-devel.i686 available. Error: Nothing to do -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On 07/09/11 16:52, Nathaniel McCallum wrote: > "gcc -m32 -o foo foo.c" gives me: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file > or directory > > If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package > into the right place and run the command above again I get: Installing the 32 bit glibc-devel package would probably have worked better. > Am I doing something wrong? Or is this a packaging bug? I can't think of > any reason why I shouldn't be able to compile at least a basic C program > with no deps as 32bit on 64bit. Well you can, but you do need things like glibc-devel.i686 to do it... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On Wed, Sep 07, 2011 at 11:52:58AM -0400, Nathaniel McCallum wrote: > "gcc -m32 -o foo foo.c" gives me: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file > or directory > > If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package > into the right place and run the command above again I get: > /usr/bin/ld: cannot find crt1.o: No such file or directory > /usr/bin/ld: cannot find crti.o: No such file or directory > /usr/bin/ld: skipping > incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when > searching for -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for > -lc > /usr/bin/ld: cannot find -lc > /usr/bin/ld: skipping > incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when > searching for -lgcc_s > /usr/bin/ld: cannot find -lgcc_s > /usr/bin/ld: cannot find crtn.o: No such file or directory > collect2: ld returned 1 exit status > > Hrm... > > Am I doing something wrong? Or is this a packaging bug? I can't think of > any reason why I shouldn't be able to compile at least a basic C program > with no deps as 32bit on 64bit. No, it is a user error. The packaging goal is that nobody is forced to have 32-bit packages installed on x86_64 (and similarly for other architectures). So, if you want to compile/link 32-bit packages, you need to install a minimal set of 32-bit packages (at least yum install glibc-devel.i686 libgcc.i686 ). Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Compiling 32bit on 64bit Fedora
On 2011-09-07 11:52:58 AM, Nathaniel McCallum wrote: > "gcc -m32 -o foo foo.c" gives me: > /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file > or directory > > If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package > into the right place and run the command above again I get: I don't think you should need to copy files manually like that - just install glibc-devel.i686 and libgcc.i686. Thanks, Ricky pgp2FyVRUwoJp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Compiling 32bit on 64bit Fedora
"gcc -m32 -o foo foo.c" gives me: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory If I copy the gnu/stubs-32.h file from the 32bit glibc-devel package into the right place and run the command above again I get: /usr/bin/ld: cannot find crt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc /usr/bin/ld: cannot find -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/4.6.1/libgcc_s.so when searching for -lgcc_s /usr/bin/ld: cannot find -lgcc_s /usr/bin/ld: cannot find crtn.o: No such file or directory collect2: ld returned 1 exit status Hrm... Am I doing something wrong? Or is this a packaging bug? I can't think of any reason why I shouldn't be able to compile at least a basic C program with no deps as 32bit on 64bit. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-distutils-extra for EPEL?
On Wed, Sep 07, 2011 at 10:28:19AM -0500, Matt Domsch wrote: > > 05.09.2011, 20:35, "Fedora Python SIG" > > : > > > 31.08.2011, 00:58, "Matt Domsch" : > > > - Is anyone in the Python SIG interested in maintaining > > > - python-distutils-extra in el6? The Fedora maintainer has declined to > > > - participate in EPEL, but would welcome someone else doing so. The > > > - rawhide copy builds clean in koji against el6 right now, so it > > > - shouldn't be that hard to maintain. > > > - > > > - This is needed by openstack-nova, which the Cloud SIG is in process of > > > - packaging for Fedora and EL6. > > > On Wed, Sep 07, 2011 at 06:25:23AM -0500, nomc...@yandex.ru wrote: > > It's very interesting.How and what can I > > begin? Before I didn't realise such tasks. > > While above I said python-distutils-extra, I really meant the package > bpython. p-d-e was built by fab, and he pushed it to updates-testing > for EPEL. I built bpython, and pushed it to updates-testing for EPEL. > > Going forward, I would like you to maintain bpython for EPEL, just as > you do for Fedora. (by "you", I mean a member of the python SIG who is interested in such. I recognize nomctan is not the official owner of bpython Fedora branches). -- Matt Domsch Technology Strategist Dell | Office of the CTO ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 11:30 -0400, Josh Boyer wrote: > On Wed, Sep 7, 2011 at 11:18 AM, seth vidal wrote: > > On Wed, 2011-09-07 at 19:16 +0400, Dmitry Butskoy wrote: > >> Dmitry Butskoy wrote: > >> > seth vidal wrote: > >> > > >> >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > >> >> > >> >> > >> >>> Well, but what should I do if that mirror seems broken? > >> >>> > >> >>> > >> >> Broken how? > >> >> > >> > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > >> > > >> > >> Now the files have appeared, but the repomd.xml files are still differ. > >> > >> Compare: > >> http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > >> and > >> http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > >> > >> It seems something is not reliable in the mirroring process... > >> > > > > it is a mirror - it happens gradually. > > It might be worth pointing out that mirrors.kernel.org has been down > for a couple of days, so any of the other mirrors that sync from that > will be stale. A good point. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate provides for provides for perl(DynaLoader)
On Sep 7, 2011, at 7:52 AM, Richard Hughes wrote: > Not really a big problem, but I got this in my daily updates check: > > (zif:836): Zif-WARNING **: found multiple provides for perl(DynaLoader) ~ : > (zif:836): Zif-WARNING **: > 1.perl-ExtUtils-MakeMaker-6.57.5-187.fc16.noarch (updates-testing) > (zif:836): Zif-WARNING **: 2. perl-4:5.14.1-187.fc16.x86_64 (updates-testing) > > Is this intentional? It seemed a bit odd to be provided by the former. > > Richard. I believe it is intentional. The perl sig has split out some of what's bundled in perl itself until individual packages that can be updated out of sync with perl itself. It is intentional that both the base perl package and the split off package provide the same things, they are expecting n-v-r ordering to sort it out. This isn't much different from having two versions of the same package, an older one in base and a newer one in updates. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, Sep 7, 2011 at 11:18 AM, seth vidal wrote: > On Wed, 2011-09-07 at 19:16 +0400, Dmitry Butskoy wrote: >> Dmitry Butskoy wrote: >> > seth vidal wrote: >> > >> >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: >> >> >> >> >> >>> Well, but what should I do if that mirror seems broken? >> >>> >> >>> >> >> Broken how? >> >> >> > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. >> > >> >> Now the files have appeared, but the repomd.xml files are still differ. >> >> Compare: >> http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml >> and >> http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml >> >> It seems something is not reliable in the mirroring process... >> > > it is a mirror - it happens gradually. It might be worth pointing out that mirrors.kernel.org has been down for a couple of days, so any of the other mirrors that sync from that will be stale. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: python-distutils-extra for EPEL?
> 05.09.2011, 20:35, "Fedora Python SIG" : > > 31.08.2011, 00:58, "Matt Domsch" : > > - Is anyone in the Python SIG interested in maintaining > > - python-distutils-extra in el6? The Fedora maintainer has declined to > > - participate in EPEL, but would welcome someone else doing so. The > > - rawhide copy builds clean in koji against el6 right now, so it > > - shouldn't be that hard to maintain. > > - > > - This is needed by openstack-nova, which the Cloud SIG is in process of > > - packaging for Fedora and EL6. On Wed, Sep 07, 2011 at 06:25:23AM -0500, nomc...@yandex.ru wrote: > It's very interesting.How and what can I > begin? Before I didn't realise such tasks. While above I said python-distutils-extra, I really meant the package bpython. p-d-e was built by fab, and he pushed it to updates-testing for EPEL. I built bpython, and pushed it to updates-testing for EPEL. Going forward, I would like you to maintain bpython for EPEL, just as you do for Fedora. The el6 branch now exists in the bpython git package. https://fedoraproject.org/wiki/Joining_EPEL https://fedoraproject.org/wiki/EPEL_Package_Maintainers Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: submitters +1ing their own packages
On Wed, Sep 07, 2011 at 01:38:09PM +1000, Peter Hutterer wrote: > On Tue, Sep 06, 2011 at 07:38:53PM -0700, Adam Williamson wrote: > > > plus a trac ticket. Whether it has some practical effect or not, it's > > clearly against the current policy, and what I'm questioning is whether > > Bodhi should be enforcing that policy automatically. > > my argument is that even though it's against official policy, it can be > useful in some cases. The current voluntary compliance is imo a good > solution since it can be circumvented when needed. I'm definitely not > advocating doing this for every update. > Then the current policy needs to be modified to show that this is appropriate. Otherwise there are people who follow the rules and are disgruntled that other people are able to get away with not following them. One aspect of policy should be to give people an understanding of how to coexist with one another. If the rules don't apply equally (even if that means "The rules apply to those who feel the need to follow them and don't apply to those who do not feel the need to do so") then the common understanding is broken. Getting the policy updated so that people know that there are cases where you can +1 your own update is a better way to build community than just letting people who feel okay about doing so circumvent the policy when they see fit. -Toshio pgpovBnPZs3TJ.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 19:16 +0400, Dmitry Butskoy wrote: > Dmitry Butskoy wrote: > > seth vidal wrote: > > > >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > >> > >> > >>> Well, but what should I do if that mirror seems broken? > >>> > >>> > >> Broken how? > >> > > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > > > > Now the files have appeared, but the repomd.xml files are still differ. > > Compare: > http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > and > http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml > > It seems something is not reliable in the mirroring process... > it is a mirror - it happens gradually. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
Dmitry Butskoy wrote: > seth vidal wrote: > >> On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: >> >> >>> Well, but what should I do if that mirror seems broken? >>> >>> >> Broken how? >> > Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > Now the files have appeared, but the repomd.xml files are still differ. Compare: http://download.fedora.redhat.com/pub/fedora/linux/updates/14/SRPMS/repodata/repomd.xml and http://mirror.yandex.ru/fedora/linux/updates/14/SRPMS/repodata/repomd.xml It seems something is not reliable in the mirroring process... Regards, Dmitry Butskoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 03:06 PM, "Jóhann B. Guðmundsson" wrote: > On 09/07/2011 03:04 PM, Rahul Sundaram wrote: >> On 09/07/2011 08:20 PM, Tomasz Torcz wrote: >>> (I would prefer dropping sysconfig file altogether, like Lennart >>> suggested some time ago. And few other. It should work with only >>> ExecStart= and User= in [Service]). >> I am fine with dropping the sysconfig file > > It kinda does not server purpose from my point of view having an > Environment= that gets called once so final would look something like > this... > > [Unit] > Description=Transmission-Daemon A bittorrent Client > After=syslog.target network.target > > [Service] > User=transmission > ExecStart=/usr/bin/transmission-daemon -f --blocklist -g > /var/lib/transmission/.config/transmission > StandardError=syslog > > [Install] > WantedBy=multi-user.target > Sorry missed the -T when puzzle this together for that post so ExecStart should look like... ExecStart=/usr/bin/transmission-daemon -f -T --blocklist -g /var/lib/transmission/.config/transmission JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 03:04 PM, Rahul Sundaram wrote: > On 09/07/2011 08:20 PM, Tomasz Torcz wrote: >> (I would prefer dropping sysconfig file altogether, like Lennart >> suggested some time ago. And few other. It should work with only >> ExecStart= and User= in [Service]). > I am fine with dropping the sysconfig file It kinda does not server purpose from my point of view having an Environment= that gets called once so final would look something like this... [Unit] Description=Transmission-Daemon A bittorrent Client After=syslog.target network.target [Service] User=transmission ExecStart=/usr/bin/transmission-daemon -f --blocklist -g /var/lib/transmission/.config/transmission StandardError=syslog [Install] WantedBy=multi-user.target -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 08:20 PM, Tomasz Torcz wrote: > (I would prefer dropping sysconfig file altogether, like Lennart > suggested some time ago. And few other. It should work with only > ExecStart= and User= in [Service]). I am fine with dropping the sysconfig file Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/07/2011 04:14 PM +9:00:
> 06.09.2011 18:47, TASAKA Mamoru wrote:
>> Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/06/2011 07:00 PM +9:00:
>>> 05.09.2011 19:17, TASAKA Mamoru wrote:
>> 2. The line 28
%if %{?php_zend_api}0
cannot be parsed when %php_zend_api is not integer (and this is
actually happening
currently). The correct line would be something like
%if 0%{?php_zend_api?1:0}
however it seems this line is no longer needed on Fedora:
http://fedoraproject.org/wiki/Packaging:PHP#C_extensions_.28PECL_and_others.29
>>> It stil needed for EPEL
>>> http://fedoraproject.org/wiki/Packaging:EPEL#PHP_ABI_Check_Handling
>>> and exactly in this form
>>
>> Then you have to write this only for EPEL build. Again on F-17 parsing
>> "%if %{?php_zend_api}0" actually failed, because php_zend_api is not
>> integer
>> (actually %php_zend_api is now 20090626-x86-32 on F-17 i686)
>> This EPEL form is no longer valid on Fedora (at least on F-17).
>>
>> However "%if 0%{?php_zend_api?1:0}" is also wrong and this should be
>> "%if 0%{?php_zend_api:1}" if you want to use (guessing php_zend_api
>> is not defined as "0" even on EPEL)
>>
> It wasn't sole issue, but I understand your idea. Thank you again.
> It also was in php command below what I also make silent fail if command
> not found.
If you still see some issue, please write in detail what you see (and post
the spec file you are currently using).
> Just for interest - is there change of minimal buildroot happened since
> F15? Why it was worked before? Was it announced and I miss something?
F-15+ is using rpm 4.9.x. F-14 uses 4.8.1. At least this changed (note
that your initial spec file does not work even on F-15). Perhaps this
is related, although I have not examined further.
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Duplicate provides for provides for perl(DynaLoader)
Not really a big problem, but I got this in my daily updates check: (zif:836): Zif-WARNING **: found multiple provides for perl(DynaLoader) ~ : (zif:836): Zif-WARNING **: 1. perl-ExtUtils-MakeMaker-6.57.5-187.fc16.noarch (updates-testing) (zif:836): Zif-WARNING **: 2. perl-4:5.14.1-187.fc16.x86_64 (updates-testing) Is this intentional? It seemed a bit odd to be provided by the former. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On Wed, Sep 07, 2011 at 02:43:56PM +, "Jóhann B. Guðmundsson" wrote: > Here is a service file for transmission > https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service > >>> From the looks of it missing an > > I uploaded a new version with this command and changes suggested by > > Tomasz Torcz. > > Your unit file is still incomplete > > 2. If using an EnvironmentFile= we add '-' in front of the path. > 3. Adding the -f has the daemon stuck in foreground leaving the user > waiting for the command to complete Note that Type=forking is removed in new version, so it defaults to Type=simple and DTRT. (I would prefer dropping sysconfig file altogether, like Lennart suggested some time ago. And few other. It should work with only ExecStart= and User= in [Service]). -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 02:29 PM, Michał Piotrowski wrote: > W dniu 7 września 2011 16:18 użytkownik Michał Piotrowski > napisał: >> 2011/9/7 "Jóhann B. Guðmundsson": >>> On 09/07/2011 01:55 PM, Michał Piotrowski wrote: Yes, conversion into two separate services seems to be the most appropriate solution. Here is a service file for transmission https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service >>> From the looks of it missing an >>> >>> PIDFile=/run/transmission-daemon.pid >> I added this command to service and pid file isn't created. I'm using F15. >> > I uploaded a new version with this command and changes suggested by > Tomasz Torcz. Your unit file is still incomplete 1. there is no point in sourcing the sysconfig file if you are using an Environment variable 2. If using an EnvironmentFile= we add '-' in front of the path. 3. Adding the -f has the daemon stuck in foreground leaving the user waiting for the command to complete 4. You are calling the Environment you set wrong which results in.. 22197 /usr/bin/transmission-daemon -f -T # missing --blocklist -g /var/lib/transmission/.config/transmission 5. the reason there exist no pid file is because you omitted the section that creates it in the legacy sysv init script as in ""pidof -o %PPID -x $NAME > $DAEMON_PIDFILE" JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
seth vidal wrote: > On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > >> Well, but what should I do if that mirror seems broken? >> > > Broken how? Some SRPMS in fedora/linux/updates/14/SRPMS are missed. > Go to the url from the mirrorlist= line in a webbrowser and it will give > you all the baseurls you could possibly desire. > Thanks. I just have recollected download.fedora.redhat.com ;) BTW is there a way to filter some particular url from the mirrorlist? Regards, Dmitry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
Daniel J Walsh wrote: ... > Grab libselinux-2.1.5-3.fc17 out of koji, should fix the problem. Thanks. That solved it for me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
W dniu 7 września 2011 16:18 użytkownik Michał Piotrowski napisał: > 2011/9/7 "Jóhann B. Guðmundsson" : >> On 09/07/2011 01:55 PM, Michał Piotrowski wrote: >>> Yes, conversion into two separate services seems to be the most >>> appropriate solution. >>> >>> Here is a service file for transmission >>> https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service >> >> From the looks of it missing an >> >> PIDFile=/run/transmission-daemon.pid > > I added this command to service and pid file isn't created. I'm using F15. > I uploaded a new version with this command and changes suggested by Tomasz Torcz. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, Sep 07, 2011 at 10:22:48AM -0400, seth vidal wrote: > Broken how? If the mirror is not functional yum should switch to the > next mirror in your mirrorlist from mirrormanager. Well, I have had broken (kickstart) installs more than once, because packages couldn't be found etc. I had to solve this by specifying a well-known mirror as base url. If a mirror is accessible, but has a broken repository, you're lost. -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 18:04 +0400, Dmitry Butskoy wrote: > seth vidal wrote: > > download.fedoraproject.org hits a redirector which sends you to the > > nearest mirror from mirrormanager. > > > > Well, but what should I do if that mirror seems broken? Broken how? If the mirror is not functional yum should switch to the next mirror in your mirrorlist from mirrormanager. > Try to obtain > the full mirror list and try each mirror step by step? Why we no more > provide just a true "baseurl"? Go to the url from the mirrorlist= line in a webbrowser and it will give you all the baseurls you could possibly desire. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
2011/9/7 "Jóhann B. Guðmundsson" : > On 09/07/2011 01:55 PM, Michał Piotrowski wrote: >> Yes, conversion into two separate services seems to be the most >> appropriate solution. >> >> Here is a service file for transmission >> https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service > > From the looks of it missing an > > PIDFile=/run/transmission-daemon.pid I added this command to service and pid file isn't created. I'm using F15. > > JBG > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 01:55 PM, Michał Piotrowski wrote: > Yes, conversion into two separate services seems to be the most > appropriate solution. > > Here is a service file for transmission > https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service From the looks of it missing an PIDFile=/run/transmission-daemon.pid JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
seth vidal wrote: > download.fedoraproject.org hits a redirector which sends you to the > nearest mirror from mirrormanager. > Well, but what should I do if that mirror seems broken? Try to obtain the full mirror list and try each mirror step by step? Why we no more provide just a true "baseurl"? Regards, Dmitry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones wrote: > On Tue, Sep 06, 2011 at 03:27:15PM -0800, Jef Spaleta wrote: >> On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson wrote: >> >> > Well, yes, that parallel came up in my mind too, but really, the two >> > aren't particularly similar. I don't think there's any intent to >> > obfuscate in the case of the glibc spec, it's simply done the way that >> > seemed convenient to its maintainers at the time. Note the Fedora kernel >> > package is a normal source / split out patches set. I'm not sure that >> > whole kerfuffle is particularly relevant to Fedora. >> > >> > >> Let me turn that on its head. >> >> As more projects become git based over time, the preferred form for code >> development might actually be a bisectable git checkout and not broken out >> patchsets for some projects. I'm not sure the distribution and packaging >> model that we collectively understand now and which grew up in the cvs and >> svn dominated era fits really well in the git dominated era. I think we are >> still groping around trying to figure out what the "preferred form" really >> is in the git dominated era. I'm not sure the broken out patchset will be >> it. It might soon be considered a legacy format in some situations. > > While I agree with you, the glibc "big blob of patch" approach > isn't in either of the preferred forms. > > Wishlist item: > > At the same time that RPM allows you to bundle a git repo, perhaps we > can finally get rid of %changelog? %changelog isn't for developers. It's for users to see what the developers changed in the package. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Baseurl" download source for now?
On Wed, 2011-09-07 at 17:53 +0400, Dmitry Butskoy wrote: > I've discovered data inconsistencies in a (nearest) mirror of Fedora. > > For me, > "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch"; > > return a mirror at "mirror.yandex.ru". > > Assuming it is some temporary issues, I prefer to switch (for a while) > to the "baseurl" in the repo config file, ie. to > http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/ > > . > But any attempt to address this link returns me the same mirror at > yandex.ru. > > IOW, it seems that "baseurl" is the same behavior as "mirrorlist". > > How can I download something from the "primary", "baseurl" Fedora repos > (not from mirrors)? > download.fedoraproject.org hits a redirector which sends you to the nearest mirror from mirrormanager. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
2011/9/7 "Jóhann B. Guðmundsson" : > On 09/07/2011 01:12 PM, Rahul Sundaram wrote: >> Hi >> >> These two torrent packages includes init scripts for the daemons and >> need to be converted to systemd. I have been meaning to convert but >> could use some help. If someone can take a look a look and file a >> patch, I will be happy to role them in. Thanks >> >> Rahul > > Hum I thought a had converted torrent already anyway deluge into two > seperated daemons from a quick look of it the service and the "web.service" Yes, conversion into two separate services seems to be the most appropriate solution. Here is a service file for transmission https://github.com/eventhorizonpl/systemd-services/blob/master/transmission-daemon.service > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
"Baseurl" download source for now?
I've discovered data inconsistencies in a (nearest) mirror of Fedora. For me, "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch"; return a mirror at "mirror.yandex.ru". Assuming it is some temporary issues, I prefer to switch (for a while) to the "baseurl" in the repo config file, ie. to http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/ . But any attempt to address this link returns me the same mirror at yandex.ru. IOW, it seems that "baseurl" is the same behavior as "mirrorlist". How can I download something from the "primary", "baseurl" Fedora repos (not from mirrors)? Regards, Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Wed, Sep 7, 2011 at 8:05 AM, Richard W.M. Jones wrote: > Wishlist item: > > At the same time that RPM allows you to bundle a git repo, perhaps we > can finally get rid of %changelog? I suspect that fedpkg is a better integration point. Between the "fedora patches" branch discussed in my other post, and a git log of the fedpkg repo, you can generate the changelog at srpm creation time. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Tue, Sep 6, 2011 at 7:27 PM, Jef Spaleta wrote: > As more projects become git based over time, the preferred form for code > development might actually be a bisectable git checkout +100 -- some of the git primitives seem to be here to stay - a hash identifying a commit or tree as the key identity, plus repo url, and optionally a branchname. You can see those 3 with minimal variation across DSCMs. Perhaps fedpkg could grow some tentacles to make it easy to replace the source tarball with a reference to a commit hash, and perhaps to point to a 2nd repo/branchname/hash where the "as patched in this fedora rpm" branch is available. That commit being a direct descendant of the "upstream commit". If you define the config stanzas and internal API around those 2 triplets, I think you can start with git and then extend to the relevant DSCMs . This would make rebasing patchsets (dropping patches as upstream merges or nixes them) -much- easier. It would require a 2nd set of git repos, however, where fedora has full clones of upstream's git repo with the fedora-specific branches. Upstream projects may or may not welcome the fedora braches in their repo... Fedora may want to keep more direct control over them re commit access and direct manipulation (branch renames, etc). Maybe that can be rolled into what's tracked in pkgs.fp.org, but the size difference is... um... :-) m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Transmission and Deluge sysv to systemd
On 09/07/2011 01:12 PM, Rahul Sundaram wrote: > Hi > > These two torrent packages includes init scripts for the daemons and > need to be converted to systemd. I have been meaning to convert but > could use some help. If someone can take a look a look and file a > patch, I will be happy to role them in. Thanks > > Rahul Hum I thought a had converted torrent already anyway deluge into two seperated daemons from a quick look of it the service and the "web.service" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/2011 04:01 AM, Jim Meyering wrote: > I was getting ready to release coreutils-8.13, after two > pre-release snapshots, > > http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1554 > http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631 > > when I went to make sure its tests all pass also on rawhide. I test > that regularly, and they've all been passing (of course), so I > didn't expect any surprises. I certainly didn't expect 7 > failures, and never something as basic as this: > > $ touch a $ env -i /usr/bin/install a b zsh: segmentation fault > env -i /usr/bin/install a b [Exit 139 (SEGV)] > > [the "env -i " prefix is just to ensure that none of my > MALLOC_DEBUG_ or MALLOC_PERTURB_ settings (or any other envvar) is > causing trouble. ] > > gdb shows that it's officially a NULL-deref, but says there's a > "Corrupted DWARF expression", probably discovered in read_sleb128: > > $ env -i gdb -q --args /usr/bin/install a b Reading symbols from > /usr/bin/install...Reading symbols from > /usr/lib/debug/usr/bin/install.debug...done. done. (gdb) r Starting > program: /usr/bin/install a b [Thread debugging using libthread_db > enabled] Using host libthread_db library > "/lib64/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. __strtok_r_1c > (__nextp=read_sleb128: Corrupted DWARF expression. ) at > /usr/include/bits/string2.h:1179 1179 while (*__s == __sep) > (gdb) p __s $1 = 0x0 (gdb) bt #0 __strtok_r_1c > (__nextp=read_sleb128: Corrupted DWARF expression. ) at > /usr/include/bits/string2.h:1179 #1 init (rec=0x626930, > opts=0x77fe2718, n=) at label_file.c:440 #2 > 0x77bc4b3d in selabel_open (backend=0, > opts=0x77fe2718, nopts=5) at label.c:165 #3 0x77bc3e16 > in matchpathcon_init_prefix_internal (path=0x0, subset=0x0) at > matchpathcon.c:321 #4 0x77bc40a9 in matchpathcon > (path=0x7fffefbf "b", mode=33261, con=0x7fffeb98) at > matchpathcon.c:406 #5 0x0040452f in setdefaultfilecon > (file=0x7fffefbf "b") at install.c:345 #6 change_attributes > (name=0x7fffefbf "b") at install.c:471 #7 install_file_in_file > (from=, to=0x7fffefbf "b", x=) at > install.c:672 #8 0x00403cd6 in main (argc=, > argv=) at install.c:978 (gdb) > > So install is just the messenger, since it's calling libselinux's > matchpathcon function, in which all of this is happening. Given the > dwarf corruption, libselinux may be a messenger, too, but for now, > I've just put all this in a BZ: > > http://bugzilla.redhat.com/736259 > > This seems so fundamental that I have to wonder if it's something > specific to my own set-up... Grab libselinux-2.1.5-3.fc17 out of koji, should fix the problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5nc6IACgkQrlYvE4MpobNDmACeIXdcOS371tlTRGH/hjojGIHA SSMAnR8xu2PTr5zgGgzHZX9JkuxKMvOZ =DFrb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CPAN-Meta-YAML-0.004.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-CPAN-Meta-YAML: 120025b9fd39b9dbfeb6ffc5f4a2dd8d CPAN-Meta-YAML-0.004.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: Transmission and Deluge sysv to systemd
Hi, 2011/9/7 Rahul Sundaram : > Hi > > These two torrent packages includes init scripts for the daemons and > need to be converted to systemd. I have been meaning to convert but > could use some help. If someone can take a look a look and file a > patch, I will be happy to role them in. Thanks I don't use it, but I can take a look. > > Rahul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
On Wed, Sep 7, 2011 at 6:02 AM, Jim Meyering wrote: > Richard W.M. Jones wrote: >> On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote: >>> Jim Meyering wrote: >>> ... >>> > $ touch a && $ env -i /usr/bin/install a b >>> > zsh: segmentation fault env -i /usr/bin/install a b >>> > [Exit 139 (SEGV)] >>> >>> Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64 >>> made it so he too sees the above failure. >> >> [...] >> >> Instead of this workaround, can we ask rel-eng to untag the >> broken libselinux update? > > Good idea. > Done: https://fedorahosted.org/rel-eng/ticket/4914 Koji has libselinux-2.1.5-3.fc17.x86_64. Its changelog says: * Tue Sep 06 2011 Dan Walsh - 2.1.5-3 - Fix handling of subset labeling that is causing segfault in restorecon After downloading/installing: "Works for me". tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Transmission and Deluge sysv to systemd
Hi These two torrent packages includes init scripts for the daemons and need to be converted to systemd. I have been meaning to convert but could use some help. If someone can take a look a look and file a patch, I will be happy to role them in. Thanks Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
Richard W.M. Jones wrote: > On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote: >> Jim Meyering wrote: >> ... >> > $ touch a && $ env -i /usr/bin/install a b >> > zsh: segmentation fault env -i /usr/bin/install a b >> > [Exit 139 (SEGV)] >> >> Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64 >> made it so he too sees the above failure. > > [...] > > Instead of this workaround, can we ask rel-eng to untag the > broken libselinux update? Good idea. Done: https://fedorahosted.org/rel-eng/ticket/4914 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
License change for rcs
Hi, rcs license has changed from GPLv2+ to GPLv3+ in rcs-5.8, which will be in Rawhide soon. Regards, Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Notice of intent: patching glibc
On Tue, Sep 06, 2011 at 03:27:15PM -0800, Jef Spaleta wrote: > On Tue, Sep 6, 2011 at 3:09 PM, Adam Williamson wrote: > > > Well, yes, that parallel came up in my mind too, but really, the two > > aren't particularly similar. I don't think there's any intent to > > obfuscate in the case of the glibc spec, it's simply done the way that > > seemed convenient to its maintainers at the time. Note the Fedora kernel > > package is a normal source / split out patches set. I'm not sure that > > whole kerfuffle is particularly relevant to Fedora. > > > > > Let me turn that on its head. > > As more projects become git based over time, the preferred form for code > development might actually be a bisectable git checkout and not broken out > patchsets for some projects. I'm not sure the distribution and packaging > model that we collectively understand now and which grew up in the cvs and > svn dominated era fits really well in the git dominated era. I think we are > still groping around trying to figure out what the "preferred form" really > is in the git dominated era. I'm not sure the broken out patchset will be > it. It might soon be considered a legacy format in some situations. While I agree with you, the glibc "big blob of patch" approach isn't in either of the preferred forms. Wishlist item: At the same time that RPM allows you to bundle a git repo, perhaps we can finally get rid of %changelog? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote: > Jim Meyering wrote: > ... > > $ touch a && $ env -i /usr/bin/install a b > > zsh: segmentation fault env -i /usr/bin/install a b > > [Exit 139 (SEGV)] > > Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64 > made it so he too sees the above failure. [...] Instead of this workaround, can we ask rel-eng to untag the broken libselinux update? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
Jim Meyering wrote: ... > $ touch a && $ env -i /usr/bin/install a b > zsh: segmentation fault env -i /usr/bin/install a b > [Exit 139 (SEGV)] Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64 made it so he too sees the above failure. > http://bugzilla.redhat.com/736259 For any of you who are already affected, you may be wondering how automated tools will install fixed versions without a working "install" program. At least I was. There may well be a simpler solution, like using a small install-simulating script, but I'm inclined to use the "real" install program, with a minimal adjustment: === Build the latest coreutils from source, but with a small twist to disable the offending matchpathcon calls: Get the sources, from a link here: http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631 e.g., wget http://people.redhat.com/meyering/cu/coreutils-ss.tar.xz wget http://people.redhat.com/meyering/cu/coreutils-ss.tar.xz.sig Verify the signature before unpacking: gpg --verify coreutils-ss.tar.xz.sig Unpack (as non-root, of course): tar xf coreutils-ss.tar.xz && cd coreutils-8.12* Configure and build with one added definition. This overrides the "ginstall_CPPFLAGS = -DENABLE_MATCHPATHCON=1" setting in src/Makefile.am: ./configure && make ginstall_CPPFLAGS= Verify that the just-built install binary works: (or also run "make check" for the whole test suite) touch a; src/ginstall a b Install it, replacing your temporarily-broken one: sudo src/ginstall src/ginstall /usr/bin/install -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-Load] Created tag perl-Class-Load-0.10-1.fc17
The lightweight tag 'perl-Class-Load-0.10-1.fc17' was created pointing to: 2cc49aa... Update to 0.10 -- 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-Class-Load] Created tag perl-Class-Load-0.10-1.fc16
The lightweight tag 'perl-Class-Load-0.10-1.fc16' was created pointing to: 2cc49aa... Update to 0.10 -- 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-Class-Load] Created tag perl-Class-Load-0.10-1.el6
The lightweight tag 'perl-Class-Load-0.10-1.el6' was created pointing to: 2cc49aa... Update to 0.10 -- 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-Class-Load] Created tag perl-Class-Load-0.08-1.fc17
The lightweight tag 'perl-Class-Load-0.08-1.fc17' was created pointing to: cd10c7b... Update to 0.08: -- 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
KDE-SIG meeting report (36/2011)
This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. = Weekly KDE Summary = Week: 36/2011 Time: 2011-09-05 15:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-09-05 Meeting minutes: http://meetbot.fedoraproject.org/fedora- meeting/2011-09-06/kde-sig.2011-09-06-15.03.html Meeting log: http://meetbot.fedoraproject.org/fedora-meeting/2011-09-06/kde- sig.2011-09-06-15.03.log.html = Participants = * Kevin Kofler * Jaroslav Reznik * Radek Novacek * Than Ngo * Rex Dieter * Lukas Tinkl * nucleo = Agenda = * KDE 4.7.1 status * Qt 4.7.4 status * Nepomuk startup warnings [1] == Summary == KDE 4.7.1 status * Than is working on git updates * rdieter to update f15 47 repo after import and builds are done * a lot of reviews for kdeedu and telepathy-kde [2] ** jreznik and rnovacek do work on it Qt 4.7.4 status * done by rdieter * jreznik to prepare update Nepomuk warnings * idea is to disable Nepomuk by default on live CD, disable warnings ** upstream work: do not show warning again patch * rdieter and rnovacek to make it easier to switch between mysql and sqlite for akonadi = Next Meeting = http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-09-12 = Links = [1] https://bugzilla.redhat.com/show_bug.cgi?id=731269 [2] https://bugzilla.redhat.com/showdependencytree.cgi?id=656997&hide_resolved=1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
I was getting ready to release coreutils-8.13, after two pre-release snapshots, http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1554 http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631 when I went to make sure its tests all pass also on rawhide. I test that regularly, and they've all been passing (of course), so I didn't expect any surprises. I certainly didn't expect 7 failures, and never something as basic as this: $ touch a $ env -i /usr/bin/install a b zsh: segmentation fault env -i /usr/bin/install a b [Exit 139 (SEGV)] [the "env -i " prefix is just to ensure that none of my MALLOC_DEBUG_ or MALLOC_PERTURB_ settings (or any other envvar) is causing trouble. ] gdb shows that it's officially a NULL-deref, but says there's a "Corrupted DWARF expression", probably discovered in read_sleb128: $ env -i gdb -q --args /usr/bin/install a b Reading symbols from /usr/bin/install...Reading symbols from /usr/lib/debug/usr/bin/install.debug...done. done. (gdb) r Starting program: /usr/bin/install a b [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. __strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression. ) at /usr/include/bits/string2.h:1179 1179 while (*__s == __sep) (gdb) p __s $1 = 0x0 (gdb) bt #0 __strtok_r_1c (__nextp=read_sleb128: Corrupted DWARF expression. ) at /usr/include/bits/string2.h:1179 #1 init (rec=0x626930, opts=0x77fe2718, n=) at label_file.c:440 #2 0x77bc4b3d in selabel_open (backend=0, opts=0x77fe2718, nopts=5) at label.c:165 #3 0x77bc3e16 in matchpathcon_init_prefix_internal (path=0x0, subset=0x0) at matchpathcon.c:321 #4 0x77bc40a9 in matchpathcon (path=0x7fffefbf "b", mode=33261, con=0x7fffeb98) at matchpathcon.c:406 #5 0x0040452f in setdefaultfilecon (file=0x7fffefbf "b") at install.c:345 #6 change_attributes (name=0x7fffefbf "b") at install.c:471 #7 install_file_in_file (from=, to=0x7fffefbf "b", x=) at install.c:672 #8 0x00403cd6 in main (argc=, argv=) at install.c:978 (gdb) So install is just the messenger, since it's calling libselinux's matchpathcon function, in which all of this is happening. Given the dwarf corruption, libselinux may be a messenger, too, but for now, I've just put all this in a BZ: http://bugzilla.redhat.com/736259 This seems so fundamental that I have to wonder if it's something specific to my own set-up... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: php-pear package build problem
06.09.2011 18:47, TASAKA Mamoru wrote:
> Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/06/2011 07:00 PM +9:00:
>> 05.09.2011 19:17, TASAKA Mamoru wrote:
> 2. The line 28
>>>
>>> %if %{?php_zend_api}0
>>>
>>> cannot be parsed when %php_zend_api is not integer (and this is
>>> actually happening
>>> currently). The correct line would be something like
>>>
>>> %if 0%{?php_zend_api?1:0}
>>>
>>> however it seems this line is no longer needed on Fedora:
>>> http://fedoraproject.org/wiki/Packaging:PHP#C_extensions_.28PECL_and_others.29
>>>
>> It stil needed for EPEL
>> http://fedoraproject.org/wiki/Packaging:EPEL#PHP_ABI_Check_Handling
>> and exactly in this form
>
> Then you have to write this only for EPEL build. Again on F-17 parsing
> "%if %{?php_zend_api}0" actually failed, because php_zend_api is not
> integer
> (actually %php_zend_api is now 20090626-x86-32 on F-17 i686)
> This EPEL form is no longer valid on Fedora (at least on F-17).
>
> However "%if 0%{?php_zend_api?1:0}" is also wrong and this should be
> "%if 0%{?php_zend_api:1}" if you want to use (guessing php_zend_api
> is not defined as "0" even on EPEL)
>
It wasn't sole issue, but I understand your idea. Thank you again.
It also was in php command below what I also make silent fail if command
not found.
Just for interest - is there change of minimal buildroot happened since
F15? Why it was worked before? Was it announced and I miss something?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
