Work-needing packages report for Sep 21, 2012

2012-09-20 Thread wnpp 
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 454 (new: 0)
Total number of packages offered up for adoption: 139 (new: 0)
Total number of packages requested help for: 66 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 454 packages are
orphaned.  See http://www.debian.org/devel/wnpp/orphaned
for a complete list.



No new packages have been given up for adoption, but a total of 139 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apt-xapian-index (#567955), requested 962 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Installations reported by Popcon: 56964

   asymptote (#517342), requested 1301 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 3258

   athcool (#278442), requested 2886 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 74

   balsa (#642906), requested 361 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 255

   bastille (#592137), requested 775 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 196

   boinc (#511243), requested 1351 days ago
 Description: BOINC distributed computing
 Installations reported by Popcon: 1671

   cardstories (#624100), requested 514 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 8

   chromium-browser (#583826), requested 844 days ago
 Description: Chromium browser
 Installations reported by Popcon: 10519

   debtags (#567954), requested 962 days ago
 Description: Enables support for package tags
 Installations reported by Popcon: 2502

   doc-central (#566364), requested 971 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 199

   elvis (#432298), requested 1900 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Installations reported by Popcon: 376

   fbcat (#565156), requested 981 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 143

   flightgear (#487388), requested 1552 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 829

   freeipmi (#628062), requested 483 days ago
 Description: GNU implementation of the IPMI protocol
 Installations reported by Popcon: 1865

   gnat-4.4 (#539633), requested 1619 days ago
 Description: backport bug fixes from trunk (GCC 4.5)
 Installations reported by Popcon: 1639

   gnat-gps (#496905), requested 1484 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 424

   gnokii (#677750), requested 96 days ago
 Description: Datasuite for mobile phone management
 Installations reported by Popcon: 2400

   gnupg (#660685), requested 213 days ago
 Description: GNU privacy guard - a free PGP replacement
 Installations reported by Popcon: 124519

   golang (#668870), requested 158 days ago
 Description: Go programming language compiler - metapackage
 Installations reported by Popcon: 312

   gpa (#663405), requested 194 days ago
 Description: GNU Privacy Assistant (GPA)
 Installations reported by Popcon: 512

   gradle (#683666), requested 49 days ago
 Description: Groovy based build system
 Installations reported by Popcon: 29

   grub2 (#248397), requested 3055 days ago
 Description: GRand Unified Bootloader
 Installations reported by Popcon: 115507

   hfsprogs (#557892), requested 1030 days ago
 Description: mkfs and fsck for HFS and HFS+ file systems
 Installations reported by Popcon: 1218

   horde4 (#686007), requested 24 days ago
 Description: web-based groupware and other applications

   hotkey-setup (#483107), requested 1577 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 3352

   irssi-scripts (#663577), requested 192 days ago
 Description: collection of scripts for irssi
 Installations reported by Popcon: 996

   isdnutils (#661110), requested 209 days ago
 Description: ISDN utilities
 Installations reported by Popcon: 11036

   jove (#470185), requested 1656 days ago
 Description: Jonathan's Own Version of Emacs - a compact, powerful
   ed

Re: symbols file: To hide or not to hide...

2012-09-20 Thread Lisandro Damián Nicanor Pérez Meyer 
On Thu 20 Sep 2012 13:59:52 Andrey Rahmatullin escribió:
> On Thu, Sep 20, 2012 at 05:34:36PM +0200, Mathieu Malaterre wrote:
> >   So I finally managed to get my C++ symbols file generated. However
> > 
> > before shooting myself in the foot, I'd like to know if I need to
> > generate the symbol file using -fvisibility=hidden or not ?
> 
> Theoretically, it is much better to export only those symbols you (as the
> upstream) actually intend to. Benefits vary from shortening the exports
> table to clearly defining the ABI. But if you do that incorrectly,
> problems may arise, so it may be better to not do that, especially if you
> are not the upstream.

On the other side, in the pkg-kde team we do use fvisibility=hidden.
Yes, upstream may have an error. But normally in those cases means missing 
symbols and stuff that depend on your lib will FTBFS, so it's quite easy to 
check.

Adding a symbol later is much easier than removing one (which normally means a 
soname change).

P.S.: I am not *very* knowledgeable about this, so if anyone feels that I0m 
missing something do not heasitate in fixing it ;) 

Kinds regards, Lisandro.

-- 
"Los pibes no piden que levantemos un muro para que tengan un límite,
sino que los ayudemos a crecer en libertad."
  Padre Bergoglio - http://www.lanacion.com.ar/1153060

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: Handling /etc/modprobe.d and module load order

2012-09-20 Thread Amit 
Marco d'Itri  Linux.IT> writes:

[snip]

> 
> Or just:
> 
> echo ' ' > /sys/bus/usb/drivers/usbhid/remove_id
> modprobe your_driver
> 

Tried this but it seems the PIC is buggier than I thought. There are
times when it disconnects and reconnects itself. As soon as the
reconnect happens, usbhid takes over the device. Thus, negating the
above command.

I ended up placing a line in */etc/default/grub* that passes the usbhid
quirks and have the postinst call update-grub. This passes the quirks to
kernel during boot so all seems well now.

Thanks,
Amit


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/loom.20120920t211137...@post.gmane.org

Re: packages with E: md5sum-mismatch in the archive

2012-09-20 Thread Niels Thykier 
On 2012-09-20 18:52, Andreas Beckmann wrote:
> On 2012-09-18 09:30, Andreas Beckmann wrote:
>> Just to give a short impression what we can find here:
> 
>> guile-1.6-dev_1.6.8-10.1
>>   /usr/lib/libguile-ltdl.la
>>   /usr/lib/libguile.la
>>   /usr/lib/libguile-srfi-srfi-13-14-v-1.la
>>   /usr/lib/libguile-srfi-srfi-4-v-1.la
>>   /usr/lib/libguilereadline-v-12.la
> 
> [...]
> 
> Can someone do a lintian check for just this tag on the whole archive, 
> all architectures, all releases? That's just *.deb on a full mirror :-)
> And ports should be checked, too.
> 
> Andreas
> 
> [...]
> 
> 

I am doing a lintian run for amd64 + i386 on stable for starters
(limited to md5sum-mismatch).  I think that (plus the normal sid runs)
should cover most issues.

~Niels


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/505b689f.8030...@thykier.net

Re: packages with E: md5sum-mismatch in the archive

2012-09-20 Thread Jakub Wilk 

* Andreas Beckmann , 2012-09-20, 18:52:

Actually, we have lintian errors on the packages in the archive:

E: guile-1.6-libs: md5sum-mismatch usr/lib/libguile-srfi-srfi-4-v-1.la
E: guile-1.6-libs: md5sum-mismatch usr/lib/libguile-srfi-srfi-13-14-v-1.la
E: guile-1.6-libs: md5sum-mismatch usr/lib/libguilereadline-v-12.la
E: guile-1.6-dev: md5sum-mismatch usr/lib/libguile-ltdl.la
E: guile-1.6-dev: md5sum-mismatch usr/lib/libguile.la

I tried rebuilding guile-1.6 in a clean sid pbuilder chroot on amd64 
and could not reproduce the error. So a binNMU might be sufficient to 
fix this.


A binNMU would just paper over the actual bug. guile-1.6 debian/rules has this:

dh_md5sums
sed -i "/dependency_libs/ s/'.*'/''/" `find $(CURDIR)/debian/ -name 
'*.la'`
dh_builddeb

...which is wrong.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120920172038.ga7...@jwilk.net

Re: symbols file: To hide or not to hide...

2012-09-20 Thread Andrey Rahmatullin 
On Thu, Sep 20, 2012 at 05:34:36PM +0200, Mathieu Malaterre wrote:
>   So I finally managed to get my C++ symbols file generated. However
> before shooting myself in the foot, I'd like to know if I need to
> generate the symbol file using -fvisibility=hidden or not ?
Theoretically, it is much better to export only those symbols you (as the
upstream) actually intend to. Benefits vary from shortening the exports
table to clearly defining the ABI. But if you do that incorrectly,
problems may arise, so it may be better to not do that, especially if you
are not the upstream.

See also http://gcc.gnu.org/wiki/Visibility

-- 
WBR, wRAR


signature.asc
Description: Digital signature

packages with E: md5sum-mismatch in the archive (was: Re: mass bug filing about packages manipulating/deleting shipped files)

2012-09-20 Thread Andreas Beckmann 
On 2012-09-18 09:30, Andreas Beckmann wrote:
> Just to give a short impression what we can find here:

> guile-1.6-dev_1.6.8-10.1
>   /usr/lib/libguile-ltdl.la
>   /usr/lib/libguile.la
>   /usr/lib/libguile-srfi-srfi-13-14-v-1.la
>   /usr/lib/libguile-srfi-srfi-4-v-1.la
>   /usr/lib/libguilereadline-v-12.la

Actually, we have lintian errors on the packages in the archive:

E: guile-1.6-libs: md5sum-mismatch usr/lib/libguile-srfi-srfi-4-v-1.la
E: guile-1.6-libs: md5sum-mismatch usr/lib/libguile-srfi-srfi-13-14-v-1.la
E: guile-1.6-libs: md5sum-mismatch usr/lib/libguilereadline-v-12.la
E: guile-1.6-dev: md5sum-mismatch usr/lib/libguile-ltdl.la
E: guile-1.6-dev: md5sum-mismatch usr/lib/libguile.la

I tried rebuilding guile-1.6 in a clean sid pbuilder chroot on amd64 
and could not reproduce the error. So a binNMU might be sufficient to 
fix this. And it's the md5sum that is wrong, the .la files don't change
after the rebuild.

But the more important question is: how can it happen that such broken 
packages enter the archive?

Shouldn't md5sum-mismatch be in ftp-master-auto-reject.profile?

Can someone do a lintian check for just this tag on the whole archive, 
all architectures, all releases? That's just *.deb on a full mirror :-)
And ports should be checked, too.

Andreas

sha256 sums from the bad .debs:
f6530f30619aa2451e88f3ea245824ff779d41e24cb7e3eeacd6b83c7dbfea00  
/var/cache/apt/archives/guile-1.6-dev_1.6.8-10.1_amd64.deb
c023046e8ac1180643b42f598b2f0a0aa90e5be50f878fe69fae2d07b5815cb6  
/var/cache/apt/archives/guile-1.6-libs_1.6.8-10.1_amd64.deb
22e8a4dc75c6b57bcfd8b0c365a48eb045b8f3317aa74cd00670c7af085f3acb  
/var/cache/apt/archives/guile-1.6_1.6.8-10.1_amd64.deb


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/505b49eb.5080...@abeckmann.de

symbols file: To hide or not to hide...

2012-09-20 Thread Mathieu Malaterre 
Hi,

  So I finally managed to get my C++ symbols file generated. However
before shooting myself in the foot, I'd like to know if I need to
generate the symbol file using -fvisibility=hidden or not ? The output
of pkgkde-gensymbols/pkgkde-symbolshelper[1] seems to be drastically
affected by having/not having this compiler flag.
  I could not find any explanation in §8.6

Here is my d/rules when using hidden flag:

#!/usr/bin/make -f
[...]
export DEB_CFLAGS_MAINT_APPEND=-fvisibility=hidden
export DEB_CXXFLAGS_MAINT_APPEND=-fvisibility=hidden


Thanks !
-M
[1] http://www.eyrie.org/~eagle/journal/2012-01/008.html


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsyOsEZ+hQtt2kjNzCW9EaFEdaaxWF=lexebzq6qjjb...@mail.gmail.com

Re: status of eligibility of dug lists on lists.debian.org

2012-09-20 Thread Ivan Shmakov 
> martin f krafft  writes:

[…]

 > So the solution was to get one or two additional people, and
 > eventually I was even able to invest in more fail-proof hardware.

 > … and then you ask yourself what to do with all the spare cycles and
 > wouldn't other LUGs profit from your setup…  And you keep going and
 > going and the dependence on you grows.

Yes.

[…]

 > Now there are three ways forward:

 > 1. take back the mailing list, my infrastructure still exists and
 >could handle it, but am I willing to give a guarantee for the next
 >years to come?

 > 2. work with teams.debian.net to get it back up to speed.

 > 3. or use the official and professionally maintained infrastructure
 >on alioth.d.o or lists.d.o, which can probably handle a couple
 >dozens of additional lists.  I can understand that we don't want a
 >new list for every formation or group in the Debian universe,

To be honest, it's the very reason I dislike mailing lists.  The
groups come and go, while mailing lists have to stay forever,
for their archive to be available for posterity.

Usenet is better (though still not ideal) in this respect, as
newsgroups aren't much more than just “tags”, which a single
message may bear an arbitrary number of.

Starting a “discussion group” should require no more skill and
time than tuning a radio to an agreed frequency.  And the
archive should persist for as long as there's anyone to care.

 >but a list for large groups like the Debian users in and around of
 >Munich should arguably be doable.

 > My preference is clearly (3.).  Maybe one of the sysadmins who could
 > host their own LUG list would be interested in helping the
 > listmasters.  And should the hardware not be enough, then we can
 > probably find ways to upgrade it.

I'd be fine going (2), either.  What exactly needs to be done?

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86mx0l3qrv@gray.siamics.net

Re: status of eligibility of dug lists on lists.debian.org

2012-09-20 Thread Jon Dowland 
Personally, I think l.d.o would be an appropriate home for such things, but I
believe the decision is one for the list server admins. Having said that, I
think efforts are underway so that the alioth-hosted lists are moved to the
l.d.o infrastructure, precicely because it is recognised that running multiple
list servers across the Debian community is counter-productive. IMHO the same
reasoning applies here, but it is for the list admins to say authoratively.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120920105112.GB17882@debian

Re: Comments on Mate DE

2012-09-20 Thread Jon Dowland 
Hello,

Thank you for your mail.

The reason MATE is not in Debian is that nobody has put the work in to make it
so. In Debian, things happen thanks to developers putting effort in, usually in
their spare time.  Whilst it's true that some people believe MATE should not be
included in Debian, they do so for technical reasons, not religious ones - and
they won't prevent it being included so long as people are prepared to put the
work in.

Some people have started to put the work in - see 
.
However the timing is such that it will not be included in the next Debian 
stable
release. It might make the one after that…


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120920104927.GA17882@debian

Re: Comments on Mate DE

2012-09-20 Thread Thomas Goirand 

On 09/20/2012 01:58 AM, superuserlaptop wrote:

Mate Desktop environment (http://www.mate-desktop.org)

I am writing in support of Mate DE. In less than a year a few people
have designed an alternative to Gnome 3.

I have been averaging one reconditioned HP Compaq nc6400 laptop per
quarter year, four per year. This is one of my contributions to Debian
and Linux.

I give these out to individuals who do not have a computer and cannot
afford one and have very limited computer skills.

I use Debian with a Mate DE. The reports back so far from everyone that
has received a laptop that they like the way it handles better than
Windows or Apple.

It has been a simple process until now September 18, 2012. Just as in
the past Debian broke OpenOffice and substituted LibreOffice.


You can't say it this way. At the maximum, you could say that the maintainer
of OpenOffice decided to follow the LibreOffice branch rather than the
Apache OpenOffice one. It's not a "decision" that Debian made, but the
choice of a maintainer, who spent quite a large amount of time on it.

If you want to maintain Apache OpenOffice in Debian, please do, but first
explain to us why we would need to support both. As I understand, the
LibreOffice suite adds patches and features to the Apache OpenOffice,
when the other way isn't truth.


It was a
major effort to undo the damage caused by that action.


What damage are you talking about? I'm really happy with LibreOffice
myself.


I have still not
completely repaired the damage of lost components to Open Office. Which
I have finally reinstalled.


What components?


You are now allowing OO to live side by side with LO. This is as it
should be.


I don't think anyone forbid that. If that was the case, please give
a reference where you read that it wasn't allowed to maintain both
packages in Debian.


But again you have taken a similar action to Mate.


Could you define these actions? I don't think anyone willingly
tried to break the compatibility with Mate.


This to me is a form of sabotage.


Come on!!! Please don't use such bad words, I don't think anyone
in Debian is trying to do any kind of sabotage.


I understand that Mate is not totally
in line with the philosophy of Debian, but they are getting there.


Why do you think so? I never read that Debian has something against
Mate or any other open source project.


What better way to create good will for Debian and Linux than to do this
service?


Debian isn't a company. If you wish to see Mate in Debian, then please
maintain its packages.


Yet someone decided that this would not be.


Who exactly are you talking about?


There is a difference
between endorsing, or not, a program, to breaking it because someone did
not like what it was doing.


Please give a reference here.


Debian has had this attitude of doing it the Debian way or leave.


Again, please give references.


It is the same with some of the programs that are available, the only
way to use them is to go up into SID. The components to the software
always stay in SID.


Well, after some times in SID, packages goes in testing, then when the new
stable is released, it goes to Stable. These are very well established 
rules in
Debian, and I see no problem with it. If you want more updated software, 
then

please do switch to testing. What problem do you have with testing anyway?


Yet this causes problems with the system that can
only be rectified by turning off updates.

This is why, I do not allow updates from Debian. I do for Mate and
Multimedia. I have been burned too often by Debian.


Again, no reference to any specific issue, so we can't help.


Yet Debian is a very good operating system when this self-rightious
attitude is not involved.


Again, Debian is composed with a set of people. Accusing the entire
project like this doesn't help, and isn't nice (you are attacking about
1000 people at the same time...). And it wont make things better...
Instead, please explain what your problem is, and point to specific
issues. That would be a lot more constructive.


There has been limited discussions about forking Debian to get away from
these problems that make life measurable.


According to distrowatch, there's 139 Debian derivatives. So there
has been a little more than "limited discussions"...


It is time for the people who make the decisions at Debian that there is
a very strong cause and effect relationship between what you do and how
well the community will operate.


What community are you talking about? Do you mean "users"?


By adding problems that are not technical but solely the opinion of one
or two or even a handful of people is destructive.


If you are again talking about Gnome or Mate support or OpenOffice, then 
again,

please feel free to contribute and address the issues.


I have always encouraged people to financially help with a few dollars
to free programs. Again this year I do not encourage financial support
for Debian. Last year you lost this endorsement bec