Re: Why should I ever bother filing another bug?

[Michael Schwendt]

On Sun, 07 Nov 2010 19:07:08 -0500, Digimer wrote:

> Try popping by IRC and asking why a particular bug hasn't been acted on.

Does that scale?

> If it's a lack of time, then there you go.

I wouldn't expect somebody to lurk on IRC then and visit a ticket just
because someone else makes some noise.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Peter Lemenkov]

2010/11/8 Felix Miata :
> https://bugzilla.redhat.com/show_bug.cgi?id=623742 was duped to newer bug
> https://bugzilla.redhat.com/show_bug.cgi?id=624297
>
> The older:

[sorry, skipped]

> 4-has 48 CCs

This is a known issue in  (at least in RedHat's) bugzilla. If you
close bug "A" as duplicate of another bug "B", then all your CC-ed to
bug "A" users won't re-subscribed to bug "B".

Bugzilla is evil.
-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Peter Lemenkov]

2010/11/8 Peter Lemenkov :
> 2010/11/8 Felix Miata :
>> https://bugzilla.redhat.com/show_bug.cgi?id=623742 was duped to newer bug
>> https://bugzilla.redhat.com/show_bug.cgi?id=624297
>>
>> The older:
>
> [sorry, skipped]
>
>> 4-has 48 CCs
>
> This is a known issue in  (at least in RedHat's) bugzilla. If you
> close bug "A" as duplicate of another bug "B", then all your CC-ed to
> bug "A" users won't re-subscribed to bug "B".

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

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide report: 20101108 changes

[Rawhide Report]

Compose started at Mon Nov  8 08:15:29 UTC 2010

Broken deps for x86_64
--
abrt-gui-1.1.13-2.fc15.x86_64 requires libnotify.so.1()(64bit)
apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit)
balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit)
beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit)
beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit)
bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1
bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit)
claws-mail-plugins-notification-3.7.6-7.fc15.x86_64 requires 
libnotify.so.1()(64bit)
cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit)
cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit)
clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 
0:1.3.0
clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 
0:1.3.0
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()(64bit)
dh-make-0.55-2.fc15.noarch requires debhelper
edje-0.9.99.49898-1.fc14.i686 requires libecore_evas-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libecore_imf-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libembryo-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libecore_imf_evas-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.i686 requires libevas-ver-svn-06.so.0
edje-0.9.99.49898-1.fc14.x86_64 requires 
libevas-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libeina-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libecore_file-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libembryo-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libecore_evas-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libecore_imf-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libecore-ver-svn-06.so.0()(64bit)
edje-0.9.99.49898-1.fc14.x86_64 requires 
libecore_imf_evas-ver-svn-06.so.0()(64bit)
edje-devel-0.9.99.49898-1.fc14.i686 requires pkgconfig(eina-0)
edje-devel-0.9.99.49898-1.fc14.x86_64 requires pkgconfig(eina-0)
eekboard-0.0.5-3.fc15.x86_64 requires libnotify.so.1()(64bit)
efreet-0.5.0.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0
efreet-0.5.0.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0
efreet-0.5.0.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0
efreet-0.5.0.49898-1.fc14.x86_64 requires 
libeina-ver-svn-06.so.0()(64bit)
efreet-0.5.0.49898-1.fc14.x86_64 requires 
libecore-ver-svn-06.so.0()(64bit)
efreet-0.5.0.49898-1.fc14.x86_64 requires 
libecore_file-ver-svn-06.so.0()(64bit)
efreet-devel-0.5.0.49898-1.fc14.i686 requires pkgconfig(eina-0)
efreet-devel-0.5.0.49898-1.fc14.x86_64 requires pkgconfig(eina-0)
empathy-2.91.0-4.fc15.x86_64 requires libnotify.so.1()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libeconnman-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libevas-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libeina-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libehal-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_input_evas-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libedbus-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_input-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_file-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_evas-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libebluez-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libeofono-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_x-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_imf-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_con-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore-ver-svn-06.so.0()(64bit)
enlightenment-0.16.999.49898-1.fc14.x86_64 requires 
libecore_ipc-ver-svn-06.so.0()(

Re: Fedora - Cold Boot Attack

[Petr Pisar]

On 2010-11-06, Vaclav Mocek  wrote:
>
> It would be usefull to overwrite some parts of memory (keys etc.), 
> before the computer is switched off. So, my question is: Is there 
> already implemented and used some kind of protection?
>
There was a patch for Linux to scramble memory just before halt. However
it has not been pushed to developers nor incoroporated into the Linux.

Unfortunatelly, I cannot find it now. It's few years old code. I rember
it had solved more problems than just this one and that the patch
touched halt(8) utility and kernel.

-- Petr

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

Re: Fedora - Cold Boot Attack

[Petr Pisar]

On 2010-11-06, Vaclav Mocek  wrote:
>
> I work like an Embedded SW/HW Developer and my experience is that data 
> could remain in the dynamic memory for quite long time, even in the room 
> temperature. I have used it successfully for debugging, when a booting 
> routine after the cold reset copies some parts of memory to another 
> location which could be read lately.
>
> It would be usefull to overwrite some parts of memory (keys etc.), 
> before the computer is switched off. So, my question is: Is there 
> already implemented and used some kind of protection?
>

Acctully there is better approach---to encrypt data destinated for
operating system/processes in CPU. This would prevent attacks by
unclean shutdown.

One of the problem is where to store the key. I found a thesis

right now which describes working implementation using SSE registers as
a permanent (untill power cycle) storage for the key. I have not read it
yet but it looks promissing.

-- Petr

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

Re: Fedora - Cold Boot Attack

[Petr Pisar]

On 2010-11-08, Petr Pisar  wrote:
> One of the problem is where to store the key. I found a thesis
>
> right now which describes working implementation using SSE registers as
> a permanent (untill power cycle) storage for the key. I have not read it
> yet but it looks promissing.
>
So, after quick reading, this is not what I expected. This is just
another kernel block cypher used by dmcrypt to (de)crypt block device
data guartneeing encryption key does no leave CPU by storing the key in
SSE register. The drawback is nobody can use SSE instructions then.

-- Petr

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

Re: bugzilla bugzappers?

[Benjamín Valero Espinosa]

2010/11/6 Till Maas

> On Sat, Nov 06, 2010 at 12:23:00PM +0200, Alexander Kurtakov wrote:
>
> > Why does everyone want to put more and more burden on maintainers and
> arguing
> > about small things that users should do?
> > How can you expect a maintainer to fix/respond to hundreds of bugs and
> not
> > expect the user to verify his/her bug still applies?
>

I am an example of a user who sometimes send a report through ABRT but
rarely replies in it, because I have no idea how to reproduce it. For
example, if "randomly" (from my user point of view) Firefox or Empathy
crashes, I suppose that the debug trace is enough for the author to see the
problem. Unfortunately, if the maintainer asks me for more info, I will
hardly be able to give it, because for me the crashes are random.

Sometimes I can guess a possible way of reproducing the bug, and then I add
it as a comment in ABRT, but this is very strange.

So please, don't blame users for not replying bugs, because most of them
will think that pushing the button (and waiting for all the debug packages
to download) are enough work for them. Besides, most of them perhaps even
don't speak English.

Sometimes I try to help finding duplicates, and I find bugs not detected
automatically by ABRT because, although the trace is almost identical, the
bug title is not, because the version of the package has changed a little.
Perhaps this could be improved.

Sorry for the noise.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla bugzappers?

[Jiri Moskovcak]

On 11/06/2010 02:53 AM, Ralf Corsepius wrote:
> On 11/05/2010 09:46 PM, Michael Schwendt wrote:
>> On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
>>
>>> ABRT
>>
>>> It doesn't tell the user that core dumps without reproducer are
>>> worthless in most cases but blindly sends out reports
>>
>> Parts of the Fedora user base "abuse" ABRT in that they refuse to
>> fill in the empty fields. Blame the reporters not the tool.
> A matter of point of view: To me this is an ABRT GUI issue. It currently
> doesn't suck as much as it did before, nevertheless its usability still
> leaves much to be desired.
>

- please, send me some ideas or mockups and I will be more than happy to 
change the GUI... but just complaining "it sucks" doesn't give me much 
information what to fix ...

> As yourself:
> What would you do if you were a "simple computer user" and are facing
> this "flash bulb icon" asking you to become "root"

- this is not true, you don't need a root for user crashes, so please 
don't lie ...

> and to get a bugzilla
> account?

- yes, that's unfortunate, but what would be the solution here? allowing 
some anonymous account will lead to even worse situation...

>
>You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty
> soon, when you call him for the "Nth time".

- don't understand, why would you call admin? maybe this comes from the 
wrong presumption that ABRT needs root...

>As a user you'd also think "what kind of crap is this Fedora/Linux -
> the WinXP I have at home is better".
>

- hm, wxp bug reporting is nice, because end-users can't even see where 
the bug went and check it's progress... if someone thinks it's better 
then...then I won't try to argue with him...

>> It's too
>> easy for such people to open tickets via ABRT and then ignore
>> a maintainer's NEEDINFO request.
> Correct - But the same applies to maintainers.
>
> My experience is, most of them ignore ABRT reports, probably because
> the ABRT reports are not helpful to them and/or don't contain sufficient
> infos.
>

- again and again and again - We know ABRT is not able to provide a good 
debug informations for every application we have, but the solution is 
not ignoring the bugs, but send us email or create a RFE in bugzilla 
describing what additional info you'd like and how/where to get it ...

>> It's disheartening in some cases, but
>> it's a people-problem not a tool-problem.
> I disagree - IMO; ABRT is not end-user ready. It presumes end-users
> to be familiar with redhat's infrastructure, which is a developer
> infrastructure and them to be interested to get involved into Fedora
> development. This simply does not apply.
>
>>> Also, this produces incomplete traceback in many (IMO all) cases.
>>
>> Cannot confirm that.
>
> In almost all cases, I am observing missting debuginfos even after
> executing debuginfo-installs.
>
>   >  There seem to be some issues with not finding the
>> needed debuginfo packages, which may be related to frequent updates of
>> repos and older packages getting pruned. It may also be related to users
>> updating their boxes at strange times, e.g. seldomly but immediately after
>> a crash.
>
> Possible. This certainly this applies in some cases.
>
> However, I am experiencing missing debuginfos after debuginfo-install
> even with what is supposed to be "uptodate" Fedora installations.
>

- not ABRT problem,, but there are some projects trying to deal with 
this which I mentioned in one of my previous emails.. (debuginfofs and 
retrace server)

> Ralf

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

Re: Fedora - Cold Boot Attack

[Gregory Maxwell]

On Sun, Nov 7, 2010 at 1:57 PM, Stephen John Smoogen  wrote:
> Ok there are several different "cold boot attacks". The one  I think
> you are talking about is the removing memory from the system and
> reading its contents with a special board. The kernel does not
[snip]

Not even with a special board, ...

> In the end, if someone has physical access to your system, you are not
> going to be able to completely defend against a cold boot attack.
> Encrypting the drive and keeping it reasonably secure is about all you
> can do without having hardware that helps.

Here is the attack:  Your system is running with nice secure encrypted
drives, no console access (or a locked screen on a laptop). The
attacker inserts a bootable USB key and hits the power switch. System
reboots into the USB key, it retrieves the cryptographic keys for
reading your disk from memory, then copies whatever information it
likes.

This works even when a fairly high percentage of the key bits are
corrupted because the bits of the AES key schedule have simple linear
relationships with the key, so it functions as an excellent error
correcting code.

For some common situations like protecting your laptop with disk
encryption this attack completely invalidates the protection, at least
against a moderately savvy attacker.

The software for performing this attack is available from here:
http://citp.princeton.edu/memory/code/

This is not merely a theoretical weakness. It is easily executable by
anyone without the need for special hardware.

Without special hardware (like support for CPU-internal key
management, CPU support for encrypted ram) this attack is impossible
to close completely but small improvement could easily be made which
dramatically increased the difficulty of the attack.

* The kernel could avoid leaving confidentiality critical data laying
around for long spans of time, long term keying could be stored in
areas of memory more reliably overwritten at reboot

* Bioses could be modified to zero-ize memory at start

* Ciphers with linear key-schedules could be avoided (unfortunately
everything from the AES contest is bad at this, because the contest
pressure to work on low memory devices and small message sizes made
everyone use very cheap initialization; blowfish is an example of
something which I think is mostly free of that particular weakness)

* Userspace could freeze all access to encrypted volumes when the
screen is locked and toss the keys. (This is most reasonable when the
volume password and the user's login password are the same)


There were patches posted to the Linux kernel to reduce the exposure
from this kind of attack: http://lwn.net/Articles/334747/  but
unfortunately the author and the LKML didn't get along and the patches
were never merged.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: bugzilla bugzappers?

[Ralf Corsepius]

On 11/08/2010 01:34 PM, Jiri Moskovcak wrote:
> On 11/06/2010 02:53 AM, Ralf Corsepius wrote:
>> On 11/05/2010 09:46 PM, Michael Schwendt wrote:
>>> On Fri, 05 Nov 2010 17:56:51 +0100, Ralf wrote:
>>>
 ABRT
>>>
 It doesn't tell the user that core dumps without reproducer are
 worthless in most cases but blindly sends out reports
>>>
>>> Parts of the Fedora user base "abuse" ABRT in that they refuse to
>>> fill in the empty fields. Blame the reporters not the tool.
>> A matter of point of view: To me this is an ABRT GUI issue. It currently
>> doesn't suck as much as it did before, nevertheless its usability still
>> leaves much to be desired.
>>
>
> - please, send me some ideas or mockups and I will be more than happy to
> change the GUI... but just complaining "it sucks" doesn't give me much
> information what to fix ...
ABRT is your baby. You can't expect others doing your job.

Some food for you to think about:
- get rid of bugzilla accounts
- get rid of forcing users to fillup their systems with debuginfos.
- make the layout usable.
...

>> As yourself:
>> What would you do if you were a "simple computer user" and are facing
>> this "flash bulb icon" asking you to become "root"
>
> - this is not true, you don't need a root for user crashes, so please
> don't lie ...
Ignoring the rudity of this part of your respone, debuginfo-install 
requires root. Remove the debuginfo-install stuff and what you say will 
become true.

>> You'd call your sys-admin, who'll deinstall or deactivate ABRT pretty
>> soon, when you call him for the "Nth time".
>
> - don't understand, why would you call admin?

... because a "simple computer user", will not understand what this 
"flash bulb" etc. is about, what debuginfos are, what a core dump is, 
has never heard about bugzilla, kerneloopes etc.

> maybe this comes from the
> wrong presumption that ABRT needs root...
No. It comes from you apparently being the father of ABRT and being too 
close to it.

Take a person, without a IT background and without Linux familarity, 
e.g. somebody whose computer usage basically is working with a handful 
of GUI apps (firefox, thunderbird, openoffice) and confront this person 
with a nautilus ARBT (without having him told in advance)

... watch for what will happen ...

>> As a user you'd also think "what kind of crap is this Fedora/Linux -
>> the WinXP I have at home is better".
>>
>
> - hm, wxp bug reporting is nice, because end-users can't even see where
> the bug went and check it's progress... if someone thinks it's better
> then...then I won't try to argue with him...
correct ... WinXP hides those details "uneducated users" will not be 
able to understand.

 From an "uneducated user's POV" this is the easier to use alternative. 
 From an educated user's POV it's the worst of all possible solutions.

> - again and again and again - We know ABRT is not able to provide a good
> debug informations for every application we have, but the solution is
> not ignoring the bugs, but send us email or create a RFE in bugzilla
> describing what additional info you'd like and how/where to get it ...
Again and again, I say: Critical serious and reproducable bugs have 
always been manually reported before ABRT was around. ABRT does not 
provide substantial benefits wrt. the qualtiy of Fedora and fixing 
"critical and serious" bugs.


>> However, I am experiencing missing debuginfos after debuginfo-install
>> even with what is supposed to be "uptodate" Fedora installations.
>>
>
> - not ABRT problem,,
Pardon - What? The foundations of your works are based on, are flawed 
and you are saying this is not your problem?

With all due respect, but you can't be serious.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

What are differences between real and rpmbuild's environment?

[Michal Hlavinka]

Hi,

I'm trying to find out what are differences between environment for local rpm 
build and usual user's environment. I've added regression tests to %check 
section of ksh spec file. These tests never fails when executed in user's 
environment, but some of them always fail when executed as part of rpm build 
process. I've tried to compare variable in the environment and ulimit values, 
but there does not seem to be any significant difference. I've also tried to 
use 
the same script generated by rpmbuild for %check section (from 
/var/tmp/rpm.*), but still it does not reproduce the problem. Any ideas?

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

Re: What are differences between real and rpmbuild's environment?

[Rex Dieter]

Michal Hlavinka wrote:

> I'm trying to find out what are differences between environment for local
> rpm build and usual user's environment. 

You mean the difference between rpmbuild and... a manual "./configure; 
make"?

For starters, see rpm's output from

rpm --eval "%{configure}" which sets variance build/optimization flags.

and rpmbuild also does:
LANG=C ; export LANG
unset DISPLAY

-- Rex

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

[Review swap] Reviewer needed for emacs-auto-complete

[Michel Alexandre Salim]

Dear fellow packagers,

I just created a package for auto-complete, an intelligent auto-
completion extension for Emacs.

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

See screenshots on the project page:

http://cx4a.org/software/auto-complete/

Would anyone want to swap one of their review tickets for this?

Thanks,

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

Email:  sali...@fedoraproject.org  | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de   | IRC: hir...@irc.freenode.net

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Orphaning a few packages

[Adam Jackson]

I've got some stuff that I can't really give proper attention to, and
I'd rather not even get the bugmail.  I just packaged them because I
wanted to consume them, not because I wanted to own them.  So, free to a
good home:

bing
bootchart
powertop
wdfs

Already orphaned in pkgdb for rawhide, first come first served.

- ajax

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

Re: [Review swap] Reviewer needed for emacs-auto-complete

[Arun SAG]

Hi,

On Mon, Nov 8, 2010 at 9:20 PM, Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

>
>
> >Would anyone want to swap one of their review tickets for this?
>
>
I would like to review the package. Here is mine
https://bugzilla.redhat.com/show_bug.cgi?id=632858
-- 
Arun S.A.G
http://zer0c00l.in/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning a few packages

[Jean-Francois Saucier]

On Mon, Nov 8, 2010 at 11:16 AM, Adam Jackson  wrote:
> bing
> wdfs

Hi Adam,

I just took ownership of bing and wdfs.


Thanks!

-- 
Jean-Francois Saucier (djf_jeff)
GPG key : 0xA9E6E953
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Ankur Sinha]

On Mon, 2010-11-08 at 11:58 +0300, Peter Lemenkov wrote:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=523634 

Added comments with the *latest* example. The bug last had a reply from
the maintainer in 2009. Somehow, he called it a "feature request" rather
than a bug[1]. *shrug*

[1] https://bugzilla.redhat.com/show_bug.cgi?id=523634#c2

-- 
Thanks!
Regards,
Ankur 

https://fedoraproject.org/wiki/User:Ankursinha

"FranciscoD"

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

Orphaning yakuake

[Johan Cwiklinski]

Hello,

I've just orphaned yakuake on all branches ; I do not longer use it.

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

Re: What are differences between real and rpmbuild's environment?

[Richard W.M. Jones]

On Mon, Nov 08, 2010 at 03:49:28PM +0100, Michal Hlavinka wrote:
> I'm trying to find out what are differences between environment for
> local rpm build and usual user's environment. I've added regression
> tests to %check section of ksh spec file. These tests never fails
> when executed in user's environment, but some of them always fail
> when executed as part of rpm build process. I've tried to compare
> variable in the environment and ulimit values, but there does not
> seem to be any significant difference. I've also tried to use the
> same script generated by rpmbuild for %check section (from
> /var/tmp/rpm.*), but still it does not reproduce the problem. Any
> ideas?

Is the spec file using %configure?  That adds a lot of flags to the
configure script.  Similarly make _vs_ make %{_smp_flags}.

Have you tried 'printenv' at the top of the %check section?

Are you specifically running rpmbuild as the same user?  Or are we
talking about rpmbuild in some other environment (mock or Koji)?
There is a Koji bug which affects ksh %check in particular
(RHBZ#639275).

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://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning yakuake

[Jochen Schmitt]

  Am 08.11.10 18:22, schrieb Johan Cwiklinski:
> Hello,
>
> I've just orphaned yakuake on all branches ; I do not longer use it.
I will take it.

Best Regards:

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

Re: bugzilla bugzappers?

[Till Maas]

On Sat, Nov 06, 2010 at 04:22:29PM +0200, Alexander Kurtakov wrote:

> We can argue about this a lot (e.e.  submitter can reopen bug whenever he 
> finds 
> the time to verify the bug).  

The problem is, there is no proper way to track whether a bug has been
verified, because the result may also be, that it is fixed.

> So the real problem is the notice period? 
> Will it help if there is 6 weeks notice instead of 4?
> Any other idea?

It would also help if the bugs won't be closed when F12 is EOL to allow
some time to migrate to the next Fedora release, handle the new issues
and then take the time to check for old ones. So maybe first notify 6
weeks before the EOL date, then when it is EOLed again and close the bug
6 weeks after the EOL date.

Nevertheless, I would welcome it more if bug submitters would only be
asked to verify a bug when there is some maintainer available to fix
the verified bug.

Regards
Till


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

Re: Orphaning a few packages

[Jaroslav Skarvada]

> powertop

I took powertop, thanks

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

Re: rawhide report: 20101108 changes

[Paul F. Johnson]

Hi,

>   db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0

Problem here is that db4o now uses a newer version of mono-cecil and
mono-cecil-flowanalysis. The current fedora version flowanalysis is
something like 0.6 whereas head it 0.9.

However, it's not as simple as building 0.9 to get things working...

>   deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()

Lots seem broken with libnotify.so.1 - any chance of pushing rebuilds?

TTFN

Paul
-- 
Vertraue mir, ich weiss, was ich mache...

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

Re: rawhide report: 20101108 changes

[Michael Schwendt]

On Mon, 08 Nov 2010 20:19:17 +, Paul wrote:

> > deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()
> 
> Lots seem broken with libnotify.so.1 - any chance of pushing rebuilds?

http://lists.fedoraproject.org/pipermail/devel/2010-November/144914.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Multilib issue with hard-coded paths in mash script

[Matthias Clasen]

On Sun, 2010-11-07 at 00:43 +0100, Christian Krause wrote:
> Hi,

> The whole issue raises now some questions:
> 
> 1. Specifically with respect to the problem with gdk-pixbuf: Should the
> gdk-pixbuf loaders be multilib or not? If yes, the mash script must be
> adjusted.
> 
> 2. Should the mash script be reviewed whether there are any other
> hard-coded paths outdated? Should the script even be Fedora release
> specific?
> 

Sigh, multilib is just so broken...
 
The loaders are shared objects, and the 64-bit modules won't help you on
32-bit, so yes, they need to be multilib.

And yes, having hardcoded paths like that stored in a script without the
package maintainers knowledge is a good way to have breakage like this.


Matthias



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

File Net-Patricia-1.18_80.tar.gz uploaded to lookaside cache by philipp

[Philip Prindeville]

A file has been added to the lookaside cache for perl-Net-Patricia:

c88ad7b5da63e34b58c07bece1089ac8  Net-Patricia-1.18_80.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: Ubuntu moving towards Wayland

[Adam Williamson]

On Sat, 2010-11-06 at 16:41 +, Richard W.M. Jones wrote:

> Really, I have no
> problem using my keyboard,

Given your location and native language, I suspect your keyboard layout
is en_US, in which case this isn't much of a surprise - it's one of the
simplest cases (it requires one of the fewest numbers of characters of
any layout) and it's also the one which gets most attention, development
and testing.

If you spoke Chinese - or, even better, something Indic - you may have a
different perspective. =)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Why should I ever bother filing another bug?

[Adam Williamson]

On Sun, 2010-11-07 at 19:00 -0500, Felix Miata wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=623742 was duped to newer bug 
> https://bugzilla.redhat.com/show_bug.cgi?id=624297
> 
> The older:
> 
> 1-began life with equivalent summary: "system-config-display fails "
> 
> 2-contains same comment 0 information as the latter
> 
> 3-was directed to be filed by triagers on IRC
> 
> 4-has 48 CCs
> 
> If bug fixers plan to only fix bugs they themselves file or randomly choose 
> to attach patches to, there's no need for anyone else to file bugs, as the 
> fixers obviously can't be bothered to see what bugs already have been filed. 
> They might as well be the only testers too.
> 
> If I was a regular triager in Redhat's Bugzilla, this would put an end to it.

jeez, over-react much?

The duping was done by Lubomir, as he was providing a patch to fix the
problem (which is, lest we forget, what we all wanted in the first
place). He explained his reasoning right in the comment. I don't know
why you think it's a great idea to blow this up into a huge issue on a
mailing list.

We have fairly permissive permissions on Bugzilla, because we don't have
enough people to rule it with an iron fist, so we mostly trust people to
Get It Right. If there's a major ongoing systemic problem we have
mechanisms for dealing with it. A case where one other community member
did something you disagree with while he was busy actually fixing the
bug really doesn't qualify, IMO.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Multilib issue with hard-coded paths in mash script

[Christian Krause]

Hi,

On 11/08/2010 11:15 PM, Matthias Clasen wrote:
>> 1. Specifically with respect to the problem with gdk-pixbuf: Should the
>> gdk-pixbuf loaders be multilib or not? If yes, the mash script must be
>> adjusted.
>  
> The loaders are shared objects, and the 64-bit modules won't help you on
> 32-bit, so yes, they need to be multilib.

Thanks for the info - I've added all relevant information to the
mentioned bug report [1] and moved it to the "mash" component.

Best regards,
Christian

[1] https://bugzilla.redhat.com/show_bug.cgi?id=649339
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide report: 20101108 changes

[Adam Williamson]

On Mon, 2010-11-08 at 22:21 +0100, Michael Schwendt wrote:
> On Mon, 08 Nov 2010 20:19:17 +, Paul wrote:
> 
> > >   deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()
> > 
> > Lots seem broken with libnotify.so.1 - any chance of pushing rebuilds?
> 
> http://lists.fedoraproject.org/pipermail/devel/2010-November/144914.html

IOW, it's not a straight rebuild, you generally need to port a bit.

(I just fixed xchat-gnome, because it was a simple fix and it's the only
thing still broken that I personally use.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: [Review swap] Reviewer needed for emacs-auto-complete

[Michel Alexandre Salim]

On Mon, 08 Nov 2010 22:03:25 +0530, Arun SAG wrote:

> Hi,
> 
> On Mon, Nov 8, 2010 at 9:20 PM, Michel Alexandre Salim <
> sali...@fedoraproject.org> wrote:
> 
> 
>>
>> >Would anyone want to swap one of their review tickets for this?
>>
>>
> I would like to review the package. Here is mine
> https://bugzilla.redhat.com/show_bug.cgi?id=632858

Wonderful, thanks!

-- 
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/

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

[perl-Net-Patricia] Maintenance version update.

[Philip Prindeville]

commit 2075f03bc12a7e1a7520f99ceba32741746eff77
Author: Philip Prindeville 
Date:   Mon Nov 8 16:20:27 2010 -0700

Maintenance version update.

 .gitignore |1 +
 perl-Net-Patricia.spec |   10 +++---
 sources|2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 58d5de2..2f97c50 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 Net-Patricia-1.17_01.tar.gz
 /Net-Patricia-1.18.tar.gz
 /Net-Patricia-1.18_01.tar.gz
+/Net-Patricia-1.18_80.tar.gz
diff --git a/perl-Net-Patricia.spec b/perl-Net-Patricia.spec
index 1ae9941..c5f4bdc 100644
--- a/perl-Net-Patricia.spec
+++ b/perl-Net-Patricia.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-Patricia
-Version:1.18_01
-Release:2%{?dist}
+Version:1.18_80
+Release:1%{?dist}
 Summary:Patricia Trie perl module for fast IP address lookups
 License:Distributable, see COPYING
 Group:  Development/Libraries
@@ -61,7 +61,11 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
-* Sun Nov  7 2010 Philip Prindeville  - 1.18_01-01
+* Mon Nov  8 2010 Philip Prindeville  - 1.18_80-1
+- new upstream version, maintenance fix
+  - still doesn't handle 0 being passed as data argument to add()
+
+* Sun Nov  7 2010 Philip Prindeville  - 1.18_01-1
 - new upstream version, maintenance fix
   - bug in AFINET6 version of add() method.
 
diff --git a/sources b/sources
index ac7e48d..019cab8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-322326acedb249df29c4f3605dbb77f2  Net-Patricia-1.18_01.tar.gz
+c88ad7b5da63e34b58c07bece1089ac8  Net-Patricia-1.18_80.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: Orphaning a few packages

[Rafael Azenha Aquini]

On Mon, Nov 08, 2010 at 11:16:18AM -0500, Adam Jackson wrote:
> bootchart

Adam, I took this package ownership.

best regards 
-- 
Rafael Aquini 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Felix Miata]

On 2010/11/08 18:01 (GMT-0500) Adam Williamson composed:

> The duping was done by Lubomir, as he was providing a patch to fix the
> problem (which is, lest we forget, what we all wanted in the first
> place). He explained his reasoning right in the comment. I don't know
> why you think it's a great idea to blow this up into a huge issue on a
> mailing list.

His explanation "useless chatter" was nothing but an excuse. There was no 
material useless chatter there. Useless chatter is complaining, advocating, 
or asking for personal support, none of which was in the original, which, 
unlike the latter, dates the origin of the problem more accurately.

Lubomir made exactly zero comments in the original prior to duping it, a 
likely indicator that he didn't bother to even look for it before duping, or 
check to see its longer history included the newer bug's content.

> A case where one other community member
> did something you disagree with while he was busy actually fixing the
> bug really doesn't qualify, IMO.

If the policy can't be clear that _reasonable_ justification is prerequisite 
to duping an older bug to a newer, and some semblance of enforcement applied, 
then I don't need to file any more bugs, or test any further. I don't see why 
many others would either, or why triagers would waste their time.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Adam Williamson]

On Mon, 2010-11-08 at 19:51 -0500, Felix Miata wrote:

> If the policy can't be clear that _reasonable_ justification is prerequisite 
> to duping an older bug to a newer, and some semblance of enforcement applied, 
> then I don't need to file any more bugs, or test any further. I don't see why 
> many others would either, or why triagers would waste their time.

So, again: Lubomir fixed the bug. The bug is fixed. That gets him a lot
of leeway in my world. One person fixing the bug is a lot more use than
500 people reporting it and going 'what is the status of this bug?!'

I don't see why this is a huge deal. There's a bug in Bugzilla that it
doesn't merge CC lists when you dupe bugs, yeah. Aside from that? What's
the huge problem with duping an older bug to a newer one?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Why should I ever bother filing another bug?

[Felix Miata]

On 2010/11/08 18:06 (GMT-0800) Adam Williamson composed:

> I don't see why this is a huge deal. There's a bug in Bugzilla that it
> doesn't merge CC lists when you dupe bugs, yeah. Aside from that? What's
> the huge problem with duping an older bug to a newer one?

Like I said, let the people who actually fix bugs both find them and file 
them. There's no point in anyone else bothering. Triagers won't be necessary, 
saving everyone time, cluttering the tracker with fewer dupes. And, they'll 
always look, according to buglists, as if they were fixed more quickly than 
they really were. Everybody wins, except those who can't fix bugs but would 
like to feel their testing and reporting serves a purpose.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why should I ever bother filing another bug?

[Adam Williamson]

On Mon, 2010-11-08 at 21:30 -0500, Felix Miata wrote:
> On 2010/11/08 18:06 (GMT-0800) Adam Williamson composed:
> 
> > I don't see why this is a huge deal. There's a bug in Bugzilla that it
> > doesn't merge CC lists when you dupe bugs, yeah. Aside from that? What's
> > the huge problem with duping an older bug to a newer one?
> 
> Like I said, let the people who actually fix bugs both find them and file 
> them. There's no point in anyone else bothering. Triagers won't be necessary, 
> saving everyone time, cluttering the tracker with fewer dupes. And, they'll 
> always look, according to buglists, as if they were fixed more quickly than 
> they really were. Everybody wins, except those who can't fix bugs but would 
> like to feel their testing and reporting serves a purpose.

That's just a rant that doesn't answer my question at all.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Why should I ever bother filing another bug?

[Ankur Sinha]

Hello,

On Mon, 2010-11-08 at 21:30 -0500, Felix Miata wrote:
> Like I said, let the people who actually fix bugs both find them and
> file 
> them. 

You need to rethink this. Maintainers(ones who actually fix the bugs)
already have enough work on their hands. Adding "look, manage multiple
copies of the same error and comment them all" will just add to their
workload. Triagers are there for a reason. Bug triaging is there for a
reason. The current work flow is good. The only thing that happened
incorrectly here was that bugzilla did not add CCs to the bug. There's a
bug filed for this, as Peter already mentioned. 

A bug that has more comments from reporters will not have more priority
than one that has more comments from the maintainer. Maintainers need
one bug report per issue. Multiple bug reports are no extra help. As
long as even one bug report with good info exists, and the maintainer is
aware of it, I see no problem anywhere. 

-- 
Thanks!
Regards,
Ankur 

https://fedoraproject.org/wiki/User:Ankursinha

"FranciscoD"

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

Re: Why should I ever bother filing another bug?

[David Tardon]

On Mon, Nov 08, 2010 at 09:30:54PM -0500, Felix Miata wrote:
> On 2010/11/08 18:06 (GMT-0800) Adam Williamson composed:
> 
> > I don't see why this is a huge deal. There's a bug in Bugzilla that it
> > doesn't merge CC lists when you dupe bugs, yeah. Aside from that? What's
> > the huge problem with duping an older bug to a newer one?
> 
> Like I said, let the people who actually fix bugs both find them and file 
> them. There's no point in anyone else bothering. Triagers won't be necessary, 
> saving everyone time, cluttering the tracker with fewer dupes. And, they'll 
> always look, according to buglists, as if they were fixed more quickly than 
> they really were. Everybody wins, except those who can't fix bugs but would 
> like to feel their testing and reporting serves a purpose.
> -- 
> "The wise are known for their understanding, and pleasant
> words are persuasive." Proverbs 16:21 (New Living Translation)
> 
>   Team OS/2 ** Reg. Linux User #211409
> 
> Felix Miata  ***  http://fm.no-ip.com/

Btw, maybe you should look at the proverb in your signature and try to
apply it to yourself. Because in this thread you have neither shown
understanding nor used pleasant words.

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

Re: Why should I ever bother filing another bug?

[Felix Miata]

On 2010/11/09 07:39 (GMT+0100) David Tardon composed:

> Btw, maybe you should look at the proverb in your signature and try to
> apply it to yourself. Because in this thread you have neither shown
> understanding nor used pleasant words.

The words I used are not inherently unpleasant, only unpleasant because 
people don't want to hear the truth they report. Testers who can't fix bugs 
are treated like lepers compared to those who provide patches, deserving of 
less than equal respect. As a Bugzilla user for a decade or so, I understand 
this very well. It's a constant battle to remember to spend enough time 
rereading before sending in order to prevent inappropriate language to 
escape, particularly as given so little respect in the whole test and bug 
process overall (e.g. not only the duping of good older bugs to newer bugs, 
but Bugzilla itself: https://bugzilla.redhat.com/show_bug.cgi?id=638726 ).

As the subject says, I see no point in further bother.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/Auth/rudeweb.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel