Re: About a mass bug report not based on Sid or Jessie.

[Andreas Tille]

Hi,

On Mon, Apr 14, 2014 at 05:12:32PM +0200, Matthias Klose wrote:
> it would be much more productive for Debian if you wouldn't claim wrong things
> and start fixing the issue in at least this package.

Just for the record:  The bug is fixed but die to some additional changes
(providing data for autopkgtest) the package went over new queue:

   https://ftp-master.debian.org/new/staden-io-lib_1.13.5-2.html

Kind regards

Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417072413.gf22...@an3as.eu

Re: About a mass bug report not based on Sid or Jessie.

[Thorsten Glaser]

Wookey dixit:

> +++ Paul Wise [2014-04-16 19:51 +0800]:
> > On Wed, Apr 16, 2014 at 7:13 PM, Santiago Vila wrote:
> > 
> > > What some people here try to do, update config.guess and related files,
> > > is, IMHO, just a hack. Sure, it will just work, but only for us (Debian).
[…]
> > Other distributors do the config.guess/sub dance by default IIRC.
> 
> Certainly build-from-source distros like OE and gentoo do. Not sure
[…]

We do both in MirPorts (for MirBSD): update config.{guess,sub} is
only half the part though, you really also need to run autoconf,
autoheader, aclocal, automake usually. (In MirBSD I even swap out
libtool, but that’s because platform support is not upstreamed, and
even if it were, that’d be too late for the vast majority of the
software around because software uses libtool 1.5, or at best 2.0/2.1
not $current+1 which is where that’d end up.)

> * add autotools-dev to build-essential so it's always available for

autotools-dev is not enough, see above and below. But build-essential
is the wrong place: debhelper is not in it either…


Paul Wise dixit:

> On Thu, Apr 17, 2014 at 2:42 AM, Russ Allbery wrote:
> > Wookey writes:
> >
> >> So, where in debian should we put responsiblity for updating
> >> config.{sub,guess}?
> >
> > I lean towards being more aggressive than this and running autoreconf or
> > the moral equivalent on any package using Autoconf, by default.  For that

Full ACK here, both with DD hat, and as advice from what I learned
porting software to MirBSD.

> Add a lintian warning for packages using autotools, debhelper compat <
> 10 and not using --with autoreconf.

As long as lintian will not trigger this warning for people not
using dh7 short style, agreed.

(How does one use dh-autoreconf manually, anyway? It’s a pretty
recent thing, never seen it… just B-D on it and call it before
running configure?)


On Wed, 16 Apr 2014, Guido Günther wrote:

> On Mon, Apr 14, 2014 at 05:10:40PM -0700, Steve Langasek wrote:
[…]
> > But I think we ought to switch to autoreconfing by default.
> 
> I do too but I do wonder if this might make stable backports harder
> since newer autoconf macros might not be available in stable and we
> wouldn't have noticed (or cared) until rerunning autoreconf. So being
> able to easily turn it off would be nice.

Full NAK there: if adding dh-autoreconf produces errors (other than
bugs in dh-autoreconf or autoconf that make regenerating configure
with the method used by dh-autoreconf fail), your package is RC-buggy
because it does not build from the source that’s shipped in the archive.

If you need newer autoconf macros in backports, you can build-depend
on a backport of autoconf.

It’s kinda the same thing as “regenerate documentation at build time”
except not doing so for autoconf/automake/libfool is worse and has a
much higher potential for introducing problems.

One PITA here is that autofools versions are not upwards or downwards
compatible. In MirPorts, we solved this by hacking libtool 1.5 to also
work with automake 1.4 and autoconf 2.13, then packaging several ver‐
sions of autoconf and automake, which are coïnstallable, and allow the
package to select (between “old” 1.4/2.13 and “new”, which is 1.9/2.61
by default but allows e.g. 1.10/2.64 too.)

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.10.1404171028430.19...@tglase.lan.tarent.de

Bug#744996: ITP: varscan -- variant detection in next-generation sequencing data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: varscan
  Version : 2.3.6
  Upstream Author : Dan Koboldt
* URL : http://varscan.sourceforge.net/
* License : NPOSL-3.0
  Programming Lang: Java
  Description : variant detection in next-generation sequencing data
 Variant detection in massively parallel sequencing. For one sample,
 calls SNPs, indels, and consensus genotypes. For tumor-normal pairs,
 further classifies each variant as Germline, Somatic, or LOH, and also
 detects somatic copy number changes.


This package is maintained by the Debian Med team at
 git://anonscm.debian.org/debian-med/varscan.git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140417092448.27585.63180.report...@mail.an3as.eu

debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

How to reconfigure one package from another?

I want to reconfigure packages from other packages.

Example:

  * package foo-player
+ supports both JackD and PulseAudio, but only one
+ asks which method to use via debconf
  * package bar-studio-desktop
+ depends on xfce4, jackd2 and foo-player
+ conflicts against bar-office-desktop
+ postinst script asks foo-player to use JackD
  * package bar-office-desktop
+ depends on xfce4, pulseaudio and foo-player
+ conflicts against bar-studio-desktop
+ postinst script asks foo-player to use PulseAudio.

How could such postinst scripts look?

I thought debconf-set-selections + dpkg-reconfigure would work, but as 
[Petter points out] current package setting takes precedence over 
preseeded values.

Seems to me that I need to do like dpkg-reconfigure, but have my new 
preseeding value(s) take precedence over both debconf database and 
package state.

Help figuring this out is much appreciated.

 - Jonas

[Petter points out]: 
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2014-April/006333.html

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: debconf reconfiguration from postinst of another package

[Charles Plessy]

Le Thu, Apr 17, 2014 at 01:50:40PM +0200, Jonas Smedegaard a écrit :
> How to reconfigure one package from another?
> 
> I want to reconfigure packages from other packages.
> 
> Example:
> 
>   * package foo-player
> + supports both JackD and PulseAudio, but only one
> + asks which method to use via debconf
>   * package bar-studio-desktop
> + depends on xfce4, jackd2 and foo-player
> + conflicts against bar-office-desktop
> + postinst script asks foo-player to use JackD
>   * package bar-office-desktop
> + depends on xfce4, pulseaudio and foo-player
> + conflicts against bar-studio-desktop
> + postinst script asks foo-player to use PulseAudio.
> 
> How could such postinst scripts look?

Hi Jonas,

If the maintainer scripts of the three packages can cooperate, have you
considered using Dpkg triggers ?

Have a nice day

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417121741.gm21...@falafel.plessy.net

Re: debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

Quoting Charles Plessy (2014-04-17 14:17:41)
> Le Thu, Apr 17, 2014 at 01:50:40PM +0200, Jonas Smedegaard a écrit :
>> How to reconfigure one package from another?
> If the maintainer scripts of the three packages can cooperate, have 
> you considered using Dpkg triggers ?

Sorry if that was unclear: My question is about use of debconf.

foo-player is a package maintained by someone, and more realistically 
there are 10 or maybe 50 such packages that I want to reconfigure.

Concretely I need this for Debian Blends like FreedomBox, DebianParl and 
Debian-design - and I dearly hope same techniques will be embraced also 
for Skolelinux to solve bug#311188.

This issue is not specific to Blends, however - hence raising the 
question here.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#745035: ITP: ruby-faraday-middleware-multi-json -- Response JSON parser using MultiJson and FaradayMiddleware

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: ruby-faraday-middleware-multi-json
  Version : 0.0.5
  Upstream Author : Dennis Rogenius 
* URL : https://github.com/denro/faraday_middleware-multi_json
* License : MIT
  Programming Lang: Ruby
  Description : Response JSON parser using MultiJson and FaradayMiddleware

ruby-faraday-middleware-multi-json is a simple Faraday middleware that uses
MultiJson to unobtrusively encode JSON requests and parse JSON responses.

This package will be maintained by the Ruby team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417124645.29609.78568.reportbug@localhost

Re: automatic autoconf config file updating

[Wookey]

+++ Russ Allbery [2014-04-16 11:42 -0700]:
> Wookey  writes:
> 
> > So, where in debian should we put responsiblity for updating
> > config.{sub,guess}? 
> 
> I lean towards being more aggressive than this and running autoreconf or
> the moral equivalent on any package using Autoconf, by default. 

Yes, I should have qualified my message to say 'this is only
considering the easy, config-update part of this'.

I too am in favour of full autoreconfing, for the reasons you covered.

The one thing to say in favour of just the config.{sub,guess} part (I
wish it had a better 'name' :-) is that it is something so safe and
simple that it could just be done, without every maintainer having to
do an upload. Breakage would be negligible and a large fraction of the
problem would be solved (for arm64 and many other ports, although not
for the ppc64el port or cases like it), and it could be done in a
week or two, not a year or five. Gating on an upload with debhelper
compat level change, and for some packages actual work by maintainers
to fix 'newer autotools' breakage is going to make this a slow
transition.

Still, we do like to do things properly if slowly round here, so I'm
quite happy that the consensus seems to be to solve the hard problem
and not just part of it.

I explore a bit below whether it makes sense to work on both of these
things.

> If we assume that we want to solve the whole problem in the dh-autoreconf
> approach instead of only updating config.{sub,guess}, I think it restricts
> the problem space somewhat more.  For example, no patch to Autoconf is
> going to tackle that alone, and I think adding all of autoconf, automake,
> and libtool to build-essential is a harder sell than just adding
> autotools-dev.

Agreed
 
> What I'd therefore lean towards is for debhelper and CDBS (with a new
> compat level) to automatically run dh-autoreconf if Autoconf was detected
> but without depending on them, resulting in an immediate FTBFS on all
> platforms if the package doesn't Build-Depend on dh-autoreconf but no
> change for packages that use some other build system (like our innumerable
> Perl modules).

Does CDBS have 'compat levels'? Maybe it doesn't matter as the
debhelper one will show through in this case?

Also this doesn't fix things for packages using autoconf but not
debhelper (whether via CDBS or not). I guess those can/should only be
fixed by explicit changes to the rules file (to run dh_autoreconf) or
an autoconf patch which would update the config files by default.

Ben, are you following this thread? If you don't object violently to
adding Paul's 'update from Debian canonical config.{sub.guess}
locations by default' patch to the Debian autoconf, then that just
leaves my original issue of what ensures that those files are
installed at build time? Can we put it in Build-essential, or do we
have to have every package build-dep on it explicitly (which get us
back to the 'fix every package' issue (although it is a trivial fix
that anyone can get right in this case)).

Some input from the debhelper and CDBS maintainers on whether they
think Russ's approach makes sense would be good.

> The maintainer will then have to add the dh-autoreconf
> build dependency when they update the debhelper compat level, and then the
> rest of the machinery will be taken care of by the helpers if they're
> used.

What is the right build-dependency for non-debhelper packages?

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417142009.gh29...@stoneboat.aleph1.co.uk

Bug#745052: ITP: python-xmltodict -- Python module to easily work with XML tree

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: python-xmltodict
  Version : 0.9.0
  Upstream Author : Martin Blech 
* URL : https://github.com/martinblech/xmltodict
* License : MIT
  Programming Lang: Python
  Description : Python module to easily work with XML tree

xmltodict is a Python module that makes working with XML feel like you are
working with JSON. xmltodict is very fast (Expat-based) and has a streaming
mode with a small memory footprint, suitable for big XML dumps·


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417154450.27408.84134.reportbug@localhost

Re: automatic autoconf config file updating

[Wookey]

+++ Wookey [2014-04-17 15:20 +0100]:
> +++ Russ Allbery [2014-04-16 11:42 -0700]:
> > Wookey  writes:
> > 
> > > So, where in debian should we put responsiblity for updating
> > > config.{sub,guess}? 
> > 
> > I lean towards being more aggressive than this and running autoreconf or
> > the moral equivalent on any package using Autoconf, by default. 
> 
> Yes, I should have qualified my message to say 'this is only
> considering the easy, config-update part of this'.
> 
> I too am in favour of full autoreconfing, for the reasons you covered.

OK. And, entirely by chance, up comes an example of why this is
thornier than it should be and this isn't as simple as 'either update
config.sub,guess, or autoreconf'. We have to do both, and the latter
doesn't necessarily do the former for us.

(Note I'm not picking on the libgc maintainer here - he's diligently
updated stuff like we asked and couldn't easily test any of the new
architecture cases - this is just a convenient example)

So libgc is a package where the maintainer has helpfully just uploaded
a version with "Run full autoconf during build (Closes: #732349)" -
i.e. did just what we've been recommending.

However it still FTBFS on arm64: 
http://buildd.debian-ports.org/status/package.php?p=libgc&suite=sid
with: Invalid configuration `aarch64-linux-gnu': machine `aarch64' not 
recognized

The maintainer has noted that upstream provides a non-trivial
autogen.sh script so has told dh_autoreconf to run that. This all
seems very sensible (although I get vague about the full implications
of this, it's certainly quite a common case).  However the config.sub
and guess in the package are 2011-vintage and thus too old to know
about aarch64. (actually oddly, config.guess does know about it and
says 'you are on aarch64', but config.sub then says 'never heard of
it' and barfs - this pairing is perhaps a bug in itself, but as it
illustrates a wider point I'm not going to blame the maintainer - lets
just pretend they were both too old - it makes no practical
difference).

The issue here is ultimately that anything that uses upstream
autotools, rather than debian wrapping round it will _never find_ the
canononical distro config files in /usr/share/misc/config.{sub,guess}.

You can run autoreconf till you are blue in the face it'll never pick
up those files. dh_autotools-dev_updateconfig will, dh_autoreconf
should, but doesn't under all circs, possibly for good reasons.

So the core issue here is that because upstream autoconf have said
they don't want to look through a list of distro canonical paths,
(https://lists.gnu.org/archive/html/autoconf/2012-10/msg00036.html)
autoconf will never find our (uptodate) config.* files by itself. You
have to use some debian-foo to do that (or set the upstream magic env
var CONFIG_GUESS=path before calling configure). I tried setting the
magic var and it didn't work (possibly because the configure script is
too old).

So far as I can see the way to make this work the way it should is to
put Paul's 'and look in the debian paths' patch into the debian
version of autoconf. At which point any use of autoreconf should pick
them up (although I admit to being rather vague about exactly when
this will/won't work without some more poking about).

So (AIUI, which isn't that well) there are three parts to this
1) ensure uptodate config.* files are on the system at build time
2) ensure they get used
3) autoreconf things so all the other pieces are uptodate too.

Without all three of those things porting problems will persist.



Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417170507.gi29...@stoneboat.aleph1.co.uk

Re: automatic autoconf config file updating

[Jonas Smedegaard]

Quoting Wookey (2014-04-17 16:20:09)
> +++ Russ Allbery [2014-04-16 11:42 -0700]:
>> What I'd therefore lean towards is for debhelper and CDBS (with a new 
>> compat level) to automatically run dh-autoreconf if Autoconf was 
>> detected but without depending on them, resulting in an immediate 
>> FTBFS on all platforms if the package doesn't Build-Depend on 
>> dh-autoreconf but no change for packages that use some other build 
>> system (like our innumerable Perl modules).
>
> Does CDBS have 'compat levels'?

No, not in similar sense as debhelper.

(there's an ABI but that has so far never been bumped).


> Maybe it doesn't matter as the debhelper one will show through in this 
> case?

Not sure what you mean here.

CDBS could simply have the autotools.mk snippet opportunistically 
include autoreconf.mk (i.e. with "-include").  Lintian could then check 
for "build-depends on cdbs and includes autotools.mk but does not 
build-depend on dh-autoreconf" with as high a severity as we want to 
pressure maintainers.

If we decide dh-autoreconf is the way forward, that is.

Personally I would then silence the lintian warning, because...

 a) I dislike dh-autoreconf: It removes changed files  which breaks my
workflow where disappearing files are treated as an error.
 b) I prefer stripping automade files from source tarball, to avoid the 
(IMO required) hassle of both verifying that we also ship proper 
sources for them, and track copyright/licensing for them.


> Also this doesn't fix things for packages using autoconf but not 
> debhelper (whether via CDBS or not). I guess those can/should only be 
> fixed by explicit changes to the rules file (to run dh_autoreconf) or 
> an autoconf patch which would update the config files by default.

Perhaps lintian could here check for "depends on autotools but none of 
debhelper, cdbs or dh-autotools".


> Some input from the debhelper and CDBS maintainers on whether they 
> think Russ's approach makes sense would be good.

I like this general idea but not the actual dh-autoreconf tool, but have 
no alternative proposal so can live with that if others find it cool.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#745062: ITP: python-ncclient -- Python library for NETCONF clients

[Sebastien Badia]

Package: wnpp
Severity: wishlist
Owner: Sebastien Badia 

* Package name: python-ncclient
  Version : 0.4.1
  Upstream Author : Leonidas Poulopoulos 
* URL : http://ncclient.grnet.gr/
* License : Apache-2
  Programming Lang: Python
  Description : Python library for NETCONF clients

ncclient is a Python library that facilitates client-side scripting
and application development around the NETCONF protocol.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417173012.1981.89468.reportbug@localhost

Re: automatic autoconf config file updating

[Steve Langasek]

On Thu, Apr 17, 2014 at 03:20:09PM +0100, Wookey wrote:
> Also this doesn't fix things for packages using autoconf but not
> debhelper (whether via CDBS or not).

https://lists.debian.org/debian-devel-changes/2014/04/msg01249.html

Even Manoj, the most stalwart supporter of by-hand rules files, has started
adopting dh(1).  (Welcome back, Manoj!)  It's time for us to stop making
excuses for maintainers making things hard for the project by refusing to
use our higher-level abstractions.

> Ben, are you following this thread? If you don't object violently to
> adding Paul's 'update from Debian canonical config.{sub.guess}
> locations by default' patch to the Debian autoconf, then that just
> leaves my original issue of what ensures that those files are
> installed at build time? Can we put it in Build-essential, or do we
> have to have every package build-dep on it explicitly (which get us
> back to the 'fix every package' issue (although it is a trivial fix
> that anyone can get right in this case)).

> Some input from the debhelper and CDBS maintainers on whether they
> think Russ's approach makes sense would be good.

There's no reason for a debhelper subtool to be part of build-essential.  It
can, however, be straightforwardly rolled into debhelper as a dependency or
by being absorbed directly.  I don't see any reason not to do this, and
intend to put together a patch when I have a few minutes to spare.

> > The maintainer will then have to add the dh-autoreconf
> > build dependency when they update the debhelper compat level, and then the
> > rest of the machinery will be taken care of by the helpers if they're
> > used.

> What is the right build-dependency for non-debhelper packages?

The right build-dependency for non-debhelper packages is 'debhelper'. :P

-- 
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: automatic autoconf config file updating

[Russ Allbery]

Jonas Smedegaard  writes:

> Personally I would then silence the lintian warning, because...

>  a) I dislike dh-autoreconf: It removes changed files  which breaks my
> workflow where disappearing files are treated as an error.
>  b) I prefer stripping automade files from source tarball, to avoid the 
> (IMO required) hassle of both verifying that we also ship proper 
> sources for them, and track copyright/licensing for them.

You realize these contradict each other, right?  If you strip the automade
files from the source tarball, then dh-autoreconf will no longer delete
changed files, since the files that it deletes are exactly the files that
you're stripping.

So unless I'm missing something, it seems like you should continue to do
(b) if you want to do that... and then also use dh-autoreconf.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx9r4xzr@windlord.stanford.edu

':any' syntax in package names in jessie/sid Packages

[Eugene V. Lyubimkin]

Hello,

It seems that in jessie (and similar in sid) a number of packages [1]
started to use ':' symbol in their dependency lists as part of package
names. This is, if I'm not misreading the Debian Policy §7.1 and §5.6.1,
is not allowed.

Suggestions for issue's severity and how to proceed?


[1] mainly python-related + libidl0, > 800 binary packages in total

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140417192411.GA27749@debian-w500.Elisa

Re: ':any' syntax in package names in jessie/sid Packages

[Jakub Wilk]

* Eugene V. Lyubimkin , 2014-04-17, 22:24:
It seems that in jessie (and similar in sid) a number of packages [1] 
started to use ':' symbol in their dependency lists as part of package 
names. This is, if I'm not misreading the Debian Policy §7.1 and 
§5.6.1, is not allowed.


Suggestions for issue's severity and how to proceed?


[1] mainly python-related + libidl0, > 800 binary packages in total


Regarding python, you mind find this thread interesting:
https://lists.debian.org/20130916140255.gf32...@riva.ucam.org

--
Jakub Wilk


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

Re: ':any' syntax in package names in jessie/sid Packages

[Jakub Wilk]

* Jakub Wilk , 2014-04-17, 21:40:

* Eugene V. Lyubimkin , 2014-04-17, 22:24:
It seems that in jessie (and similar in sid) a number of packages 
[1] started to use ':' symbol in their dependency lists as part of 
package names. This is, if I'm not misreading the Debian Policy §7.1 
and §5.6.1, is not allowed.


Suggestions for issue's severity and how to proceed?


[1] mainly python-related + libidl0, > 800 binary packages in total


Regarding python, you mind find this thread interesting:
https://lists.debian.org/20130916140255.gf32...@riva.ucam.org


Blah, I meant debian-python part of this thread, which is:
https://lists.debian.org/debian-python/2013/09/msg00044.html

--
Jakub Wilk


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

Re: automatic autoconf config file updating

[Bas Wijnen]

FTR: I like running autoreconf to make sure actual sources are used, and
to document the build process for users who want to change any source
file, including Makefile.am etc.

On Thu, Apr 17, 2014 at 07:08:30PM +0200, Jonas Smedegaard wrote:
>  a) I dislike dh-autoreconf: It removes changed files  which breaks my
> workflow where disappearing files are treated as an error.

AFAIK this is incorrect.  It will make backup copies during build, and
replace them during clean.

Thanks,
Bas


signature.asc
Description: Digital signature

Re: automatic autoconf config file updating

[Jakub Wilk]

* Bas Wijnen , 2014-04-17, 22:11:

On Thu, Apr 17, 2014 at 07:08:30PM +0200, Jonas Smedegaard wrote:
a) I dislike dh-autoreconf: It removes changed files  which breaks my 
workflow where disappearing files are treated as an error.


AFAIK this is incorrect. It will make backup copies during build, and 
replace them during clean.


I think this needs an entry on
. :-P

From the manpage: “dh_autoreconf […] is complemented by 
dh_autoreconf_clean which creates a list of all changed and added files 
and removes them.”


--
Jakub Wilk


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

Re: About a mass bug report not based on Sid or Jessie.

[Florian Weimer]

* Steve Langasek:

> But I think we ought to switch to autoreconfing by default.

It's a bit risky if we don't do a mass rebuild after a new
autotools-related package upload.  I still see quite a lot of warnings
if I re-run the tools on older sources, but these days, most builds
seem to work out alright.

Given that it makes this makes it more likely that patches that
require rerunning the tools work out cleanly, it seems a good idea
overall.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761m7wu6t@mid.deneb.enyo.de

Re: About a mass bug report not based on Sid or Jessie.

[Florian Weimer]

* Russ Allbery:

> It's an interesting question whether we should just force
> dh-autoreconf in debhelper unless the package maintainer explicitly
> turns it off.  It would save me work, just as I've now been able to
> take overrides back out of all of my packages now that dpkg defaults
> to xz compression.  But it would be disruptive, and some packages
> would definitely fail to build afterwards.

The correct long-term fix is to change autotools to check a list of
well-known paths for more recent versions of the scripts and use them
instead of what is provided in the package.  The current autotools
setup implicitly assumes that most users run on a hostile system where
GNU tools are available under /usr/local at best, but thankfully, the
world has moved on (mostly).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a9bjwuj0@mid.deneb.enyo.de

Re: About a mass bug report not based on Sid or Jessie.

[Russ Allbery]

Florian Weimer  writes:

> It's a bit risky if we don't do a mass rebuild after a new
> autotools-related package upload.  I still see quite a lot of warnings
> if I re-run the tools on older sources, but these days, most builds seem
> to work out alright.

Yeah, most of the warnings are about underquoting, and *usually* m4 ends
up doing the right thing anyway.

> Given that it makes this makes it more likely that patches that require
> rerunning the tools work out cleanly, it seems a good idea overall.

My impression from doing this in about ten packages is that it's more
likely to break things than a new gcc release for C code but less likely
than a new g++ release for C++ code or a new major Perl release for Perl
packages.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87eh0vzm4g@windlord.stanford.edu

Re: About a mass bug report not based on Sid or Jessie.

[Russ Allbery]

Florian Weimer  writes:
> * Russ Allbery:

>> It's an interesting question whether we should just force dh-autoreconf
>> in debhelper unless the package maintainer explicitly turns it off.  It
>> would save me work, just as I've now been able to take overrides back
>> out of all of my packages now that dpkg defaults to xz compression.
>> But it would be disruptive, and some packages would definitely fail to
>> build afterwards.

> The correct long-term fix is to change autotools to check a list of
> well-known paths for more recent versions of the scripts and use them
> instead of what is provided in the package.

This doesn't regenerate the other files from scratch.  This only addresses
config.{sub,guess}, which is only a small part of the problem.  And if you
run autoreconf, that takes care of this update as well (at least most of
the time).  I therefore don't think pursuing this is particularly useful,
and we should instead make this problem moot by using dh-autoreconf or
something similar.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a9bjzm23@windlord.stanford.edu

Re: Bug#745087: guake-indicator: ITP: guake-indicator -- An indicator that lets you manage your ssh host with Guake

[Andrei POPESCU]

Control: reassign -1 wnpp

On Jo, 17 apr 14, 23:20:24, Alessio Garzi wrote:
> Package: guake-indicator
> Version: 0.1-0~35~ubuntu13.10.1
> Severity: wishlist
> 
> Guake-indicator is a C software application designed for Ubuntu 13.10 and 
> 14.04
> with Unity that lets you manage your favorite ssh hosts establishing a new ssh
> connection with Guake. Guake is a top-down terminal written in Python by Max
> Ulidtko,Pierre-Yves Chibon, Aleksandar Krsteski, Lincoln de Sousa, Gabriel
> Falcão.
> Guake-indicator sticks to your "Ubuntu System Tray" and displays your 
> favorites
> ssh hosts retrieved from ~/.guake.indicator/guake-indicator.json.
> You can customize  guake-indicator.json config file with your favorite text
> editor, the fields are  self-explanatory, however, I'm going to give you a 
> more
> in-depth description of each one:
> protocol : the protocol implementation used to open a new connection (can be
> only `telnet' or `ssh'), if this field is missing, the `ssh' value is used by
> default.
> 
> hostname : the host to connect (it can be his IP address or his DNS)
> 
> login : the ssh user
> 
> menu_name : the name that will show up in the indicator itself
> 
> tab_name : the name of the guake terminal tab once it is opened
> 
> command_after_login : command to issue after the ssh login is successfully
> performed - this field is optional
> 
> for more informations visit http://guake-indicator.ozzyboshi.com/
> 
> 
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers saucy-updates
>   APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 
> 'saucy'), (100, 'saucy-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.11.0-19-generic (SMP w/4 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages guake-indicator depends on:
> ii  libappindicator112.10.1+13.10.20130920-0ubuntu2
> ii  libc6   2.17-93ubuntu4
> ii  libdbus-glib-1-20.100.2-1
> ii  libgdk-pixbuf2.0-0  2.28.1-1ubuntu2
> ii  libglib2.0-02.38.1-0ubuntu1
> ii  libgtk2.0-0 2.24.20-1ubuntu1
> ii  libjson-c2  0.11-2ubuntu1
> 
> guake-indicator recommends no packages.
> 
> guake-indicator suggests no packages.
> 
> -- no debconf information

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

previously on this list Aaron Zauner contributed:

I agree with MACs being questionable in that they are an extra
*FINAL* layer only really effective on simple systems where they
arguably aren't needed, can be circumvented by kernel exploits and
often MACs are used on systems despite the wide ranging capabilities of
DACs being ignored which are more reliable and less complex

(RedHat/Fedora failing to realise the power of existing tech like groups
is a classic example, Debian is better here).

However I do believe Debian and Linux should be doing a lot more
outside of grsec/pax/gentoo hardened. I could be wrong but I'm under the
impression that Ubuntu is ahead (maybe just as more bleeding edge and
PAE by default etc. though I am surprised they don't ship two
kernels on their install or two cds for those few idiotic years intel
laptops dropped PAE for).

> I'm aware of this. Some of them also implement PaX (or W^X in OpenBSDs
> case). That said, it will probably improve security a bit, in particular
> against skiddies just running scripts of the web. But any serious
> attacker may circumvent stack canaries anyway. Thats not deep magic
> anymore. There are now automated tools to make ROP/return-to-lib-c
> attacks particularly easy to pull off (finding ROP gadgets
> automatically, even writing weaponized exploit code and so forth).

Your links are very old and miss out combining security features.
OpenBSD employs randomisation all over and recently starting with the
boot loader. you would have a real hard time making it run out of
entropy too. I'm told it's Not AS good but is a good start, has debian
considered running haveged by default?

The average linux system is lagging behind.

http://www.openbsd.org/papers/ru13-deraadt/

The linux code may be less integrated as it is just the kernel but is
all there as shown below and mentioned in Theo's Talk above.

http://pax.grsecurity.net/docs/pax.txt
http://pax.grsecurity.net/docs/PaXTeam-LATINOWARE12-PaX-linux-security.pdf

An abstract on this very subject
___

(1) introduce/execute arbitrary code
(2) execute existing code out of original program order
(3) execute existing code in original program order with arbitrary data

For example the well known shellcode injection technique belongs to (1) 
while the so-called return-to-libc style technique belongs to (2).

Before going into the analysis of the above techniques, let's note an
often overlooked or misunderstood property of combining defense
mechanisms. Some like to look at the individual pieces of a system and
arrive at a conclusion regarding the effectivenes of the whole based on
that (or worse, dismiss one mechanism because it is not efficient
without employing another, and vice versa). In our case this approach
can lead to misleading results. Consider that one has a defense
mechanism against (1) and (2) such as NOEXEC and the future userland
changes in PaX. If only NOEXEC is employed, one could argue that it is
pointless since (2) can still be used (in practice this reason has
often been used to dismiss non-executable stack approaches, which is
not to be confused with NOEXEC however). If one protects against (2)
only then one could equally well argue that why bother at all if the
attacker can go directly for (1) and then the final conclusion comes
saying that none of these defense mechanisms is effective. As hinted at
above, this turns out to be the wrong conclusion here, deploying both
kinds of defense mechanisms will protect against both (1) and (2) at
the same time - where one defense line would fail, the other prevents
that (i.e., NOEXEC can be broken by a return-to-libc style attack only
and vice versa).
___

Personally I look forward to the day that code is written with these
security features in mind and it is realised that browser rendering
speed is important but JIT needs to go.

WRT heartbleed it is quite shocking that this memory handling was
applied to all builds.

http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

Building exploit mitigations isn’t easy. It’s difficult because the
attackers are relentlessly clever. And it’s aggravating because there’s
so much shitty software that doesn’t run properly even when it’s not
under attack, meaning that many mitigations cannot be fully enabled.
But it’s absolutely infuriating when developers of security sensitive
software are actively thwarting those efforts by using the world’s most
exploitable allocation policy and then not even testing that one can
disable it.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd

Re: automatic autoconf config file updating

[Jonas Smedegaard]

Quoting Russ Allbery (2014-04-17 20:22:32)
> Jonas Smedegaard  writes:
>
>> Personally I would then silence the lintian warning, because...
>
>>  a) I dislike dh-autoreconf: It removes changed files  which breaks my
>> workflow where disappearing files are treated as an error.
>>  b) I prefer stripping automade files from source tarball, to avoid the 
>> (IMO required) hassle of both verifying that we also ship proper 
>> sources for them, and track copyright/licensing for them.
>
> You realize these contradict each other, right?  If you strip the 
> automade files from the source tarball, then dh-autoreconf will no 
> longer delete changed files, since the files that it deletes are 
> exactly the files that you're stripping.
> 
> So unless I'm missing something, it seems like you should continue to 
> do (b) if you want to do that... and then also use dh-autoreconf.

Yup, I realize that - thanks for noticing :-)

I am involved in maintaining 350+ packages, and only for some of them I 
have raised the bar of perfection to the level of stripping 
pesudo-source.  I.e. *nowadays* I dislike dh-autoreconf and prefer 
stripping automade files.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Work-needing packages report for Apr 18, 2014

[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: 573 (new: 9)
Total number of packages offered up for adoption: 133 (new: 0)
Total number of packages requested help for: 58 (new: 0)

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



The following packages have been orphaned:

   VolView (#745024), orphaned today
 Description: Advanced volume visualization tool

   eqonomize (#744738), orphaned 3 days ago
 Description: personal accounting software for the small household
   economy
 Installations reported by Popcon: 180

   firedns (#744997), orphaned today
 Description: Runtime libraries for firedns, an asynch. dns resolver
   library
 Reverse Depends: dsbltesters libfiredns-dev
 Installations reported by Popcon: 17

   firestring (#744998), orphaned today
 Description: Runtime libraries for firestring, a string handling
   library
 Reverse Depends: dsbltesters firedns libfiredns-dev libfiredns0.9
   libfirestring-dev
 Installations reported by Popcon: 31

   getstream (#744999), orphaned today
 Description: DVB streaming application
 Installations reported by Popcon: 209

   minit (#745011), orphaned today
 Description: Small but powerful init system
 Installations reported by Popcon: 5

   paris-traceroute (#745000), orphaned today
 Description: New version of well known tool traceroute
 Installations reported by Popcon: 229

   pxe (#745001), orphaned today
 Description: free PXE daemon
 Installations reported by Popcon: 215

   wxmaxima (#744706), orphaned 4 days ago
 Description: GUI for the computer algebra system Maxima
 Installations reported by Popcon: 2334

564 older packages have been omitted from this listing, 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 133 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 1536 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 79728

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

   balsa (#642906), requested 935 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 826

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

   chromium-browser (#583826), requested 1418 days ago
 Description: Chromium browser
 Reverse Depends: chromedriver chromium chromium-dbg chromium-l10n
   mozplugger
 Installations reported by Popcon: 25520

   cups (#532097), requested 1776 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client cups-core-drivers cups-daemon
   cups-dbg (62 more omitted)
 Installations reported by Popcon: 139908

   debtags (#567954), requested 1536 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2444

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

   freeipmi (#628062), requested 1057 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-tools libfreeipmi-dev libfreeipmi12 libipmiconsole-dev
   libipmiconsole2 libipmidetect-dev libipmidetect0 (3 more omitted)
 Installations reported by Popcon: 4837

   gnat-4.8 (#539562), requested 2198 days ago
 Description: help needed to execute test cases
 Reverse Depends: dh-ada-library gnat-4.8 gnat-4.8-sjlj libgnat-4.8
   libgnat-4.8-dbg libgnatprj4.8 libgnatprj4.8-dbg libgnatprj4.8-dev
   libgnatvsn4.8 libgnatvsn4.8-dbg (2 more omitted)
 Installations reported by Popcon: 110

   gnat-gps (#496905), requested 2058 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 521

   gnokii (#677750), requested 670 days ago
 Description: Datasuite for mobile phone management
 Reverse

Re: debconf reconfiguration from postinst of another package

[Paul Wise]

On Thu, Apr 17, 2014 at 7:50 PM, Jonas Smedegaard wrote:

>   * package foo-player
> + supports both JackD and PulseAudio, but only one
> + asks which method to use via debconf
>   * package bar-studio-desktop
> + depends on xfce4, jackd2 and foo-player
> + conflicts against bar-office-desktop
> + postinst script asks foo-player to use JackD
>   * package bar-office-desktop
> + depends on xfce4, pulseaudio and foo-player
> + conflicts against bar-studio-desktop
> + postinst script asks foo-player to use PulseAudio.

In this particular case I think foo-player should detect at when it is
started what audio system to use and offer a choice if both are
running, anything else isn't a good idea IMO.

-- 
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: 
https://lists.debian.org/caktje6hxi1elvi6vsdkkexkgdwhyrpkemhuq_bpwrtvtw1p...@mail.gmail.com

Re: About a mass bug report not based on Sid or Jessie.

[Paul Wise]

On Fri, Apr 18, 2014 at 4:49 AM, Florian Weimer wrote:

> The correct long-term fix is to change autotools to check a list of
> well-known paths for more recent versions of the scripts and use them
> instead of what is provided in the package.

Both the config.guess/sub and autoconf upstreams explicitly rejected
that approach (details in my earlier mail) and I don't think it is a
good idea to diverge from upstream on that. See also Russ' answer.

-- 
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: 
https://lists.debian.org/CAKTje6FSa86HH7HHwPj9AptrRC=drotcc5nm6053h2d8bf1...@mail.gmail.com

Re: automatic autoconf config file updating

[Paul Wise]

On Thu, Apr 17, 2014 at 10:20 PM, Wookey wrote:

> Ben, are you following this thread? If you don't object violently to
> adding Paul's 'update from Debian canonical config.{sub.guess}
> locations by default' patch to the Debian autoconf, then that just
> leaves my original issue of what ensures that those files are
> installed at build time? Can we put it in Build-essential, or do we
> have to have every package build-dep on it explicitly (which get us
> back to the 'fix every package' issue (although it is a trivial fix
> that anyone can get right in this case)).

I don't think we should diverge from upstream autoconf here.

-- 
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: 
https://lists.debian.org/CAKTje6ES-mwuODpRjrL=s2w77wpc+u9gxjcof1v-dwkgjfg...@mail.gmail.com

Re: ':any' syntax in package names in jessie/sid Packages

[Guillem Jover]

Hi!

On Thu, 2014-04-17 at 22:24:11 +0300, Eugene V. Lyubimkin wrote:
> It seems that in jessie (and similar in sid) a number of packages [1]
> started to use ':' symbol in their dependency lists as part of package
> names. This is, if I'm not misreading the Debian Policy §7.1 and §5.6.1,
> is not allowed.

> Suggestions for issue's severity and how to proceed?

After my warning [W] about this subverting the dependency system was
willfully ignored, I concluded trying to do anything else about it
was a waste of time and energy.

  [W] 

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140418051156.ga22...@gaara.hadrons.org