Re: gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later
2011/7/6 Bruno Wolff III : > On Wed, Jul 06, 2011 at 02:25:56 +0200, > "Joshua C." wrote: >> I've been testing with grub and found an interesting problem. When I >> install the package >> http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-0.97-71.fc15.x86_64.rpm >> everything is fine and grub works as it should: >> >> When I recompile the grub-rpm and reinstall it I get this: >> >> Error 6rd: Mismatched or corrupt version of stage1/stage2 > >> All newer packages result in the same error "Error 6rd: Mismatched or >> corrupt version of stage1/stage2" and grub reports that 31 sectors >> have been embedded. >> So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package??? > > Note that this problem has been reported as bug 718722. > I think this is a separate issue from rbz#718722. My Problem is that the current compiler produces different results than the one used to build the packages in koji. This shouldn't be the case. I think this is a gcc issues not a grub problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, 2011-07-05 at 17:11 -0500, Michael Cronenworth wrote: > On 07/05/2011 11:59 AM, Adam Williamson wrote: > > That sounds like an excellent idea for a contribution! Remember, the > > AutoQA project is explicitly designed to allow and indeed encourage > > tests to be contributed - we would love it if the core AutoQA team > > worked mostly on the framework, and tests were contributed by many > > people. Seehttps://fedoraproject.org/wiki/Writing_AutoQA_Tests . > > There's a few cavets that have been mentioned in this thread that would > make this functionality mostly pointless to try and implement. > > 1) Not all packages include gpg signatures. >a) not everyone knows they can include them >b) SCM checkouts don't have signatures >c) some projects don't use them > 2) We don't have a system to validate a gpg signature in place. My > understanding of GPG is that we would need to house all the public keys > to validate against. Nothing like this exists. I'm lazy and don't feel > like creating such a system. :) > > We're stuck with the lookaside cache checksum for now. 1) doesn't really matter. So we get some assurance for some packages, not all; it's still better than none. Don't make the perfect the enemy of the good. 2) ditto - we can 'house' them in so far as including them as package sources. If they aren't included then don't run the check. If they are, run the check... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later
On Wed, Jul 06, 2011 at 02:25:56 +0200, "Joshua C." wrote: > I've been testing with grub and found an interesting problem. When I > install the package > http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-0.97-71.fc15.x86_64.rpm > everything is fine and grub works as it should: > > When I recompile the grub-rpm and reinstall it I get this: > > Error 6rd: Mismatched or corrupt version of stage1/stage2 > All newer packages result in the same error "Error 6rd: Mismatched or > corrupt version of stage1/stage2" and grub reports that 31 sectors > have been embedded. > So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package??? Note that this problem has been reported as bug 718722. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Taking ownership of libcmpiutil and libvirt-cim
Previous maintainer cvincent aparently didn't sign on the new CLA in time, and the 2 packages are now orphaned for a week or so. So I will take over, I already own the ACLs for those packages https://admin.fedoraproject.org/pkgdb/acls/name/libcmpiutil https://admin.fedoraproject.org/pkgdb/acls/name/libvirt-cim Note that both packages are listed as owned by "orphan" but they don't show up in the orphan list (yet ?) https://admin.fedoraproject.org/pkgdb/acls/orphans Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gcc-4.6.0-10.fc15.x86_64 breaks grub-0.97-71.fc15 and later
I've been testing with grub and found an interesting problem. When I install the package http://kojipkgs.fedoraproject.org/packages/grub/0.97/71.fc15/x86_64/grub-0.97-71.fc15.x86_64.rpm everything is fine and grub works as it should: [root@localhost x86_64-redhat]# grub Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97-71.fc15 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd0,1) root (hd0,1) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 26 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+26 p (hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded Done. grub> quit quit [root@localhost x86_64-redhat]# When I recompile the grub-rpm and reinstall it I get this: [root@localhost x86_64-unknown]# grub Probing devices to guess BIOS drives. This may take a long time. GNU GRUB version 0.97-71.fc15 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd0,1) root (hd0,1) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/e2fs_stage1_5" exists... yes Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 31 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd0) (hd0)1+31 p (hd0,1)/boot/grub/stage2 /boot/grub/grub.conf"... failed Error 6rd: Mismatched or corrupt version of stage1/stage2 grub> quit quit [root@localhost x86_64-unknown]# --- As you can see the difference is in the following lines: Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 26 sectors are embedded. (with the downloaded package) Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 31 sectors are embedded. (with the recompiled package) All newer packages result in the same error "Error 6rd: Mismatched or corrupt version of stage1/stage2" and grub reports that 31 sectors have been embedded. So why does the gcc-4.6.0-10.fc15.x86_64 breaks my package??? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, Jul 5, 2011 at 3:18 PM, Michael Schwendt wrote: > Google finds these: > > https://fedorahosted.org/fesco/ticket/386 > -> > https://www.redhat.com/archives/fedora-devel-announce/2009-March/msg00010.html Thanks. I remember reading that fedora-devel message, but somehow concluded that I would need to apply for membership, instead of noting that current sponsors would be included in provenpackagers. Well, the upside of this is that I haven't used my provenpackager powers to do any damage ... until today, anyway! -- Jerry James, who plans to continue limiting the damage http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-App-SVN-Bisect] update to 1.1
commit 7956d87dec5870634a605931b439ac134e6bb07a
Author: Xavier Bachelot
Date: Wed Jul 6 00:13:25 2011 +0200
update to 1.1
.gitignore |1 +
perl-App-SVN-Bisect.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 974b583..bdcc103 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
App-SVN-Bisect-1.0.tar.gz
+/App-SVN-Bisect-1.1.tar.gz
diff --git a/perl-App-SVN-Bisect.spec b/perl-App-SVN-Bisect.spec
index f0a1f39..8c035c8 100644
--- a/perl-App-SVN-Bisect.spec
+++ b/perl-App-SVN-Bisect.spec
@@ -1,6 +1,6 @@
Name: perl-App-SVN-Bisect
-Version:1.0
-Release:3%{?dist}
+Version:1.1
+Release:1%{?dist}
Summary:Binary search through svn revisions
License:Artistic 2.0
Group: Development/Libraries
@@ -78,6 +78,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Tue Jul 05 2011 Xavier Bachelot 1.1-1
+- Update to 1.1.
+
* Tue Feb 08 2011 Fedora Release Engineering
- 1.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index 3daa876..99abde6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d8540f354b27d904eee56cc473542cbc App-SVN-Bisect-1.0.tar.gz
+a929a878b7bee04adae2e592770c0ea2 App-SVN-Bisect-1.1.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 App-SVN-Bisect-1.1.tar.gz uploaded to lookaside cache by xavierb
A file has been added to the lookaside cache for perl-App-SVN-Bisect: a929a878b7bee04adae2e592770c0ea2 App-SVN-Bisect-1.1.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: vsftpd in the news
On 07/05/2011 11:59 AM, Adam Williamson wrote: > That sounds like an excellent idea for a contribution! Remember, the > AutoQA project is explicitly designed to allow and indeed encourage > tests to be contributed - we would love it if the core AutoQA team > worked mostly on the framework, and tests were contributed by many > people. Seehttps://fedoraproject.org/wiki/Writing_AutoQA_Tests . There's a few cavets that have been mentioned in this thread that would make this functionality mostly pointless to try and implement. 1) Not all packages include gpg signatures. a) not everyone knows they can include them b) SCM checkouts don't have signatures c) some projects don't use them 2) We don't have a system to validate a gpg signature in place. My understanding of GPG is that we would need to house all the public keys to validate against. Nothing like this exists. I'm lazy and don't feel like creating such a system. :) We're stuck with the lookaside cache checksum for now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On 07/05/2011 03:46 AM, Michael Schwendt wrote: > Some packagers do upload the detached sig and add it to the spec > as another Source file URL. Great! Except I haven't done so. I wasn't required to submit a signature for my package nor does the Package Guildline pages refer to doing so. Might be worth someone's time to mention it on the wiki (who knows about this functionality). > The uploaded tarball checksum enters the "sources" file in git, and any > tarball downloaded from the lookaside cache MUST match that checksum. > Else it wouldn't be downloaded and used. Source RPM build in koji would > fail. This is just a checksum against the tarball that enters the lookaside cache. Yes, I know about this. A malicious package could have been uploaded to the lookaside cache, however. This leads to demanding everyone have signatures available, but what do you do about SVN/Git checkouts or projects that don't wish to provide signatures? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, 5 Jul 2011 14:32:42 -0600, JJ (Jerry) wrote: > > You are a member of the Advanced Fedora Packager Group (aka > > provenpackagers), > > which made it possible for you to commit in git. Bodhi, however, doesn't > > handle provenpackagers membership in the same way. > > Wow, my memory must be worse than I thought. When did that happen? I > remember applying to become a sponsor, but I have no memory of > applying to become a provenpackager. Google finds these: https://fedorahosted.org/fesco/ticket/386 -> https://www.redhat.com/archives/fedora-devel-announce/2009-March/msg00010.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Tue, Jul 5, 2011 at 7:43 PM, Benjamin Lewis wrote: > On 07/05/2011 05:15 PM, Adam Williamson wrote: >> >> I didn't see any suggestion that packages be *required* to have a >> signature, only that we somehow run an automated check on one if there >> is one. >> >> Rather than making specific Source numbers special case, why not just go >> on naming? The convention for signatures is to add an extension to the >> name of the tarball the signature is for; that shouldn't be too hard to >> implement, I don't think. > > Surely the automated testing tool would need a way of being fed > known-trusted public keys in advance as well? Unless my memory is failing me, we already had a mechanism for this (specifying the trusted keys and verifying signatures) in the CVS package repository (in Makefile.common). Perhaps most of that could be reused. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, Jul 5, 2011 at 12:57 PM, Michael Schwendt wrote: > You are a member of the Advanced Fedora Packager Group (aka provenpackagers), > which made it possible for you to commit in git. Bodhi, however, doesn't > handle provenpackagers membership in the same way. Wow, my memory must be worse than I thought. When did that happen? I remember applying to become a sponsor, but I have no memory of applying to become a provenpackager. D. Haley, can you try pushing the buttons one more time to grant me commit access to givaro in pkgdb? Thanks. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)
W dniu 5 lipca 2011 21:13 użytkownik nodata napisał: > On 05/07/11 21:11, Michał Piotrowski wrote: >> Hi, >> >> W dniu 16 czerwca 2011 21:37 użytkownik Michał Piotrowski >> napisał: >>> Hi, >>> >>> Do anyone noticed any problems with mounting eCryptfs recently on F15? >>> It seems to me unlikely that I have an I/O errors on few disks. >>> Especially if only eCryptfs reports them. >>> >> >> I've got two dirs >> >> /home/s1 - ext3 >> /home/s2 - ext3 + eCryptfs >> >> If I copy a file from my laptop to /home/s1 it has md5 sum >> c7da3acc8e85f64661b49b9788771bf6 >> when I copy this file from shell to /home/s2 it has the same md5 sum >> c7da3acc8e85f64661b49b9788771bf6 >> >> If I copy the same file from my laptop to /home/s2 I get a strange error >> in Total commander "please remove the write protection" - TC's progress bar >> doesn't show any progress - after copying file has correct size, but >> it's totally >> broken - md5 sum >> f26767c3aed2f6e639ddb9ad6601daaf >> >> Does anyone have any idea what could be wrong? I guess that data corruption >> problem is related to this strange "Error mounting eCryptfs: [-5] >> Input/output error" >> message. >> >> > > Check dmesg, nothing here > your the logs Some samba problem Jul 5 21:21:21 ozzy smbd[6939]: [2011/07/05 21:21:21.750117, 0] lib/util_sock.c:1514(matchname) Jul 5 21:21:21 ozzy smbd[6939]: matchname: host name/address mismatch: :::192.168.101.100 != dio Jul 5 21:21:21 ozzy smbd[6939]: [2011/07/05 21:21:21.751328, 0] lib/util_sock.c:1635(get_peer_name) Jul 5 21:21:21 ozzy smbd[6939]: Matchname failed on dio :::192.168.101.100 Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.603368, 0] lib/util_sock.c:680(write_data) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.604101, 0] lib/util_sock.c:1441(get_peer_addr_internal) Jul 5 21:21:30 ozzy smbd[4815]: getpeername failed. Error was Drugi koniec nie jest połączony Jul 5 21:21:30 ozzy smbd[4815]: write_data: write failure in writing to client 0.0.0.0. Error Przerwany potok Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.607351, 0] smbd/process.c:79(srv_send_smb) Jul 5 21:21:30 ozzy smbd[4815]: Error writing 62 bytes to client. -1. (Drugi koniec nie jest połączony) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.608346, 0] lib/util_sock.c:680(write_data) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.608883, 0] lib/util_sock.c:1441(get_peer_addr_internal) Jul 5 21:21:30 ozzy smbd[4815]: getpeername failed. Error was Drugi koniec nie jest połączony Jul 5 21:21:30 ozzy smbd[4815]: write_data: write failure in writing to client 0.0.0.0. Error Przerwany potok Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.610048, 0] smbd/process.c:79(srv_send_smb) Jul 5 21:21:30 ozzy smbd[4815]: Error writing 55 bytes to client. -1. (Drugi koniec nie jest połączony) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.612862, 0] lib/util_sock.c:680(write_data) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.613797, 0] lib/util_sock.c:1441(get_peer_addr_internal) Jul 5 21:21:30 ozzy smbd[4815]: getpeername failed. Error was Drugi koniec nie jest połączony Jul 5 21:21:30 ozzy smbd[4815]: write_data: write failure in writing to client 0.0.0.0. Error Przerwany potok Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.615032, 0] smbd/process.c:79(srv_send_smb) Jul 5 21:21:30 ozzy smbd[4815]: Error writing 53 bytes to client. -1. (Drugi koniec nie jest połączony) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.616071, 0] lib/util_sock.c:680(write_data) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.616580, 0] lib/util_sock.c:1441(get_peer_addr_internal) Jul 5 21:21:30 ozzy smbd[4815]: getpeername failed. Error was Drugi koniec nie jest połączony Jul 5 21:21:30 ozzy smbd[4815]: write_data: write failure in writing to client 0.0.0.0. Error Przerwany potok Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.617768, 0] smbd/process.c:79(srv_send_smb) Jul 5 21:21:30 ozzy smbd[4815]: Error writing 75 bytes to client. -1. (Drugi koniec nie jest połączony) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.619713, 0] lib/util_sock.c:680(write_data) Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.620268, 0] lib/util_sock.c:1441(get_peer_addr_internal) Jul 5 21:21:30 ozzy smbd[4815]: getpeername failed. Error was Drugi koniec nie jest połączony Jul 5 21:21:30 ozzy smbd[4815]: write_data: write failure in writing to client 0.0.0.0. Error Przerwany potok Jul 5 21:21:30 ozzy smbd[4815]: [2011/07/05 21:21:30.621454, 0] smbd/process.c:79(srv_send_smb) Jul 5 21:21:30 ozzy smbd[4815]: Error writing 75 bytes to client. -1. (Drugi koniec nie jest połączony) Jul 5 21:21:33 ozzy smartd[558]: Device: /dev/sdd [SAT], is back in ACTIVE or IDLE mode, resuming checks (7 checks skipped) > and the file sizes. File size is correct > selinux perhaps? disabled What is perhaps important is that the problem appea
Re: I'm givaro comaintainer ... or am I?
On Tue, 5 Jul 2011 20:57:33 +0200 Michael Schwendt wrote: > On Tue, 5 Jul 2011 12:41:31 -0600, JJ (Jerry) wrote: > > > I recently asked the givaro maintainer, D Haley (CCed), for > > permission to become comaintainer, so I can push out a coordinated > > update of givaro and linbox. I received a reply stating that this > > had been done in pkgdb. Today I built new givaro and linbox > > versions for Rawhide. I would also like to push Fedora 15 updates > > for the 2 packages. So I built the same new version of givaro, and > > went to https://admin.fedoraproject.org/updates/ to get a buildroot > > override for givaro, so I can kick off the linbox build. I got > > this message: > > > > Error: You do not have commit privileges to givaro > > > > So I go to pkgdb, and sure enough, it shows my requests for commit > > access as "Awaiting Review". What's going on here? If I don't have > > commit privileges (which D Haley assured me were approved), then how > > did I update givaro for F-15 and Rawhide, and build the new version > > in both places? If I do, then why can't I get a buildroot override? > > You are a member of the Advanced Fedora Packager Group (aka > provenpackagers), which made it possible for you to commit in git. > Bodhi, however, doesn't handle provenpackagers membership in the same > way. Not only that, but you need to have commit access to the Rawhide branch in order to create a buildroot override for *any* branch, which is unfortunate for instance if Fedora and EPEL have separate maintainers. Ironically, Rawhide is the only branch you don't actually need overrides. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)
On 05/07/11 21:11, Michał Piotrowski wrote: > Hi, > > W dniu 16 czerwca 2011 21:37 użytkownik Michał Piotrowski > napisał: >> Hi, >> >> Do anyone noticed any problems with mounting eCryptfs recently on F15? >> It seems to me unlikely that I have an I/O errors on few disks. >> Especially if only eCryptfs reports them. >> > > I've got two dirs > > /home/s1 - ext3 > /home/s2 - ext3 + eCryptfs > > If I copy a file from my laptop to /home/s1 it has md5 sum > c7da3acc8e85f64661b49b9788771bf6 > when I copy this file from shell to /home/s2 it has the same md5 sum > c7da3acc8e85f64661b49b9788771bf6 > > If I copy the same file from my laptop to /home/s2 I get a strange error > in Total commander "please remove the write protection" - TC's progress bar > doesn't show any progress - after copying file has correct size, but > it's totally > broken - md5 sum > f26767c3aed2f6e639ddb9ad6601daaf > > Does anyone have any idea what could be wrong? I guess that data corruption > problem is related to this strange "Error mounting eCryptfs: [-5] > Input/output error" > message. > > Check dmesg, your the logs and the file sizes. selinux perhaps? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F15 ext3, eCryptfs + samba = data corruption (Re: F15 "Error mounting eCryptfs: [-5] Input/output error" on different disks)
Hi, W dniu 16 czerwca 2011 21:37 użytkownik Michał Piotrowski napisał: > Hi, > > Do anyone noticed any problems with mounting eCryptfs recently on F15? > It seems to me unlikely that I have an I/O errors on few disks. > Especially if only eCryptfs reports them. > I've got two dirs /home/s1 - ext3 /home/s2 - ext3 + eCryptfs If I copy a file from my laptop to /home/s1 it has md5 sum c7da3acc8e85f64661b49b9788771bf6 when I copy this file from shell to /home/s2 it has the same md5 sum c7da3acc8e85f64661b49b9788771bf6 If I copy the same file from my laptop to /home/s2 I get a strange error in Total commander "please remove the write protection" - TC's progress bar doesn't show any progress - after copying file has correct size, but it's totally broken - md5 sum f26767c3aed2f6e639ddb9ad6601daaf Does anyone have any idea what could be wrong? I guess that data corruption problem is related to this strange "Error mounting eCryptfs: [-5] Input/output error" message. -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: I'm givaro comaintainer ... or am I?
On Tue, 5 Jul 2011 12:41:31 -0600, JJ (Jerry) wrote: > I recently asked the givaro maintainer, D Haley (CCed), for permission > to become comaintainer, so I can push out a coordinated update of > givaro and linbox. I received a reply stating that this had been done > in pkgdb. Today I built new givaro and linbox versions for Rawhide. > I would also like to push Fedora 15 updates for the 2 packages. So I > built the same new version of givaro, and went to > https://admin.fedoraproject.org/updates/ to get a buildroot override > for givaro, so I can kick off the linbox build. I got this message: > > Error: You do not have commit privileges to givaro > > So I go to pkgdb, and sure enough, it shows my requests for commit > access as "Awaiting Review". What's going on here? If I don't have > commit privileges (which D Haley assured me were approved), then how > did I update givaro for F-15 and Rawhide, and build the new version in > both places? If I do, then why can't I get a buildroot override? You are a member of the Advanced Fedora Packager Group (aka provenpackagers), which made it possible for you to commit in git. Bodhi, however, doesn't handle provenpackagers membership in the same way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Calling autoconf in a spec.
On 07/03/2011 11:36 PM, Sam Varshavchik wrote: > Kevin Kofler writes: > >> And in addition, I consider the concept of including generated files in >> what's supposed to be a source tarball to be broken by design. A source >> tarball is supposed to contain SOURCE code, not generated code. Anything >> needing to be generated should be generated during the build process. > > Ok. You want all upstreams to remove configure.in or configure.ac, as well > as Makefile.in from their tarballs? I think you're being ironic, but just in case I am being Cpt. Obvious here: he was arguing to remove Makefile and configure. This aside, I always understood that the sense of including both configure.in and configure was a reasonable and practical compromise, that allows an average user to compile the package, while also enabling a sophisticated developer who has autotools installed to rebuild the entire package. Hence, things like 'make superclean' etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Tue, 05.07.11 20:36, Lennart Poettering (mzerq...@0pointer.de) wrote: > > > We'd like to request that virtio-serial devices (/dev/virtio-ports/*) > > > are tagged so we can use them as systemd devices. Dan Berrange thinks > > > the right incantation is to add: > > > > > > SUBSYSTEM=="virtio-ports", TAG+="systemd" > > > > > > to /lib/udev/rules.d/99-systemd.rules > > > > The goal is that we want to automagically run /usr/sbin/guestfsd > > when /dev/virtio-ports/org.libguestfs.channel.0 is present. For > > this I believe we need to have a '.device' unit for the virtio-port > > device populated from the above udev rule, so we can in turn have a > > guestfsd.service unit looking like: > > I think adding such a rule to systemd's unit file is not a bad idea, but > since the use case here is very specific to your app, another option > would be to add an app-specific udev rule for this. (See below) Oops, wanted to write "systemd's udev rules file" here, and not "systemd's unit file". > Either way I have now added to git a patch that marks virtio ports for > exposure in systemd, by marking them with "systemd". So, I am a bit confused now after reading this: http://fedoraproject.org/wiki/Features/VirtioSerial How does /dev/hvcxxx relate to these virtio ports? hvc ports are tagged "systemd" anyway in udev, so if this is the same thing, why do we have to tag the virtio ports too? Can you explain how hvc and virtio relate to each other and under which kernel device names they show up in udev and how they correspond? Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
I'm givaro comaintainer ... or am I?
I recently asked the givaro maintainer, D Haley (CCed), for permission to become comaintainer, so I can push out a coordinated update of givaro and linbox. I received a reply stating that this had been done in pkgdb. Today I built new givaro and linbox versions for Rawhide. I would also like to push Fedora 15 updates for the 2 packages. So I built the same new version of givaro, and went to https://admin.fedoraproject.org/updates/ to get a buildroot override for givaro, so I can kick off the linbox build. I got this message: Error: You do not have commit privileges to givaro So I go to pkgdb, and sure enough, it shows my requests for commit access as "Awaiting Review". What's going on here? If I don't have commit privileges (which D Haley assured me were approved), then how did I update givaro for F-15 and Rawhide, and build the new version in both places? If I do, then why can't I get a buildroot override? -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: Tagging /dev/virtio-ports/* for systemd
On Tue, 05.07.11 16:54, Daniel P. Berrange (berra...@redhat.com) wrote:
Heya,
> On Tue, Jul 05, 2011 at 04:47:18PM +0100, Richard W.M. Jones wrote:
> > [Is there a Fedora-specific systemd list? Not that I can find.]
> >
> > We'd like to request that virtio-serial devices (/dev/virtio-ports/*)
> > are tagged so we can use them as systemd devices. Dan Berrange thinks
> > the right incantation is to add:
> >
> > SUBSYSTEM=="virtio-ports", TAG+="systemd"
> >
> > to /lib/udev/rules.d/99-systemd.rules
>
> The goal is that we want to automagically run /usr/sbin/guestfsd
> when /dev/virtio-ports/org.libguestfs.channel.0 is present. For
> this I believe we need to have a '.device' unit for the virtio-port
> device populated from the above udev rule, so we can in turn have a
> guestfsd.service unit looking like:
I think adding such a rule to systemd's unit file is not a bad idea, but
since the use case here is very specific to your app, another option
would be to add an app-specific udev rule for this. (See below)
> [Unit]
> Description=libguestfs management daemon
> BindTo=dev-virtio\x2dports-org.libguestfs.channel.0.device
> After=dev-virtio\x2dports-org.libguestfs.channel.0.device
>
> [Service]
> ExecStart=-/usr/sbin/guestfsd
Prefixing the binary path with "-" will result in the exit code of
guestfsd be ignored, i.e. we wouldn't put the service into failed state
if it crashes (or exits otherwise abnormally). I'd encourage never to
prefix with "-" unless you have a really good reason to.
> Restart=always
> RestartSec=0
>
> [Install]
> WantedBy=multi-user.target
If you use "WantedBy=multi-user.target" then this unit would be started
at boot, and delayed until the device in question shows up. If it never
shows up (for example because you boot on bare metal), then it would
have to timeout, which wouldn't be particularly pretty.
I wonder if it wouldn't be nicer to use the device showing up as _only_
trigger to spawn the service. This would be nicer I think because it
would spawn the service only if run in a VM. If you run the machine on
bare metal, then it wouldn't be started at all, and would not have to
timeout. (And if I grok this properly, then the virtio serial ports are
even hotpluggable, which makes this even more interesting) To implement
a scheme like that, you'd just ship a udev rules file which you install
to /lib/udev/rules/99-guestfs.rules with contents
like this:
SUBSYSTEM=="virtio-ports", ATTR{name}=="org.libguestfs.channel.0",
TAG+="systemd", ENV{SYSTEMD_WANTS}="guestfsd.service"
(untested, I hope the match is right)
It's up to you whether you prefer the "spawn unconditionally but wait
for the device to show up" approach or my suggestion of "spawn if and
when the device shows up".
Either way I have now added to git a patch that marks virtio ports for
exposure in systemd, by marking them with "systemd".
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-Server-SS-PreFork/f15] Initial import.
commit 6cb9f317774c3f46510ae965296215bf396c933b
Author: Emmanuel Seyman
Date: Tue Jul 5 19:55:17 2011 +0200
Initial import.
.gitignore |1 +
perl-Net-Server-SS-PreFork.spec | 56 +++
sources |1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..ed393cb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-Server-SS-PreFork-0.05.tar.gz
diff --git a/perl-Net-Server-SS-PreFork.spec b/perl-Net-Server-SS-PreFork.spec
new file mode 100644
index 000..8ad4b36
--- /dev/null
+++ b/perl-Net-Server-SS-PreFork.spec
@@ -0,0 +1,56 @@
+Name: perl-Net-Server-SS-PreFork
+Version:0.05
+Release:2%{?dist}
+Summary:Hot-deployable variant of Net::Server::PreFork
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Net-Server-SS-PreFork/
+Source0:
http://www.cpan.org/authors/id/K/KA/KAZUHO/Net-Server-SS-PreFork-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(HTTP::Server::Simple::CGI)
+BuildRequires: perl(LWP::Simple)
+BuildRequires: perl(Net::Server)
+BuildRequires: perl(Server::Starter)
+BuildRequires: perl(Test::TCP)
+
+# Temporary workabout around bug #719048
+BuildRequires: perl(CGI)
+
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+
+%description
+Net::Server::SS::PreFork is a Net::Server personality, extending
+Net::Server::PreFork. It can be run by the start_server script of
+Server::Starter.
+
+%prep
+%setup -q -n Net-Server-SS-PreFork-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/Net
+%{_mandir}/man3/Net*
+
+%changelog
+* Tue Jul 05 2011 Emmanuel Seyman 0.05-2
+- Add perl(CGI) as a BuildRequires until brc #719048 is fixed.
+- Use more explicit entries in the files stanza
+
+* Fri Jun 17 2011 Emmanuel Seyman 0.05-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..ba5541d 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+4198d48d27353f60cc297178f86c216f Net-Server-SS-PreFork-0.05.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Server-SS-PreFork] Initial import.
commit c31401ce2b103de2f5d5e1910f86924c573b22c6
Author: Emmanuel Seyman
Date: Tue Jul 5 19:44:59 2011 +0200
Initial import.
.gitignore |1 +
perl-Net-Server-SS-PreFork.spec | 56 +++
sources |1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..ed393cb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-Server-SS-PreFork-0.05.tar.gz
diff --git a/perl-Net-Server-SS-PreFork.spec b/perl-Net-Server-SS-PreFork.spec
new file mode 100644
index 000..8ad4b36
--- /dev/null
+++ b/perl-Net-Server-SS-PreFork.spec
@@ -0,0 +1,56 @@
+Name: perl-Net-Server-SS-PreFork
+Version:0.05
+Release:2%{?dist}
+Summary:Hot-deployable variant of Net::Server::PreFork
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Net-Server-SS-PreFork/
+Source0:
http://www.cpan.org/authors/id/K/KA/KAZUHO/Net-Server-SS-PreFork-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(HTTP::Server::Simple::CGI)
+BuildRequires: perl(LWP::Simple)
+BuildRequires: perl(Net::Server)
+BuildRequires: perl(Server::Starter)
+BuildRequires: perl(Test::TCP)
+
+# Temporary workabout around bug #719048
+BuildRequires: perl(CGI)
+
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+
+%description
+Net::Server::SS::PreFork is a Net::Server personality, extending
+Net::Server::PreFork. It can be run by the start_server script of
+Server::Starter.
+
+%prep
+%setup -q -n Net-Server-SS-PreFork-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/Net
+%{_mandir}/man3/Net*
+
+%changelog
+* Tue Jul 05 2011 Emmanuel Seyman 0.05-2
+- Add perl(CGI) as a BuildRequires until brc #719048 is fixed.
+- Use more explicit entries in the files stanza
+
+* Fri Jun 17 2011 Emmanuel Seyman 0.05-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..ba5541d 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+4198d48d27353f60cc297178f86c216f Net-Server-SS-PreFork-0.05.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 Net-Server-SS-PreFork-0.05.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Net-Server-SS-PreFork: 4198d48d27353f60cc297178f86c216f Net-Server-SS-PreFork-0.05.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: vsftpd in the news
On 07/05/2011 05:15 PM, Adam Williamson wrote: > > I didn't see any suggestion that packages be *required* to have a > signature, only that we somehow run an automated check on one if there > is one. > > Rather than making specific Source numbers special case, why not just go > on naming? The convention for signatures is to add an extension to the > name of the tarball the signature is for; that shouldn't be too hard to > implement, I don't think. Surely the automated testing tool would need a way of being fed known-trusted public keys in advance as well? -- Benjamin Lewis Returning Officer and Past-President Durham Union Society Mobile: +44 7540 379074 Office: +44 191 384 3724 Pemberton Buildings, Palace Green, Durham signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 719069] clean up compiler warnings in 389-ds-base 1.2.9
https://bugzilla.redhat.com/show_bug.cgi?id=719069 https://bugzilla.redhat.com/attachment.cgi?id=511349&action=diff https://bugzilla.redhat.com/attachment.cgi?id=511349&action=edit Thanks, --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: vsftpd in the news
On Tue, 2011-07-05 at 11:13 +0200, Nils Philippsen wrote: > On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: > > On 07/04/2011 10:53 PM, Paul Wouters wrote: > > > It would be nice if we could upload/commit the .asc or .sig file, and > > > have the rpmbuild script > > > automatically check the tar ball. > > > > Hm, yes. It would be nice to see Koji support checking source sigs. OBS > > already does so. Seeing as Debian has done this for years with the > > source .deb including a signature file, RPM >4.9 could support sigs for > > the Source0 file. > > Making Source0 a special case sounds rather dirty to me, if at all such > functionality should be available for all source files (and patches > eventually). > > Furthermore, just having a signature file doesn't help a bit if you > can't be sure who created the signature... and I suspect if we were to > restrict ourselves to upstream packages that a) have gpg signatures b) > from keypairs not more than a certain "distance" (web-of-trust-wise) > away from a known good keypair, we'd be able to trim down the package > repositories substantially ;-). So for the time being I guess we should > stick with letting package maintainers check this (of there is anything > to check). I didn't see any suggestion that packages be *required* to have a signature, only that we somehow run an automated check on one if there is one. Rather than making specific Source numbers special case, why not just go on naming? The convention for signatures is to add an extension to the name of the tarball the signature is for; that shouldn't be too hard to implement, I don't think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: > In the mean time, perhaps AutoQA could have a check added against the > source checksum? That sounds like an excellent idea for a contribution! Remember, the AutoQA project is explicitly designed to allow and indeed encourage tests to be contributed - we would love it if the core AutoQA team worked mostly on the framework, and tests were contributed by many people. See https://fedoraproject.org/wiki/Writing_AutoQA_Tests . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 719048] perl-HTTP-Server-Simple has no dependencies on perl-CGI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=719048 --- Comment #2 from Fedora Update System 2011-07-05 12:23:21 EDT --- perl-HTTP-Server-Simple-0.44-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/perl-HTTP-Server-Simple-0.44-1.fc15 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 719048] perl-HTTP-Server-Simple has no dependencies on perl-CGI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=719048 --- Comment #3 from Fedora Update System 2011-07-05 12:23:32 EDT --- perl-HTTP-Server-Simple-0.44-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/perl-HTTP-Server-Simple-0.44-1.fc14 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Comaintaining and/or help for qucs and freehdl
Le 04/07/2011 05:42, Bruno Wolff III a écrit : > On Sun, Jul 03, 2011 at 22:30:01 +0200, >Eric Tanguy wrote: >> Could you help me for this problem also ? > I can take a look at it, but probably not for a few days. Ok thanks, the file is difficult to find because the upstream web site is not up to date. Here is a link for the file : http://sourceforge.net/projects/qucs/files/qucs/0.0.16/freehdl-0.0.8.tar.gz Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9.1 and Lucene Core for F16
2011/7/4 Stanislav Ochotnicky : > Excerpts from Michał Piotrowski's message of Mon Jul 04 13:11:06 +0200 2011: >> Unfortunately I do not have enough java programming experience to help >> you in fixing problems. > > There might be a more simple way to do it though. There was already a > started lucene3 review that would be able to live in parallel with > current lucene 2.x. In the end it wasn't finished, but if you feel up > to it you can continue: > https://bugzilla.redhat.com/show_bug.cgi?id=664826 Thanks for the link, I'll look at this tonight and see if I can help. (Although I have no experience with creating spec files, but I will try to remove at least a few rpmlint warnings) > > Good luck, > > -- > Stanislav Ochotnicky > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com > > -- > 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: systemd: Tagging /dev/virtio-ports/* for systemd
On Tue, Jul 05, 2011 at 04:47:18PM +0100, Richard W.M. Jones wrote: > [Is there a Fedora-specific systemd list? Not that I can find.] > > We'd like to request that virtio-serial devices (/dev/virtio-ports/*) > are tagged so we can use them as systemd devices. Dan Berrange thinks > the right incantation is to add: > > SUBSYSTEM=="virtio-ports", TAG+="systemd" > > to /lib/udev/rules.d/99-systemd.rules The goal is that we want to automagically run /usr/sbin/guestfsd when /dev/virtio-ports/org.libguestfs.channel.0 is present. For this I believe we need to have a '.device' unit for the virtio-port device populated from the above udev rule, so we can in turn have a guestfsd.service unit looking like: [Unit] Description=libguestfs management daemon BindTo=dev-virtio\x2dports-org.libguestfs.channel.0.device After=dev-virtio\x2dports-org.libguestfs.channel.0.device [Service] ExecStart=-/usr/sbin/guestfsd Restart=always RestartSec=0 [Install] WantedBy=multi-user.target Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (719056) migrate-ds-admin.pl needs to update SELinux policy
https://bugzilla.redhat.com/show_bug.cgi?id=719056 https://bugzilla.redhat.com/attachment.cgi?id=511339&action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
systemd: Tagging /dev/virtio-ports/* for systemd
[Is there a Fedora-specific systemd list? Not that I can find.] We'd like to request that virtio-serial devices (/dev/virtio-ports/*) are tagged so we can use them as systemd devices. Dan Berrange thinks the right incantation is to add: SUBSYSTEM=="virtio-ports", TAG+="systemd" to /lib/udev/rules.d/99-systemd.rules Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: qt-ibase - ibase sql driver for Qt
On Tue, Jul 5, 2011 at 9:26 AM, Minh Ngo wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=719002 > you will have it soon :-) -- 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
Re: Something wrong with atlas-3.8.3-18.fc14.src.rpm
On Tue, 05 Jul 2011 08:42:57 -0400, NB (Neal) wrote: > 0. F15 x86_64 > 1. yumdownloader --source atlas > 2. rpmbuild -D 'enable_native_atlas 1' atlas.spec > error: line 75: Bad Requireflags: qualifiers: Requires(posttans): > chkconfig > > How can it be that my system fails rpmbuild but fedora build is OK? It hasn't been built for F15, but for F14. You could have found out some of this as an exercise, too: * http://koji.fedoraproject.org/koji/packageinfo?packageID=1345 => no fc15 build, last build inherited for F15 is from 2010-07-28 * Typo in the spec got fixed here in pkg git: http://pkgs.fedoraproject.org/gitweb/?p=atlas.git;a=commitdiff;h=5d470356500fdfa68f1ea7af0047046480e208c6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something wrong with atlas-3.8.3-18.fc14.src.rpm
On 05/07/11 13:42, Neal Becker wrote: > 0. F15 x86_64 > 1. yumdownloader --source atlas > 2. rpmbuild -D 'enable_native_atlas 1' atlas.spec > error: line 75: Bad Requireflags: qualifiers: Requires(posttans): > chkconfig > > How can it be that my system fails rpmbuild but fedora build is OK? Because the Fedora build was done with an older version of rpmbuild that didn't complain about the unrecognised qualifier on the Requires. That complaint is a recent addition to rpmbuild. No doubt it was meant to be Requires(posttrans) with an r. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-ConsistentVersion/f15] Initial import.
commit 9ab194bf113d263ec0396c4ff896b6684536c749
Author: Emmanuel Seyman
Date: Tue Jul 5 14:47:43 2011 +0200
Initial import.
.gitignore |1 +
perl-Test-ConsistentVersion.spec | 51 ++
sources |1 +
3 files changed, 53 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..dd64b6f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Test-ConsistentVersion-v0.2.3.tar.gz
diff --git a/perl-Test-ConsistentVersion.spec b/perl-Test-ConsistentVersion.spec
new file mode 100644
index 000..0527af6
--- /dev/null
+++ b/perl-Test-ConsistentVersion.spec
@@ -0,0 +1,51 @@
+Name: perl-Test-ConsistentVersion
+Version:0.2.3
+Release:1%{?dist}
+Summary:Ensures a CPAN distribution has consistent versioning
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Test-ConsistentVersion/
+Source0:
http://www.cpan.org/authors/id/C/CE/CEBJYRE/Test-ConsistentVersion-v%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Test::Builder)
+BuildRequires: perl(Test::Pod::Content)
+
+# Needed for TEST_AUTHOR tests
+BuildRequires: perl(Test::Perl::Critic)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Simple)
+
+BuildRequires: perl(version)
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
+
+%description
+The purpose of this module is to make it easy for other distribution
+authors to have consistent version numbers within the modules (as well as
+readme file and changelog) of the distribution.
+
+%prep
+%setup -q -n Test-ConsistentVersion-v%{version}
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+TEST_AUTHOR=1 ./Build test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon May 16 2011 Emmanuel Seyman 0.2.3-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..762ad35 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+f4e90bd16dd08330e6c89da0abc7b8ec Test-ConsistentVersion-v0.2.3.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
Something wrong with atlas-3.8.3-18.fc14.src.rpm
0. F15 x86_64 1. yumdownloader --source atlas 2. rpmbuild -D 'enable_native_atlas 1' atlas.spec error: line 75: Bad Requireflags: qualifiers: Requires(posttans): chkconfig How can it be that my system fails rpmbuild but fedora build is OK? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: qt-ibase - ibase sql driver for Qt
On 07/05/2011 10:40 AM, Itamar Reis Peixoto wrote: > On Tue, Jul 5, 2011 at 4:12 AM, Minh Ngo wrote: >> Hi, >> I would suggest adding qt-sql-ibase driver to the Fedora repository. >> This driver provides the InterBase/FireBird plugin for Qt 4. The patch >> for the spec >> file:https://raw.github.com/Ignotus/spec-files/e35c5f95b72b63f7f51b7ae4cfc4e06fc3d62d97/sqlibase.patch >> >> Regards, >> -- >> Minh [ignotus] Ngo >> Kiev, Ukraine >> JID: ignot...@jabber.kiev.ua > > > go ahead and submit the package for review > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > feel free to contact me if you need help in something. > > > > > > 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) https://bugzilla.redhat.com/show_bug.cgi?id=719002 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110705 changes
Compose started at Tue Jul 5 08:15:20 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) 1:anerley-0.2.14-7.fc16.i686 requires libcamel-1.2.so.26 1:anerley-0.2.14-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) audacious-plugin-xmp-3.3.0-7.fc16.x86_64 requires audacious(plugin-api) = 0:19 bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) camcardsync-0.1.1-4.fc15.x86_64 requires libhal.so.1()(64bit) contacts-0.12-7.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.0-10.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) empathy-3.1.3-1.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-couchdb-0.5.90-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-exchange-3.1.2-1.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-mapi-3.1.2-1.fc16.i686 requires libcamel-provider-1.2.so.26 evolution-mapi-3.1.2-1.fc16.i686 requires libcamel-1.2.so.26 evolution-mapi-3.1.2-1.fc16.x86_64 requires libcamel-provider-1.2.so.26()(64bit) evolution-mapi-3.1.2-1.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libebook-1.2.so.10()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-provider-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libcamel-1.2.so.25()(64bit) evolution-rss-0.2.90-21.20110523git.fc16.x86_64 requires libgnome-desktop-3.so.0()(64bit) evolution-sharp-0.21.1-14.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) ffgtk-plugin-evolution-0.7.94-2.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) gdb-heap-0.5-5.fc16.x86_64 requires glibc(x86-64) = 0:2.13.90 gedit-valencia-0.3.0-4.fc14.x86_64 requires libvala-0.10.so.0()(64bit) ghc-hinotify-0.3.1-9.fc16.i686 requires libHSarray-0.3.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSdirectory-1.1.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-time-1.0.0.6-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSold-locale-1.0.0.2-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSunix-2.4.2.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSfilepath-1.2.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSbase-4.3.1.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.i686 requires libHScontainers-0.4.0.0-ghc7.0.2.so ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSghc-prim-0.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-time-1.0.0.6-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSbase-4.3.1.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSinteger-gmp-0.2.0.3-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSold-locale-1.0.0.2-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64 requires libHSfilepath-1.2.0.0-ghc7.0.2.so()(64bit) ghc-hinotify-0.3.1-9.fc16.x86_64
Re: vsftpd in the news
On Tue, 05 Jul 2011 11:01:15 +0200, AS (Andreas) wrote: > > The uploaded tarball checksum enters the "sources" file in git, and any > > tarball downloaded from the lookaside cache MUST match that checksum. > > Else it wouldn't be downloaded and used. Source RPM build in koji would > > fail. > > That won't help if the tarball is already defective when uploaded. The > checksum is basically only used to identify the blob in the cache, at > most to detect cache corruptions. And I didn't claim otherwise. The post I replied to already had mentioned: | For Fedora, package maintainers are responsible for uploading verified | tar balls to the fedora build system. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 2011-07-04 at 23:27 -0500, Michael Cronenworth wrote: > On 07/04/2011 10:53 PM, Paul Wouters wrote: > > It would be nice if we could upload/commit the .asc or .sig file, and have > > the rpmbuild script > > automatically check the tar ball. > > Hm, yes. It would be nice to see Koji support checking source sigs. OBS > already does so. Seeing as Debian has done this for years with the > source .deb including a signature file, RPM >4.9 could support sigs for > the Source0 file. Making Source0 a special case sounds rather dirty to me, if at all such functionality should be available for all source files (and patches eventually). Furthermore, just having a signature file doesn't help a bit if you can't be sure who created the signature... and I suspect if we were to restrict ourselves to upstream packages that a) have gpg signatures b) from keypairs not more than a certain "distance" (web-of-trust-wise) away from a known good keypair, we'd be able to trim down the package repositories substantially ;-). So for the time being I guess we should stick with letting package maintainers check this (of there is anything to check). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
Michael Schwendt writes: > The uploaded tarball checksum enters the "sources" file in git, and any > tarball downloaded from the lookaside cache MUST match that checksum. > Else it wouldn't be downloaded and used. Source RPM build in koji would > fail. That won't help if the tarball is already defective when uploaded. The checksum is basically only used to identify the blob in the cache, at most to detect cache corruptions. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vsftpd in the news
On Mon, 4 Jul 2011 23:53:38 -0400 (EDT), PW (Paul) wrote: > It would be nice if we could upload/commit the .asc or .sig file, and have > the rpmbuild script > automatically check the tar ball. Some packagers do upload the detached sig and add it to the spec as another Source file URL. The uploaded tarball checksum enters the "sources" file in git, and any tarball downloaded from the lookaside cache MUST match that checksum. Else it wouldn't be downloaded and used. Source RPM build in koji would fail. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: qt-ibase - ibase sql driver for Qt
On Tue, Jul 5, 2011 at 4:12 AM, Minh Ngo wrote: > Hi, > I would suggest adding qt-sql-ibase driver to the Fedora repository. > This driver provides the InterBase/FireBird plugin for Qt 4. The patch > for the spec > file:https://raw.github.com/Ignotus/spec-files/e35c5f95b72b63f7f51b7ae4cfc4e06fc3d62d97/sqlibase.patch > > Regards, > -- > Minh [ignotus] Ngo > Kiev, Ukraine > JID: ignot...@jabber.kiev.ua go ahead and submit the package for review https://fedoraproject.org/wiki/Join_the_package_collection_maintainers feel free to contact me if you need help in something. 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
qt-ibase - ibase sql driver for Qt
Hi, I would suggest adding qt-sql-ibase driver to the Fedora repository. This driver provides the InterBase/FireBird plugin for Qt 4. The patch for the spec file:https://raw.github.com/Ignotus/spec-files/e35c5f95b72b63f7f51b7ae4cfc4e06fc3d62d97/sqlibase.patch Regards, -- Minh [ignotus] Ngo Kiev, Ukraine JID: ignot...@jabber.kiev.ua -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
