Re: More unhelpful update descriptions

[drago01]

On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal  wrote:
> On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten  wrote:
>> Not sure if it makes any sense but maybe could we have something like
>> "freeze tag changes until desc is better".
>>
>> I propose this because testers will not _really_ want to -1 karma, and
>> as a maintainer it might be a bit hard, but with a good reminder like
>> "not pushed to stable until desc is better" I would have made less
>> mistakes
>>
>> yes not being reminded is not an excuse and such proposal would not save
>> time, still I believe it could help more than hurt
>
>
> There is already a perfect example of this.
>
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19

This is also a perfect example of useless "does not fix bug x" karma.
If it is not *worse* then the previous package there is no reason to
give it negative karma.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Johannes Lips]

On Wed, Jul 3, 2013 at 9:32 AM, drago01  wrote:

> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal  wrote:
> > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten  wrote:
> >> Not sure if it makes any sense but maybe could we have something like
> >> "freeze tag changes until desc is better".
> >>
> >> I propose this because testers will not _really_ want to -1 karma, and
> >> as a maintainer it might be a bit hard, but with a good reminder like
> >> "not pushed to stable until desc is better" I would have made less
> >> mistakes
> >>
> >> yes not being reminded is not an excuse and such proposal would not save
> >> time, still I believe it could help more than hurt
> >
> >
> > There is already a perfect example of this.
> >
> >
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
>
> This is also a perfect example of useless "does not fix bug x" karma.
> If it is not *worse* then the previous package there is no reason to
> give it negative karma.
>
If it doesn't fix the bugs, the update should fix, it is appropriate to
give negative karma. Otherwise the bugs would be closed, when it becomes
stable, but won't be fixed.

Johannes

> --
> 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: More unhelpful update descriptions

[Michael Scherer]

Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
> 
> 
> 
> On Wed, Jul 3, 2013 at 9:32 AM, drago01  wrote:
> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
>  wrote:
> > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
>  wrote:
> >> Not sure if it makes any sense but maybe could we have
> something like
> >> "freeze tag changes until desc is better".
> >>
> >> I propose this because testers will not _really_ want to -1
> karma, and
> >> as a maintainer it might be a bit hard, but with a good
> reminder like
> >> "not pushed to stable until desc is better" I would have
> made less
> >> mistakes
> >>
> >> yes not being reminded is not an excuse and such proposal
> would not save
> >> time, still I believe it could help more than hurt
> >
> >
> > There is already a perfect example of this.
> >
> >
> 
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
> 
> 
> This is also a perfect example of useless "does not fix bug x"
> karma.
> If it is not *worse* then the previous package there is no
> reason to
> give it negative karma.
> If it doesn't fix the bugs, the update should fix, it is appropriate
> to give negative karma. Otherwise the bugs would be closed, when it
> becomes stable, but won't be fixed.

That's not what the guidelines say :

https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to


-- 
Michael Scherer

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

Re: More unhelpful update descriptions

[Johannes Lips]

On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer  wrote:

> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
> >
> >
> >
> > On Wed, Jul 3, 2013 at 9:32 AM, drago01  wrote:
> > On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
> >  wrote:
> > > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
> >  wrote:
> > >> Not sure if it makes any sense but maybe could we have
> > something like
> > >> "freeze tag changes until desc is better".
> > >>
> > >> I propose this because testers will not _really_ want to -1
> > karma, and
> > >> as a maintainer it might be a bit hard, but with a good
> > reminder like
> > >> "not pushed to stable until desc is better" I would have
> > made less
> > >> mistakes
> > >>
> > >> yes not being reminded is not an excuse and such proposal
> > would not save
> > >> time, still I believe it could help more than hurt
> > >
> > >
> > > There is already a perfect example of this.
> > >
> > >
> >
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
> >
> >
> > This is also a perfect example of useless "does not fix bug x"
> > karma.
> > If it is not *worse* then the previous package there is no
> > reason to
> > give it negative karma.
> > If it doesn't fix the bugs, the update should fix, it is appropriate
> > to give negative karma. Otherwise the bugs would be closed, when it
> > becomes stable, but won't be fixed.
>
> That's not what the guidelines say :
>
>
> https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to
>
Could be, but if the still broken bugs are going to be closed, when the
update becomes stable, doesn't really help, or? Given that this is enabled
in the update.


>
>
> --
> Michael Scherer
>
> --
> 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: More unhelpful update descriptions

[Michael Scherer]

Le mercredi 03 juillet 2013 à 09:54 +0200, Johannes Lips a écrit :
> 
> 
> 
> On Wed, Jul 3, 2013 at 9:47 AM, Michael Scherer  wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a
> écrit :
> >
> >
> >
> > On Wed, Jul 3, 2013 at 9:32 AM, drago01 
> wrote:
> > On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
> >  wrote:
> > > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
> >  wrote:
> > >> Not sure if it makes any sense but maybe could we
> have
> > something like
> > >> "freeze tag changes until desc is better".
> > >>
> > >> I propose this because testers will not _really_
> want to -1
> > karma, and
> > >> as a maintainer it might be a bit hard, but with
> a good
> > reminder like
> > >> "not pushed to stable until desc is better" I
> would have
> > made less
> > >> mistakes
> > >>
> > >> yes not being reminded is not an excuse and such
> proposal
> > would not save
> > >> time, still I believe it could help more than
> hurt
> > >
> > >
> > > There is already a perfect example of this.
> > >
> > >
> >
> 
> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
> >
> >
> > This is also a perfect example of useless "does not
> fix bug x"
> > karma.
> > If it is not *worse* then the previous package there
> is no
> > reason to
> > give it negative karma.
> > If it doesn't fix the bugs, the update should fix, it is
> appropriate
> > to give negative karma. Otherwise the bugs would be closed,
> when it
> > becomes stable, but won't be fixed.
> 
> 
> That's not what the guidelines say :
> 
> 
> https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to
> Could be, but if the still broken bugs are going to be closed, when
> the update becomes stable, doesn't really help, or? Given that this is
> enabled in the update.

Then we could decide on :
- better process, ie "if you happen to notice a bug is not fixed by
update, please reopen it"
- better tooling, ie a way to say "do not close this bug" to bodhi.
Either a message in bodhi, or something on bugzilla side.


-- 
Michael Scherer

-- 
Michael Scherer

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

abi-compliance-checker and abi-dumper to track API/ABI

[Andrey Ponomarenko]

Hi,

There is a new simple way to track changes in API/ABI of system 
libraries using a new ABI dumper [1] tool. Just compile two library 
versions with -g additional option (to contain DWARF debug info) or take 
them from the appropriate debug packages and create ABI dumps of both:


  abi-dumper OLD.so -o ABI-0.dump -lver 0
  abi-dumper NEW.so -o ABI-1.dump -lver 1

Then compare these ABI dumps by the ACC [2] tool:

  abi-compliance-checker -l NAME -old ABI-0.dump -new ABI-1.dump

So it is no need to create any input XML descriptors and compile header 
files of a library anymore.


However, this approach has some drawbacks. Perhaps the main drawback is 
the inability to perform some compatibility checks. For example, there 
is no possibility to check for changes in the values of the constants 
(defines as well as const global data), since their values are inlined 
at compile time, and not presented in the debug information of the 
binary ELF-object. In general, there can be checked about 98% of all 
compatibility rules.


Another disadvantage is the long time required to analyse large objects 
bigger than 50 mb. But one can use the dwz utility to compress input 
debug-info.


Enjoy!

[1] https://github.com/lvc/abi-dumper
[2] https://github.com/lvc/abi-compliance-checker

--
Andrey Ponomarenko, ROSA Lab.

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

Re: fedup performance

[Panu Matilainen]

On 07/03/2013 09:59 AM, Panu Matilainen wrote:

On 07/03/2013 07:42 AM, Alex G. wrote:

On 07/02/2013 08:28 PM, Neal Becker wrote:

Not d/l speed related.  I just want to share.  I update a very fast 8
core
server, with a conventional disk drive.  Took 2-3 hours, not
including d/l.

I update my laptop which has an ssd (and MORE packages).  Took 10-15
minutes.


I think this might simply have to do with rpm running ldconfig (a very
disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.

DISCLAIMER: I may be very wrong. Please don't quote me on this.


ldconfig gets run a lot yes, but its also really fast these days.
fdatasync() which gets called even more (a lot more at that) seems like
a more likely painpoint on upgrades.


Oh and here are some numbers for your entertainment. This is a 185 core 
package install to empty chroot on my laptop with a conventional disk, 
with the two worst script-offenders (kernel and selinux-policy-targeted 
have) taken out of the picture as they'd very much dominate the running 
time on a set this small:


fdatasync, no scripts   1m16s
fdatasync, scripts  1m29s

no fdatasync, no scripts  16s
no fdatasync, scripts 25s

When fdatasync() is disabled (on initial install where there's no data 
to lose), sure all the scripts start taking a considerable portion of 
the running time. But for normal operation (such as upgrades), 
fdatasync() is where the vast majority of time gets spent.


Of course on real-world upgrades there are many many more things at play 
than in the simple test-case above, but to improve performance you need 
to figure out where the time is getting spent, guessing gets you nowhere.


- Panu -

- Panu -

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

Re: fedup performance

[Alex G.]

On 07/03/2013 03:23 AM, Panu Matilainen wrote:
> On 07/03/2013 09:59 AM, Panu Matilainen wrote:
>> On 07/03/2013 07:42 AM, Alex G. wrote:
>>> On 07/02/2013 08:28 PM, Neal Becker wrote:
 Not d/l speed related.  I just want to share.  I update a very fast 8
 core
 server, with a conventional disk drive.  Took 2-3 hours, not
 including d/l.

 I update my laptop which has an ssd (and MORE packages).  Took 10-15
 minutes.

>>> I think this might simply have to do with rpm running ldconfig (a very
>>> disk IO expensive operation) for a large number of packages. I'm not
>>> sure yum/rpm has deferred ldconfig processing.
>>>
>>> DISCLAIMER: I may be very wrong. Please don't quote me on this.
>>
>> ldconfig gets run a lot yes, but its also really fast these days.
>> fdatasync() which gets called even more (a lot more at that) seems like
>> a more likely painpoint on upgrades.
> 
> Oh and here are some numbers for your entertainment. This is a 185 core
> package install to empty chroot on my laptop with a conventional disk,
> with the two worst script-offenders (kernel and selinux-policy-targeted
> have) taken out of the picture as they'd very much dominate the running
> time on a set this small:
> 
> fdatasync, no scripts   1m16s
> fdatasync, scripts  1m29s
> 
> no fdatasync, no scripts  16s
> no fdatasync, scripts 25s
> 
> When fdatasync() is disabled (on initial install where there's no data
> to lose), sure all the scripts start taking a considerable portion of
> the running time. But for normal operation (such as upgrades),
> fdatasync() is where the vast majority of time gets spent.
> 
> Of course on real-world upgrades there are many many more things at play
> than in the simple test-case above, but to improve performance you need
> to figure out where the time is getting spent, guessing gets you nowhere.
> 
Guessing gets other people to research the matter. A great way to get
others to work for you for free. :p

Alex
> - Panu -
> 
> - Panu -
> 

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

Re: fedup performance

[Panu Matilainen]

On 07/03/2013 11:29 AM, Alex G. wrote:

On 07/03/2013 03:23 AM, Panu Matilainen wrote:

On 07/03/2013 09:59 AM, Panu Matilainen wrote:

On 07/03/2013 07:42 AM, Alex G. wrote:

On 07/02/2013 08:28 PM, Neal Becker wrote:

Not d/l speed related.  I just want to share.  I update a very fast 8
core
server, with a conventional disk drive.  Took 2-3 hours, not
including d/l.

I update my laptop which has an ssd (and MORE packages).  Took 10-15
minutes.


I think this might simply have to do with rpm running ldconfig (a very
disk IO expensive operation) for a large number of packages. I'm not
sure yum/rpm has deferred ldconfig processing.

DISCLAIMER: I may be very wrong. Please don't quote me on this.


ldconfig gets run a lot yes, but its also really fast these days.
fdatasync() which gets called even more (a lot more at that) seems like
a more likely painpoint on upgrades.


Oh and here are some numbers for your entertainment. This is a 185 core
package install to empty chroot on my laptop with a conventional disk,
with the two worst script-offenders (kernel and selinux-policy-targeted
have) taken out of the picture as they'd very much dominate the running
time on a set this small:

fdatasync, no scripts   1m16s
fdatasync, scripts  1m29s

no fdatasync, no scripts  16s
no fdatasync, scripts 25s

When fdatasync() is disabled (on initial install where there's no data
to lose), sure all the scripts start taking a considerable portion of
the running time. But for normal operation (such as upgrades),
fdatasync() is where the vast majority of time gets spent.

Of course on real-world upgrades there are many many more things at play
than in the simple test-case above, but to improve performance you need
to figure out where the time is getting spent, guessing gets you nowhere.


Guessing gets other people to research the matter. A great way to get
others to work for you for free. :p


Sometimes maybe, but it can also be a great way to irritate people who 
have done their research a long time ago.


- Panu -

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

Re: More unhelpful update descriptions

[Ian Malone]

On 3 July 2013 08:47, Michael Scherer  wrote:
> Le mercredi 03 juillet 2013 à 09:44 +0200, Johannes Lips a écrit :
>>
>>
>>
>> On Wed, Jul 3, 2013 at 9:32 AM, drago01  wrote:
>> On Mon, Jul 1, 2013 at 11:54 PM, Dan Mashal
>>  wrote:
>> > On Mon, Jul 1, 2013 at 2:52 PM, Pierre-Yves Luyten
>>  wrote:
>> >> Not sure if it makes any sense but maybe could we have
>> something like
>> >> "freeze tag changes until desc is better".
>> >>
>> >> I propose this because testers will not _really_ want to -1
>> karma, and
>> >> as a maintainer it might be a bit hard, but with a good
>> reminder like
>> >> "not pushed to stable until desc is better" I would have
>> made less
>> >> mistakes
>> >>
>> >> yes not being reminded is not an excuse and such proposal
>> would not save
>> >> time, still I believe it could help more than hurt
>> >
>> >
>> > There is already a perfect example of this.
>> >
>> >
>> 
>> https://admin.fedoraproject.org/updates/FEDORA-2013-11846/selinux-policy-3.12.1-57.fc19
>>
>>
>> This is also a perfect example of useless "does not fix bug x"
>> karma.
>> If it is not *worse* then the previous package there is no
>> reason to
>> give it negative karma.
>> If it doesn't fix the bugs, the update should fix, it is appropriate
>> to give negative karma. Otherwise the bugs would be closed, when it
>> becomes stable, but won't be fixed.
>
> That's not what the guidelines say :
>
> https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to
>
>

Quoting:
> If you find an update does not fix a bug it claims to fix, this is not 
> usually a case where you should file negative karma.
> Only file negative karma if that is the *only* change in the update. If an 
> update claims to fix five bugs, but only fixes four
> of them, it is not helpful to post negative karma as this may result in the 
> update being rejected, which does not help
> those suffering from the bug that wasn't fixed, and hurts those suffering 
> from the bugs that are fixed.

Tooling issues aside (and it is undesireable that bugs should get
marked fixed if they haven't been) I think this rule is wrong under a
strict reading. If an update claims to fix two bugs and fixes neither
then neither is the *only* change (highlighting is on the guidelines
page), yet obviously the rationale for this rule does not apply in
that case.
Pedantry aside, there is another case: where the update is meant to
fix a bug and the maintainer has tried to do this by pulling in an
upstream update that might not otherwise have been picked up (e.g. a
git hash which has added a feature in the process of fixing the bug).
The upstream update might be part of the change, but it was not the
purpose of the change.


-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self Introduction + Sponsor Needed

[Dario Faggioli]

Hi everyone,

I have just submitted a package review request for xen-tools
(http://www.xen-tools.org/software/xen-tools/) here:

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

From the same website, you can easily reach other Xen related tools,
like xen-shell, and also rinse, which I plan to be packaging too. See
here a (old) blog post of mine about how to use xen-tools on Fedora as
of now (i.e., without it being packaged):
http://blog.xen.org/index.php/2013/01/24/using-xen-tools-on-fedora/

This is my first submission so I'm sending this e-mail for both
introducing myself and looking for a sponsor. :-)

So, I'm Dario (dariof on FAS), I work for Citrix on the Xen Hypervisor
in the 'Open Source Team' (yeah, 100% only OSS stuff, kind of
cool! :-P). I've been there for about one year and a half now, and I'm
working on improving Xen NUMA support.

For that same purpose, I just started recently to contribute to libvirt,
implementing some of the missing bits of the NUMA interface for the
libvirt libxl driver (one of the Xen libvirt backends).

As I use Fedora for both work and leisure, I'm also the one that
maintains Fedora related information on our Wiki (see
http://wiki.xen.org/wiki/Category:Fedora) and I try to keep an eye on
how, in general, Xen works on Fedora (together with Konrad from Oracle).

In the Xen dev and user community, we use xen-tools a lot (for instance,
it is part of our automated testing infrastructure). That's basically
why I'd like Fedora to ship it natively (and I'm of course stepping up
for maintainership): I really believe this could improve both Xen users
and developers experience, help both testing and real workloads and, in
general, bring the two communities closer.

Some more stuff, I live in central Italy (I work from home), I did my
Ph.D on Real-Time Systems in Pisa --during which I did Linux kernel
stuff, http://lwn.net/Articles/412745/). I've been on Linux since
beginning of the university, back in 2000, and on Fedora since F15
(yeah, that is not so long ago... sorry! :-P).
I _love_ Fedora because it gives me bleeding edge software, but still in
a comfortable and stable environment... I was on Debian before, with
experimental repos enabled, and a broken X server (among other things)
at least once a week! :-D

I've got a wife, Luana, an almost 3 years old daughter, Lara, and three
cats: Byte, Mega and Slash.

Looking forward to hearing from you.

Thanks and Regards,
Dario

-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

excellent work!

[Neal Becker]

Just want to say I updated 2 machines using fedup, and everything seems to have 
gone perfectly.

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

Re: More unhelpful update descriptions

[Richard W.M. Jones]

On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
> Richard W.M. Jones wrote:
> > %changelog -f 
> > %changelog -g 
> 
> And, I suppose:
> 
> %changelog -s 
> %changelog -c 
> %changelog -m 
> %changelog -h 
> %changelog -a 
> %changelog -b 

No.  Just implementing -f (local file) solves 80% of cases.  Git most
of the rest.  No one cares about other version control systems.

> > %release_notes -f 
> 
> And what would that mean? Should that entire web page be copied into the
> update announcement? Including stylesheets and images? Or should the
> update announcement only contain a link to the release notes?

No, -f refers to a local file in the package, as it does for all other
RPM -f options.

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 KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Michael Catanzaro]

On Wed, 2013-07-03 at 09:32 +0200, drago01 wrote:
> This is also a perfect example of useless "does not fix bug x" karma.
> If it is not *worse* then the previous package there is no reason to
> give it negative karma.
Yes, that is a problem too. Particularly so with selinux updates.

But getting back to the current concern, the "here is where" update has
now made it to 3 karma and is going to go out to thousands of users.


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

rawhide report: 20130703 changes

[Fedora Rawhide Report]

Compose started at Wed Jul  3 08:15:02 UTC 2013

Broken deps for x86_64
--
[avgtime]
avgtime-0-0.6.git20130201.fc20.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[contour]
contour-0.3-2.fc19.x86_64 requires libsolidcontrolifaces.so.4()(64bit)
contour-0.3-2.fc19.x86_64 requires libsolidcontrol.so.4()(64bit)
[derelict]
derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-3-20.20130626gite70c293.fc20.x86_64 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod
derelict-tcod-devel-3-20.20130626gite70c293.fc20.x86_64 requires tcod
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
[evolution-rss]
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit)
1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit)
[gdb-heap]
gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gtkd]
gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60
gtkd-2.0.0-29.20120815git9ae9181.fc18.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[jboss-as]
jboss-as-7.1.1-19.fc20.noarch requires cxf-common >= 0:2.6.3
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[koji]
koji-vm-1.8.0-1.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit)
[lancet]
lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1
[openbox]
gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel
gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires 
gnome-panel
[openlierox]
openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit)
[ovirt-engine]
ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires 
classpathx-mail
[ovirt-guest-agent]
ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires 
libgdmsimplegreeter.so.1()(64bit)
[oyranos]
oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5
oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit)
[perl-Bio-ASN1-EntrezGene]
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
[perl-Bio-SamTools]
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
[perl-PDL]
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
[perl-qpid]
perl-qpid-0.22-2.fc20.x86_64 requires libqpidtypes.so.1.0.0()(64bit)
perl-qpid-0.22-2.fc20.x86_64 requires libqpidmessaging.so.2.0.0()(64bit)
[python-TraitsBackendQt]
python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI
[rubygem-openshift-origin-common]
rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires 
rubygem(safe_yaml)
[rubygem-openshift-origin-node]
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
rubygem(safe_yaml)
rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires 
openshift-origin-node-proxy
[rubygem-qpid]
rubygem-qpid-0.16.0-14.fc20.x86_64 requires 
libqpidmessaging.so.3()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit)
rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit)
[rubygem-qpid_messaging]
rubygem-qpid_messaging-0.22.0-1.fc20.x86_64 requires 
libqpidtypes.so.1.0.0()(64bit)
rubygem-qpid_messaging-0.22.0-1.fc20.x86_64 requires 
libqpidmessaging.so.2.0.0()(64bit)
rubygem-qpid_messaging-0.22.0-1.fc20.x86_64 requires 
libqpidcommon.so.2.0.0()(64bit)
rubygem-qpid_messaging-0.22.0-1.fc20.x86_64 requires 
libqpidclient.so.2.0.0()(64bit)
[sagemath]
sagemath-core-5.9-5.fc20.i686 requires libgd.so.2
sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit)
[scala]
scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library)
[spacewalk-web]
spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup)
[spring]
spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit)
[sumwars]
sumwars-0.5.6-12.fc20.x86_64 requires libenet-1.3.7.so()(64bit)
[tango]
tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60
tango-2-12.20120821git7b92443.fc19.x86_64 requires 
libphobos-ldc.so.60()(64bit)
[vfrnav]
vfrnav-20130510-1.fc20.x86_64 requires libpolyclipping.so.8()(64bit)
vfrnav-utils-20130510-1.fc20.x86_64 requires 
libpolyclipping.so.8()(64bit)
[zarafa]
libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0
libmapi-7.0.13-1.fc19.i686 requires libical.so.0
libmapi-7.0.13-1.fc19.x86_64 requires libicalss.

Re: abi-compliance-checker and abi-dumper to track API/ABI

[Richard Shaw]

I've got it packaged up and ready for review request.

I'm assuming there is interest in automating this.

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

Re: find-lang.sh search path

[Antonio Trande]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/02/2013 09:02 AM, Michael Schwendt wrote:
> On Mon, 01 Jul 2013 23:28:00 +0200, Antonio Trande wrote:
> 
> Then let's not hack the paths, but find out why %find_lang doesn't 
> find the files. If %name is not part of the filenames, normally
> you would need to add option --all-name, but there's a bug in RPM
> which I've reopened: https://bugzilla.redhat.com/729336
> 

Thank you, Michael.

Meanwhile, I use this code to replace %find-lang macro:

find %{buildroot} -type f -o -type l|sort|sed '
s:'"%{buildroot}"'::
s:\(.*/locale/\)\([^/_]\+\)\(.*\.qm$\):%lang(\2) \1\2\3:
s:^\([^%].*\)::
/^$/d' > %{name}.lang

- -- 
- 
Antonio Trande

mailto: sagit...@fedoraproject.org
Homepage: http://www.fedoraos.worpress.com
GPG Key: D400D6C4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1CgUAAoJED2vIvfUANbEwPoP/0dvDImpsdmSZzSESJg37NiQ
iCApASOn4x8d8+42d11JjoiIL0IcuDQwE4d00TzjfHfLTvc3HehQMuT4Z/GxF3Wn
o4hOMmP4Y388uUaRC8UvRkL+C8g/x3X0i4C45pFDUljyZWnN3WUZoqKRSt0ztvd9
UfEcFoxSPfbsIOjW5lZmWC2Qme/AlRoOArTrVJBfa0NH5zag0IZSKmSOVBdq3PRk
6/xmZhPSADE95uwu/X7tVsduq0YZXZYoFOnKs9Uxs0oGTUOM/PgBXCjOqyjEDVnT
TPiQrmiFKijv3CbUuRP0C20UWLZ7xPRsMHlCzm49TwS86ZYpCIklyhRylrAImtmW
wjWCvTUYpKBSIwg9Kb5VXJnfVxkMFbS7b5PPXmXgxxsexOCIlzz+tgn1DLK1qrIb
KF9cLN3UjViYhpY3xRSnGCs9s9Ybh7BLKByBHiK4q6VB6x0fDB1d+HtJIU1Lu7c5
InToSY22lG3WvW3dE22Jjhzo2pE0O6DTDdsL5YnFB6NASfhQOhCPuafR4OOJUOi4
53izQYOv4jGTLtW1Prg+ojhWa5xMECY0ETaqTilNkySrzf5X1ETxRuHWeVixkN/Z
HyCaoD2IyV2V2f0GiO4nhzEHXr8sxuPkff+hcWhL1eJrRPqrXp0eJbkn+Elh1w21
hGbzCs0tmwtlxdkFoBDn
=nGdm
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libgd breakage

[Orion Poplawski]

On 07/01/2013 03:52 PM, Orion Poplawski wrote:

See https://bugzilla.redhat.com/show_bug.cgi?id=959696.  Renaming ht to
t4ht was clearly the wrong thing to do.  I'm reverting it for now.


texlive and gnuplot now have been rebuilt in rawhide.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reminder: Fedora 17 end of life on 2013-07-30

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings. 

This is a reminder email about the end of life process for Fedora 17. 

Fedora 17 will reach end of life on 2013-07-30, and no further updates
will be pushed out after that time. Additionally, with the recent
release of Fedora 19, no new packages will be added to the Fedora 17
collection. 

Please see http://fedoraproject.org/wiki/DistributionUpgrades for more
information on upgrading from Fedora 17 to a newer release. 


Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlHUNr8ACgkQkSxm47BaWfeMyACfclL38HAQ5BH6JwkzyjUhuCoo
5rkAnjdoGzPhPvB3pLlZhXJEddKkn4tW
=vE+d
-END PGP SIGNATURE-
___
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

Announcing the release of Fedora 19 for Power

[Phil Knirsch]

The Fedora Secondary Arch Team for Power is delighted to announce the 
release of Fedora 19 ("Schrödinger's Cat") for Power architecture. Open 
the box and take a look for yourself!


Fedora is a leading-edge, free and open source operating system that 
continues to deliver innovative features to many users, with a new 
release about every six months.


Download it now:

http://fedoraproject.org/en/get-fedora-options#2nd_arches

Detailed information about this release on Power can be seen in the 
release notes:

https://fedoraproject.org/wiki/Architectures/PowerPC/F19_release_announcement

For the general release notes for this release take a look here:
http://docs.fedoraproject.org/en-US/Fedora/19/html/Release_Notes/

** What's New in Fedora 19 for Power? **

* The new LLVMPipe rendering engine is now fully functional and enabled 
by default. This greatly speeds up graphics rendering on systems with no 
3D graphics drivers or working with VNC sessions.


A complete list with details of each new feature is available here:
http://fedoraproject.org/wiki/Releases/19/FeatureList

*** Downloads, upgrades, documentation, and common bugs ***

Start by downloading Fedora 19:
http://fedoraproject.org/en/get-fedora-options#2nd_arches

If you are upgrading from a previous release of Fedora, refer to:
http://fedoraproject.org/wiki/Upgrading

Fedora now includes FedUp in order to enable an easy upgrade to Fedora 19.

*** Documentation ***

Read the full release notes for Fedora 19, guides for several languages, 
and learn about known bugs and how to report new ones:

http://docs.fedoraproject.org/

Because of the number of changes to the installer, we particularly 
suggest taking a peek at the Installation Guide:

http://docs.fedoraproject.org/en-US/Fedora/19/html/Installation_Guide/index.html

Fedora 19 common bugs are documented at:
http://fedoraproject.org/wiki/Common_F19_bugs

This page includes information on several known bugs in the installer, 
so we recommend reading it before installing Fedora 19.


*** Contributing ***

We can't build Fedora inside a box. We need your help! Bug reports are 
especially helpful--if you encounter any issues, please report them!


Fedora is a fantastic, friendly community, and we have many ways in 
which you can contribute, including documentation, marketing, design, 
QA, and development.


To learn how to help us, visit:
http://join.fedoraproject.org/

*** Fedora 20 ***

Fedora 20 has been in active development for several months already. We 
plan to release it in November 2013, though the final schedule is part 
of the planning process and subject to change:


https://fedoraproject.org/wiki/Releases/20/Schedule

*** Contact information ***

If you are a journalist or reporter, you can find additional information 
here:


https://fedoraproject.org/wiki/Press

In the name of the whole Fedora Secondary Arch Team for Power i'd like 
to thank everyone making this an awesome release.


Thanks & regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: abi-compliance-checker and abi-dumper to track API/ABI

[Richard Shaw]

Review request submitted:

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

It took me a bit to work some txt2man magic to get a decent manpage.

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

Re: More unhelpful update descriptions

[Panu Matilainen]

On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:

On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:

Richard W.M. Jones wrote:

%changelog -f 
%changelog -g 


And, I suppose:

%changelog -s 
%changelog -c 
%changelog -m 
%changelog -h 
%changelog -a 
%changelog -b 


No.  Just implementing -f (local file) solves 80% of cases.  Git most
of the rest.  No one cares about other version control systems.


You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for 
this. At least Mageia and Mandriva have been pulling their rpm 
changelogs from their dist-vcs for years, see eg

https://wiki.mageia.org/en/Packaging_guidelines#Changelogs


- Panu -

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

Re: More unhelpful update descriptions

[Richard W.M. Jones]

On Wed, Jul 03, 2013 at 06:21:51PM +0300, Panu Matilainen wrote:
> On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:
> >On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:
> >>Richard W.M. Jones wrote:
> >>>%changelog -f 
> >>>%changelog -g 
> >>
> >>And, I suppose:
> >>
> >>%changelog -s 
> >>%changelog -c 
> >>%changelog -m 
> >>%changelog -h 
> >>%changelog -a 
> >>%changelog -b 
> >
> >No.  Just implementing -f (local file) solves 80% of cases.  Git most
> >of the rest.  No one cares about other version control systems.
> 
> You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for
> this. At least Mageia and Mandriva have been pulling their rpm
> changelogs from their dist-vcs for years, see eg
> https://wiki.mageia.org/en/Packaging_guidelines#Changelogs

SuSE too ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Reindl Harald]

Am 03.07.2013 09:54, schrieb Johannes Lips:
> Could be, but if the still broken bugs are going to be closed, when the 
> update becomes stable

since when do bugs get magically closed?




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

Re: fedup performance

[Alexey I. Froloff]

On Wed, Jul 03, 2013 at 12:25:19AM -0500, Alex G. wrote:
> aptitude has something called "deferred ldconfig processing", and
> annoyingly, aptitude updates faster than yum. I've always wondered how
> yum/rpm can be smartized to speed things up this way. But this
> discussion is for a brighter day.
Well, this is how dpkg works.  It downloads all packages, then
"unpacks" it on filesystem and then "configures" them all, which
means "running post-scripts".  Personally, I dislike this
design...

-- 
Regards,--
Sir Raorn.   --- http://thousandsofhate.blogspot.com/


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

Re: More unhelpful update descriptions

[Matthew Miller]

On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
> > Could be, but if the still broken bugs are going to be closed, when the 
> > update becomes stable
> since when do bugs get magically closed?

Since 2007 or so?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM Weekly Status Meeting 2013-07-03 Canceled

[Brendan Conoboy]

Hi everybody,

Yesterday we made a simultaneous release of F19 on ARM and x86, a first 
ever.  Thank you to everybody who contributed- it was truly a great team 
effort, and it produced the best Fedora on ARM release yet.


It's a holiday week in the US and Canada and half the members of the ARM 
team are traveling or packing their bags today.  We are going to skip 
the weekly IRC discussion in #fedora-meeting-1, take flight, and be back 
next week ready to rock Fedora 20's world.


TL;DR: No irc meeting today.

Thanks,

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Self Introduction / Sponsor Request

[Ed Santiago]

Hi,

I've submitted a package review request for rpmgrill:

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

rpmgrill is yet another QA tool for catching problems in koji builds.

About me: I've been writing UNIXy software tools in one form or
another since the late 80s, open-sourcing when possible. I'm new
to Fedora, having started using it three years ago.

Thanks,
Ed
-- 
Ed Santiago Toolsmith santi...@redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads up: Upcoming python-pillow 2.2 breaks "import _imaging"

[Kevin Fenzi]

On Mon, 01 Jul 2013 01:35:14 +0200
Sandro Mani  wrote:

> Hello all,
> 
> As described here [1], the upcoming python-pillow 2.2 will break
> "import _imaging", and "from PIL.Image import core as _imaging"
> should be used instead). This does not break backwards compatibility
> with python-pillow < 2.2.
> 
> Python-pillow-2.2 will probably land in rawhide some time next
> weekend. In the meantime, maintainers of packages requiring
> python-imaging or python-pillow should check if this breakage affects
> them. The following quick hacky script [2] shows that the following
> packages might need to be adapted:
> 
> !! calibre-0:0.9.36-1.fc20.x86_64 may contain _imaging import:
> usr/lib64/calibre/calibre/test_build.py:import _imaging, 
> _imagingmath, _imagingft
> usr/lib64/calibre/calibre/test_build.py:_imaging,
> _imagingmath, _imagingft
> usr/lib64/calibre/calibre/test_build.py:from PIL import 
> _imaging, _imagingmath, _imagingft
> usr/lib64/calibre/calibre/test_build.py:_imaging, _imagingmath, 
> _imagingft

Note that this is a test script thats not run as part of the build,
however, it is shipped in the rpm for people to use, so we do need to
fix it. 

Can you whip up a patch? Otherwise I can try and do so... 

kevin


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

[389-devel] Please review: Ticket #47384 - Plugin library path validation

[Noriko Hosoi]

https://fedorahosted.org/389/ticket/47384

https://fedorahosted.org/389/attachment/ticket/47384/0001-Ticket-47384-Plugin-library-path-validation.3.patch

Description: commit a4b81c0ae59a4246d2d44790efea093a62fc972c

only checks the invalid plugin path when the value is modified.
This patch adds the check when a plugin entry is added.
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Self Introduction / Sponsor Request

[Christopher Meng]

I've left some candies there :-D
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Schedule for Wednesday's FESCo Meeting (2013-07-03)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry for the lateness of this email. FESCo meeting *IS* scheduled for
today.

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '-MM-DD HH:MM UTC'

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

= New FESCo =
#topic Thank departing FESCo member jwb
#topic Welcome new FESCo member mattdm

= Followups =

#topic #1128 switching from "-fstack-protector" to
"-fstack-protector-strong" in Fedora 20
.fesco 1128
https://fedorahosted.org/fesco/ticket/1128

= New business =

#topic #1132 libtool + %global _hardened_build 1 = no full hardening
.fesco 1132
https://fedorahosted.org/fesco/ticket/1132

#topic 1131 Organize FESCo attendance at Flock
.fesco 1131
https://fedorahosted.org/fesco/ticket/1131

= 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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHUWbAACgkQeiVVYja6o6MH3wCgrvsCepJ84QH2TgA28GfHezKz
bGoAoJOLCcKr2z+4rH/AJQNxMCYKn606
=OgGE
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Schedule for Wednesday's FESCo Meeting (2013-07-03)

[Josh Boyer]

On Wed, Jul 3, 2013 at 1:04 PM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Sorry for the lateness of this email. FESCo meeting *IS* scheduled for
> today.
>
> Following is the list of topics that will be discussed in the FESCo
> meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '-MM-DD HH:MM UTC'
>
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
>
> = New FESCo =
> #topic Thank departing FESCo member jwb

Thanks not needed.  It was a pleasure to serve as usual.  I most
likely won't make the meeting, so don't worry about doing this as a
separate topic.

> #topic Welcome new FESCo member mattdm

Hurrah!  Congrats to Matt.

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

python-setuptools-0.7.7 built for rawhide; hold off on mass rebuilds

[Toshio Kuratomi]

I've just built python-setuptools-0.7.7 for rawhide.  As mentioned in the
Changes Planning page:
https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7#Summary

This is a switch of code base so there is the possibility of failures
however it isn't a major change of API so it should hopefully be mostly
transparent.

*Do* go about rebuilding python packages as usual and let me know if you see
any failures that you think could be attributed to the new setuptools.

*Do not* start mass rebuilding all your python packages with the expectation
that this is the last major change for this release cycle -- there's
a setuptools-0.8 package that is due out in a week or two and I would like
to talk with ncoghlan about whether we should push that into Fedora 20.  The
changes from 0.7 to 0.8 seem to be similar in scope as the 0.6 to 0.7 switch
(little to no API changes, large changes to the code base itself to make it
more maintainable) so it probably makes sense to switch over to that for F20
(I'll build the beta2 for rawhide if Nick agrees that that is a good plan).

*Note*: python packages do not need to rebuild against this package.
However, I hope we can include python packages in any mass rebuild for F20
to make sure that there aren't any major new bugs in the new package that
would cause other packages to unexpectedly FTBFS later on.

-Toshio


pgpWsEMGkWQZn.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Reindl Harald]

Am 03.07.2013 18:21, schrieb Matthew Miller:
> On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
>>> Could be, but if the still broken bugs are going to be closed, when the 
>>> update becomes stable
>> since when do bugs get magically closed?
> 
> Since 2007 or so?

what sense makes this?

a new upstream-release does not implicitly close any bug

on the other hand it makes hardly sense to hold back a update
not fixing all bugreports - this all makes no sense for me



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

Re: More unhelpful update descriptions

[Kevin Fenzi]

On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald  wrote:

> 
> 
> Am 03.07.2013 18:21, schrieb Matthew Miller:
> > On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
> >>> Could be, but if the still broken bugs are going to be closed,
> >>> when the update becomes stable
> >> since when do bugs get magically closed?
> > 
> > Since 2007 or so?
> 
> what sense makes this?
> 
> a new upstream-release does not implicitly close any bug
> 
> on the other hand it makes hardly sense to hold back a update
> not fixing all bugreports - this all makes no sense for me

I think there's a misunderstanding here. 

Bodhi doesn't do anything at all with bugs that are not attached to an
update. How could it?

The bugs that are attached to an update are supposed to be fixed by
that update. If they are not, you should -1 karma the update and if
possible note in the bug that it's not fixed and help provide any info
to the maintainer in bug. 

If the update has some bugs attached, but doesn't fix a bug that is NOT
attached, you should NOT -1 karma for that bug not being fixed. It's
not expected that it would be. You could note in that bug that the
update doesn't fix it, but the maintainer probibly knows that or they
would have also attached that bug to the update. 

Bodhi will (by default, but override able) close any bugs attached to
an update when the update goes stable. If you find such a closed but
that was not really fixed, reopen it or note to the maintainer in the
bug and they can do so. 

Is that more clear?

kevin


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

Re: More unhelpful update descriptions

[Reindl Harald]

Am 03.07.2013 19:54, schrieb Kevin Fenzi:
> On Wed, 03 Jul 2013 19:38:00 +0200
> Reindl Harald  wrote:
>> a new upstream-release does not implicitly close any bug
>>
>> on the other hand it makes hardly sense to hold back a update
>> not fixing all bugreports - this all makes no sense for me
> 
> I think there's a misunderstanding here. 
> 
> Bodhi doesn't do anything at all with bugs that are not attached to an
> update. How could it?
> 
> The bugs that are attached to an update are supposed to be fixed by
> that update. If they are not, you should -1 karma the update and if
> possible note in the bug that it's not fixed and help provide any info
> to the maintainer in bug. 
> 
> If the update has some bugs attached, but doesn't fix a bug that is NOT
> attached, you should NOT -1 karma for that bug not being fixed. It's
> not expected that it would be. You could note in that bug that the
> update doesn't fix it, but the maintainer probibly knows that or they
> would have also attached that bug to the update. 
> 
> Bodhi will (by default, but override able) close any bugs attached to
> an update when the update goes stable. If you find such a closed but
> that was not really fixed, reopen it or note to the maintainer in the
> bug and they can do so. 
> 
> Is that more clear?

this makes much more sense
thanks!



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

Re: More unhelpful update descriptions

[drago01]

On Wed, Jul 3, 2013 at 7:54 PM, Kevin Fenzi  wrote:
> On Wed, 03 Jul 2013 19:38:00 +0200
> Reindl Harald  wrote:
>
>>
>>
>> Am 03.07.2013 18:21, schrieb Matthew Miller:
>> > On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
>> >>> Could be, but if the still broken bugs are going to be closed,
>> >>> when the update becomes stable
>> >> since when do bugs get magically closed?
>> >
>> > Since 2007 or so?
>>
>> what sense makes this?
>>
>> a new upstream-release does not implicitly close any bug
>>
>> on the other hand it makes hardly sense to hold back a update
>> not fixing all bugreports - this all makes no sense for me
>
> I think there's a misunderstanding here.
>
> Bodhi doesn't do anything at all with bugs that are not attached to an
> update. How could it?
>
> The bugs that are attached to an update are supposed to be fixed by
> that update. If they are not, you should -1 karma the update and if
> possible note in the bug that it's not fixed and help provide any info
> to the maintainer in bug.
>
> If the update has some bugs attached, but doesn't fix a bug that is NOT
> attached, you should NOT -1 karma for that bug not being fixed. It's
> not expected that it would be. You could note in that bug that the
> update doesn't fix it, but the maintainer probibly knows that or they
> would have also attached that bug to the update.

No only if this is the only bug there. And even then -1 is
questionable ... you should just not that in the bug.
-1 means "pushing this update is harmful" not fixing a bug is not.

It might have 5 bug fixes where one of the fix does not fix the
problem. What do we gain by not pushing it?

-1 for "does not fix a bug that is present in the current release" is
in 99.99% of the cases nonsense.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problem with abrt update on F18?

[Richard Vickery]

On Jul 2, 2013 2:20 PM, "Richard Shaw"  wrote:
>
> I saw this during the update:
>
> Updating   : abrt-libs-2.1.5-1.fc18.x86_64
 10/76
> cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/environâ: No such file or
directory
> cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/mapsâ: No such file or
directory
> cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/countâ: No such file or
directory
> cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/hostnameâ: No such file or
directory
> cp: cannot create regular file
â/var/tmp/abrt/ccpp-2013-03-27-09:24:26-2877/core_backtraceâ: No such file
or directory
>
> Is it anything to worry about?
>
> Richard
>
> --
To avoid possible future problems, I believe that sometimes it is possible
to either "yum upgrade" or "yum install" these files separately.

Hope this helps,

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

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-03 0:54, Johannes Lips wrote:


If it doesn't fix the bugs, the update should fix, it is

appropriate

to give negative karma. Otherwise the bugs would be closed, when

it

becomes stable, but won't be fixed.


That's not what the guidelines say :



https://fedoraproject.org/wiki/QA:Update_feedback_guidelines#Update_does_not_fix_a_bug_it_claims_to

[2]


Could be, but if the still broken bugs are going to be closed, when
the update becomes stable, doesn't really help, or? Given that this is
enabled in the update.


That is a bureaucratic detail that can be fixed. Priority #1 should 
*always* be pushing out better software: it is wrongheaded to avoid 
pushing out better software because it would cause a minor inconvenience 
in our bug tracking system. We should prioritize pushing out the update 
if it's better than the previous update, and we can deal with re-opening 
incorrectly closed bugs.


If an update *only* claims to fix one bug, and doesn't actually fix it, 
it is appropriate to give it a -1. But if it claims to fix 10 bugs, 
fixes 9, but doesn't fix the tenth (and doesn't make anything else worse 
in a major way, of course) then we really want to push that update out, 
because it makes things better for people. We can deal with the tenth 
bug later.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-03 1:11, Michael Scherer wrote:


Then we could decide on :
- better process, ie "if you happen to notice a bug is not fixed by
update, please reopen it"
- better tooling, ie a way to say "do not close this bug" to bodhi.
Either a message in bodhi, or something on bugzilla side.


The maintainer can already do this; they can edit the update and remove 
that bug from the list of 'bugs fixed by this update'. It would be good 
if, when a maintainer becomes aware an update definitely doesn't fix a 
bug they thought it did, they could do this.

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

Summary/Minutes from today's FESCo Meeting (2013-07-03)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

===
#fedora-meeting: FESCO (2013-07-03)
===


Meeting started by sgallagh at 18:01:28 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-07-03/fesco.2013-07-03-18.01.log.html
.



Meeting summary
- ---
* init process  (sgallagh, 18:01:39)

* #1128 switching from "-fstack-protector" to "-fstack-protector-strong"
  in Fedora 20  (sgallagh, 18:07:05)
  * ACTION: sgallagh to ping panu about including
-fstack-protector-strong patch  (sgallagh, 18:09:32)
  * ACTION: abadger1999 to file mass-rebuild tracker ticket for F20. He
will discuss with dgilmore where to file it.  (sgallagh, 18:12:25)
  * AGREED: Close ticket 1128 and address remaining issues with a
mass-rebuild  (sgallagh, 18:14:08)

* #1132 libtool + %global _hardened_build 1 = no full hardening
  (sgallagh, 18:14:23)
  * AGREED: shelve for a week, pending ajax input  (sgallagh, 18:27:53)

* 1131 Organize FESCo attendance at Flock  (sgallagh, 18:28:03)
  * AGREED: Move "Meet Your FESCo" to Sunday 4pm to act as a capstone
discussion for the conference.  (sgallagh, 18:54:32)
  * ACTION: sgallagh to speak with Flock conference organizers to
shuffle the schedule  (sgallagh, 18:55:23)

* Next week's chair  (sgallagh, 18:58:17)
  * abadger1999 to chair next week's meeting  (sgallagh, 18:58:58)

* Open Floor  (sgallagh, 18:59:04)

Meeting ended at 19:12:37 UTC.




Action Items
- 
* sgallagh to ping panu about including -fstack-protector-strong patch
* abadger1999 to file mass-rebuild tracker ticket for F20. He will
  discuss with dgilmore where to file it.
* sgallagh to speak with Flock conference organizers to shuffle the
  schedule




Action Items, by person
- ---
* abadger1999
  * abadger1999 to file mass-rebuild tracker ticket for F20. He will
discuss with dgilmore where to file it.
* sgallagh
  * sgallagh to ping panu about including -fstack-protector-strong patch
  * sgallagh to speak with Flock conference organizers to shuffle the
schedule
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (111)
* nirik (44)
* abadger1999 (43)
* mattdm (32)
* mitr (16)
* mmaslano (10)
* zodbot (8)
* spot (1)
* t8m (0)
* pjones (0)
* notting (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHUe8UACgkQeiVVYja6o6NHAQCgiUlfnM9nYG4mfpvKUt3ZdSDd
WOMAn2IjJ/4C/+PoSU64T4rwMMBA1pnJ
=ES2j
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-03 2:28, Ian Malone wrote:


Tooling issues aside (and it is undesireable that bugs should get
marked fixed if they haven't been) I think this rule is wrong under a
strict reading. If an update claims to fix two bugs and fixes neither
then neither is the *only* change (highlighting is on the guidelines
page), yet obviously the rationale for this rule does not apply in
that case.


I was kinda hoping people would be able to draw the obvious 
interpretation there. That page (like just about everything I write...) 
is too long already, I really don't want to make it any longer.



Pedantry aside, there is another case: where the update is meant to
fix a bug and the maintainer has tried to do this by pulling in an
upstream update that might not otherwise have been picked up (e.g. a
git hash which has added a feature in the process of fixing the bug).
The upstream update might be part of the change, but it was not the
purpose of the change.


I'm not sure what conclusion you're drawing here?

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-03 8:21, Panu Matilainen wrote:

On 07/03/2013 03:12 PM, Richard W.M. Jones wrote:

On Wed, Jul 03, 2013 at 12:28:19AM +0200, Björn Persson wrote:

Richard W.M. Jones wrote:

%changelog -f 
%changelog -g 


And, I suppose:

%changelog -s 
%changelog -c 
%changelog -m 
%changelog -h 
%changelog -a 
%changelog -b 


No.  Just implementing -f (local file) solves 80% of cases.  Git most
of the rest.  No one cares about other version control systems.


You dont need incompatible-with-rpm-prior-x.y.z %changelog flags for
this. At least Mageia and Mandriva have been pulling their rpm
changelogs from their dist-vcs for years, see eg
https://wiki.mageia.org/en/Packaging_guidelines#Changelogs


Right. I think *this* is actually rather more practical than trying to 
auto-generate update descriptions. I see much more difference between an 
update description and a package changelog than between a package 
changelog and a package SCM commit log.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Adam Williamson]

On 2013-07-03 10:54, Kevin Fenzi wrote:

On Wed, 03 Jul 2013 19:38:00 +0200
Reindl Harald  wrote:




Am 03.07.2013 18:21, schrieb Matthew Miller:
> On Wed, Jul 03, 2013 at 10:25:12AM +0200, Reindl Harald wrote:
>>> Could be, but if the still broken bugs are going to be closed,
>>> when the update becomes stable
>> since when do bugs get magically closed?
>
> Since 2007 or so?

what sense makes this?

a new upstream-release does not implicitly close any bug

on the other hand it makes hardly sense to hold back a update
not fixing all bugreports - this all makes no sense for me


I think there's a misunderstanding here.

Bodhi doesn't do anything at all with bugs that are not attached to an
update. How could it?

The bugs that are attached to an update are supposed to be fixed by
that update. If they are not, you should -1 karma the update and if
possible note in the bug that it's not fixed and help provide any info
to the maintainer in bug.


As discussed up thread, this is not the current policy and I'd really 
prefer people don't do this. -1 is a Serious Thing, not to be used 
lightly.


If an update claims to fix multiple bugs and *does* fix some of them and 
doesn't make anything worse, it should be +1ed, not -1ed. If that leads 
to some bugs that weren't actually fixed being closed, we can re-open 
them. We should not delay useful fixes going out due to bureaucratic 
details.


(The update submitter can edit the not-fixed bugs out of the update 
before it goes stable to avoid them being closed, if s/he is paying 
sufficient attention.)

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Kevin Fenzi]

On Wed, 03 Jul 2013 12:55:11 -0700
Adam Williamson  wrote:

> As discussed up thread, this is not the current policy and I'd really 
> prefer people don't do this. -1 is a Serious Thing, not to be used 
> lightly.

Sorry, you are right. 

> If an update claims to fix multiple bugs and *does* fix some of them
> and doesn't make anything worse, it should be +1ed, not -1ed. If that
> leads to some bugs that weren't actually fixed being closed, we can
> re-open them. We should not delay useful fixes going out due to
> bureaucratic details.

I think the key part here is the 'doesn't make anything worse'. 

Ie, 10 bugs on a update, 9 of them are fixed, but the one that isn't
causes data loss that wasn't present before this update, etc. 

> (The update submitter can edit the not-fixed bugs out of the update 
> before it goes stable to avoid them being closed, if s/he is paying 
> sufficient attention.)

Yeah, I agree... just trying to answer too many emails at once. ;( 

I'd add that you could note _on the bug_ or in a comment on the update
(with +0) that whatever bug you see attached to the update that isn't
fixed isn't fixed, so the maintainer knows and can remove it from the
update or evaluate how bad it is and decide what they want to do. 

kevin


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

Who uses abi-compliance-checker?

[Richard Shaw]

I initially got abi-compliance-checker into Fedora because one of my
packages does not maintain any sort of API/ABI compatibility or even
versioning for that matter. That way I could always check a new release to
see if any of its dependencies needed to be rebuilt.

Since then, I've started using it for all of my libraries in the spirit of
"Trust but verify", and I've occasionally found issues even though upstream
didn't bump the soversion.

So out of curiosity, anyone else using this great tool?

If anyone is curious about it, I don't mind typing up the process I go
through to make the checks. I think I've found a pretty good path of least
resistance method :)

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

Re: vote for systemd: Nay.

[Lennart Poettering]

On Tue, 02.07.13 10:08, Jean-Marc Pigeon (j...@safe.ca) wrote:
> This little project gave satisfactory results with various distributions when
> I designed and tested it 2 years ago. First I checked it with a standard
>   EL6.4 template (400 Megs) under this new kernel (3.9.4,  HOST
> EL6.4) to see if my tool was
> still operational. Everything went perfectly. I was ready to test
> FC18. The selected
> FC18 template is a very standard one (a 939 MBytes tgz file) which
> (and this is a key factor) was proved to be fully working "as is" in an openvz
> container (kernel 2.6.32-042stab076.8). "as is" means that Template
> was never taylored
> to be on openvz container (template is used out of the box in openvz
> container) and could
> be used to seed a working HOST too.

So, as you mentioned earlier you used this recipe to set up your image:

https://gist.github.com/fabaff/5512671

This recipe is very broken (which I already told you), and by using
this, you create an OS image that changes a number of early boot things
in a way that will break things if you then try to boot the same image
on bare metal.

The things it changes are early-boot things, very low-level stuff. You
interfered with much of the most basic OS initialization stuff there
(masking sysinit.target!), and if you do this then you really need
to know what you are doing. And you should not expect that the same
image will then continue to boot on normal hardware.

I understand you are new to systemd, but you chose to alter the lowest
level bits of the OS, and then were subsequently lost then. This is
certainly very understandable, but please accept that this is not our
primary use case. We assume that if you touch that kind of low-level
stuff, and alter the early-boot dep tree, then you know how to help
yourself. The more low-level you go the more expertise you need.

We are working on making systemd work out-of-the-box on container
managers. libvirt-lxc and systemd-nspawn are relatively nicely
integrated with systemd so that things just work without any manual
recipe. OpenVZ is not something we test against, and we certainly do not
test systems that have been modified to work with OpenVZ but then are
attempted to be booted on bare-metal hardware again.

From the systemd side it is our goal to ensure that systemd will work
fine on bare metal, inside a VM and in a container, with the exact same
image, without any ateration. With nspawn/libvirt-lxc we are very close
to that. However, all that work will be incomplete, unless Fedora as a
whole starts to care about this (for example, by giving the various
container managers a role like a "release architecture", to ensure they
just work with unmodified future fedora releases), and unless the
various container managers actually start to implement the most basic
common interfaces like the ones we documented:

http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/

So, please work with Fedora, with the container vendor of your choice to
make all this stuff just work out-of-the-box. And please don't use
recipes like the one you linked, they made things worse, not better. You
don't need any recipes at all if your container manager just implements
the ContainerInterface mini spec...

Being able to migrate OS images between VMs, bare metal, containers, in
all directions without alteration is absolutely a worthy goal, and not
far off, if people actually start caring.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: More unhelpful update descriptions

[Ian Malone]

On 3 July 2013 20:48, Adam Williamson  wrote:
> On 2013-07-03 2:28, Ian Malone wrote:
>
>> Tooling issues aside (and it is undesireable that bugs should get
>> marked fixed if they haven't been) I think this rule is wrong under a
>> strict reading. If an update claims to fix two bugs and fixes neither
>> then neither is the *only* change (highlighting is on the guidelines
>> page), yet obviously the rationale for this rule does not apply in
>> that case.
>
>
> I was kinda hoping people would be able to draw the obvious interpretation
> there. That page (like just about everything I write...) is too long
> already, I really don't want to make it any longer.
>

I think the intent is pretty clear, but the wording is slightly
contradictory. It could probably be tidied up without making it
longer, but exactly how depends on this:

>
>> Pedantry aside, there is another case: where the update is meant to
>> fix a bug and the maintainer has tried to do this by pulling in an
>> upstream update that might not otherwise have been picked up (e.g. a
>> git hash which has added a feature in the process of fixing the bug).
>> The upstream update might be part of the change, but it was not the
>> purpose of the change.
>
>
> I'm not sure what conclusion you're drawing here?
>
>

Well in such a case (and I've been in one, quite a while ago), there's
a bug (in that case a kernel bug). The maintainer is trying to fix it
and produces an update. It doesn't fix the problem, it is technically
a newer version that might not have been packaged otherwise. There is
a cost to having this pushed out and everyone updating for no benefit.
Or maybe more concretely this (picked at random, I'm sure it probably
fixes what it's meant to):
https://admin.fedoraproject.org/updates/libdrm-2.4.46-1.fc19

(In this case there's no BZ, so it might not have been reported in
Fedora.) This pulls an upstream update to fix a bug. In such cases
it's probably known that the upstream update does fix the issue. But
if it turns out it doesn't when tested then maybe something has gone
wrong with the update or the bug wasn't really fixed upstream. It
looks pretty clear here since it's listed as a bugfix and a single
issue, if you were testing it then you would give it a -1 if it failed
to fix qxl cursor bugs.

However, if this was kernel 3.9.7 (which doesn't seem to have been
packaged, went 3.9.6 -> 3.9.8) which had been built as a bugfix for a
single bug which it didn't fix should it be -1ed? I'm not really
arguing either way, I generally only test packages on bugs I'm
subscribed to, but I suspect cases like often rely on some
alternate-channel communication between the tester and the maintainer,
whether through bugzilla or mailing lists. (Of course in the multiple
bugs case I'd just report it on the BZ entry that the update hasn't
made an improvement.)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: vote for systemd: Nay (now working but still Voting Nay)

[Lennart Poettering]

On Tue, 02.07.13 16:57, Jean-Marc Pigeon (j...@safe.ca) wrote:

> As expected the problem stand on a very small detail (within /etc/fstab)
> 
> Not working
> /vzgot/   ext4defaults0 0
> proc  /proc   procdefaults0 0
> sysfs /syssysfs   defaults0 0
> devpts/dev/ptsdevpts  defaults0 0
> tmpfs /dev/shmtmpfs   defaults0 0
> 
> Working
> #/vzgot   /   ext4defaults0 0
> proc  /proc   procdefaults0 0
> sysfs /syssysfs   defaults0 0
> devpts/dev/ptsdevpts  defaults0 0
> tmpfs /dev/shmtmpfs   defaults0 0

Note that in a systemd world fstab shouldn't really list any of the
virtual file systems like procfs, sysfs, devpts, /dev/shm, unless you
have specific mount options that need to override the defaults. Also,
the root file system doesn't need to be listed. It is hence a good idea
to leave fstab out entirely if you run things in a container.

> The fact that the line just below says, "Please see journal" but
> journal is not available (empty) just compound the effect.

How did you access the journal? The journal is actually available pretty
much all the time. It logs to /run as long as /var is not there, to make
this work (very much unlike classic syslog, btw).

> So, no, sorry, systemd doesn't grade "production level" (not yet? or
> never?).

Well, as mentioned you altered the most low-level parts of the unit dep
tree. So yeah, a setup like that certainly is not "production level",
but that's hardly our fault.

> May I propose some way to improve it.
> - journal should be accessible regardless of systemd status or
> trouble.

It is. journalctl directly accesses all journal files and starts very
early in the boot process, including in initrd (hint: this is *much*
earlier than classic syslog). And for the time even before the journal
is around, we log to kmsg (i.e. demsg).

> - You should have a way to proceed in a 'step by step' boot mode
>(avoiding in parallel fast scrolling report)

systemd.confirm_spawn=yes

But disabling the parallelization doesn't really work. If a service foo
triggers starting of a service bar while it is starting up, and needs an
answer from bar before it can proceed, how do you want to ever solve
this? You need to start both foo and bar at the same time.

> - On a more philosophical side:
>* linking PID1 and systemd seems to me a problem (why it is
> mandatory still escape me),

systemd is an init system. init systems run as PID 1. This how Unix
works. 

> Bug:
> - After a very quick check, there is maybe a bug the way systemd is
> handling 'int reboot(int cmd);',
>I have the strong feeling systemd is not feeding WTERMSIG(status),
> but it is very
>preliminary, I could be wrong

Hmm? I cannot parse this.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Sérgio Basto]

On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote: 
> I initially got abi-compliance-checker into Fedora because one of my
> packages does not maintain any sort of API/ABI compatibility or even
> versioning for that matter. That way I could always check a new
> release to see if any of its dependencies needed to be rebuilt.
> 
> 
> Since then, I've started using it for all of my libraries in the
> spirit of "Trust but verify", and I've occasionally found issues even
> though upstream didn't bump the soversion.
> 
> 
> So out of curiosity, anyone else using this great tool?
> 
> 
> If anyone is curious about it, I don't mind typing up the process I go
> through to make the checks. I think I've found a pretty good path of
> least resistance method :)

could we use this tool on x264/ffmpeg/mplayer packages ? 
> 


-- 
Sérgio M. B.

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

Re: Heads up: Upcoming python-pillow 2.2 breaks "import _imaging"

[Sandro Mani]

On 03.07.2013 18:49, Kevin Fenzi wrote:

On Mon, 01 Jul 2013 01:35:14 +0200
Sandro Mani  wrote:


Hello all,

As described here [1], the upcoming python-pillow 2.2 will break
"import _imaging", and "from PIL.Image import core as _imaging"
should be used instead). This does not break backwards compatibility
with python-pillow < 2.2.

Python-pillow-2.2 will probably land in rawhide some time next
weekend. In the meantime, maintainers of packages requiring
python-imaging or python-pillow should check if this breakage affects
them. The following quick hacky script [2] shows that the following
packages might need to be adapted:

!! calibre-0:0.9.36-1.fc20.x86_64 may contain _imaging import:
usr/lib64/calibre/calibre/test_build.py:import _imaging,
_imagingmath, _imagingft
usr/lib64/calibre/calibre/test_build.py:_imaging,
_imagingmath, _imagingft
usr/lib64/calibre/calibre/test_build.py:from PIL import
_imaging, _imagingmath, _imagingft
usr/lib64/calibre/calibre/test_build.py:_imaging, _imagingmath,
_imagingft

Note that this is a test script thats not run as part of the build,
however, it is shipped in the rpm for people to use, so we do need to
fix it.

Can you whip up a patch? Otherwise I can try and do so...
I would suggest to simply remove the imports of _imaging, _imagingmath 
and  _imagingft, since
- They are "low-level" modules which are imported by the "high-level" 
Imaging* modules. If they are missing, the import of the high-level 
Imaging module fails.

- They are never imported directly elsewhere in the calibre codebase.

A corresponding patch is here [1].

- Sandro


[1] http://smani.fedorapeople.org/calibre-_imaging.patch
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Who uses abi-compliance-checker?

[Xavier Bachelot]

On 07/03/2013 10:03 PM, Richard Shaw wrote:
> I initially got abi-compliance-checker into Fedora because one of my packages
> does not maintain any sort of API/ABI compatibility or even versioning for 
> that
> matter. That way I could always check a new release to see if any of its
> dependencies needed to be rebuilt.
> 
> Since then, I've started using it for all of my libraries in the spirit of
> "Trust but verify", and I've occasionally found issues even though upstream
> didn't bump the soversion.
> 
> So out of curiosity, anyone else using this great tool?
>
I'm not using abi-compliance-checker by itself but through the pkgdiff wrapper.
I agree this tool is very helpful.

Regards,
Xavier

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

Re: More unhelpful update descriptions

[Michael Catanzaro]

On Wed, 2013-07-03 at 16:33 +0100, Richard W.M. Jones wrote:
> 
> SuSE too ...
> 
> Rich.
But they reformat everything by hand. For a representative example,
compare:

https://git.gnome.org/browse/evolution/tree/NEWS
with
https://build.opensuse.org/package/view_file/openSUSE:Factory/evolution?expand=1&file=evolution.changes

And every single update has a high-quality description of what
specifically has been fixed in that update, completely separate from the
RPM log.

Aside: the SUSE .changes file is included in the .spec by a macro (%
changelog). This makes the .specs themselves about 10x smaller than
Fedora .specs, and accordingly much easier to scroll through and work
with.


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: Who uses abi-compliance-checker?

[Richard Shaw]

On Wed, Jul 3, 2013 at 4:33 PM, Sérgio Basto  wrote:

> On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
> > I initially got abi-compliance-checker into Fedora because one of my
> > packages does not maintain any sort of API/ABI compatibility or even
> > versioning for that matter. That way I could always check a new
> > release to see if any of its dependencies needed to be rebuilt.
> >
> >
> > Since then, I've started using it for all of my libraries in the
> > spirit of "Trust but verify", and I've occasionally found issues even
> > though upstream didn't bump the soversion.
> >
> >
> > So out of curiosity, anyone else using this great tool?
> >
> >
> > If anyone is curious about it, I don't mind typing up the process I go
> > through to make the checks. I think I've found a pretty good path of
> > least resistance method :)
>
> could we use this tool on x264/ffmpeg/mplayer packages ?
>

Yes, I'm trying it out, but it looks like there's some windows only headers
installed trying to include d3d9.h which are tripping it up...

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

Re: Who uses abi-compliance-checker?

[Paulo César Pereira de Andrade]

IBook. 'Kiomjm
Em 03/07/2013 19:00, "Xavier Bachelot"  escreveu:

> On 07/03/2013 10:03 PM, Richard Shaw wrote:
> > I initially got abi-compliance-checker into Fedora because one of my
> packages
> > does not maintain any sort of API/ABI compatibility or even versioning
> for that
> > matter. That way I could always check a new release to see if any of its
> > dependencies needed to be rebuilt.
> >
> > Since then, I've started using it for all of my libraries in the spirit
> of
> > "Trust but verify", and I've occasionally found issues even though
> upstream
> > didn't bump the soversion.
> >
> > So out of curiosity, anyone else using this great tool?
> >
> I'm not using abi-compliance-checker by itself but through the pkgdiff
> wrapper.
> I agree this tool is very helpful.
>
> Regards,
> Xavier
>
> --
> 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: Who uses abi-complian. V. I UVce-checker?

[Paulo César Pereira de Andrade]

/  lo" m'
Em 03/07/2013 21:16, "Richard Shaw"  escreveu:

> On Wed, Jul 3, 2013 at 4:33 PM, Sérgio Basto  wrote:
>
>> On Qua, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
>> > I initially got abi-compliance-checker into Fedora because one of my
>> > packages does not maintain any sort of API/ABI compatibility or even
>> > versioning for that matter. That way I could always check a new
>> > release to see if any of its dependencies needed to be rebuilt.
>> >
>> >
>> > Since then, I've started using it for all of my libraries in the
>> > spirit of "Trust but verify", and I've occasionally found issues even
>> > though upstream didn't bump the soversion.
>> >
>> >
>> > So out of curiosity, anyone else using this great tool?
>> >
>> >
>> > If anyone is curious about it, I don't mind typing up the process I go
>> > through to make the checks. I think I've found a pretty good path of
>> > least resistance method :)
>>
>> could we use this tool on x264/ffmpeg/mplayer packages ?
>>
>
> Yes, I'm trying it out, but it looks like there's some windows only
> headers installed trying to include d3d9.h which are tripping it up...
>
> Richard
>
> --
> 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: Who uses abi-compliance-checker?

[Richard Shaw]

This is an extreme example, but after removing the offending headers I got
this:

https://dl.dropboxusercontent.com/u/34775202/compat_reports/ffmpeg/0.10.7_to_1.2.1/compat_report.html

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

Re: Who uses abi-compliance-checker?

[Mathieu Bridon]

On Wed, 2013-07-03 at 15:03 -0500, Richard Shaw wrote:
> If anyone is curious about it, I don't mind typing up the process I go
> through to make the checks. I think I've found a pretty good path of least
> resistance method :)

I've never used it, but I'd certainly be interested in reading that if
you ever write it up. :)


-- 
Mathieu

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

Re: Who uses abi-compliance-checker?

[Sérgio Basto]

On Qui, 2013-07-04 at 00:00 +0200, Xavier Bachelot wrote: 
> On 07/03/2013 10:03 PM, Richard Shaw wrote:
> > I initially got abi-compliance-checker into Fedora because one of my 
> > packages
> > does not maintain any sort of API/ABI compatibility or even versioning for 
> > that
> > matter. That way I could always check a new release to see if any of its
> > dependencies needed to be rebuilt.
> > 
> > Since then, I've started using it for all of my libraries in the spirit of
> > "Trust but verify", and I've occasionally found issues even though upstream
> > didn't bump the soversion.
> > 
> > So out of curiosity, anyone else using this great tool?
> >
> I'm not using abi-compliance-checker by itself but through the pkgdiff 
> wrapper.
> I agree this tool is very helpful.

pkgdiff and abi-compliance-checker seems to be a very cool tool,
unfortunately now, I'm very busy and haven't time to investigate
further, or just to follow this thread ... 
anyway IIRC I think that what Nicolas (kwizart) ask for when we want
bump soname on ffmpeg and others packages etc ...   So maybe this is
interesting for rpmfusion  . 

-- 
Sérgio M. B.

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

Re: Who uses abi-compliance-checker?

[Remi Collet]

Le 03/07/2013 22:03, Richard Shaw a écrit :
> I initially got abi-compliance-checker into Fedora because one of my
> packages does not maintain any sort of API/ABI compatibility or even
> versioning for that matter. That way I could always check a new release
> to see if any of its dependencies needed to be rebuilt.
> 
> Since then, I've started using it for all of my libraries in the spirit
> of "Trust but verify", and I've occasionally found issues even though
> upstream didn't bump the soversion.
> 
> So out of curiosity, anyone else using this great tool?

I used it for some libraries I maintain.
http://rpms.famillecollet.com/compat_reports/

But I also use http://upstream-tracker.org/
Very usefull, except for not yet released version.

Remi

> 
> If anyone is curious about it, I don't mind typing up the process I go
> through to make the checks. I think I've found a pretty good path of
> least resistance method :)
> 
> Thanks,
> Richard
> 
> 

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