Re: urandom vs haveged

[Gregory Maxwell]

On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy  wrote:
> So then the question is, if urandom is what's recommended, are faster 
> substitutes just as good? If they are just as good, then why aren't they the 
> first recommendation? And if this step is superfluous, then I'd suggest 
> documentation be changed to eliminate the suggestion altogether.

Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the
key and one of the secure block modes (e.g. aes-lrw or aes-essiv).
Then I fill the dmcrypt device with /dev/zero.  This goes fairly fast,
filling the device with securely encrypted zeros.

Then I drop the volume and set up luks normally.

From a security perspective an attack which allowed the attacker to
distinguish the randomly encrypted /dev/zero from your other data
would be a fairly bad vulnerability generally against the encrypted
volume... much worse than the information leak wrt used blocks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Dennis Jacobfeuerborn]

On 03/27/2012 03:54 AM, Ken Dreyer wrote:
> On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn
>  wrote:
>> I disagree. Since this is a major update that gets introduced together with
>> a new Fedora version this opportunity should be used to make switches like
>> these.
> 
> In principle I agree with what you're saying, but this is still going
> to require changing lots of packages, and it should be properly scoped
> on the httpd 2.4 feature page.

All the more reason for making this change now with a major version change
and early in the F18 release cycle rather than being forced to go through
this in a later supposedly minor update.

> Here's what I plan to use in Cacti.
> 
> 
>2.2>
> Require host localhost
>   
>   
> Order deny,allow
> Deny from all
> Allow from localhost
>   
> 

I don't think making this a runtime configuration is a good idea. Most
people only run either 2.2 or 2.4 but not both so having this in their
config is really unnecessary and makes things more complicated then it
needs to be.
Why not make this distinction in the spec file and include one of two
configuration files in the rpm depending on the release version? That way
F18+ users get a clean config for 2.4 and older version get a clean config
for 2.2.

Regards,
  Dennis
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Ken Dreyer]

On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn
 wrote:
> I disagree. Since this is a major update that gets introduced together with
> a new Fedora version this opportunity should be used to make switches like
> these.

In principle I agree with what you're saying, but this is still going
to require changing lots of packages, and it should be properly scoped
on the httpd 2.4 feature page.

Here's what I plan to use in Cacti.


   2.2>
Require host localhost
  
  
Order deny,allow
Deny from all
Allow from localhost
  

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Dennis Jacobfeuerborn]

On 03/26/2012 10:10 PM, Michał Piotrowski wrote:
> 2012/3/26 Nicolas Mailhot :
>> The following is going to kill pretty much every packaged webapp unless they
>> are changed now:
>>
>> https://httpd.apache.org/docs/2.4/upgrading.html#access
> 
> IMHO mod_access_compat should be enabled by default
> https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html

I disagree. Since this is a major update that gets introduced together with
a new Fedora version this opportunity should be used to make switches like
these. Otherwise you'll be forced to either keep this compat stuff around
for a long time (given the long apache release cycles) or remove it with a
minor update when people least expect it.

Regards,
  Dennis

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Reindl Harald]

Am 26.03.2012 21:51, schrieb Kevin Kofler:
> Reindl Harald wrote:
>> i notice this since upgraded to Fedora 16 on mostly all
>> virtual machines while i have never seeen this with F15
> 
> When did you see that? Yesterday? Might that be related to DST (Daylight 
> Savings Time, or Dumb Sucker Time as I like to call it ;-) )?

argh some bastard script/update must have touched
"/etc/adjtime" because this was surely UTC and never
modified by me since summer 2008 :-(

[root@arrakis:~]$ cat /etc/adjtime
0.081032 1331163580 0.00
1331163580
LOCAL

[root@arrakis:~]$ stat /etc/adjtime
  Datei: „/etc/adjtime“
  Größe: 46 Blöcke: 8  EA Block: 4096   reguläre Datei
Gerät: 811h/2065d   Inode: 81938   Verknüpfungen: 1
Zugriff: (0644/-rw-r--r--)  Uid: (0/root)   Gid: (0/root)
Zugriff: 2010-12-08 18:08:32.499797772 +0100
Modifiziert: 2012-03-08 00:39:41.499387577 +0100
Geändert   : 2012-03-08 00:39:41.499387577 +0100
 Geburt: -
___

after sync this file from my workstation which is still UTC

* unlink /etc/localtime
* ln -s /usr/share/zoneinfo/Europe/Vienna /etc/localtime

this seems to be OK again, nevermind, i have seen this
not a single time since years :-( sorry for the noise



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Adam Williamson]

On Mon, 2012-03-26 at 11:52 +0100, Richard Hughes wrote:
> At the moment the GNOME updates in Fedora are a bit of chaotic affair.
> They mostly work, but only because of people like mclasen who spend
> hours and hours building packages and putting everything together
> manually. For 3.3.92 I experimented doing a mega-update and trying to
> get all the 3.3.92 builds in one place, and working with kalev on a
> google spreadsheet to make sure everything was built in good time, and
> nothing was left behind.
> 
> For the GNOME 3.4.0 release, I'm asking people to copy this pattern,
> and try to get all the builds into *one* update rather than 90% of the
> builds in one mega-update and then 10% in random updates that other
> people have filed. If this works, I'm intending to do the 3.4.1 update
> as one update as well.
> 
> So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92
> upstream release and is about to have a 3.4.0 release, please build
> the package like normal, but don't file an update. Instead add the
> build ID to 
> https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc
> and then I'll pick up the build for the mega update.
> 
> Hopefully this makes the updates system easier to QA, as GNOME is more
> and more interconnected, and it' just not possible to QA updates when
> you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version
> of gnome-screenshot.

Thanks a lot for this, Richard. It'll make QAing the updates much more
manageable.
-- 
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

Self Introduction

[Alexander Chernyakhovsky]

Hi,

I am Alex Chernyakhovsky. I am currently a 2nd-year student at the 
Massachusetts Institute of Technology, studying Electrical Engineering and 
Computer Science. I am a long-time user of Red Hat Linux, Fedora, and Red 
Hat Enterprise Linux.


I greatly admire the work the Fedora contributors do, and for the longest 
time have wanted to participate beyond simply reporting bugs. I now wish 
to become a Fedora Packager, and finally have the opportunity to do so. I 
have packaged "Mosh: the mobile shell". The review request can be found 
here: https://bugzilla.redhat.com/show_bug.cgi?id=806665


Thanks!

Sincerely,
-Alex



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

[Chris Murphy]

On Mar 26, 2012, at 4:31 PM, Pádraig Brady wrote:
> 
> Well if you're just writing huge amounts of "random" data
> to clear existing space, then you don't need it to be cryptographically 
> secure.
> Why are you doing this exactly? Would /dev/zero suffice?

In every supposed best practice case of dm-crypt LUKS setup, urandom is used by 
example. Including by Red Hat and Fedora Projects. The Fedora link says: 
"You're looking at a process that takes many hours, but it is imperative to do 
this in order to have good protection against break-in attempts. Just let it 
run overnight."

http://www.redhat.com/summit/2011/presentations/summit/taste_of_training/wednesday/Strickland_On_Disk_Encryption_with_RHEL.pdf

http://fedoraproject.org/wiki/Implementing_LUKS_Disk_Encryption

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption-Manually_Encrypting_Directories-Step_by_Step_Instructions.html

So then the question is, if urandom is what's recommended, are faster 
substitutes just as good? If they are just as good, then why aren't they the 
first recommendation? And if this step is superfluous, then I'd suggest 
documentation be changed to eliminate the suggestion altogether.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)

[Richard W.M. Jones]

I don't want it to sounds like I'm discouraging anyone from packaging
these.  I'm a well-known "packaging maximalist" :-)  If they even let
me do 'dpkg-deb -c ...' then there is some use for them.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)

[Oron Peled]

On Monday, 26 בMarch 2012 13:08:33 Jeroen van Meeuwen (Kolab Systems) wrote:
> I'm still interested in making available the packages through Fedora 
> repositories proper, but I'm also, admittedly, not paying attention to 
> the review tickets. I have what I need (rubygem-passenger and many 
> others included), and while I'd like Fedora to also make available what 
> I have, I have little interest in completing the slow, lengthy, 
> scrutinizing and therefore painful and time-consuming review process.

Understandable. Would you like to assign me as maintainer/co-maintainer?

My plan is:
 - Refresh build for Fedora/rawhide

 - Refresh source version to what exist in Debian/squeeze as a minimum.
   (I think Debian/testing [wheezy] is a better match for Fedora
release cycle, but I prefer to be conservative at the beginning)

 - Go through the review process.

So, will I get this hot-potato?

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
"In theory, it's practical. In practice - it's only a theory".
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: urandom vs haveged

[Pádraig Brady]

On 03/26/2012 08:56 PM, Chris Murphy wrote:
> 
> Performance:
> 
> dd if=/dev/zero   ~56MB/s CPU < 10%
> dd if=/dev/urandom~12MB/s CPU 99%
> haveged   ~54MB/s CPU < 25%
> 
> 
> The dd relative values are consistent with kernels in Fedora 16. However 
> these tests were done with 3.3.0-1. The questions are:
> 
> Is the urandom performance expected?
> 
> What is the quality of pseudo-random data produced by urandom vs haveged?
> 
> If the qualities are similar, or haveged's is better, is there anything that 
> can be done to improve urandom's performance? It really takes quite a bit 
> longer to prepare a disk/volume for encryption.

Well if you're just writing huge amounts of "random" data
to clear existing space, then you don't need it to be cryptographically secure.
Why are you doing this exactly? Would /dev/zero suffice?
In any case it seems you could use shred rather than dd to clear data?
It has been changed to use a much faster internal generator:

http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v7.2-21-gaf5723c

cheers,
Pádraig.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fwd: Connotation analysis for Fedora Project codenames

[Robert 'Bob' Jensen]

This discussion started on the "board" list yet I know a lot of developers have 
an opinion on the topic.

The deadline for F18 name ideas is almost over but the discussion is still 
valid. Join the board list and speak up! Fedora is supposed to be community 
driven, take the wheel.

-- Bob

- Forwarded Message -
From: "Jaroslav Reznik" 
To: "Fedora community advisory board" 
Sent: Friday, March 23, 2012 9:14:36 AM GMT -06:00 US/Canada Central
Subject: Connotation analysis for Fedora Project codenames

Hi,
there's ongoing discussion about the connotation analysis
of Fedora Project code names (so not only for Fedora itself
but other sub-projects too) started by Rajesh Ranjan (thanks
for ticket!). 

It's a right time to get an input from community as there's 
currently running Fedora 18 codename process [1].

As Rajesh posted to Fedora Board Track ticket, connotation is
"the emotional and imaginative association for a word, where
denotation is the strict dictionary meaning of a word."

Current process for selecting next code name is - community 
members suggests the name, there's publicly accessible list for 
everyone, then Board goes through the suggested names list to 
remove the clear examples of names breaking the policy (yeah, 
usually it's one search term in Google to find out the name has 
to be ruled out, but that's Board deal ;-) and this list is 
sent to Red Hat legal for proper legal review. Then the voting
is opened for everyone with valid FAS account and only names
that passed the process are allowed.

In Fedora we believe in freedom and openness, we don't have to 
stick to the strict "corporate-like| rules but on the other hand we
should respect our community and we don't want to offend anyone
consciously.

Usually, we use the common sense to rule out offending stuff but 
also we (and Board neither) don't  have a degree in sociology, politics,
religion and our geek culture is also from the another universe :).

As I already pointed out - the process is open. Anybody can step
into in the early phase of naming selection and comment the 
potential problems. And I believe the Board members will think
about the concerns raised (at least me ;-). 

So personally I'd like to avoid any strict rule/policy as it could 
hurt our community, we don't have a proper set of skills to do 
the full analysis during the Board turn and I really hope with help 
provided by community we  can avoid the naming problems in the 
future - just we need your, community, input.

Any thoughts?

PS: I like Christoph's comment in ticket - that as an international 
project we should be proud of our diversity. It is a chance and 
a burden at the same time, Fedora will face this problem often and 
we can do our best to respect others and their views.

Jaroslav

[1] http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_18
___
advisory-board mailing list
advisory-bo...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/advisory-board
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)

[Oron Peled]

On Monday, 26 בMarch 2012 11:32:10 Richard W.M. Jones wrote:
> On Mon, Mar 26, 2012 at 12:57:44AM +0200, Oron Peled wrote:
> >- This means that a Debian/Ubuntu workstation can build both .deb
> >  and RPM packages, and we cannot use Fedora for a similar role.
> 
> Is this really true?  What happens if, say, your program depends on
> PCRE, which has different sonames on Debian/Ubuntu and Fedora (for
> essentially the same library):

You are correct that packaging tools by themselves do not solve *all*
portability problems (e.g: Suse/Mandriva/Feodra use RPM, but nobody
sane would try to install cross-distro -- even with same package format)

However, there are many important working use-cases.
Examples:

 * If the programs or libraries you compile yourselve, use just glibc,
   you are normally good to go (due to the very strict ABI provided
   by glibc):

   oron@squeeze1:~$ objdump --all /lib/libc-2.11.3.so | grep SONAME
   SONAME   libc.so.6

   [oron@localhost ~]$ rpm -q fedora-release
   fedora-release-15-3.noarch
   [oron@localhost ~]$ objdump --all /lib/libc-2.14.1.so | grep SONAME
   SONAME   libc.so.6

 * Noarch packages (perl/python/ruby/you-name-it)

 * Packaging cross-compiler toolchain/libraries (which is really
   a special case of the two previous items)

 * Manipulating packages:
   - createrepo
   - downloading/extracting source packages

> I don't understand how a binary built on one platform could be copied
> across to the other and work.

Moreover, if we have pbuilder on Fedora (which is one of the packages
I listed), we are done, as it build in a chroot environment (similar
to Fedora's mock).

Actually, even when building on a Debian host I always use either
pbuilder(1) for unattended builds, or build in an schroot(1) for
interactive builds. This enables me to build the same source tree
(maybe with pending commits) for different OS releases.

[Note: schroot(1) is already packaged in Fedora -- anybody who didn't
   try it is missing a crown jewl]

-- 
Oron Peled Voice: +972-4-8228492
o...@actcom.co.il  http://users.actcom.co.il/~oron
"The future is here,  it's just not evenly distributed yet." 
- William Gibson
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Olav Vitters]

On Mon, Mar 26, 2012 at 12:49:32PM +0100, Richard Hughes wrote:
> On 26 March 2012 11:58, Peter Robinson  wrote:
> > It would be nice if the rawhide stream was built at the same time as
> > well as not doing so has the effect of people trying to work with
> > rawhide as well get random failures and in the process of building
> > F-17 and rawhide on ARM a non insignificant number of gnome packages
> > have newer builds in F-16 than they do in both rawhide and F-17 that
> > I've ended up having to fix.
> 
> Yes, this is a valid critisism. I'm hoping to write a tool to
> automatically update GNOME builds in a stable release and in rawhide
> (that watches ftp-release list), rather than having to do it all
> manually.

If you want ideas:
http://svnweb.mageia.org/soft/mga-gnome/trunk/mga-gnome?view=markup
Though note that Mageia packages per .so library version, so any bumps =
breakage (on purpose, goes in another package)

Also, if you need more information on ftp.gnome.org or in
ftp-release-list:
http://git.gnome.org/browse/sysadmin-bin/tree/ftpadmin
Still want:
- One (preferably json) file on ftp.gnome.org containing all latest
  versions of all modules. Problem is that master.gnome.org uses NFS and
  bit worried about how to update such a file nicely.
- An RSS feed again (apparently there is some django module which makes
  this easy; needs to be available for RHEL6/EPEL6).

-- 
Regards,
Olav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Matthew Garrett]

On Mon, Mar 26, 2012 at 03:32:15PM -0400, DJ Delorie wrote:
> 
> > Given that the "pc" sense of BIOS includes having arguments returned in 
> > x86 registers, I really don't think that's true.
> 
> ARM has registers too...
> 
> My point is, the ARM chips *do* support an on-board flash bootloader,
> and there's no reason why that bootloader couldn't export a standard
> ABI that uses interrupts and register passing, and boot off a standard
> attached disk...

I think you misunderstood Richard. ARM hardware is moving towards 
adopting UEFI as the standard firmware interface, which is BIOS-like in 
the sense that you're describing. Richard was explicitly talking about 
BIOS-as-in-x86-asm-and-int-calls being preferable to UEFI. There's no 
real way ARM could implement the latter.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: orphaning bibus

[Alex Lancaster]

Pkgdb link:

https://admin.fedoraproject.org/pkgdb/acls/name/bibus

I kept myself on as a co-maintainer, but it deserves a more
proactive main owner.

- Original Message -
> I don't really use it anymore (replaced it with Zotero) and don't
> have time to maintain it, but it is still being developed upstream
> (as of late 2011):
> 
> http://sourceforge.net/projects/bibus-biblio/
> 
> There is a 1.5.2 release available, see also:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=757675
> 
> Hopefully it will go to a better home.
> 
> Alex
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

orphaning bibus

[Alex Lancaster]

I don't really use it anymore (replaced it with Zotero) and don't
have time to maintain it, but it is still being developed upstream
(as of late 2011):

http://sourceforge.net/projects/bibus-biblio/

There is a 1.5.2 release available, see also:

https://bugzilla.redhat.com/show_bug.cgi?id=757675

Hopefully it will go to a better home.

Alex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Dependencies on Bodhi Updates

[Jochen Schmitt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26.03.2012 21:53, Stephen Gallagher wrote:
>
> So now we have our first updates dependency issue. If we submit
> libtevent as its own update, it is possible that it will achieve its
> karma requirement before libtalloc does. It would then be pushed to the
> "fedora-updates" repository and then introduce a dependency issue in the
> stable repository (because users trying to update libtevent would be
> unable to update libtalloc without enabling the updates-testing
> repository).
>
> The current recommended approach is to bundle the two updates into a
> single one carrying multiple packages. The first problem with this is
> that you must have commit privilege on all packages that you are
> bundling into an update. If you do not, then you need to track down a
> provenpackager to do it for you.
>
>
Thank you for your post about this topic.

In this year we have as a minimum two cases were we have got broken
dependencies in the F-16 stable repository.

1.) alsa-utils and alsa-libs was pushed out of sync

2.) gcc and llvm which requires as specific version of gcc was pushed
out of sync.

The issue is, that the user will get an ugly error message which is not
a good
advertisement for the Fedora project.

I have wrote mails to the maintainers and in the second case I have got
the feeling, that
the maintainer didn't understood my complain.

Of course we can get run in error if the push fails due an technical
issue, but
this is an onther topic.

Best Regards:

Jochen Schmitt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iJwEAQECAAYFAk9w0cYACgkQZLAIBz9lVu+lVAP9F50AXP0B5nDHWvFuxRd4f5wY
UyZz2gkNi7CMX5jD9DkkzQ+swrrvEVOQCpUA4zOplP3bsEpR8MV8i4Y104gz8Ygw
cCg/V8xhEMfalhJ3ORDST6yVLlBViHKsjOcV0tJ0fAFX10zShxXwlnxutp+RP8V2
MKT4JUhj1lD8knqWo50=
=XZBT
-END PGP SIGNATURE-

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Kernel bug with USB disks ?

[J. Randall Owens]

On 03/26/2012 06:05 AM, Terry Barnaby wrote:
> Hi,
> 
> I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
> problems with a MicroSD card connected to a USB card reader. This has
> been working fine until recently (at least in F14 on the same hardware).
> 
> The problem is that "umount" does not appear to be working correctly.
> I have an ext3 file system on the card. I can mount it, and I can copy
> files to it. However when I use the "umount ..." command it returns
> instantly (should sync the files to the card). The system says the card
> is unmounted (at least it is not listed with mount, df etc).
> 
> However if I run sync, there is a lot of disk activity to the card ...
> 
> Also if I try and run "mkfs" it says the device in in use ...
> If I mount a blank card it lists the files present on the previous card ...
> 
> This sounds like a nasty kernel bug ...
> Anyone else seen this ?

I thought I'd noticed something like this with 3.2.x kernels also; I
couldn't narrow it down more than that.  In my case, it's a USB external
HDD.  After unmounting, I have an old habit of running 3 syncs in one
line.  And lately, I've noticed that I don't even get that disk activity
until I give it a second trio of syncs, which certainly doesn't seem right.
Let me check right now with 3.3.0-4...  Odd, now I do get the activity
at about the same time as the umount, and no further activity when I
issue the syncs.  Seems to be the opposite of what you've reported.

-- 
J. Randall Owens | http://www.ghiapet.net/

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Dependencies on Bodhi Updates

[Kevin Kofler]

Stephen Gallagher wrote:
> 2) We could continue on the "single update for multiple packages"
> approach, but revamp the karma system so that each SRPM gets its own
> karma, rather than the update as a whole. Then, the whole update would
> not be pushed via autokarma until all of the dependent packages had
> sufficient karma (or the owner of the update could push them after the
> stable wait period, of course).

This just does not scale for large update groups such as the KDE SC updates.

I think it would also acerbate the already existing "How do I provide 
feedback for a library?" problem (because now it'd also affect libraries 
included in update groups, not just those filed separately).

I don't understand why we need to make up more and more complicated rules 
for updates rather than just killing the whole karma and autokarma business 
and having the maintainer READ the update feedback and make an informed (and 
unhindered by bureaucracy) decision based on that.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Michał Piotrowski]

2012/3/26 Nicolas Mailhot :
> The following is going to kill pretty much every packaged webapp unless they
> are changed now:
>
> https://httpd.apache.org/docs/2.4/upgrading.html#access

IMHO mod_access_compat should be enabled by default
https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html

>
> --
> Nicolas Mailhot
>
> --
> 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: httpd 2.4 is coming, RFC on module packaging draft

[Chris Adams]

Once upon a time, Nicolas Mailhot  said:
> The following is going to kill pretty much every packaged webapp unless they
> are changed now:
> 
> https://httpd.apache.org/docs/2.4/upgrading.html#access

Did you read this part:

  "The old access control idioms should be replaced by the new
   authentication mechanisms, although for compatibility with old
   configurations, the new module mod_access_compat is provided."

It would be easy to include mod_access_compat in the Fedora default
config for a release or two while the compat config is deprecated (and
noted in the release notes as such).

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

urandom vs haveged

[Chris Murphy]

Performance:

dd if=/dev/zero ~56MB/s CPU < 10%
dd if=/dev/urandom  ~12MB/s CPU 99%
haveged ~54MB/s CPU < 25%


The dd relative values are consistent with kernels in Fedora 16. However these 
tests were done with 3.3.0-1. The questions are:

Is the urandom performance expected?

What is the quality of pseudo-random data produced by urandom vs haveged?

If the qualities are similar, or haveged's is better, is there anything that 
can be done to improve urandom's performance? It really takes quite a bit 
longer to prepare a disk/volume for encryption.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Dependencies on Bodhi Updates

[Stephen Gallagher]

As requested during the FESCo meeting, I am going to try to summarize
some of the issues inherent in the way that Bodhi updates currently
work.

First, I'll try to explain the goals and constraints:

1) The stable 'fedora-updates' yum repository should NEVER exist in a
state where any package has dependency issues. In other words, it should
never be possible for an update to be pushed to stable that breaks
cleanly updating any other package.

2) Updates must be possible and (ideally) timely. This is probably
self-evident.

3) Packages pushed to the stable 'fedora-updates' yum repository should
(ideally) not introduce regressions in packages that depend on them.

4) New features in "superpackages" such as Firefox, GNOME or FreeIPA
that have many and varied dependencies may require new features in
packages they depend on in order to enhance or fix the superpackage.


In the trivial example, a package (let's say libtalloc) needs to make an
update to fix a bug. This package requires nothing new from its
dependencies and is a self-contained fix. For this example, it is simple
to just build libtalloc in koji and then create a Bodhi update and pass
it through "updates-testing", get karma and *poof* off to
"fedora-updates".

Now let's extend the example. Suppose that we have another package
libtevent that has libtalloc as a dependency. Libtevent's maintainer
wants to add a new feature to libtevent, but the patch from upstream
depends on the bug in libtalloc having been fixed in order for the new
feature to work properly. In this situation, the maintainer of libtevent
would build libtevent with an explicit Requires: libtalloc >= 
in the specfile (possibly pulling libtalloc into the BuildRoot overrides
if necessary) and then test it locally to see that it works.

So now we have our first updates dependency issue. If we submit
libtevent as its own update, it is possible that it will achieve its
karma requirement before libtalloc does. It would then be pushed to the
"fedora-updates" repository and then introduce a dependency issue in the
stable repository (because users trying to update libtevent would be
unable to update libtalloc without enabling the updates-testing
repository).

The current recommended approach is to bundle the two updates into a
single one carrying multiple packages. The first problem with this is
that you must have commit privilege on all packages that you are
bundling into an update. If you do not, then you need to track down a
provenpackager to do it for you.


Now let's make the problem even more fun. Consider that the update to
libtevent might be coming in because it is necessary for a new feature
in libldb, which is in turn providing new functionality necessary for
SSSD. So now we have four packages all sitting in the same update. The
problem with this is that the tendency will be to only test the most
user-visible package(s) in the set. In this particular case, that might
be SSSD. So people would likely test SSSD and, if nothing went wrong,
consider the entire update stable.

But wait! SSSD isn't the only package that depends on libldb, libtevent
and libtalloc. So too does the samba package. Suppose that the bugfix in
libtalloc, after resolving the original issue, results in exposing
another more serious bug in samba? Now we need to pull a samba update
into this same update series.

A contrived example, you say? That would never happen, bugfixes aren't
likely to do that. Well, for one example:
https://admin.fedoraproject.org/updates/FEDORA-2011-11845 In this
particular example, we knew up-front that it was going to necessitate a
rebuild of several dependent packages and we coordinated a single
release to address them. So in this case, the proper approach was to
bundle them together in a single update. This worked because we
specifically knew that the libtevent change was going to break other
packages.

But what about when we don't know that? Let's take another example:
https://admin.fedoraproject.org/updates/FEDORA-2011-17399

In this case, there was a security bug reported against Firefox. Such
things are serious, and acted on quickly. However, the bug was actually
fixed in the nss package, and Firefox, Xulrunner and friends were
rebuilt against that nss package. The problem was this: the fix made to
the nss package introduced regressions in every other package that
depended on it. However, because the default install of Firefox
contained no issues, it rapidly received the necessary karma points and
the whole update was pushed to stable. It then broke nearly every
application in Fedora that relied on cryptography.

The problem here was sociological, not technological. The only package
that received testing was Firefox. It's hard to say without evidence
whether the problem would have been averted by having nss go through its
own update, but I strongly suspect that what we would have seen was
greater testing on actual nss features for that specific update.


Of course, we now have the same p

Re: F16: "last superblock write time in future"

[Kevin Kofler]

Reindl Harald wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15

When did you see that? Yesterday? Might that be related to DST (Daylight 
Savings Time, or Dumb Sucker Time as I like to call it ;-) )?

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Nicolas Mailhot]

The following is going to kill pretty much every packaged webapp unless they
are changed now:

https://httpd.apache.org/docs/2.4/upgrading.html#access

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Kevin Kofler]

Rex Dieter wrote:
> the kde-sig has similar pain-points doing mass updates.  Having a list of
> pkgs to build (seems done on google docs in your case already, good), and
> having your own koji tag/target does seem to simplify matters a bunch. 
> Then it's relatively easy to compose a bodhi update from the output from:
> koji list-tagged --latest f16-gnome
> for example.

Let's also mention our mass-update script:
https://fedorahosted.org/kde-settings/browser/scripts
which may or may not be of interest.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[DJ Delorie]

> Given that the "pc" sense of BIOS includes having arguments returned in 
> x86 registers, I really don't think that's true.

ARM has registers too...

My point is, the ARM chips *do* support an on-board flash bootloader,
and there's no reason why that bootloader couldn't export a standard
ABI that uses interrupts and register passing, and boot off a standard
attached disk...

... but that's not what the vendors do.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Kevin Kofler]

Matthias Clasen wrote:
> The trick is to not build for rawhide ever, until after the stable
> release is out, and instead rely on inheritance. Since building
> everything twice is just a terrible waste of effort, and makes this
> whole mass building thing even more of a torture. But, of course, this
> only works if you get on the right track when doing the first build
> after the fork - unfortunately, our forking setup makes it not easy to
> avoid doing at least one accidental F18 build before you notice the new
> branch...

I don't recommend relying on this, because underlying libraries can have 
different sonames in Rawhide than in the release. IMHO it's better to always 
build for Rawhide separately, even when not strictly necessary.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Messaging SIG - IRC Meetings on Tuesdays

[RJ Bean]

Just an announcement - the Messaging SIG is starting regular IRC meetings on
Tuesdays at 16:00 UTC.

Wiki page for the SIG:
 http://fedoraproject.org/wiki/Messaging_SIG

My work on a proposal and a python library:
 https://github.com/ralphbean/fedmsg/blob/develop/doc/proposal.rst
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Matthew Garrett]

On Mon, Mar 26, 2012 at 01:37:39PM -0400, DJ Delorie wrote:
> 
> > Which leads me to a rant about ARM.  G RANT!!  I didn't think
> > I'd ever love the BIOS, but compared to the alternatives (UEFI and a
> > million different ARM bootloaders) it's simple and effective.
> 
> This is getting way off-topic, but... most linux-capable ARM chips
> support a BIOS in the "pc" sense.  Vendors choose not to do it that
> way.

Given that the "pc" sense of BIOS includes having arguments returned in 
x86 registers, I really don't think that's true.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)

[Kevin Kofler]

Richard W.M. Jones wrote:
> Is this really true?  What happens if, say, your program depends on
> PCRE, which has different sonames on Debian/Ubuntu and Fedora (for
> essentially the same library):

The same thing which happens if you build for, say, RHEL 6 on Fedora 16 
using mock, pbuilder is the Debian equivalent to mock.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Reindl Harald]

Am 26.03.2012 21:11, schrieb Jef Spaleta:
> On Mon, Mar 26, 2012 at 10:42 AM, Reindl Harald  
> wrote:
>> the document above is hughe outdated
> 
> Oh well. Nevermind then. Good luck correcting your configs

as you see in this output the configs are correct
this 19 guests are using the same ntp-servers (ntpd not chrony)
a script on one machine fires up "date" on each one
3 of them are currently F15, the rest F16

the last one is even connected over cable-internet
and sychronized to the host-ntpd which has the
same time sources as all other guests over openVPN

the problem happens only on F16 guests
so i see no time-config problem here

the 6 seconds difference are the ssh-logins on the machines

Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: httpd 2.4 is coming, RFC on module packaging draft

[Joe Orton]

On Fri, Mar 23, 2012 at 06:39:25PM +0100, Michał Piotrowski wrote:
> Do you know if the new version of httpd has major changes in modules
> API? I'm trying to cobble together spec file for mod_spdy
> https://github.com/eventhorizonpl/mod_spdy/blob/master/mod_spdy.spec
> and I hope to finish it for F18 :)

Hi Michal, yes, there are changes in the 2.4 module API, though mostly 
relatively small - details are here:

http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html

Regards, Joe
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Meeting minutes FESCo (2012-03-26)

[Marcela Mašláňová]

===
#fedora-meeting: FESCO (2012-03-26)
===


Meeting started by mmaslano at 17:00:20 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2012-03-26/fesco.2012-03-26-17.00.log.html
.



Meeting summary
---
* init process  (mmaslano, 17:00:39)

* #699 Proposal to remove the package "tzdata" from Critical Path
  (mmaslano, 17:03:44)
  * ACTION: mmaslano will close 699 with proposal from previous week
(mmaslano, 17:05:47)

* #830 F18 Feature: ARM as Primary Arch
  --https://fedoraproject.org/wiki/Features/FedoraARM  (mmaslano,
  17:06:28)
  * ACTION: mmaslano will rename ticket to "define requirements for
secondary arch promotion"  (mmaslano, 17:32:03)
  * AGREED: mjg59 will prepare wiki at the end of a wek with list of
requirements from devel list (+8,-0)  (mmaslano, 17:37:10)
  * AGREED: mjg59 will prepare wiki at the end of a wek with list of
requirements from devel list (+9,-0)  (mmaslano, 17:37:36)

* #829 New sponsor request: Pavel Alexeev (hubbitus)  (mmaslano,
  17:39:20)
  * AGREED: hubbitus was rejected as a sponsor (-6,+2)  (mmaslano,
17:58:47)

* Next week's chair  (mmaslano, 17:59:12)
  * AGREED: mitr will be chairman next week  (mmaslano, 18:00:40)

* Time change  (mmaslano, 18:01:10)
  * AGREED: meeting time 17UTC, 19CEST, 13EST (+7,0)  (mmaslano,
18:12:21)

* Open floor  (mmaslano, 18:12:38)

* provenpackager/sponsor approval process  (notting, 18:12:55)
  * AGREED: on move sponsor feedback on sponsor/provenpackager requests
to tickets, not mail alias (+5,-1)  (mmaslano, 18:28:15)
  * AGREED: on move sponsor feedback on sponsor/provenpackager requests
to tickets, not mail alias (+6,-1)  (mmaslano, 18:28:34)

* Open floor  (mmaslano, 18:29:01)
  * AGREED: sgallagh will start another discussion about updates on
devel list (+6,0)  (mmaslano, 19:01:24)

Meeting ended at 19:01:34 UTC.




Action Items

* mmaslano will close 699 with proposal from previous week
* mmaslano will rename ticket to "define requirements for secondary arch
  promotion"




Action Items, by person
---
* mmaslano
  * mmaslano will close 699 with proposal from previous week
  * mmaslano will rename ticket to "define requirements for secondary
arch promotion"
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (93)
* mmaslano (88)
* pjones (75)
* nirik (69)
* notting (47)
* limburgher (47)
* adamw (46)
* mitr (45)
* t8m (43)
* mjg59 (39)
* jonmasters (29)
* drago01 (26)
* bconoboy (13)
* dgilmore (13)
* tflink (11)
* tibbs (10)
* zodbot (7)
* thunderbirdtr (2)
* lmacken (1)
* Southern_Gentlem (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Booting Fedora from LVM with grub2

[Kevin Kofler]

Richard W.M. Jones wrote:
> Umm ... okay.
> 
> Any particular reason?

Kickstarts are not very user-friendly nor convenient (unless you have 
several machines to install with identical installs, which is what they were 
invented for).

> Any other plans to make the current situation better?

Even QA-wise, I don't think making such a feature kickstart-only would 
improve the situation at all, it'd reduce the testing it gets by a lot.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-App-Cmd] Update to 0.317

[Emmanuel Seyman]

commit d7f775a901ed75c709cc7cc4ff0a7693ba987ffa
Author: Emmanuel Seyman 
Date:   Mon Mar 26 21:14:49 2012 +0200

Update to 0.317

 .gitignore|1 +
 perl-App-Cmd.spec |6 +-
 sources   |2 +-
 3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7eb7690..8aa1cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ App-Cmd-0.307.tar.gz
 /App-Cmd-0.314.tar.gz
 /App-Cmd-0.315.tar.gz
 /App-Cmd-0.316.tar.gz
+/App-Cmd-0.317.tar.gz
diff --git a/perl-App-Cmd.spec b/perl-App-Cmd.spec
index afc8f00..b42dc5d 100644
--- a/perl-App-Cmd.spec
+++ b/perl-App-Cmd.spec
@@ -1,6 +1,6 @@
 Name:   perl-App-Cmd
 Summary:Write command line apps with less suffering
-Version:0.316
+Version:0.317
 Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -9,6 +9,7 @@ URL:http://search.cpan.org/dist/App-Cmd
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 BuildArch:  noarch
 
+BuildRequires:  perl(parent)
 BuildRequires:  perl(Capture::Tiny)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Class::Load) >= 0.06
@@ -72,6 +73,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Mar 26 2012 Emmanuel Seyman  - 0.317-1
+- Update to 0.317
+
 * Sun Feb 12 2012 Emmanuel Seyman  - 0.316-1
 - Update to 0.316
 
diff --git a/sources b/sources
index 1721aaa..e115d6c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-441facfdfbcf62541247bb6da4df6396  App-Cmd-0.316.tar.gz
+0c0bcc097c1530a8059469ff3e7524d1  App-Cmd-0.317.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: F16: "last superblock write time in future"

[Jef Spaleta]

On Mon, Mar 26, 2012 at 10:42 AM, Reindl Harald  wrote:
> the document above is hughe outdated

Oh well. Nevermind then. Good luck correcting your configs

-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Reindl Harald]

Am 26.03.2012 20:22, schrieb Jef Spaleta:
>> hmmm - which HWCLOCK clock?
>> we are speaking about VMware Machines on ESXi/vSphere
> 
> My best suggestion for you is to read the following document.
> 
> www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
> 
> and follow the best practises outlined there.  You should have your
> linux guests setting so system time is in UTC not local time. I would
> suspect base on your symptoms you've got the wrong settings for the
> guest operating system.
> 
> The issue here is long standing and predates systemd. You really do
> need to follow the best practise recommendations set forth by vmware
> when using their virtualization product.

the document above is hughe outdated

this machines are installed 2008 with F9 and since then
upgraded, the first time this ever happens is after
upgrade to F16

all guests are using two ntp-servers in the LAN and time
is stable as long no reboot is done proven by the following
output which is a script calling "date" per ssh on each guest

Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:41 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:42 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:43 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:44 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:45 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:46 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012
Mo 26. Mär 20:40:47 CEST 2012




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[DJ Delorie]

> Which leads me to a rant about ARM.  G RANT!!  I didn't think
> I'd ever love the BIOS, but compared to the alternatives (UEFI and a
> million different ARM bootloaders) it's simple and effective.

This is getting way off-topic, but... most linux-capable ARM chips
support a BIOS in the "pc" sense.  Vendors choose not to do it that
way.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: gforth and gcc 4.7

[Jakub Jelinek]

On Mon, Mar 26, 2012 at 04:54:05PM +0200, Adrian Reber wrote:
> Trying to build gforth with gcc 4.7 fails currently. The forth engine is
> build but it fails its included tests. The problem is that every newline
> the forth engine writes is replaced with 0x00 as seen in following diff:
> 
>  010: 6566 696e 6564 2047 4458 2020 594f 5520  efined GDX  YOU 
>  020: 5348 4f55 4c44 2053 4545 2054 4845 2053  SHOULD SEE THE S
>  030: 5441 4e44 4152 4420 4752 4150 4849 4320  TANDARD GRAPHIC 
> -040: 4348 4152 4143 5445 5253 3a00 2021 2223  CHARACTERS:. !"#
>  ^^ actual output
> +040: 4348 4152 4143 5445 5253 3a0a 2021 2223  CHARACTERS:. !"#
>  ^^ expected output
>  050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
> 
> Removing -O2 from the compiler commandline fixes it, but I have no idea
> why this happens. Does anyone have an idea how this can be solved?

If -O0 works and -O2 doesn't, first narrow it down using a binary search
between -O0 and -O2 compiled objects to at least a single compilation
unit, then you could use __attribute__((optimize (0))) (resp.
__attribute__((optimize (2))) ) and/or -fno-inline to narrow it even
further, read the problematic code, see if there aren't any e.g. aliasing
warnings (-O2 enables -fstrict-aliasing), if you don't spot a bug in the
gforth code after this and still suspect the compiler, turn that into
self-contained minimal testcase (for the problematic routine add main
that calls it with the right arguments, make the problematic
routine __attribute__((noinline, noclone)) and stub out anything it calls,
then file a gcc bugreport?

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Eric Sandeen]

On 3/26/12 11:16 AM, Reindl Harald wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15
> 
> how to track down and for which component file a bugreport?
> 
> EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
> systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von 
> SuperBlock liegt in der Zukunft.
> systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
> gesetzter Hardware-Uhr)  REPARIERT.
> systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock 
> liegt in der Zukunft.
> systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
> gesetzter Hardware-Uhr)  REPARIERT.
> systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von 
> SuperBlock liegt in der Zukunft.
> systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
> gesetzter Hardware-Uhr)  REPARIERT.
> systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von 
> SuperBlock liegt in der Zukunft.
> systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
> gesetzter Hardware-Uhr)  REPARIERT.
> systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht 
> zusammenh\xffc3\xffa4\xffa4ngend),
> 15985/261048 Bl\xffc3\xffb6\xffb6cke
> 
> 
> 

  N_("@S last write time is in the future.\n\t(by less than a day, "
 "probably due to the hardware clock being incorrectly set).  "),

These messages are from e2fsck...

Can you check whether the hardware clock is being moved back when you reboot?

-Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[DJ Delorie]

> Any particular reason why you boot the thing via tftp?  I'd expect
> just having /boot on the sd card (which you need for boot anyway) is
> easier, especially when it comes to kernel updates.

I wanted the minimum on the sdcard (it just has the tftboot script)
because our build farm only has one local person, and he's not always
there.  With everything on the server, we can swap everything out,
power cycle it, and be done.

Remember, the iscsi volumes can be mounted on your regular desktop if
needed, to "fix" the image before booting the trimslice.

Plus, my way can use ancient tiny sdcards without worrying about space
or performance.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Jef Spaleta]

> hmmm - which HWCLOCK clock?
> we are speaking about VMware Machines on ESXi/vSphere

My best suggestion for you is to read the following document.

www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

and follow the best practises outlined there.  You should have your
linux guests setting so system time is in UTC not local time. I would
suspect base on your symptoms you've got the wrong settings for the
guest operating system.

The issue here is long standing and predates systemd. You really do
need to follow the best practise recommendations set forth by vmware
when using their virtualization product.

-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Reindl Harald]

Am 26.03.2012 19:34, schrieb Jef Spaleta:
> On Mon, Mar 26, 2012 at 9:29 AM, Jef Spaleta  wrote:
>> On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald  
>> wrote:
>>> i notice this since upgraded to Fedora 16 on mostly all
>>> virtual machines while i have never seeen this with F15
>>>
>>> how to track down and for which component file a bugreport?
>>
>> http://forums.fedoraforum.org/showthread.php?t=273727
> 
> 
> Bug report from 2009 concerning the very same issue.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=522969
> 
> You'll note that this is clearly a cyclic issue that comes and goes
> across multiple release timescales...as far back as F9

hmmm - which HWCLOCK clock?
we are speaking about VMware Machines on ESXi/vSphere

the problem with this issue is that it costs much time
at boot and wasted every systemd-improvement multiple

sync to HWCLOCK is also disabled in /etc/sysconfig/ntpd
since forever, yes there is not running chrony because
internal ntpd

cat /etc/sysconfig/ntpd
# Drop root to id 'ntp:ntp' by default.
OPTIONS="-u ntp:ntp -p /var/run/ntpd.pid -g"
# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Miloslav Trmač]

On Mon, Mar 26, 2012 at 6:16 PM, Reindl Harald  wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15
>
> how to track down and for which component file a bugreport?
>
> EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
> systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von 
> SuperBlock liegt in der Zukunft.
> systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
> gesetzter Hardware-Uhr)  REPARIERT.

Compare the hardware clock and system time, you might be hitting
something like https://bugzilla.redhat.com/show_bug.cgi?id=750883 .
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Jef Spaleta]

On Mon, Mar 26, 2012 at 9:29 AM, Jef Spaleta  wrote:
> On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald  wrote:
>> i notice this since upgraded to Fedora 16 on mostly all
>> virtual machines while i have never seeen this with F15
>>
>> how to track down and for which component file a bugreport?
>
> http://forums.fedoraforum.org/showthread.php?t=273727


Bug report from 2009 concerning the very same issue.

https://bugzilla.redhat.com/show_bug.cgi?id=522969

You'll note that this is clearly a cyclic issue that comes and goes
across multiple release timescales...as far back as F9.

-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: "last superblock write time in future"

[Jef Spaleta]

On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald  wrote:
> i notice this since upgraded to Fedora 16 on mostly all
> virtual machines while i have never seeen this with F15
>
> how to track down and for which component file a bugreport?

http://forums.fedoraforum.org/showthread.php?t=273727



-jef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F16: "last superblock write time in future"

[Reindl Harald]

i notice this since upgraded to Fedora 16 on mostly all
virtual machines while i have never seeen this with F15

how to track down and for which component file a bugreport?

EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr
systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von 
SuperBlock liegt in der Zukunft.
systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
gesetzter Hardware-Uhr)  REPARIERT.
systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock 
liegt in der Zukunft.
systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
gesetzter Hardware-Uhr)  REPARIERT.
systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von 
SuperBlock liegt in der Zukunft.
systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
gesetzter Hardware-Uhr)  REPARIERT.
systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von 
SuperBlock liegt in der Zukunft.
systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch 
gesetzter Hardware-Uhr)  REPARIERT.
systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht 
zusammenh\xffc3\xffa4\xffa4ngend),
15985/261048 Bl\xffc3\xffb6\xffb6cke



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Intent to retire: mod_python

[Michael Scherer]

Le lundi 26 mars 2012 à 16:04 +0100, Joe Orton a écrit :
> mod_python upstream has been inactive for five years, since Graham 
> Dumpleton went to work on mod_wsgi.  IMO it is long past time to retire 
> mod_python in Fedora.  But the following packages still depend on it:
> 
> Source  : glump-0.9.11-10.fc17.src.rpm
> Source  : koji-1.6.0-3.fc17.src.rpm
> Source  : viewvc-1.1.13-1.fc17.src.rpm

it support wsgi since a few versions ( using it in production ), but due
to various issues, consume lots of memory :/

> Source  : yawn-0-0.3.20120227svn561.fc18.src.rpm
> 
> I haven't checked whether these are simply to convert over to WSGI or 
> not.  Does anybody want to maintain mod_python?  If not, I'm going to 
> retire it.
> 
> Regards, Joe

-- 
Michael Scherer

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Intent to retire: mod_python

[Joe Orton]

mod_python upstream has been inactive for five years, since Graham 
Dumpleton went to work on mod_wsgi.  IMO it is long past time to retire 
mod_python in Fedora.  But the following packages still depend on it:

Source  : glump-0.9.11-10.fc17.src.rpm
Source  : koji-1.6.0-3.fc17.src.rpm
Source  : viewvc-1.1.13-1.fc17.src.rpm
Source  : yawn-0-0.3.20120227svn561.fc18.src.rpm

I haven't checked whether these are simply to convert over to WSGI or 
not.  Does anybody want to maintain mod_python?  If not, I'm going to 
retire it.

Regards, Joe
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 806922] perl-Socket-2.000-2 does not build in ARM Koji

[bugzilla]

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=806922

--- Comment #2 from Petr Pisar  2012-03-26 10:39:01 EDT ---
Upgrading gcc and rpm-build did not help. Running tests verbosely shows last 4
test are missing:

[...]
ok 24 - pack_sockaddr_in6->unpack_sockaddr_in6 scope_id
ok 25 - pack_sockaddr_in6->unpack_sockaddr_in6 flowinfo
ok 26 - sockaddr_in6 in list context unpacks
ok 27 - sockaddr_in6 in scalar context packs

ok 28 - sockaddr_un can handle abstract AF_UNIX paths
ok 29 - sockaddr_un abstract address length
ok 30 - sockaddr_in deprecated form doesn't warn without lexical warnings
ok 31 - sockaddr_in deprecated form warns with lexical warnings

-- 
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

gforth and gcc 4.7

[Adrian Reber]

Trying to build gforth with gcc 4.7 fails currently. The forth engine is
build but it fails its included tests. The problem is that every newline
the forth engine writes is replaced with 0x00 as seen in following diff:

 010: 6566 696e 6564 2047 4458 2020 594f 5520  efined GDX  YOU 
 020: 5348 4f55 4c44 2053 4545 2054 4845 2053  SHOULD SEE THE S
 030: 5441 4e44 4152 4420 4752 4150 4849 4320  TANDARD GRAPHIC 
-040: 4348 4152 4143 5445 5253 3a00 2021 2223  CHARACTERS:. !"#
 ^^ actual output
+040: 4348 4152 4143 5445 5253 3a0a 2021 2223  CHARACTERS:. !"#
 ^^ expected output
 050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123

Removing -O2 from the compiler commandline fixes it, but I have no idea
why this happens. Does anyone have an idea how this can be solved?

Adrian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Bruno Wolff III]

On Mon, Mar 26, 2012 at 10:07:45 -0400,
  Matthias Clasen  wrote:


The trick is to not build for rawhide ever, until after the stable
release is out, and instead rely on inheritance. Since building
everything twice is just a terrible waste of effort, and makes this
whole mass building thing even more of a torture. But, of course, this
only works if you get on the right track when doing the first build
after the fork - unfortunately, our forking setup makes it not easy to
avoid doing at least one accidental F18 build before you notice the new
branch...


If we really want to rely on this process, I think we should reconsider
having rawhide inherit from the previous release's (currently f17)
updates.

Currently it can take a while for fixes that are just in f17-updates-testing
to make it to rawhide. This is particular bad around freezes.

Another thing to note about not doing builds for rawhide, is that we don't
get early testing of build issues for things that are in rawhide but not
in branched.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Andrew Haley]

On 03/26/2012 03:09 PM, Andrew Haley wrote:
> I'd love to know how to do this.  I've never used iSCSI.

Sorry, I missed http://www.delorie.com/arm/trimslice/iscsi.html

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Andrew Haley]

On 03/23/2012 11:18 PM, DJ Delorie wrote:
> Sorry, I'm a big fan of iSCSI on trimslices.  The SATA interface is on
> USB but the gigE isn't, so network (iscsi) is about 3x faster than a
> local disk, if you have a big raid server on the other end.

I'd love to know how to do this.  I've never used iSCSI.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Matthias Clasen]

On Mon, 2012-03-26 at 11:58 +0100, Peter Robinson wrote:
> .
> 
> It would be nice if the rawhide stream was built at the same time as
> well as not doing so has the effect of people trying to work with
> rawhide as well get random failures and in the process of building
> F-17 and rawhide on ARM a non insignificant number of gnome packages
> have newer builds in F-16 than they do in both rawhide and F-17 that
> I've ended up having to fix.
> 

The trick is to not build for rawhide ever, until after the stable
release is out, and instead rely on inheritance. Since building
everything twice is just a terrible waste of effort, and makes this
whole mass building thing even more of a torture. But, of course, this
only works if you get on the right track when doing the first build
after the fork - unfortunately, our forking setup makes it not easy to
avoid doing at least one accidental F18 build before you notice the new
branch...

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Rex Dieter]

Richard Hughes wrote:

> At the moment the GNOME updates in Fedora are a bit of chaotic affair.
> They mostly work, but only because of people like mclasen who spend
> hours and hours building packages and putting everything together
> manually. For 3.3.92 I experimented doing a mega-update and trying to
> get all the 3.3.92 builds in one place, and working with kalev on a
> google spreadsheet to make sure everything was built in good time, and
> nothing was left behind.

the kde-sig has similar pain-points doing mass updates.  Having a list of 
pkgs to build (seems done on google docs in your case already, good), and 
having your own koji tag/target does seem to simplify matters a bunch.  Then 
it's relatively easy to compose a bodhi update from the output from:
koji list-tagged --latest f16-gnome
for example.

-- rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora 17 Beta Go/No-Go Meeting, Wednesday, March 28, @17:00 Eastern

[Robyn Bergeron]

Please join us on irc.freenode.net in #fedora-meeting-1 for this 
important meeting. Will the Beefy Miracle live up to the latter half of 
its name? Attend this meeting and find out! :)


Wednesday, March 28, 2012 @21:00 UTC (17:00 EDT/14:00 PDT)

"Before each public release Development, QA and Release Engineering meet 
to determine if the release criteria are met for a particular release. 
This meeting is called the Go/No-Go Meeting."


"Verifying that the Release criteria are met is the responsibility of 
the QA Team."


For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 17 Beta Blocker list:
http://fedoraproject.org/wiki/Current_Release_Blockers

Ongoing Beta RC test results can be seen here:
https://fedoraproject.org/wiki/Category:Fedora_17_Beta_RC_Test_Results

Cheers! (And do note that we will be in #fedora-meeting-1!)

-Robyn
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-Tie-RefHash-Weak/f17] Spec clean-up

[Paul Howarth]

Summary of changes:

  9c97ff7... Spec clean-up (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F16: Kernel bug with USB disks ?

[Caterpillar]

I filled a bugreport moths ago, but actually I cannot get the id number,
maybe later I can try again
Il giorno 26/mar/2012 15:05, "Terry Barnaby"  ha
scritto:

> Hi,
>
> I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
> problems with a MicroSD card connected to a USB card reader. This has
> been working fine until recently (at least in F14 on the same hardware).
>
> The problem is that "umount" does not appear to be working correctly.
> I have an ext3 file system on the card. I can mount it, and I can copy
> files to it. However when I use the "umount ..." command it returns
> instantly (should sync the files to the card). The system says the card
> is unmounted (at least it is not listed with mount, df etc).
>
> However if I run sync, there is a lot of disk activity to the card ...
>
> Also if I try and run "mkfs" it says the device in in use ...
> If I mount a blank card it lists the files present on the previous card ...
>
> This sounds like a nasty kernel bug ...
> Anyone else seen this ?
>
> Cheers
>
>
>
> Terry
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F16: Kernel bug with USB disks ?

[Terry Barnaby]

On 03/26/2012 02:05 PM, Terry Barnaby wrote:
> Hi,
> 
> I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
> problems with a MicroSD card connected to a USB card reader. This has
> been working fine until recently (at least in F14 on the same hardware).
> 
> The problem is that "umount" does not appear to be working correctly.
> I have an ext3 file system on the card. I can mount it, and I can copy
> files to it. However when I use the "umount ..." command it returns
> instantly (should sync the files to the card). The system says the card
> is unmounted (at least it is not listed with mount, df etc).
> 
> However if I run sync, there is a lot of disk activity to the card ...
> 
> Also if I try and run "mkfs" it says the device in in use ...
> If I mount a blank card it lists the files present on the previous card ...
> 
> This sounds like a nasty kernel bug ...
> Anyone else seen this ?
> 
> Cheers
> 
> 
> 
> Terry

Looks like kernel 3.2.9-2.fc16.i686.PAE is ok ...

Cheers


Terry
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F16: Kernel bug with USB disks ?

[Terry Barnaby]

Hi,

I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having
problems with a MicroSD card connected to a USB card reader. This has
been working fine until recently (at least in F14 on the same hardware).

The problem is that "umount" does not appear to be working correctly.
I have an ext3 file system on the card. I can mount it, and I can copy
files to it. However when I use the "umount ..." command it returns
instantly (should sync the files to the card). The system says the card
is unmounted (at least it is not listed with mount, df etc).

However if I run sync, there is a lot of disk activity to the card ...

Also if I try and run "mkfs" it says the device in in use ...
If I mount a blank card it lists the files present on the previous card ...

This sounds like a nasty kernel bug ...
Anyone else seen this ?

Cheers



Terry
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 806884] New: RPM2 can't be built with new rpm-4.10

[bugzilla]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.

Summary: RPM2 can't be built with new rpm-4.10

https://bugzilla.redhat.com/show_bug.cgi?id=806884

   Summary: RPM2 can't be built with new rpm-4.10
   Product: Fedora
   Version: rawhide
  Platform: Unspecified
OS/Version: Unspecified
Status: NEW
  Severity: unspecified
  Priority: unspecified
 Component: perl-RPM2
AssignedTo: mmasl...@redhat.com
ReportedBy: mmasl...@redhat.com
 QAContact: extras...@fedoraproject.org
CC: fedora-perl-devel-l...@redhat.com,
mmasl...@redhat.com, lkund...@v3.sk, ppi...@redhat.com
Classification: Fedora
  Story Points: ---
  Type: ---
Regression: ---
Mount Type: ---
 Documentation: ---


gcc -I/usr/lib64/perl5/CORE -DXS_VERSION="1.0" -DVERSION="1.0" -fPIC
-DRPM2_API=4009 -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe
-fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o lib/RPM2.o
lib/RPM2.c
lib/RPM2.xs: In function '_null_callback':
lib/RPM2.xs:74:3: error: 'rpmcliHashesCurrent' undeclared (first use in this
function)
lib/RPM2.xs:74:3: note: each undeclared identifier is reported only once for
each function it appears in
lib/RPM2.xs:85:3: error: 'rpmcliProgressTotal' undeclared (first use in this
function)
lib/RPM2.xs:86:3: error: 'rpmcliProgressCurrent' undeclared (first use in this
function)
lib/RPM2.xs:90:25: error: 'rpmcliPackagesTotal' undeclared (first use in this
function)
lib/RPM2.xs:36:6: warning: variable 'xx' set but not used
[-Wunused-but-set-variable]
lib/RPM2.c: In function 'XS_RPM2__C__PackageIterator__iterator_next':
lib/RPM2.c:621:9: warning: variable 'RETVAL' set but not used
[-Wunused-but-set-variable]
error building lib/RPM2.o from 'lib/RPM2.c' at
/usr/share/perl5/ExtUtils/CBuilder/Base.pm line 175.
error: Bad exit status from /var/tmp/rpm-tmp.okPYIr (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.okPYIr (%build)

-- 
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: Error: buildroot override already exists

[Ricardo Argüello]

On Sat, Mar 24, 2012 at 2:14 PM, Ricardo Argüello
 wrote:
> On Sat, Mar 24, 2012 at 11:18 AM, Jerry James  wrote:
>> On Sat, Mar 24, 2012 at 9:46 AM, Ricardo Argüello
>>  wrote:
>>> Hi,
>>>
>>> I need to do a buildroot override for
>>> jboss-connector-1.6-api-1.0.1-0.1.20120310git9dc9a5.fc17, in order to
>>> compile picketbox-4.0.6-5 in F17:
>>>
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=3929166
>>>
>>>
>>> But when I try to create that buildroot override, Bodhi gives me this error:
>>>
>>> Error: buildroot override for
>>> u'jboss-connector-1.6-api-1.0.1-0.1.20120310git9dc9a5.fc17' already
>>> exists
>>>
>>> The only override I have now is for 'infinispan'.
>>>
>>> Any ideas?
>>
>> I had this happen once, too.  Select the "Show expired overrides" link
>> on the upper right, and find the override for jboss-connector.  I
>> think packages are counted as expired overrides once they get pushed
>> to testing, or something like that.  I think the user interface leaves
>> a lot to be desired, as this is not intuitive behavior for us
>> packagers.
>
> Thanks for the tip. I updated the Expiration Date for the old override
> and I'm waiting to see if it works.

Thanks, it worked

-- 
Ricardo Argüello
rica...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed

[Jonathan Dieter]

On Mon, 2012-03-26 at 14:48 +0300, Panu Matilainen wrote:
> On 03/26/2012 02:30 PM, Jonathan Dieter wrote:
> > On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote:
> >> As a reminder, at least the following packages will now need a rebuild
> >> due to the soname bump:
> >>
> >> jdieter deltarpm
> >
> > Did I see that you took care of this one for me?
> 
> Doh... Sorry I forgot to remove that from the list. Deltarpm has indeed 
> been already rebuilt.

Thanks much!

Jonathan




signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Richard W.M. Jones]

On Mon, Mar 26, 2012 at 12:26:47PM +0200, Gerd Hoffmann wrote:
> Another possible way would be to boot directly from iscsi like you can
> do on x86 with an sanboot-enabled iPXE rom.  I have no idea whenever
> u-boot can handle that though.

No.  The U-boot supplied on the Trim-Slice is very simplistic in the
way it boots: It looks for a compiled script called "boot.scr" in four
possible local storage locations.  The script can then boot over the
network, but you've got to have the script in a local location in the
first place.

http://www.trimslice.com/wiki/index.php/Trim-Slice_U-Boot

[You could also patch U-boot.  It's apparently stored in some
on-motherboard serial flash memory.]

Which leads me to a rant about ARM.  G RANT!!  I didn't think I'd
ever love the BIOS, but compared to the alternatives (UEFI and a
million different ARM bootloaders) it's simple and effective.

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: Managing the GNOME updates in Fedora

[Richard Hughes]

On 26 March 2012 11:58, Peter Robinson  wrote:
> It would be nice if the rawhide stream was built at the same time as
> well as not doing so has the effect of people trying to work with
> rawhide as well get random failures and in the process of building
> F-17 and rawhide on ARM a non insignificant number of gnome packages
> have newer builds in F-16 than they do in both rawhide and F-17 that
> I've ended up having to fix.

Yes, this is a valid critisism. I'm hoping to write a tool to
automatically update GNOME builds in a stable release and in rawhide
(that watches ftp-release list), rather than having to do it all
manually.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed

[Panu Matilainen]

On 03/26/2012 02:30 PM, Jonathan Dieter wrote:

On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote:

As a reminder, at least the following packages will now need a rebuild
due to the soname bump:

jdieter deltarpm


Did I see that you took care of this one for me?


Doh... Sorry I forgot to remove that from the list. Deltarpm has indeed 
been already rebuilt.


- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-17 Branched report: 20120326 changes

[Fedora Branched Report]

Compose started at Mon Mar 26 08:15:04 UTC 2012

Broken deps for x86_64
--
[HippoDraw]
HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray
HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray
HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri
[alexandria]
alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8
[catfish]
catfish-engines-0.3.2-4.fc17.1.noarch requires pinot
[comoonics-cdsl-py]
comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py
[comoonics-cluster-py]
comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py
[contextkit]
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
[converseen]
converseen-0.4.9-3.fc17.x86_64 requires libMagickWand.so.5()(64bit)
converseen-0.4.9-3.fc17.x86_64 requires libMagickCore.so.5()(64bit)
converseen-0.4.9-3.fc17.x86_64 requires libMagick++.so.5()(64bit)
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[eruby]
eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit)
eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8
eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8
eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8
eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
[gearmand]
gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit)
gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit)
gearmand-0.23-2.fc17.x86_64 requires 
libboost_program_options-mt.so.1.47.0()(64bit)
[genius]
genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit)
gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit)
[gnome-phone-manager]
gnome-phone-manager-0.66-9.fc17.x86_64 requires 
libgnome-bluetooth.so.9()(64bit)
[gnome-user-share]
gnome-user-share-3.0.1-3.fc17.x86_64 requires 
libgnome-bluetooth.so.9()(64bit)
[gorm]
gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-gui.so.0.20()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-base.so.1.23()(64bit)
[gscribble]
gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2
[i3]
i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit)
[ibus-fep]
ibus-fep-1.4.3-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit)
[ibus-gucharmap]
ibus-gucharmap-1.4.0-3.fc17.x86_64 requires libibus-1.0.so.0()(64bit)
[ibus-panel-extensions]
ibus-panel-extensions-1.4.99.20111207-1.fc17.i686 requires 
libibus-1.0.so.0
ibus-panel-extensions-1.4.99.20111207-1.fc17.x86_64 requires 
libibus-1.0.so.0()(64bit)
[ibus-unikey]
ibus-unikey-0.6.1-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit)
[jboss-jaxrpc-1.1-api]
jboss-jaxrpc-1.1-api-1.0.1-0.1.20120309gita3c227.fc17.noarch requires 
jboss-servlet-3.0-api
[kazehakase]
kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires ruby(abi) = 
0:1.8
kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires 
libruby.so.1.8()(64bit)
[libprelude]
1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires ruby(abi) = 0:1.8
1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires libruby.so.1.8()(64bit)
[libteam]
libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-route-3.so.199
libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-nf-3.so.199
libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-genl-3.so.199
libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-cli-3.so.199
libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-3.so.199
libteam-0.1-3.20120130gitb5cf2a8.fc17.x86_64 require

[perl-RPM-VersionCompare] Rebuild against RPM 4.10

[Petr Pisar]

commit b16cf593384c95133c8c0383c6be9bcc42524a70
Author: Petr Písař 
Date:   Mon Mar 26 13:36:03 2012 +0200

Rebuild against RPM 4.10

 perl-RPM-VersionCompare.spec |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-RPM-VersionCompare.spec b/perl-RPM-VersionCompare.spec
index e0b7dff..db02674 100644
--- a/perl-RPM-VersionCompare.spec
+++ b/perl-RPM-VersionCompare.spec
@@ -1,6 +1,6 @@
 Name:   perl-RPM-VersionCompare
 Version:0.1.1
-Release:2%{?dist}
+Release:3%{?dist}
 Summary:Compare RPM version strings
 License:GPLv3+
 Group:  Development/Libraries
@@ -50,6 +50,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 26 2012 Petr Pisar  - 0.1.1-3
+- Rebuild against RPM 4.10
+
 * Fri Jan 13 2012 Fedora Release Engineering  
- 0.1.1-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
 
--
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

Plan for tomorrow's FESCo meeting (2012-03-26 at 17UTC)

[Marcela Mašláňová]

Following is the list of topics that will be discussed in the FESCo
meeting today at 17:00UTC (1:00pm EST, 19:00 CEST) in #fedora-meeting on
irc.freenode.net.

Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =
#topic #699 Proposal to remove the package "tzdata" from Critical Path
.fesco 699

#830 F18 Feature: ARM as Primary Arch -- 
https://fedoraproject.org/wiki/Features/FedoraARM

.fesco 830

= New business =
#829 New sponsor request: Pavel Alexeev (hubbitus)
.fesco 829

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-String-ToIdentifier-EN] update to 0.07

[Iain Arnell]

commit 24b6cb7d7cb3b49419abb559038e59c07f5d0f32
Author: Iain Arnell 
Date:   Mon Mar 26 05:34:48 2012 -0600

update to 0.07

 .gitignore   |1 +
 perl-String-ToIdentifier-EN.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a6ccaef..1a7da9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /String-ToIdentifier-EN-0.06.tar.gz
+/String-ToIdentifier-EN-0.07.tar.gz
diff --git a/perl-String-ToIdentifier-EN.spec b/perl-String-ToIdentifier-EN.spec
index 64e7ff8..cf51cb7 100644
--- a/perl-String-ToIdentifier-EN.spec
+++ b/perl-String-ToIdentifier-EN.spec
@@ -1,5 +1,5 @@
 Name:   perl-String-ToIdentifier-EN
-Version:0.06
+Version:0.07
 Release:1%{?dist}
 Summary:Convert Strings to English Program Identifiers
 License:GPL+ or Artistic
@@ -48,5 +48,8 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 26 2012 Iain Arnell  0.07-1
+- update to latest upstream version
+
 * Fri Jan 13 2012 Iain Arnell  0.06-1
 - Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index 4968e66..41df8c1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-262602c5b29b3a62fbf8ebc005bfebee  String-ToIdentifier-EN-0.06.tar.gz
+fb99f7b8bb574bf650563e6e1fd198a2  String-ToIdentifier-EN-0.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 String-ToIdentifier-EN-0.07.tar.gz uploaded to lookaside cache by iarnell

[Iain Arnell]

A file has been added to the lookaside cache for perl-String-ToIdentifier-EN:

fb99f7b8bb574bf650563e6e1fd198a2  String-ToIdentifier-EN-0.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

Broken dependencies: perl-Language-Prolog-Yaswi

[buildsys]

perl-Language-Prolog-Yaswi has broken dependencies in the F-17 tree:
On x86_64:
perl-Language-Prolog-Yaswi-0.19-1.fc17.x86_64 requires 
libswipl.so.5.10.5()(64bit)
On i386:
perl-Language-Prolog-Yaswi-0.19-1.fc17.i686 requires libswipl.so.5.10.5
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed

[Jonathan Dieter]

On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote:
> As a reminder, at least the following packages will now need a rebuild 
> due to the soname bump:
> 
> jdieter deltarpm

Did I see that you took care of this one for me?

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed

[Panu Matilainen]

Took a bit longer to get there (some initial issues with the alpha 
needed fixing first), but rpm 4.9.90 has been in the rawhide buildroots 
now for a few hours with no apparent issues. Knock wood.


As a reminder, at least the following packages will now need a rebuild 
due to the soname bump:


Owner   Package


abrt-team   abrt
abrt-team   libreport
anaconda-maint  anaconda
ensclibextractor
fchesystemtap
ivaxer  opensips
jancratochvil   gdb
jcollie asterisk
jdieter deltarpm
jsafranenet-snmp
kklic   libsolv
lkundrakovaldi
mlichvarrpmreaper
mmaslanoperl-RPM2
mprivoznlibvirt-snmp
peter   openser
ppisar  perl-RPM-VersionCompare
pvrabec openscap
pvrabec sectool
rhughes PackageKit
rhughes zif
rmeggins389-ds-base
rohara  foghorn
sharkcz openhpi-subagent

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Managing the GNOME updates in Fedora

[Peter Robinson]

On Mon, Mar 26, 2012 at 11:52 AM, Richard Hughes  wrote:
> At the moment the GNOME updates in Fedora are a bit of chaotic affair.
> They mostly work, but only because of people like mclasen who spend
> hours and hours building packages and putting everything together
> manually. For 3.3.92 I experimented doing a mega-update and trying to
> get all the 3.3.92 builds in one place, and working with kalev on a
> google spreadsheet to make sure everything was built in good time, and
> nothing was left behind.
>
> For the GNOME 3.4.0 release, I'm asking people to copy this pattern,
> and try to get all the builds into *one* update rather than 90% of the
> builds in one mega-update and then 10% in random updates that other
> people have filed. If this works, I'm intending to do the 3.4.1 update
> as one update as well.
>
> So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92
> upstream release and is about to have a 3.4.0 release, please build
> the package like normal, but don't file an update. Instead add the
> build ID to 
> https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc
> and then I'll pick up the build for the mega update.
>
> Hopefully this makes the updates system easier to QA, as GNOME is more
> and more interconnected, and it' just not possible to QA updates when
> you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version
> of gnome-screenshot.

It would be nice if the rawhide stream was built at the same time as
well as not doing so has the effect of people trying to work with
rawhide as well get random failures and in the process of building
F-17 and rawhide on ARM a non insignificant number of gnome packages
have newer builds in F-16 than they do in both rawhide and F-17 that
I've ended up having to fix.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Managing the GNOME updates in Fedora

[Richard Hughes]

At the moment the GNOME updates in Fedora are a bit of chaotic affair.
They mostly work, but only because of people like mclasen who spend
hours and hours building packages and putting everything together
manually. For 3.3.92 I experimented doing a mega-update and trying to
get all the 3.3.92 builds in one place, and working with kalev on a
google spreadsheet to make sure everything was built in good time, and
nothing was left behind.

For the GNOME 3.4.0 release, I'm asking people to copy this pattern,
and try to get all the builds into *one* update rather than 90% of the
builds in one mega-update and then 10% in random updates that other
people have filed. If this works, I'm intending to do the 3.4.1 update
as one update as well.

So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92
upstream release and is about to have a 3.4.0 release, please build
the package like normal, but don't file an update. Instead add the
build ID to 
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc
and then I'll pick up the build for the mega update.

Hopefully this makes the updates system easier to QA, as GNOME is more
and more interconnected, and it' just not possible to QA updates when
you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version
of gnome-screenshot.

Thanks,

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases

[Kalev Lember]

On 03/26/2012 01:57 AM, Oron Peled wrote:
> On Sunday, 25 בMarch 2012 20:01:37 Kalev Lember wrote:
>> For the past 17 months, each rawhide report has had broken dh-make deps.
>> The package was imported 21 Oct 2010 depending on a non-existing
>> "debhelper" package and has been broken ever since.
> 
> Regretfully, you are correct. What's not so clear is how can we *fix*
> this instead of abolishing all this package chain:

Wonderful. Fixing the package sounds much better than just removing it.

[snip]
> * As I mentioned on some of these bug-reports, I'm willing to maintain
> all these packages (see below).
> 
> However, I wasn't the one submitting the BR, nor the reviewer.
> What process should I follow to make this happen?

Have you tried emailing Jeroen to see if he can let you take over
dh-make / approve you as a co-maintainer? If he's not replying, I guess
you could try the
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers

Regarding unfinished package review tickets, just open new ones under
your own name and close the old ones as a duplicate, as per
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews . Then
you can continue working on importing the rest of the deps.

Good luck with this!

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Gerd Hoffmann]

On 03/26/12 11:00, Peter Robinson wrote:
> On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann  wrote:
>>  Hi,
>>
 they use a rather scary looking pile of development boards with very
 poor I/O.
>>>
>>> Buy a trimslice and run it with iSCSI.  It's a very clean package, and
>>> I can get 80 MB/sec to my file server's disks.  That is neither
>>> "scary" nor "poor I/O".
>>>
>>> http://www.delorie.com/arm/trimslice/iscsi.html
>>
>> Running the thing on iscsi is a good idea, given that local storage is
>> linked up via usb while gb ethernet is hooked up via pcie.
>>
>> Any particular reason why you boot the thing via tftp?  I'd expect just
>> having /boot on the sd card (which you need for boot anyway) is easier,
>> especially when it comes to kernel updates.
> 
> Everything needed to boot goes into the initrd now days so you don't
> even need the SD card.

Check the URL above.  The setup described there uses a sdcard with a
u-boot script, which kicks off the tftp boot.

I don't see the point in using tftp, you can place kernel+initrd
directly at the sdcard if you have one anyway.

Another possible way would be to boot directly from iscsi like you can
do on x86 with an sanboot-enabled iPXE rom.  I have no idea whenever
u-boot can handle that though.

cheers,
  Gerd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F17, firewalld, avahi

[Thomas Woerner]

On 03/24/2012 10:09 PM, Chris Murphy wrote:

Fedora-17-Beta-x86_64-Live-Desktop.iso

http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. "The 
configuration tool firewall-config is the main configuration tool for the firewall 
daemon."

But I'm not finding firewall-config. So unlike with iptables, where I had a GUI 
Firewall app, now I no longer have an easy or obvious way of altering the 
default behavior and I'm in effect stuck without ssh.

Seems the missing firewall-config is probably an oversight, and it needs to be 
included on LiveCD installs, and default DVD installs as well.


Chris Murphy


Please use firewall-cmd for now.

Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F17, firewalld, avahi

[Thomas Woerner]

On 03/24/2012 10:09 PM, Chris Murphy wrote:

Fedora-17-Beta-x86_64-Live-Desktop.iso

http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. "The 
configuration tool firewall-config is the main configuration tool for the firewall 
daemon."

But I'm not finding firewall-config. So unlike with iptables, where I had a GUI 
Firewall app, now I no longer have an easy or obvious way of altering the 
default behavior and I'm in effect stuck without ssh.

Seems the missing firewall-config is probably an oversight, and it needs to be 
included on LiveCD installs, and default DVD installs as well.


Chris Murphy

firewalld-config is not finished, yet. I am working on it.

Thomas
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fan switch on permanently

[Antonio Trande]

2012/3/26 Jan Synacek 

> On 03/24/12 at 01:42pm, Antonio Trande wrote:
> > Hello.
> >
> > With my Acer Aspire 6930G happen that after an indefinite time, the fan
> > starts to work permanently regardless of temperature.
> > In this moment,  according to nvclock [1] the GPU temp is 43°C and the
> fan
> > is on; strangely because it starts to work over 47°C all along.
> >
> > If i format the BIOS, the fan goes back to work only over 47°C.
> > Infos: [2]
> >
> > I don't know if this issue depends on Fedora, but i wish understand its
> > cause.
> > Had someone a similar experience o an idea of what is it ?
> >
>
> Are you by any chance using nvidia binary drivers? I have a similarly
> sounding
> problem on my home laptop using nvidia 8400m and binary drivers. It's
> described
> here [1]. While it may not be exactly your problem, maybe it can provide
> some
> pointers/hints.
>
> [1]
> http://www.nvnews.net/vbulletin/showthread.php?s=9f6f6c4f2dcd351cecc8a7e890126229&t=148976
>
> Regards,
> --
> Jan Synacek
> BaseOS team Brno
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

No, i use only nouveau driver with Fedora  (except Windows).

-- 
*Antonio Trande
"Fedora Ambassador"

**mail*: mailto:sagit...@fedoraproject.org 
*Homepage*: http://www.fedora-os.org
*Sip Address* : sip:sagitter AT ekiga.net
*Jabber * :sagitter AT jabber.org
*GPG Key: 19E6DF27*
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)

[Richard W.M. Jones]

On Mon, Mar 26, 2012 at 12:57:44AM +0200, Oron Peled wrote:
>  * IMO, it's important to have Debian packaging tools for Fedora so it
>can be used as a more complete development platform:
>- Currently, there's no problem building rpm's and yum repos on Debian
>  as a development platform, but not the other way around
> 
>- This means that a Debian/Ubuntu workstation can build both .deb and RPM
>  packages, and we cannot use Fedora for a similar role.

Is this really true?  What happens if, say, your program depends on
PCRE, which has different sonames on Debian/Ubuntu and Fedora (for
essentially the same library):

fedora$ rpm -qf /usr/lib64/libpcre.so.0
pcre-8.21-2.fc17.1.x86_64

ubuntu$ dpkg -S /lib/x86_64-linux-gnu/libpcre.so.3.12.1
libpcre3: /lib/x86_64-linux-gnu/libpcre.so.3.12.1
ubuntu$ dpkg -l libpcre3-dev
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  libpcre3-dev   8.12-3ubuntu2  Perl 5 Compatible Regular Expression Library

I don't understand how a binary built on one platform could be copied
across to the other and work.

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: Booting Fedora from LVM with grub2

[Richard W.M. Jones]

On Sun, Mar 25, 2012 at 11:41:18PM +0200, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > Perhaps, like Ubuntu's installer, the graphical part of Anaconda
> > should concentrate on doing the simple stuff, and leave everything
> > else to kickstart non-graphical installations.
> 
> I don't think that would be a good idea, at all.

Umm ... okay.

Any particular reason?  Any other plans to make the current situation
better?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Peter Robinson]

On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann  wrote:
>  Hi,
>
>>> they use a rather scary looking pile of development boards with very
>>> poor I/O.
>>
>> Buy a trimslice and run it with iSCSI.  It's a very clean package, and
>> I can get 80 MB/sec to my file server's disks.  That is neither
>> "scary" nor "poor I/O".
>>
>> http://www.delorie.com/arm/trimslice/iscsi.html
>
> Running the thing on iscsi is a good idea, given that local storage is
> linked up via usb while gb ethernet is hooked up via pcie.
>
> Any particular reason why you boot the thing via tftp?  I'd expect just
> having /boot on the sd card (which you need for boot anyway) is easier,
> especially when it comes to kernel updates.

Everything needed to boot goes into the initrd now days so you don't
even need the SD card.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ARM as a primary architecture

[Gerd Hoffmann]

  Hi,

>> they use a rather scary looking pile of development boards with very
>> poor I/O.
> 
> Buy a trimslice and run it with iSCSI.  It's a very clean package, and
> I can get 80 MB/sec to my file server's disks.  That is neither
> "scary" nor "poor I/O".
> 
> http://www.delorie.com/arm/trimslice/iscsi.html

Running the thing on iscsi is a good idea, given that local storage is
linked up via usb while gb ethernet is hooked up via pcie.

Any particular reason why you boot the thing via tftp?  I'd expect just
having /boot on the sd card (which you need for boot anyway) is easier,
especially when it comes to kernel updates.

cheers,
  Gerd
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Depcheck failed?

[Kamil Paral]

> On Fri, Mar 23, 2012 at 1:25 PM, Jon Ciesla 
> wrote:
> > On Fri, Mar 23, 2012 at 1:23 PM, Richard Shaw
> >  wrote:
> >>
> >> Darn... I was hoping that wouldn't bite me :) I'm assuming I can
> >> ignore the error though? Or does it need to be fixed?
> >
> > Fix.  :(
> 
> Which means I really need to bump the release in rawhide, right?
> There's nothing I can do to the f17 package that would cause it to be
> < the f18 package, unless killing the update is sufficient?

Hey, have a look here:
https://fedoraproject.org/wiki/AutoQA_tests/Upgradepath#Fixing_the_failures

which links here:
https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches

This way you _can_ update just a single branch. Use '.fc17.1' suffix. Of course 
you must know whether you want to do this (whether the fix is really not needed 
in rawhide). And since pushing to rawhide is easy... your choice.

PS: This test is called 'upgradepath', not 'depcheck'. See the headline in the 
results document.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: memtest from F17 beta DVD images

[Jaroslav Skarvada]

- Original Message -
> I booted the F17 beta ISO (x86_64, if it matters) on two laptops and
> tried the provided memtest. In both cases it reported insane amounts
> of
> errors in test 7 after running successfully through tests 1..6. The
> reported error addresses are in the 120 MB area.
> 
> I checked that when memtest is configured to go directly to test 7
> the
> errors appear right away.
> 
> I have not had the chance to retest with older images but the chance
> that both laptops independently developed RAM problems in the same
> area
> seems small. I'll do more tests and file a Bugzilla report if it
> checks out.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

It seems to be related to gcc 4.7 update:
https://bugzilla.redhat.com/show_bug.cgi?id=805813

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Django 1.4 in F17?

[Matthias Runge]

On 25/03/12 13:54, Jos Vos wrote:
> FWIW:
> Django 1.4 has now been officially released.
> 
> I submitted an upgrade request in bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=806614
> 
yes, thank you. We're aware of it. Please refer also to bug
https://bugzilla.redhat.com/show_bug.cgi?id=806463

-- 
Matthias Runge 
   
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel