Re: prepare to fix build failures with new GCC versions

[Raphael Hertzog]

On Sun, 27 Feb 2011, Matthias Klose wrote:
> Unreflected usage of symbols files for C++ libraries
> - 
> 
> These seem to be limited to Qt and KDE related libraries.
> 
> Apparently g++-4.4 did emit references to symbols defined in header files of
> depending libraries.  At least some of these are not emitted anymore with 4.5
> and 4.6.  Packages calling dpkg-gensymbols with -c2 or higher, fail to build.
> 
> The mangling for virtual thunks did change, and generates different symbols on
> some architectures.  The issues can be avoided by using the unmangled names.

Well, if the mangling changed it means binaries linked against old
libraries will no longer work so it's rather good that the symbols files
doesn't match any more because you have to bump the mimimum version number
for that symbol.

So "avoiding" the problem is not really a goal in this case... a symbols
files which does match based on the unmangled name would have let this
mistake slip through. :-|

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110228070243.ga6...@rivendell.home.ouaza.com

Re: NMU procedure

[Tollef Fog Heen]

]] Hector Oron 

Hi,

| > * Raising the severity doesn't really imply anything
| 
| True. Would you suggest some better way to proceed with porter-NMU?

I would think it quite rushed to be pushing NMUs for an archicture not
in Debian and not even in dpkg yet.  Even more so when it's not accepted
as a release goal for wheezy.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87r5asvfej@qurzaw.varnish-software.com

Re: Bug#615090: ITP: quakespasm -- an engine for iD software's Quake

[Guillem Jover]

Hi!

On Fri, 2011-02-25 at 16:59:58 +, David Banks wrote:
> Package: wnpp
> Severity: wishlist
> Owner: David Banks 
> 
> * Package name: quakespasm
>   Version : 0.85.3
>   Upstream Author : David Banks 
> * URL : http://quakespasm.sourceforge.net/
> * License : GPL
>   Programming Lang: C
>   Description : an engine for iD software's Quake
> 
> QuakeSpasm is a *Nix friendly Quake Engine based on the SDL port of the
> popular FitzQuake. It includes some new features, important fixes, and aims
> for portability and 64 bit correctness.

How does this compare to darkplaces, which is already on the archive,
only with a different name (nexuiz, see [0])?

[0] 

regards,
guillem


-- 
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/20110228031352.ga31...@gaara.hadrons.org

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Henrique de Moraes Holschuh]

On Mon, 28 Feb 2011, Olaf van der Spek wrote:
> Sure. But Sergey has a good point: why are there no bin and lib inside
> /home so normal users can safely install software without risking

AFAIK, there are strong security concerns.  You cannot have unprotected
directories in the default linker paths.

rpath exists for a reason.  Use it.   We even have an rpath editor,
package chrpath, for programs that don't use it automatically when you
tell them they're not going to be installed in a *default* system
directory like /usr/local/{bin,sbin,lib}.

Actually, we usually use it to *remove* bogus rpath, but hey, it would
be a poor tool if it couldn't be used to add a proper rpath :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



-- 
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/20110228024315.gc6...@khazad-dum.debian.net

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Andreas Rottmann]

Olaf van der Spek  writes:

> On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
>  wrote:
>>> But there is an ordering choice. local has priority.
>>
>> By default, we assume the local administrator knows what he is doing.
>>
>> That is not going to change.
>
> Sure. But Sergey has a good point: why are there no bin and lib inside
> /home so normal users can safely install software without risking
> system-wide things to go wrong?
>
Most software allows this without issues -- just run "./configure
--prefix=$HOME". You need to adjust $PATH and $LD_LIBRARY_PATH inside
your shell startup scripts, and you're done.

I'd however strongly suggest not adding any additional directories in
$HOME by default (e.g. via /etc/skel.d) -- how to organize this should
be the users' choice.  I for example use
--prefix="$HOME/.system/stow/" for each individual software
package, so I can quickly remove and reinstate them using GNU
Stow. Having ~/lib and ~/share, ~/bin, etc. unconditionally created in
my home directory would just be useless clutter.

Regards, Rotty



-- 
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/87lj119dma@gmx.at

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Olaf van der Spek]

On Mon, Feb 28, 2011 at 1:25 AM, Henrique de Moraes Holschuh
 wrote:
>> But there is an ordering choice. local has priority.
>
> By default, we assume the local administrator knows what he is doing.
>
> That is not going to change.

Sure. But Sergey has a good point: why are there no bin and lib inside
/home so normal users can safely install software without risking
system-wide things to go wrong?


-- 
Olaf



-- 
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/AANLkTi=mf=qhhvkqeazu7fuzipteib_6+p8gixwpb...@mail.gmail.com

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Henrique de Moraes Holschuh]

On Mon, 28 Feb 2011, Olaf van der Spek wrote:
> > places.  So if you want /usr/local/bin binaries to see /usr/local/lib
> > by default (that's what Debian and other Linux systems do, on purpose),
> > then all your system binaries will see them too.  Anyway, it's not a
> > bug or even really a design flaw (IMO).
> 
> But there is an ordering choice. local has priority.

By default, we assume the local administrator knows what he is doing.

That is not going to change.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



--
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/20110228002530.gb6...@khazad-dum.debian.net

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Olaf van der Spek]

On Mon, Feb 28, 2011 at 12:04 AM, Peter Samuelson  wrote:
> Unfortunately (from your perspective) there is not a way to configure a
> default library search path differently for binaries in different
> places.  So if you want /usr/local/bin binaries to see /usr/local/lib
> by default (that's what Debian and other Linux systems do, on purpose),
> then all your system binaries will see them too.  Anyway, it's not a
> bug or even really a design flaw (IMO).

But there is an ordering choice. local has priority.


-- 
Olaf



--
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/aanlktiky94dbkx3icgmqt40th00uk3by+s7a2tcxx...@mail.gmail.com

Re: NMU procedure

[Hector Oron]

Hello Raphael,

2011/2/27 Raphael Geissert :

>> I do really apologize in case we have miss something, we'll try to do
>> better next time.

> Let's list a few things:
> * I didn't like that there was no notification on the bug report

We note that one for next time.
IMHO, BTS should acknowledge the maintainers.

> * Raising the severity doesn't really imply anything

True. Would you suggest some better way to proceed with porter-NMU?

> * The release goal has not been acked by the release team AFAIK

It is a wishlist ('proposed') goal at the moment.

> If you ask me, I would say that providing a magic for file(1) as I said on
> debian-arm[1] would be more useful that NMUing a few hanging fruits.
> Lintian will annoy people with one tag per ELF object otherwise.

We have your `file' request in the TODO stack.

We picked NMUing few "hanging fruits" which nobody cares to standarize
procedures to follow in the future.

Thanks for your input and thanks for all the hard work you do in daily basis.

Kind regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/aanlktikj+w6g8tqpsbtpt64vnrmggbwcczkhqzgk9...@mail.gmail.com

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Peter Samuelson]

[sergey]
> It is a good reason to think about Debian's (or GNU/Linux) usability and
> ways to increase it.
> 
> It all was about installing software system-wide by administrator.

Well, putting /usr/local/lib in the default library search path, and
upstream software using /usr/local/lib by default, are no coincidence.
The point is that if you build a binary on your own, and it needs to
use a library you also built on your own, it is quite nice that you
don't have to provide an explicit library search path (RPATH inside the
binary, or LD_LIBRARY_PATH variable at runtime).

Unfortunately (from your perspective) there is not a way to configure a
default library search path differently for binaries in different
places.  So if you want /usr/local/bin binaries to see /usr/local/lib
by default (that's what Debian and other Linux systems do, on purpose),
then all your system binaries will see them too.  Anyway, it's not a
bug or even really a design flaw (IMO).
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/



-- 
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/20110227230431.ge10...@p12n.org

Re: NMU procedure

[Steve Langasek]

On Sun, Feb 27, 2011 at 03:29:05PM -0600, Raphael Geissert wrote:
> Steve Langasek wrote:

> > On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> >> If you ask me, I would say that providing a magic for file(1) as I said
> >> on debian-arm[1] would be more useful that NMUing a few hanging fruits.
> >> Lintian will annoy people with one tag per ELF object otherwise.

> > Um, that'll be a bug in lintian then.  There's no reason at all for
> > lintian to be spitting out tags on every package on the port for something
> > that's a detail of the upstream toolchain.

> Not saying it isn't, but not even dpkg knows about armhf.

> Point being: instead of spending time on low hanging fruits the tool chain 
> should be adapted.

Well, you're simply wrong here.  Work is progressing on having dpkg handle
armhf, and that is entirely orthogonal to any question of distinguishing
armhf and armel ELF objects at the binary level.  Having the toolchain
identify the floating-point ABI in the ELF header is a valid wishlist
request that would be useful for more than lintian, but it's not relevant to
bootstrapping the port.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: NMU procedure

[Raphael Geissert]

Steve Langasek wrote:

> On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
>> If you ask me, I would say that providing a magic for file(1) as I said
>> on debian-arm[1] would be more useful that NMUing a few hanging fruits.
>> Lintian will annoy people with one tag per ELF object otherwise.
> 
> Um, that'll be a bug in lintian then.  There's no reason at all for
> lintian to be spitting out tags on every package on the port for something
> that's a detail of the upstream toolchain.
> 

Not saying it isn't, but not even dpkg knows about armhf.

Point being: instead of spending time on low hanging fruits the tool chain 
should be adapted.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ikefn2$jfp$1...@dough.gmane.org

Re: NMU procedure

[Steve Langasek]

On Sun, Feb 27, 2011 at 02:41:32PM -0600, Raphael Geissert wrote:
> If you ask me, I would say that providing a magic for file(1) as I said on 
> debian-arm[1] would be more useful that NMUing a few hanging fruits.
> Lintian will annoy people with one tag per ELF object otherwise.

Um, that'll be a bug in lintian then.  There's no reason at all for lintian
to be spitting out tags on every package on the port for something that's a
detail of the upstream toolchain.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: NMU procedure

[Stefano Zacchiroli]

On Sun, Feb 27, 2011 at 08:21:25PM +, Hector Oron wrote:
> I do really apologize in case we have miss something, we'll try to do
> better next time.

Thanks for this followup Hector.

FWIW, no one said those NMUs were not welcome and it's in fact nice to
see you're pushing for armhf. Julien's (very valid!) points were on two
specific aspects: the lack of NMU notifications to the bug logs and the
lack of nmudiffs.  Please ensure you fix those, possibly starting from
the NMUs which are already in DELAYED.

For the random lurkers: current NMU guidelines are quite liberal in the
usage of the DELAYED queue, but require that the NMU-ed maintainer, as
well as other bug lurkers, are put in the best possible position to
catch up with the NMU-ed work.

Everyone following:

  http://www.debian.org/doc/developers-reference/pkgs.html#nmu

won't have any problem with NMUs.


/me, still campaigning for NMUs as the best device we have to fight
inertia. Cheers.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: NMU procedure

[Raphael Geissert]

[removing most CCs and setting reply to -devel]

Hi,

On Sunday 27 February 2011 14:21:25 Hector Oron wrote:
> 2011/2/27 Julien Cristau :
> > there are a number of NMUs currently in the delayed queue, adding armhf
> > support to some packages.  The bugs referenced in those uploads have
> > seen no notification of any such upload, and no NMU diff has been sent.
> > Please fix this.  And in the future, do that before you upload, per
> > http://www.debian.org/doc/developers-reference/pkgs.html#nmu
> 
>  * Patches in BTS are hanging since last year, 2010.

November 2010, during the freeze.

>  * NMU were discussed on -devel without any objection [0]
>  * Severity was raised Feb 14, 2011 for part of the packages and
> maintainers should be aware of that [1]
>  * Everyone that has complained, we have removed the upload from
> delayed queue (#604681)
>  * A bug has been created to have armhf as release goal and ease
> release team track this goal (#615513)
>
> I do really apologize in case we have miss something, we'll try to do
> better next time.

Let's list a few things:
* I didn't like that there was no notification on the bug report
* Raising the severity doesn't really imply anything
* The release goal has not been acked by the release team AFAIK
* You could have probably saved some time yourself by not NMUing every single 
package. In my case, for kgb, I highly doubt anyone uses it on arm* and one 
upload per release to clean it up should be enough (there won't be any new 
releases upstream).

Anyway, it came as a surprise, but I didn't complain when I saw dak's email 
because I really don't mind.

If you ask me, I would say that providing a magic for file(1) as I said on 
debian-arm[1] would be more useful that NMUing a few hanging fruits.
Lintian will annoy people with one tag per ELF object otherwise.

[1]http://lists.debian.org/201102191920.02232.geiss...@debian.org

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/201102271441.34185.geiss...@debian.org

Processed: closing 615476

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 615476
Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 
library
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to sergey 

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
615476: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615476
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.129883844822758.transcr...@bugs.debian.org

Re: NMU procedure

[Hector Oron]

Hello,

2011/2/27 Julien Cristau :

> there are a number of NMUs currently in the delayed queue, adding armhf
> support to some packages.  The bugs referenced in those uploads have
> seen no notification of any such upload, and no NMU diff has been sent.
> Please fix this.  And in the future, do that before you upload, per
> http://www.debian.org/doc/developers-reference/pkgs.html#nmu


 * Patches in BTS are hanging since last year, 2010.
 * NMU were discussed on -devel without any objection [0]
 * Severity was raised Feb 14, 2011 for part of the packages and
maintainers should be aware of that [1]
 * Everyone that has complained, we have removed the upload from
delayed queue (#604681)
 * A bug has been created to have armhf as release goal and ease
release team track this goal (#615513)

I do really apologize in case we have miss something, we'll try to do
better next time.

NMU bugs have been rescheduled to DELAYED/7 and maintainers affected
are CC on this email, if you are fine with it good (we would be happy
to reschedule the NMU to DELAYED/0), if not, please let us know so we
can cancel, reschedule or workout why it is wrong or how we can help
get it fixed.

If you need nmudiff, please let us know, from now we'll be attaching
it on next follow ups.

Affected packages can be reached at deferred queue list [2]

[0] http://lists.debian.org/debian-devel/2011/02/msg00351.html
[1] http://lists.debian.org/debian-arm/2011/02/msg00060.html
[2] http://ftp-master.debian.org/deferred.html

Best regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/AANLkTi=1jsge8awa63dxkqajekyvzbdra--x+ybsa...@mail.gmail.com

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[sergey]

Thank you for detailed explanation.

Please note that most software that is not included in Debian are distributed
in source tarballs. Most of this software installs to /usr/local by default now.
(You type configure && make && make install - and program installed)

So, default way is dangerous way in Debian. Non-dangerous ways are:
- not traditional;
- consumes much more time;
- more complicated.

It is a good reason to think about Debian's (or GNU/Linux) usability and
ways to increase it.

It all was about installing software system-wide by administrator.

By the way: does Debian have any simple and comfortable methods of installing 
software
by non-privileged user only for him/herself?

---
WBR, Sergey



-- 
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/20110227225227.1ef9d276.sergey_i...@rambler.ru

Re: Upcoming changes in Lintian & some bits

[Harald Jenny]

Hello,

testing with the version from experimental yielded the following additional
messages compared to unstable (all overrides were correctly detected).

W: openswan-doc: spelling-error-in-readme-debian allows to allows one to
W: openswan-modules-source: spelling-error-in-readme-debian allows to allows 
one to
W: openswan: spelling-error-in-readme-debian allows to allows one to
I: openswan: spelling-error-in-binary usr/lib/ipsec/pluto ouput output
W: openswan-modules-dkms: spelling-error-in-readme-debian allows to allows one 
to

Btw. packages tested were openswan and amavisd-milter.

Kind regards
Harald Jenny

On Sat, Feb 26, 2011 at 10:07:09AM -0600, Raphael Geissert wrote:
> Yves-Alexis Perez wrote:
> 
> > On Wed, 2011-02-23 at 22:47 -0600, Raphael Geissert wrote:
> >> As a consequence of these changes, the new Lintian release will cause
> >> many existing overrides to no longer apply.  We recognise that this will
> >> lead to some noise in the short term but are convinced that the longer
> >> term advantages make this worthwhile.
> >> 
> > Did you do an archive check with the new lintian and diff'ed it against
> > a check with previous lintian?
> 
> No, we haven't.
> 
> An archive check is running as I type, that's the easy part. However, the 
> results need to be checked, and even though Niels already volunteered to 
> take a look, I expect the diff to be quite big.
> 
> More eyes, and hands, are welcome; installing the RC and starting with one's 
> packages would be great.
> 
> Cheers,
> -- 
> Raphael Geissert - Debian Developer
> www.debian.org - get.debian.net
> 
> 
> -- 
> 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/ikb8fe$7qh$2...@dough.gmane.org


-- 
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/20110227193850.ga3...@harald-has.a-little-linux-box.at

Bug#615614: ITP: setuptools-git -- setuptools revision control system plugin for git

[Jan Dittberner]

Package: wnpp
Severity: wishlist
Owner: Jan Dittberner 


* Package name: setuptools-git
  Version : 0.3.4
  Upstream Author : Yannick Gingras 
* URL : http://pypi.python.org/pypi/setuptools-git/
* License : Public Domain
  Programming Lang: Python
  Description : setuptools revision control system plugin for git

This is a plugin for setuptools that enables git integration. Once installed,
setuptools can be told to include in a module distribution all the files
tracked by git. This is an alternative to explicit inclusion specifications
with MANIFEST.in.

The package will provide Python2 and Python3 versions of the software.


Regards,
Jan Dittberner

-- 
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
 B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/


signature.asc
Description: Digital signature

Re: linker related changes for wheezy

[Fernando Lemos]

Olaf,

On Sun, Feb 27, 2011 at 3:54 PM, Olaf van der Spek  wrote:
> On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos  wrote:
>> Those are valid points, of course, but many Boost projects will fail
>> to build now and I see no good solution[1][2][3]. Some libraries like
>
> I do: http://en.wikipedia.org/wiki/Auto-linking
> First has to be implemented in GCC though.

This has been discussed before. Good luck a) writing the code, b)
convincing the GCC developers it's a good idea and getting it upstream
and then c) getting all the pieces in Debian. Ah, all that in time for
wheezy, okay?

I'd suggest we concentrate on viable alternatives.

Regards,


-- 
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/AANLkTi=lbcicr_al_wkwxou7c97wv9ys2agbhhkt4...@mail.gmail.com

Re: linker related changes for wheezy

[Olaf van der Spek]

On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos  wrote:
> Those are valid points, of course, but many Boost projects will fail
> to build now and I see no good solution[1][2][3]. Some libraries like

I do: http://en.wikipedia.org/wiki/Auto-linking
First has to be implemented in GCC though.


-- 
Olaf


-- 
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/aanlktik5szndl4xten0k5b0rrhygimjjztyi14e_v...@mail.gmail.com

Re: linker related changes for wheezy

[Fernando Lemos]

Hi,

On Sun, Feb 27, 2011 at 1:00 PM, Matthias Klose  wrote:
[...]
> The latter change is described in [1] (section [2]).  To summarize: If a 
> library
> symbol is directly used by an object without explicitly linking this library,
> the link step now fails.  The fix is to pass the library explictly to the
> linker.  Rationale for this change:
>
>  - Correctness.  Symbols should not be resolved unintentionally.
>
>  - Robustness.  If a library drops a dependency on another library
>   with the involved symbol, then the application still using this
>   symbol will fail to build.
>
>  - Buildability with the gold linker.  Gold defaults to
>   --no-copy-dt-needed-entries.  Using gold as the default linker
>   is not a goal for wheezy, but buildability of the archive with
>   gold is required as a prerequisite.
[...]

Those are valid points, of course, but many Boost projects will fail
to build now and I see no good solution[1][2][3]. Some libraries like
libboost-filesystem and libboost-asio implicitly depend on
libboost-system or libboost-thread or some other Boost library because
they refer to their symbols in inlined functions and methods. This is
a technical requirement mostly related to C++ templates (though C
libraries could be affected too if they use inlined code).

The problem with simply "adding the missing libraries" to each
project's build system is that those dependencies aren't documented
anywhere. The mantainers would have to add them manually in each
project's build scripts. The dependencies might change in the future,
too, and in that case the package will fail to build again.

Roger Leigh proposed pkg-config integration in Boost[4] but got no
feedback. That would be a way out of this problem, but I suspect
upstream is not really interested. It could be argued that
--no-copy-dt-needed-entries is C-centric since it ignores the problems
faced by libraries that expose C++ templates.

In situations like this, what can package maintainers do? Would adding
-Wl,--copy-dt-needed-entries to the build script be acceptable and
would gold support that flag too? Should the bugs be assigned to the
libraries instead (Boost and others)? There's no way this can be
considered a bug in the packages that use such libraries, it makes no
sense.

Thanks,

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602959
[3]: http://lists.debian.org/debian-devel/2010/12/msg00055.html
[4]: https://svn.boost.org/trac/boost/ticket/1094


--
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/aanlktikxekrxx5td9fctfp64r_gye-vhqyoz4vo...@mail.gmail.com

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Cyril Brulebois]

Hi.

sergey  (27/02/2011):
> Is it normal that Debian's programs in my system gets dependencies
> from non-Debian libraries?

Phrased otherwise, it's normal to get to look into /usr/local/lib
since that's the linker's configuration, see /etc/ld.so.conf.d/libc.conf
(which has a comment about its being the default libc configuration,
so not a Debian-specific issue).

> In this situation each new installation in /usr/local is a venture
> with unpredictable results.

Yes, that's why the local administrator should be very careful when
installing stuff there.

> Any Debian's program can stop work or can begin work in unexpected
> way after installation of new program in /usr/local. It makes Debian
> unreliable system.

Wrong conclusion.

Anyway, here's what you could do:
 - remove that path from the linker's configuration, and set
   LD_LIBRARY_PATH when running the set of binaries that need special
   libraries;
 - or stop installing into /usr/local, install in other directories,
   and wrap your binaries to set LD_LIBRARY_PATH=/path/to/that/lib just
   for those binaries;
 - or even build your stuff with an RPATH pointing to the right
   directory if you don't want to wrap your calls.

KiBi.


signature.asc
Description: Digital signature

Re: Fun with libtool and cross-builds

[Enrico Weigelt]

* Loïc Minier  schrieb:
> On Thu, Feb 10, 2011, Wookey wrote:
> > Loic Minier in October last year, to libtool list
> > http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7626
> > (response: yes that seems to be a bug, no time to fix now, does sysroot
> > option fix it? 'Not for me' said lool)
> 
>  FTR, I just tried libtool.git, and it seems to still be affected by the
>  issue
> 
>  ./bootstrap
>  cd tests/depdemo
>  ./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi 
> --libdir=/usr/lib
>  make install DESTDIR=`pwd`/destdir
> 
> test -z "/usr/lib" || /bin/mkdir -p 
> "/home/lool/scratch/libtool/libtool-git/tests/depdemo/destdir/usr/lib"
  ^^
  absolutely wrong.

>  /bin/bash ../libtool   --mode=install /usr/bin/install -c   libl2.la 
> '/home/lool/scratch/libtool/libtool-git/tests/depdemo/destdir/usr/lib'
> libtool: install: warning: relinking `libl2.la'
> libtool: install: (cd 
> /home/lool/scratch/libtool/libtool-git/tests/depdemo/l2; /bin/bash 
> /home/lool/scratch/libtool/libtool-git/tests/depdemo/libtool  --tag CC 
> --mode=relink arm-linux-gnueabi-gcc -g -O2 -no-undefined -o libl2.la -rpath 
> /usr/lib l2.lo ../l1/libl1.la -inst-prefix-dir 
> /home/lool/scratch/libtool/libtool-git/tests/depdemo/destdir)
> libtool: relink: arm-linux-gnueabi-gcc -shared  -fPIC -DPIC  .libs/l2.o   
> -L/home/lool/scratch/libtool/libtool-git/tests/depdemo/destdir/usr/lib 
> -L/usr/lib -ll1  -O2   -Wl,-soname -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0
> /usr/lib/gcc/arm-linux-gnueabi/4.5.2/../../../../arm-linux-gnueabi/bin/ld: 
> skipping incompatible /usr/lib/libc.so when searching for -lc
> /usr/lib/libc.a: could not read symbols: File format not recognized
> collect2: ld returned 1 exit status
> libtool: install: error: relink `libl2.la' with the above command before 
> installing it

Obvious, since it uses wrong library pathes ;-o


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


--
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/20110227181848.GB10616@nibiru.local

Re: [Adduser-devel] Default Homedir Permissions

[Olaf van der Spek]

On Sat, Feb 19, 2011 at 10:49 AM, Olaf van der Spek
 wrote:
> On Fri, Feb 18, 2011 at 9:19 AM, Stephen Gran  wrote:
>> I don't want to prolong this thread, but this seemed useful to answer.
>>
>> I certainly have no intention of changing the default on my own.
>
> Could you at least fix the original bug and ensure preseeding works?

Stephen?


-- 
Olaf


-- 
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/aanlktikp0esxaqqwv5et4vvswgeeengd+gtp-v-y7...@mail.gmail.com

Re: linker related changes for wheezy

[Josselin Mouette]

Le dimanche 27 février 2011 à 17:00 +0100, Matthias Klose a écrit : 
> Fix build failures with ld --as-needed
> - --
> 
> [Note this is not turned on by default]
> 
> Many packages fail to build when the linker is passed --as-needed as the
> default.  These issues are collected at [4] (please tag new issues 
> accordingly).
>  The vast majority of these kind of failures are some assumptions about link
> order with the GNU linker (ld), which may not be fulfilled with other linkers.

Although I cool with the idea of --as-needed everywhere, we need to fix
bug#347650 in libtool before enabling it. This argument reordering will
also break --no-as-needed when --as-needed becomes the default.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

Re: Are circular dependencies inside a source package OK?

[Josselin Mouette]

Le dimanche 27 février 2011 à 16:31 +0100, Lucas Nussbaum a écrit : 
> Ideally, we would have binary packages named like that:
> ruby-foo: arch-indep part of the foo library
> ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
> ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
> jruby-foo: arch-dep part of the foo library, built for jruby
> rubinius-foo: arch-dep part of the foo library, built for rubinius
> 
> But then, we have a problem, because:
> - ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
>   rubinius-foo) installed to work correctly
> - ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
>   installed

Which size is ruby-foo? If it’s not significant, you’re probably wasting
your time.

> What we would like to do to reflect this is:
> - ruby-foo depend on the implementation-specific package for the default
>   version of Ruby (so Depends: ruby1.8-foo)
> - ruby-foo Depends: ruby-foo
> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we have
> many of them already, and that no important part of our infrastructure
> or tools really has problems with them. Also, they are limited to a
> single source package here.

Circular dependencies, in the same source package or not, tend to create
a lot of breakage, especially at uninstall time - partly because dpkg
doesn’t cope well with them.

> Is there a good reason not to do the above?

Yes: circular dependencies are bad. They make the dependency resolver’s
behavior less predictable, and they cause various bugs since postinst
and prerm scripts are run in random order. Triggers often hide these
bugs, but the conceptual problem is still here.

If you really want to split the arch-indep parts, you should create:
- ruby-foo-common containing the arch-indep part;
- ruby1.8-foo (and so on) containing the arch-dependent part;
- ruby-foo which is an empty package depending on ruby1.8-foo.

The simpler solution is to copy the arch-dependent parts in all binary
packages.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

Re: Bug#544060: RFA: dietlibc -- diet libc - a libc optimized for small size

[Hector Oron]

Hello,

2011/2/15 Gerrit Pape :
> Hi, I'm looking for a new maintainer for the dietlibc package.

I would be interested to help out and co-maintain it within some team.

Best regards,
-- 
 Héctor Orón

"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."

-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.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/AANLkTikndTE2TNHDKYsswhdhB8ot0=j7mzq6ord9e...@mail.gmail.com

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[sergey]

On Sun, 27 Feb 2011 15:02:36 +
"Adam D. Barratt"  wrote:

> On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
> > Is it possible that this problem exists because I have some old
> > programs in /usr/local that I moved from my previous Slackware system?
> 
> Yes, I suspect that's the problem; specifically:
> 
> /usr/local/lib/libwx_gtk2u_core-2.8.so.0:
> 
> The version of that library shipped by the Debian wx2.8 packages is
> linked about libtiff.so.4.  Does moving the above out of the way resolve
> your issues?
> 
> Regards,
> 
> Adam
> 

# mv /usr/local/lib/libwx_gtk2u_core-2.8.so.0 
/usr/local/lib/to_del-libwx_gtk2u_core-2.8.so.0
$ gnuplot
gnuplot: error while loading shared libraries: libtiff.so.3: cannot open shared 
object file: No such file or directory

No, it does not work.





-- 
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/20110227202050.637fec1d.sergey_i...@rambler.ru

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[sergey]

I also reported this problem to gnuplot's maintainers as bug #615289 before I 
found how many programs is depend on libtiff.so.3 on my system. 

With Julien's help I have discovered that gnuplot gets dependencies from old 
libraries in /usr/local:

$ ldd /usr/bin/gnuplot | grep /usr/local
libwx_gtk2u_core-2.8.so.0 => /usr/local/lib/libwx_gtk2u_core-2.8.so.0 
(0xb7bad000)
libwx_baseu-2.8.so.0 => /usr/local/lib/libwx_baseu-2.8.so.0 (0xb7a6)

Programs in /usr/local are too important for me so I can't delete them. I found 
the next solution:

$ export LD_LIBRARY_PATH=/lib:/usr/lib

Then gnuplot runs normally in this terminal session.

Is it normal that Debian's programs in my system gets dependencies from 
non-Debian libraries?
In this situation each new installation in /usr/local is a venture with 
unpredictable results.
Any Debian's program can stop work or can begin work in unexpected way after 
installation of new program in /usr/local. It makes Debian unreliable system.

---
Regards, Sergey



-- 
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/20110227182752.0611bb4f.sergey_i...@rambler.ru

Re: Are circular dependencies inside a source package OK?

[Petter Reinholdtsen]

[Lucas Nussbaum]
> However, that creates many small dependency cycles. I am under the
> impression that dependency cycles are considered bad, but that we
> have many of them already, and that no important part of our
> infrastructure or tools really has problems with them. Also, they
> are limited to a single source package here.
>
> Is there a good reason not to do the above?

Dependency loops tend to break in edge cases, and I have run into a few:

 - Installing a lot of packages (~1000 packages done by Debian Edu), a
   while back caused the set of packages to be installed to be split
   into lumps, and some times this installation would fail because the
   split would happen in the middle of such loop.  I believe a
   workaround/fix for this has been implemented, but do not know the
   details.

 - When installing several packages and one of the packages fail to
   install, the recovery system for dpkg/apt fail and leave the system
   in an inconsistent state because only some of the packages in such
   loop have been unpacked and configured.

 - Piuparts is not able to come up with a sensible order to test
   packages when there are dependency loops.  A workaround has been
   implemented.  Suspect packages with loops are simply never tested
   by piuparts

All of these issues might of cause be seen as not important parts of
our infrastructure or not important problems, but I believe they are
enough to still consider package dependency loops a bad idea.

Are there other problems with dependency loops?

Happy hacking,
-- 
Petter Reinholdtsen


-- 
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/2flk4glzdm5@login2.uio.no

Are circular dependencies inside a source package OK?

[Lucas Nussbaum]

Hi,

In the pkg-ruby-extras team, we are currently discussing some big
changes in our packaging tools.

A problem arises for libraries that have a large
architecture-independent part that can be shared between the various
implementations of ruby interpreters (ruby1.8, ruby1.9.1, jruby,
rubinius), but also an architecture-dependent part that needs to be
built for each interpreter.

Ideally, we would have binary packages named like that:
ruby-foo: arch-indep part of the foo library
ruby1.8-foo: arch-dep part of the foo library, built for ruby1.8
ruby1.9.1-foo: arch-dep part of the foo library, built for ruby1.9.1
jruby-foo: arch-dep part of the foo library, built for jruby
rubinius-foo: arch-dep part of the foo library, built for rubinius

But then, we have a problem, because:
- ruby-foo need one of (ruby1.8-foo, ruby1.9.1-foo, jruby-foo,
  rubinius-foo) installed to work correctly
- ruby1.8-foo, ruby1.9.1-foo, jruby-foo, rubinius-foo need ruby-foo
  installed

What we would like to do to reflect this is:
- ruby-foo depend on the implementation-specific package for the default
  version of Ruby (so Depends: ruby1.8-foo)
- ruby-foo Depends: ruby-foo

However, that creates many small dependency cycles. I am under the
impression that dependency cycles are considered bad, but that we have
many of them already, and that no important part of our infrastructure
or tools really has problems with them. Also, they are limited to a
single source package here.

Is there a good reason not to do the above?

- Lucas


-- 
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/20110227153129.ga21...@xanadu.blop.info

Re: What bug reports are for

[Dmitry Baryshev]

At http://www.debian.org/Bugs/Reporting is is said that we should not send
bugs to program authors, but to only Debian BTS. Imagine some system service
reads configuration file, and has critical bug in parsing it. User cannot
debug this. Maintainer closes this bug report with explanation "this is a
bug in something else in your system" (for example, in an unknown backend
library or GUI frontend). Critical bug will be closed and ignored, right?

2011/2/27 Josselin Mouette 

> Le dimanche 27 février 2011 à 14:50 +0200, Dmitry Baryshev a écrit :
> > Who should do this investigation? I did it because I know how to debug
> > this. If user don't know how to debug this, his bug report will be
> > closed without reassigning to proper package. Hence this investigation
> > should be done by maintainer, not user.
>
> You seem to forget the very reason bug reports are here. Their point is
> not to offer a service to our users - if you want that, you’ll need paid
> support. Bug reports are here to help improving the distribution.
>
> Now, maintainers receive a lot of bug reports, and have limited time to
> spare on Debian. Given the choice between:
> 1. packaging a new upstream release that fixes a lot of bugs;
> 2. fixing a nicely reported bug with a reproducible and
>well-identified cause;
> 3. investigating a dubious bug report that seems to be triggered by
>a broken user configuration;
> only masochistic maintainers will spend time on #3 when they can help a
> lot more users on #1 and #2. It’s not that it’s easier (I remember
> spending entire days on single bugs), but it’s more useful.
>
> Now, if you spend enough time investigating to be able to tell, at the
> very least, “this is a bug in library foo which is reproducible by doing
> bar”, your report might go from #3 to #2 and get fixed.
>
> Cheers,
> --
>  .''`.  Josselin Mouette
> : :' :
> `. `'  “If you behave this way because you are blackmailed by someone,
>  `-[…] I will see what I can do for you.”  -- Jörg Schilling
>
>


-- 
Regards, Krasu

Bug#615591: ITP: lightdm -- simple display manager with GTK+, Qt and Webkit greeters

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: lightdm
  Version : 0.2.3
  Upstream Author : Robert Ancell
* URL : https://launchpad.net/lightdm
* License : GPL-3
  Programming Lang: C/
  Description : simple display manager with GTK+, Qt and Webkit greeters

LightDM is a simple display manager which intents to support “modern”
standards (like ConsoleKit), various desktop environments (having three
greeters using GTK+, Qt and Webkit libs) and still be lightweight.



--
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/20110227152533.4966.15374.reportbug@hidalgo

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[Adam D. Barratt]

On Sun, 2011-02-27 at 14:33 +0300, sergey wrote:
> Is it possible that this problem exists because I have some old
> programs in /usr/local that I moved from my previous Slackware system?

Yes, I suspect that's the problem; specifically:

/usr/local/lib/libwx_gtk2u_core-2.8.so.0:

The version of that library shipped by the Debian wx2.8 packages is
linked about libtiff.so.4.  Does moving the above out of the way resolve
your issues?

Regards,

Adam




-- 
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/1298818956.535.10942.ca...@hathi.jungle.funky-badger.org

What bug reports are for

[Josselin Mouette]

Le dimanche 27 février 2011 à 14:50 +0200, Dmitry Baryshev a écrit : 
> Who should do this investigation? I did it because I know how to debug
> this. If user don't know how to debug this, his bug report will be
> closed without reassigning to proper package. Hence this investigation
> should be done by maintainer, not user.

You seem to forget the very reason bug reports are here. Their point is
not to offer a service to our users - if you want that, you’ll need paid
support. Bug reports are here to help improving the distribution.

Now, maintainers receive a lot of bug reports, and have limited time to
spare on Debian. Given the choice between: 
 1. packaging a new upstream release that fixes a lot of bugs; 
 2. fixing a nicely reported bug with a reproducible and
well-identified cause; 
 3. investigating a dubious bug report that seems to be triggered by
a broken user configuration;
only masochistic maintainers will spend time on #3 when they can help a
lot more users on #1 and #2. It’s not that it’s easier (I remember
spending entire days on single bugs), but it’s more useful.

Now, if you spend enough time investigating to be able to tell, at the
very least, “this is a bug in library foo which is reproducible by doing
bar”, your report might go from #3 to #2 and get fixed.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling



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

NMU procedure

[Julien Cristau]

Hi,

there are a number of NMUs currently in the delayed queue, adding armhf
support to some packages.  The bugs referenced in those uploads have
seen no notification of any such upload, and no NMU diff has been sent.
Please fix this.  And in the future, do that before you upload, per
http://www.debian.org/doc/developers-reference/pkgs.html#nmu

Thanks,
Julien


-- 
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/20110227132233.ga4...@radis.liafa.jussieu.fr

Re: maintainer ignores bug

[Dmitry Baryshev]

2011/2/26 Osamu Aoki 

> Hi,
>
> On Sat, Feb 26, 2011 at 11:45:46AM -0500, Michael Gilbert wrote:
> > On Sat, 26 Feb 2011 17:52:02 +0200 Dmitry Baryshev wrote:
> >
> > > Hello guys.
> > >
> > > I've filed a bug on reportbug, but its maintainer ignores it,
>
> No  maintainer did not ignore it.  He responded reasonably.
>
> > and continues
> > > to close it without any troubleshooting or debug. I did a simple
> > > troubleshooting by myself, but maintainer ignored it and closed the bug
> > > again. With whom I can talk about this strange situation? The bug
> itself:
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599476
>
> Has Mr. Mr. Dmitry Baryshev read all the responses by Sandro Tosi.  I
> think Sandro made it very clear (typo corrected):
>
> | Really, stop this game, it's not a bug in reportbug but in *something
> | else* of your system.
>
> > > Please CC any comments. Thanks!
>
> Here is CC for Mr. Dmitry Baryshev.
>
> > It looks like its an issue with your choice of .gtkrc files.  Tahoma is
> > a microsoft font and will not be on a debian system by default, so that
> > may be the problem itself.  You can just remove or back up those files,
> > and you should be fine.
>


This can happen due to broken font renderer or broken font itself. In KDE
this font works fine, so, it's a broken font renderer in GTK or python-gtk
or reportbug or something. No one even tried to diagnose this I mean.



>
> Anyway, if I trust Mr. Dmitry Baryshev, he has pure squeeze.  What ever
> application he used to create this situation may be the cause.  He needs
> to file a bug report to the package which is causing problem.  (I do not
> know how he created this ~/.gtkrc which he claims to be the cause.)
> reportbug has nothing to do with this.
>
> One may file a general bug report if he does not know which package is
> causing problem.  But that is usually a least useful kind of bug report.
>
> One should not report bug to the wrong package.  If it is not
> immediately clear to DD which package is causing problem from a vague
> bug report which seems to be caused by user miss configuration, DD will
> close such useless bug report.  It serves nothing.
>
> Please think about this.
>
> Osamu
>



-- 
Regards, Krasu

Re: enable/disable flags in /etc/default

[Adrian von Bidder]

On Saturday 26 February 2011 21.44:07 Tollef Fog Heen wrote:
> I'd like us to decide on a policy about enable/disable flags in
> /etc/default in general.

+1 on those who don't like to have them.

The init scripts (or whatever) need to

 * provide a sane default for startup order

 * allow users to override this

 * allow for startup of a daemon to be (de)activated persistently 
(persistent over package upgrades, that is.)

 * and the package scripts (pre/postinst on upgrade especially) need to 
respect this (i.e. work in a sane way when the daemon is down, not leaving 
it started if it wasn't started etc.)

 * all documentation needs to be updated so that users finally don't end up 
doing silly things just so that mysql isn't started on boot[1].

I'm sure I forgot some, but I that are the ones I can just think of.

The whole topic shouldn't be Debian specific.  I have no idea, but isn't 
there an LSB or whatever spec?  Where does it fall short?  Who should be 
involved to get something that other distributions could use as well?

-- vbi

[1] Yes, I know, the "mysql needs to be installed for kde but I don't want 
to run it" case has finally been solved.  Similar cases will keep coming up, 
I'm sure...

-- 
Nirgendwo fällt Humorlosigkeit mehr auf als beim Lachen.
-- Oliver Hassencamp


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

Re: maintainer ignores bug

[Dmitry Baryshev]

2011/2/27 Osamu Aoki 

> Hi,
>
> On Sat, Feb 26, 2011 at 07:41:18PM +0100, Jakub Wilk wrote:
> > * Osamu Aoki , 2011-02-27, 02:50:
> > >>>I've filed a bug on reportbug, but its maintainer ignores it,
> > >
> > >No  maintainer did not ignore it.  He responded reasonably.
> >
> > He did not. Declaring "it's not a bug in my package" without even
> > trying to diagnose the problem is not only unreasonable but also
> > rude.
>
> I did not quote full dialogue.  There were good deal of previous
> exchanges.  Sandro judged "unreproducible" and " this is something
> broken on your machine".
>
> > >One should not report bug to the wrong package.
> >
> > Yes, ideally one should also be omniscient...
>
> I am not sure what is "omniscient".  If it means "crystal clear", yes it
> was very clear and very unlikely reportbug was the root cause of Mr.
> Dmitry Baryshev's problem.  At least, Mr.  Dmitry Baryshev's report was
> unconvincing and now he even indicates some other application was likely
> cause.
>
>

Who should do this investigation? I did it because I know how to debug this.
If user don't know how to debug this, his bug report will be closed without
reassigning to proper package. Hence this investigation should be done by
maintainer, not user. Why? Because this problem is reproduced in reportbug,
and only in reportbug (at least on my system). In our case maintainer didn't
do any diagnostic and closed bugreport without reassigning or investigation.
So, user will waste his time to debug this by himself, to communicate with
other people in -devel lists, and so on, in other words doing maintaner's
job. Most likely he will not do that, and this bug will never be closed.



> On Sat, Feb 26, 2011 at 07:50:09PM +0100, Hendrik Sattler wrote:
> > Am Samstag 26 Februar 2011, 18:50:41 schrieb Osamu Aoki:
> > > > It looks like its an issue with your choice of .gtkrc files.
> >
> > I really do not recommend the setting in KDE to influence the themes of
> GTK
> > programs. For me, it makes iceweasel using 100% _after_ closing it. It
> drove
> > me almost nuts on my laptop until I found the cause.
>
> "Some KDE application is the root cause" was my impression, too.
>
> I recommend Mr,. Dmitry Baryshev to keep this bug report closed and file
> anther bug report on the KDE package he used to create this
> configuration after through investigation. (Of course he can use
> reopen/reassign of old bug report with method written at
> http://www.debian.org/Bugs/server-control but that is an expert option.)
>
> Osamu
>



-- 
Regards, Krasu

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Ben Finney]

jida...@jidanni.org writes:

> Well OK, but can't the package owners get a friendly mail once a day
> "yoo hoo Holmes, your package is now broken"

They can monitor the package's QA page.

> lest they relax at the beach totally unaware one day Auntie Nelda
> might suddenly have the urge to use their package in a hurry?

Why is Auntie Nelda using the unstable repository? Is she comfortable
running an OS from a repository with no promises about stability? If
not, who advised her to do that?

-- 
 \   “We must find our way to a time when faith, without evidence, |
  `\disgraces anyone who would claim it.” —Sam Harris, _The End of |
_o__) Faith_, 2004 |
Ben Finney


-- 
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/8762s563tb@benfinney.id.au

Bug#615559: ITP: libio-handle-util-perl -- IO::Handle::Util perl pakage

[Nicholas Bamber]

Package: wnpp
Severity: wishlist
Owner: Nicholas Bamber 


* Package name: libio-handle-util-perl
  Version : 0.01
  Upstream Author : Yuval Kogman 
* URL : http://search.cpan.org/dist/IO-Handle-Util/
* License : Perl
  Programming Lang: Perl
  Description : IO::Handle::Util perl pakage

utilities for IO::Handle objects



-- 
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/20110227121951.11412.52080.reportbug@leonhartsberger.periapt

Bug#615476: general: many binaries are linked with non-existent libtiff.so.3 library

[sergey]

Is it possible that this problem exists because I have some old programs in 
/usr/local that I moved from my previous Slackware system?

I have no gnuplot in /usr/local/bin.





-- 
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/20110227143330.0bdf3a98.sergey_i...@rambler.ru

Processed: Re: Bug#615153: exec: 58: /usr: Permission denied

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 615153 general
Bug #615153 [other] exec: 58: /usr: Permission denied
Warning: Unknown package 'other'
Bug reassigned from package 'other' to 'general'.
> --
Stopping processing here.

Please contact me if you need assistance.
-- 
615153: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615153
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.129880180225030.transcr...@bugs.debian.org

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Philipp Kern]

On 2011-02-27, Paul Wise  wrote:
> On Sun, Feb 27, 2011 at 4:02 PM, Lars Wirzenius  wrote:
>> We don't care if something is temporarily uninstallable in unstable. The
>> only way to prevent that from happening would be to keep packages from
>> entering unstable unless all their dependencies are in unstable already,
>> and that would prevent bug fixes from coming into unstable faster. This
>> is important because a source package might produce several binary
>> packages, and some of them might both be fixing bugs and be
>> uninstallable.
> Something that might work would be to keep the old source/binary
> packages around (as well as the new ones) until nothing depends on
> them. IIRC the release team have the ability to (temporarily) have
> multiple versions of a source package in testing, perhaps something
> like that could be added for sid.

What we do for some transitions is editing the source package a library package
comes from, so that both library revisions (libfoo1 and libfoo2) are considered
eligible to stay in testing at the same time.  This eases the pain of some
transitions.  For that to work in sid, as library removal is manual anyway, you
need to convince ftp-masters not to remove them when there are still quite a
bunch of reverse dependencies.  Given that NBS removals should show the rdeps
too, it'd only be a policy decision.

Kind regards
Philipp Kern


-- 
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/slrnimk8jn.dss.tr...@kelgar.0x539.de

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Stefano Zacchiroli]

On Sun, Feb 27, 2011 at 03:49:43PM +0800, jida...@jidanni.org wrote:
> Aren't there any checks in place to prevent a package from becoming
> uninstallable?  E.g., bug #615530, #615528.

We have tool to detect that and we periodically monitor the
uninstallable packages in the various suites using edos-distcheck:

  http://edos.debian.net/

That is not enough to *prevent* the uninstallability, because uploads to
the archive are not transactional (e.g. upload and buildd delays). But
even if they were transactional, trying to prevent (temporary)
uninstallability issues would probably create more probably than it
solves. For instance, it will create a new kind of "transition", forcing
people to upload at the same time all the packages needed to avoid
temporary uninstallability (who might be maintained by different
maintainers ...). That might work in more controlled distributions, such
as emdebian who does that, but it's most likely too constraining to
apply to Debian, for little benefit.

An in between solution would be an optional upload time check that will
warn of the temporary uninstallability that an upload will induce. To
have that though, the best way would be support for upload time hooks in
dput. We've discussed that in the past---see #477919---but no one ended
up adding the needed support to dput.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Michael Banck]

On Sun, Feb 27, 2011 at 04:42:28PM +0800, jida...@jidanni.org wrote:
> Well OK, but can't the package owners get a friendly mail once a day
> "yoo hoo Holmes, your package is now broken", lest they relax at the
> beach totally unaware one day Auntie Nelda might suddenly have the urge
> to use their package in a hurry?

If you use "Auntie Nelda" as synonym for "a regular user", we expect
those to either deal with the situation (e.g. using snapshot.debian.org)
themselves, or using testing.


Michael


-- 
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/20110227090107.gc3...@nighthawk.chemicalconnection.dyndns.org

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[jidanni]

Well OK, but can't the package owners get a friendly mail once a day
"yoo hoo Holmes, your package is now broken", lest they relax at the
beach totally unaware one day Auntie Nelda might suddenly have the urge
to use their package in a hurry?


-- 
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/87bp1xhnrf@jidanni.org

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Andrei Popescu]

On Du, 27 feb 11, 16:15:40, Paul Wise wrote:
> 
> Something that might work would be to keep the old source/binary
> packages around (as well as the new ones) until nothing depends on
> them. IIRC the release team have the ability to (temporarily) have
> multiple versions of a source package in testing, perhaps something
> like that could be added for sid.

Or just advise sid users to have testing in their sources.list ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Paul Wise]

On Sun, Feb 27, 2011 at 4:02 PM, Lars Wirzenius  wrote:

> We don't care if something is temporarily uninstallable in unstable. The
> only way to prevent that from happening would be to keep packages from
> entering unstable unless all their dependencies are in unstable already,
> and that would prevent bug fixes from coming into unstable faster. This
> is important because a source package might produce several binary
> packages, and some of them might both be fixing bugs and be
> uninstallable.

Something that might work would be to keep the old source/binary
packages around (as well as the new ones) until nothing depends on
them. IIRC the release team have the ability to (temporarily) have
multiple versions of a source package in testing, perhaps something
like that could be added for sid.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/AANLkTi=fogd2owavjejlfkn8vik0d64gmn17acw8k...@mail.gmail.com

Re: Aren't there any checks in place to prevent a package from becoming uninstallable?

[Lars Wirzenius]

On su, 2011-02-27 at 15:49 +0800, jida...@jidanni.org wrote:
> Aren't there any checks in place to prevent a package from becoming 
> uninstallable?
> E.g., bug #615530, #615528.

We don't care if something is temporarily uninstallable in unstable. The
only way to prevent that from happening would be to keep packages from
entering unstable unless all their dependencies are in unstable already,
and that would prevent bug fixes from coming into unstable faster. This
is important because a source package might produce several binary
packages, and some of them might both be fixing bugs and be
uninstallable.

Unstable is not guaranteed to work at any one time. Any missing
dependencies will get dealt with at release time if not earlier. An
attempt to make unstable work better would result in development having
more obstacles, and thus becoming slower. That would not be a good
thing.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1298793773.2809.26.ca...@havelock.lan