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

[Stuart Prescott]

Hi Eugene,

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

I think you've found yet another "multiarch is not documented in policy" 
bug. This specific issue is not yet filed, so perhaps filing a bug to track 
this problem would be appropriate.

#687900: document multiarch
#650974: Make Policy references to /usr/lib multiarch-aware
#684672: document multiarch tuple definitions
#742756: multi-arch and system-dependent header files
#636383: 10.2 and others: private libraries may also be multi-arch-ified
#621050: Document dependencies needed to use multiarch paths

Unfortunately, the people who understand multiarch well enough to write it 
up for policy haven't done so which leaves us with no normative 
documentation in policy for the the Multi-Arch field in Packages, no 
description of how the package manager should deal with multi-arch packages 
and their dependencies and no documentation of best practices for -dev 
packages etc.

As with the rest of multiarch, the documentation of python:any is at:

https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-
architecture_package_relationships

(I believe that there are some aspects of that document that have not been 
implemented in Debian or have been implemented differently in Debian -- it's 
not a substitute for having this in Policy)

Hope that helps
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7




-- 
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/liqk21$5nc$1...@ger.gmane.org

Bug#745122: ITP: django-polymorphic -- Seamless Polymorphic Inheritance for Django Models

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: django-polymorphic
  Version : 0.5.4
  Upstream Author : Bert Constantin 
* URL : https://github.com/chrisglass/django_polymorphic
* License : BSD
  Programming Lang: Python
  Description : Seamless Polymorphic Inheritance for Django Models

Django-polymorphic simplifies using inherited models in Django projects. When a
query is made at the base model, the inherited model classes are returned.

Features:
 * Full admin integration.
 * ORM integration:
   + Support for ForeignKey, ManyToManyField, OneToOneField descriptors.
   + Support for proxy models.
   + Filtering/ordering of inherited models (ArtProject___artist).
   + Filtering model types: instance_of(...) and not_instance_of(...)
   + Combining querysets of different models (qs3 = qs1 | qs2)
   + Support for custom user-defined managers.
 * Uses the minimum amount of queries needed to fetch the inherited models.
 * Disabling polymorphic behavior when needed.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTUN4/AAoJEGlMre9Rx7W24DwP/2kzLwwOz5CZe5UFNOpaBo0m
u8/sITqragRttbWUs3KxsPdZ/cbU6vxGeS112LDSeYanOn6Okw4DgQQ4FAGKVGwX
0vlyF+qbD5x2MZS/bMe8ouRCuAl8uCYSy8TSpS96qeJnGE4Jzlro4vSKELrCCKDi
cEvRilSPnswh+VGgb8fIBdrBjwN9qbYq9lQNGX/CV/8nDsbdKAW1N76dxg3rE0CE
qfRPSIToCJ7Qht934yZomV9iv6bCMNblgpXWOu/wpXXLzxDI+RRhrldvaCc1uJnV
IDxTlPFTVgFDPjiQOH0EMaTp930SOD5k43ZZn3gEqqF673KkKZ1/VMaJD18uo7KO
GcdGNo6YdNwlNokQN83suQ/EJQj950pNT7QCGjx9KbA/zWvhfVGL5piDmc6HZcc0
lL/Smy3f7fdzkKz745HEf7eUbvwTRoNfcYtIkzad89dfiP2sq4RPjXnsQ/Rr/AYJ
Ej8ElCU4bEqaf2WGS4LUDMNTcrRXhwQp9SU6Z2lKu0jDpRbRXhPAbzL07ZOFCltW
JVxjeYRi+OkpPOYhGt38FhJwaATdlE9CDOjmZX8oKbHtzmXLZFvq0j1M20IM2tPu
QLwE1V/xE5lxe1jddTAJUrOlO+qQAKmDHK7Yaz4xbFejapItPJNn+vJorqV90aVF
kdQV6oNc0MxfcRLf5IhY
=w/Am
-END PGP SIGNATURE-


-- 
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/20140418081147.2267.3707.report...@server.home.fladi.at

Re: debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

Hi Paul,

I thought subject of my mail made my question clear:

  How to reconfigure debconf from postinst of another package?

Quoting Paul Wise (2014-04-18 04:02:47)
> 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.

Thanks, but (again) I am sorry if it was not clear: The *question* is 
about *debconf* irregardless of the *example* involving other details.

Here's another example raising same question without involving audio:

  * package adduser
+ asks if home directories should be system-readable
  * package foo-hippie-desktop
+ depends on adduser
+ conflicts against foo-paranoid-desktop
+ postinst script asks adduser to make homedirs system-readable
  * package foo-paranoid-desktop
+ depends on adduser
+ conflicts against foo-hippie-desktop
+ postinst script asks adduser to not make homedirs system-readable

NB! above is again just an *example* meant to illustrate need for 
programmatically changing debconf from another package.  I have no 
interest in "solutions" that bypass debconf (unless you seriously mean 
to say that debconf is unusable for automated reconfiguration).

Here is my question again:

  How to reconfigure debconf from postinst of another package?


 - 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#745139: ITP: libykneomgr -- Yubico YubiKey NEO Manager library and tool

[Simon Josefsson]

Package: wnpp
Severity: wishlist

 * Package name: libykneomgr
   Version : 0.1.2-1
   Upstream Author : Simon Josefsson 
 * URL : http://opensource.yubico.com/libykneomgr/
 * License : LGPLv3+
   Section : utils

 This is a C library to interact with the YubiKey NEO.  There is a
 command line tool "ykneomgr" for interactive use.  It supports
 querying the YubiKey NEO for firmware version, operation mode
 (OTP/CCID) and serial number.  You may also mode switch the device and
 manage applets (list, delete and install).

The Debian package is available on mentors for review:
https://mentors.debian.net/package/libykneomgr

Source code for the Debian package is available here:
https://github.com/Yubico/libykneomgr-dpkg

/Simon


-- 
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/20140418130442.6316e...@latte.josefsson.org

Re: automatic autoconf config file updating

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2014-04-18 00:32:23)
> 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.

Perhaps better explanation:

You are right that doing a) and b) on same package makes no sense. I do 
either a) or b) on each package, however.


 - 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

Re: debconf reconfiguration from postinst of another package

[Vincent Danjean]

On 18/04/2014 12:43, Jonas Smedegaard wrote:
> Hi Paul,
> 
> I thought subject of my mail made my question clear:
> 
>   How to reconfigure debconf from postinst of another package?

My opinion is that this is not allowed (but I did not checked explicitly
in Policy, so I may be wrong).
  Calling reconfigure is a matter of changing the configuration of another
package. If I recall correctly, it is not allowed for a package to modify
the configuration of another package unless the second package provides
explicit features (dir.d, hooks, ...)
  Moreover, debconf is not a registry. So, even if their is something
in debconf, it does not mean that the admin did not modify the real
configuration file.
  Note that, if, as an admin, I explicitly choose an option in debconf
and then, latter, another package overwrite my choice (or even reprompt
me with another choice by default), it won't please me at all.

  So, perhaps, you should look at and evaluate the other propositions
made by other people...

> NB! above is again just an *example* meant to illustrate need for 
> programmatically changing debconf from another package.  I have no 
> interest in "solutions" that bypass debconf (unless you seriously mean 
> to say that debconf is unusable for automated reconfiguration).

I think so. My opinion is based on policy that says that a package must not
mess with the configuration files of other packages. If configuration must
be shared with debconf, then use such debconf feature (as xdm, gdm,
kdm, ... did for choose the default dm : they do not call each other
configure script when the default dm is changed)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/53511d6e.8050...@free.fr

Re: Proposing amd64-hardened architecture for Debian

[Aaron Zauner]

Hi Kevin,

Kevin Chadwick wrote:
> 
> 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 totally agree.

> Your links are very old and miss out combining security features.
This is true, they were intended for reference to the origin of those
attacks, current papers on those exploit techniques (or even combined
exploit techniques) can be easily obtained from a Google query :)

> 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?
As I am somewhat involved with the bettercrypto.org project, haveged has
come up quite a lot. The idea behind it is sound, the only problem I see
is missing (to the best of my knowledge) security audits and review by
cryptographers outside of the project itself. The original paper is now
very dated and I have not found and solid audit paper (or even a paper
that tries to attack haveged) on the web. I'm not sure if that's a good
or a bad sign.

Usually the Linux kernel itself provides more than enough entropy. This
can (and probably should) be enhanced but should  not be done in a
specific distribution.

> 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).
> ___
Yeah. I wasn't trying to argue that PaX/W^X is a bad idea, to the
contrary. I was refering to stack canaries. I do question if building
all packages with -fstack-protector is a good idea, of course plattforms
are very fast now, but it bloats binaries with minimal added security.

> 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.
Nothing to add here, very well said!

Aaron



signature.asc
Description: OpenPGP digital signature

Re: debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

Hi Vincent,

Quoting Vincent Danjean (2014-04-18 14:41:18)
> On 18/04/2014 12:43, Jonas Smedegaard wrote:
>>   How to reconfigure debconf from postinst of another package?
>
> My opinion is that this is not allowed (but I did not checked 
> explicitly in Policy, so I may be wrong).
>   Calling reconfigure is a matter of changing the configuration of 
> another package. If I recall correctly, it is not allowed for a 
> package to modify the configuration of another package unless the 
> second package provides explicit features (dir.d, hooks, ...)

That detail of Policy (§ 10.7.4) is indeed essential to my question.

I believe however that debconf is exactly such "extra feature".


>   Moreover, debconf is not a registry. So, even if their is something 
> in debconf, it does not mean that the admin did not modify the real 
> configuration file.

Yes, this detail of debconf is the very reason I ask for help.

It seems to me that debconf was intended to cover both initial 
bootstrapping and later reconfiguration, and cover both interactive and 
automated use.

The dpkg-reconfigure high-level tool shipped with debconf seems only 
intended for interactive use: I can find no way in the use of that tool 
to distinguish between cached answers that should be shadowed by current 
package state and new answers to override package state.


>   Note that, if, as an admin, I explicitly choose an option in debconf 
> and then, latter, another package overwrite my choice (or even 
> reprompt me with another choice by default), it won't please me at 
> all.

Right, that's the most common way to look at it.

The opposite view is systems that has *no* administrator - where you 
want Debian packaging to automatically handle package upgrades without 
ever asking about changes to conffiles - yet you still want some 
configuration to be in a certain way.

Such configuration is possible today, for packages that use debconf.

It is possible at initial install.

I dare say it ought to be possible also to reconfigure a running system.


>   So, perhaps, you should look at and evaluate the other propositions 
> made by other people...

I want to first make sure if debconf is usable to reconfigure one 
package from another package.

If not, I want to make sure that is not an oversight that can be fixed.

Only if debconf really is not and will not become a mechanism usable for 
automated reconfiguration will I give up on promoting debconf.

...and possibly I will then also give up on the whole concept of Debian 
Pure Blends as well. :-(


>> NB! above is again just an *example* meant to illustrate need for 
>> programmatically changing debconf from another package.  I have no 
>> interest in "solutions" that bypass debconf (unless you seriously 
>> mean to say that debconf is unusable for automated reconfiguration).
>
> I think so. My opinion is based on policy that says that a package 
> must not mess with the configuration files of other packages. If 
> configuration must be shared with debconf, then use such debconf 
> feature (as xdm, gdm, kdm, ... did for choose the default dm : they do 
> not call each other configure script when the default dm is changed)

I find it worrisome if only mutually coordinated packages can configure 
each other:  I fear that that scales badly.


 - 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

Re: Proposing amd64-hardened architecture for Debian

[Vincent Danjean]

  Hi,

On 18/04/2014 00:15, Kevin Chadwick wrote:
> OpenBSD employs randomisation all over and recently starting with the
> boot loader.

  I do not object to use such techniques (randomisation for example) by
default. However, it must be easy to disable them.
  Indeed: not all computers are are used as servers where security must be
really strong. Some computers are used to do development. And, in this case,
randomization is sometime really annoying: each time you re-run your program,
all variables have a new address under gdb. So, if you want to use the 'watch'
command, you need first to find again and again the address of the field of
the structure you are interested on.

  So please, take such usages into account when pushing for a better
security: document an easy way to revert to the less secure but
deterministic/non hidden/... runtime mode. It can be as simple as
documenting "kernel.randomize_va_space=0" sysctl parameter for example.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/5351400b@free.fr

Re: debconf reconfiguration from postinst of another package

[Paul Wise]

On Fri, Apr 18, 2014 at 6:43 PM, Jonas Smedegaard wrote:

> Thanks, but (again) I am sorry if it was not clear: The *question* is
> about *debconf* irregardless of the *example* involving other details.

Examples are generally less useful than knowing the exact
circumstances that make you want a particular solution. Would you
share some information about why you want this?

-- 
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/caktje6equa-m9h1azhrhxoutjwtdwezhd4o+dwfkey+esv+...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Kevin Chadwick]

On Fri, 18 Apr 2014 14:57:41 +0200
Aaron Zauner wrote:

> > Usually the Linux kernel itself provides more than enough entropy. This
> > can (and probably should) be enhanced but should  not be done in a
> > specific distribution.

I know there has been a little work on the kernel in this area, mainly
when you have a modern cpu you will be fine but are the days of waiting
on gpg and being asked to move the mouse on the latest Linux Kernel and
whichever kernel lands in debian 8 over? You should be able to write
gigabytes of random data to disk without any worry.

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

> Nothing to add here, very well said!

I realised just after sending that I had removed one too many seperating
lines (before the link).

So I wasn't as clear as I meant to be in that the bit above was taken
from an OpenBSD devs (Teds) page about Heartbleed.

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

--
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/505473.83266...@smtp146.mail.ir2.yahoo.com

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

[Wookey]

+++ Russ Allbery [2014-04-17 14:24 -0700]:
> 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).

Can someone explain how this works, because so far as I can see this
isn't true (well maybe 'most of the time' is true, but there is a
non-trivial 'rest of the time' and we need to understand when/why that
occurs, so we can make those DTRT too).

The autoconf package (containing the 'autoreconf' command) does not
have a copy of config.{sub,guess} (so cannot update them). The
autotools-dev packages does, but it puts them on debian paths that are
explicitly ignored by autotools (and thus autoreconf) unless _debian_
dh_something command is used, and even then they won't necessarily be
picked up (see my post about the libgc example where dh_autoreconf did
not find them).

Now I see that there is a copy of config.{sub,guess} in automake (in
/usr/share/automake-1.14/) so I guess that if automake is also used
(or maybe just installed?) then modern versions of these files will be
found and used (always?, sometimes? - what are the rules? libgc uses
automake and they did not get found).

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

I agree with the sentiment, but I don't understand how this is going
to work, because we know that using dh-autoreconf does not always
result in updated config.{sub,guess}. If changing the search paths is
not the right fix then what is? Making dh-autoreconf explicitly
install and run dh_autotools-dev_updateconfig would work, except where
it is overridden by an autogen.sh script. Is that effectively what is
being proposed?
 
And who understands all this well enough to explain to maintainers
what they should be doing, because if I don't really understand the
gubbins after way too much porting and crossing and bootstrapping
faffage, I assume the average packager is even less clear about all
this.

In summary: 
autoconf does not contian config.* files
autotools-dev contains current config.* files (on debian path)
automake contains current config.* files

autoconf does not depend on autotools-dev or automake
autoconf package supplies autoreconf command
autotools-dev package supplies dh_autotools-dev_updateconfig (and 
restoreconfig) commands
dh-autoreconf packages supplies dh_autoreconf (and clean) commands

running dh_autotools-dev_updateconfig (or dh --with autotools-dev)
  will always copy debian config.* files into package

This is where I start to get vague:
running autoreconf  will only copy (use-without-moving(?))
  config.* files if automake is installed(?) used(?) _and_ an autogen.sh 
  file is not used/has specific commands (which ones?)
running dh_autoreconf (or dh --with autoreconf) doesn't do anything 
  different with respect to config.* file updating than autoreconf?

Please correct any misunderstandings I have.


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/20140418182101.go29...@stoneboat.aleph1.co.uk

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

[Russ Allbery]

Wookey  writes:

> Can someone explain how this works, because so far as I can see this
> isn't true (well maybe 'most of the time' is true, but there is a
> non-trivial 'rest of the time' and we need to understand when/why that
> occurs, so we can make those DTRT too).

> The autoconf package (containing the 'autoreconf' command) does not
> have a copy of config.{sub,guess} (so cannot update them). The
> autotools-dev packages does, but it puts them on debian paths that are
> explicitly ignored by autotools (and thus autoreconf) unless _debian_
> dh_something command is used, and even then they won't necessarily be
> picked up (see my post about the libgc example where dh_autoreconf did
> not find them).

> Now I see that there is a copy of config.{sub,guess} in automake (in
> /usr/share/automake-1.14/) so I guess that if automake is also used (or
> maybe just installed?) then modern versions of these files will be found
> and used (always?, sometimes? - what are the rules? libgc uses automake
> and they did not get found).

Automake is the component that's responsible for doing this.  Packages
that use Autoconf but not Automake will require explicit updating of those
files.  There may be more of those than I expected.  If so, I think the
solution would be to add the autotools-dev logic to dh-autoreconf as well
so that it will do the updates for packages where autoreconf doesn't do
the job.

I'm not sure what's going on with libgc and haven't looked at it.  It's
possible that something complexity is hiding the relevant Autoconf macro
from Automake so it doesn't realize it's in use and doesn't update those
files.

> I agree with the sentiment, but I don't understand how this is going to
> work, because we know that using dh-autoreconf does not always result in
> updated config.{sub,guess}. If changing the search paths is not the
> right fix then what is? Making dh-autoreconf explicitly install and run
> dh_autotools-dev_updateconfig would work, except where it is overridden
> by an autogen.sh script. Is that effectively what is being proposed?

Well, I guess I can say this: if you have a typical Autoconf, Automake,
and Libtool package, dh-autoreconf will do the right thing.  I have a
bunch of those, both ones for which I'm upstream and ones where I'm not,
and have never had any trouble.

If you're doing unusual things, or if you're not using Automake, you're
right that currently dh_autotools-dev_updateconfig is more reliable.  I
think that logic should be added to dh-autoreconf so that we can focus on
a single tool that's comprehensive (whether directly or via a dependency).

> And who understands all this well enough to explain to maintainers what
> they should be doing, because if I don't really understand the gubbins
> after way too much porting and crossing and bootstrapping faffage, I
> assume the average packager is even less clear about all this.

I don't think maintainers should have to understand anything other than
"stick this rune in debian/rules."  We should make the tools smarter, not
the packaging.

> This is where I start to get vague:
> running autoreconf  will only copy (use-without-moving(?))
>   config.* files if automake is installed(?) used(?) _and_ an autogen.sh 
>   file is not used/has specific commands (which ones?)

automake is the relevant command.  In general, though, I would be very
dubious of using the upstream autogen.sh file alone.  If it regenerates
other things as well that one wants to regenerate during the packaging,
that's great, but in general I'd still let dh-autoreconf run autoreconf
itself, unless that actually *breaks*.

> running dh_autoreconf (or dh --with autoreconf) doesn't do anything 
>   different with respect to config.* file updating than autoreconf?

I believe that's currently correct, and I think you've identified good
reasons for changing that.

-- 
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/87lhv2qy0l@windlord.stanford.edu

Re: debconf reconfiguration from postinst of another package

[Jonas Smedegaard]

Quoting Paul Wise (2014-04-18 17:44:13)
> On Fri, Apr 18, 2014 at 6:43 PM, Jonas Smedegaard wrote:
>
>> Thanks, but (again) I am sorry if it was not clear: The *question* is 
>> about *debconf* irregardless of the *example* involving other 
>> details.
>
> Examples are generally less useful than knowing the exact 
> circumstances that make you want a particular solution. Would you 
> share some information about why you want this?

I want to improve the ability to have Debian (not only apply but also) 
maintain user choices.

Today it is well documented (e.g. in devref) how any debconf-enabled 
package can be reconfigured from command-line interface (using e.g.
dpkg-reconfigure).

I want to explore support for reconfiguration scripted (e.g. CFengine, 
FAI, Puppet) and via web (e.g. Plinth).

I also want to explore putting collections of choices into packages - 
i.e. "smart" task packages.

Goal is to have well-defined parts of Debian maintainable 100% by Debian 
(i.e. no custom-tuned config files at all) - configured and reconfigured 
via debconf.  I call such well-defined parts "Debian Pure Blends".

https://wiki.debian.org/DebianPureBlends#PureBlend


 - 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

Debian business card with qr-code

[Xavier Roche]

Hi folks!,

In addition to the various business card samples at
https://www.debian.org/events/materials/business-cards/, I slightly
modified the "traditional-new" version to have a two-sided version, with
an optional QR-code.
http://debian.httrack.com/card-traditional-new-2/

(Not sure if this is really worth posting an email to this list, but who
knows, it might be useful to a fellow DD.)


-- 
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/535185c9.4030...@httrack.com

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

[Wookey]

+++ Russ Allbery [2014-04-18 11:43 -0700]:
> Wookey  writes:
> 
> > Now I see that there is a copy of config.{sub,guess} in automake (in
> > /usr/share/automake-1.14/) so I guess that if automake is also used (or
> > maybe just installed?) then modern versions of these files will be found
> > and used (always?, sometimes? - what are the rules? libgc uses automake
> > and they did not get found).
> 
> Automake is the component that's responsible for doing this.  Packages
> that use Autoconf but not Automake will require explicit updating of those
> files.

OK. That helps. This seems a tad perverse given that configure needs
uptodate config.* files whether or not automake is used to make
makefiles. But I guess there is some logic behind it. 

>  There may be more of those than I expected.  If so, I think the
> solution would be to add the autotools-dev logic to dh-autoreconf as well
> so that it will do the updates for packages where autoreconf doesn't do
> the job.

Which is fine, and a solution I'm happy with; although people were
arguing earlier in this thread that the right way to do this was
upstream, and not with special debian-foo. This doesn't meet that
criterion, although I don't see how we can without diverging from
upstream behaviour.
 
> I'm not sure what's going on with libgc and haven't looked at it.  It's
> possible that something complexity is hiding the relevant Autoconf macro
> from Automake so it doesn't realize it's in use and doesn't update those
> files.

It may be that libgc upstream's autogen.sh script is not really 'right' in
some way. But there may well be a lot of upstreams like that, which is
why maintainers need clear guidance on how to deal with this, without
having to become autotools experts. i.e how to determine when they can
just run dh_autoreconf and when they need to do something more
involved.

The script basically does:
aclocal$am_version
autoconf
autoheader
automake$am_version -ac
libtoolize --automake --force

is that equivalent to dh_autoreconf?

> > I agree with the sentiment, but I don't understand how this is going to
> > work, because we know that using dh-autoreconf does not always result in
> > updated config.{sub,guess}. If changing the search paths is not the
> > right fix then what is? Making dh-autoreconf explicitly install and run
> > dh_autotools-dev_updateconfig would work, except where it is overridden
> > by an autogen.sh script. Is that effectively what is being proposed?
> 
> Well, I guess I can say this: if you have a typical Autoconf, Automake,
> and Libtool package, dh-autoreconf will do the right thing.  I have a
> bunch of those, both ones for which I'm upstream and ones where I'm not,
> and have never had any trouble.
> 
> If you're doing unusual things, or if you're not using Automake, you're
> right that currently dh_autotools-dev_updateconfig is more reliable.  I
> think that logic should be added to dh-autoreconf so that we can focus on
> a single tool that's comprehensive (whether directly or via a dependency).

OK, sounds sensible to me. Joey?

> > And who understands all this well enough to explain to maintainers what
> > they should be doing, because if I don't really understand the gubbins
> > after way too much porting and crossing and bootstrapping faffage, I
> > assume the average packager is even less clear about all this.
> 
> I don't think maintainers should have to understand anything other than
> "stick this rune in debian/rules."  We should make the tools smarter, not
> the packaging.

That's fine in theory, but in order to convert from what your package
currently does to this new way you need to know enough to understand
if your autofoo is set up right, and that any package-specific macros
or configure snippets or whatever end up in the right places. 
 
> > This is where I start to get vague:
> > running autoreconf  will only copy (use-without-moving(?))
> >   config.* files if automake is installed(?) used(?) _and_ an autogen.sh 
> >   file is not used/has specific commands (which ones?)
> 
> automake is the relevant command.  In general, though, I would be very
> dubious of using the upstream autogen.sh file alone.  If it regenerates
> other things as well that one wants to regenerate during the packaging,
> that's great, but in general I'd still let dh-autoreconf run autoreconf
> itself, unless that actually *breaks*.

OK, but again maintainers needs enough info to judge whether there is
something important in upstream's autogen.sh or if it's all effectively 
boilerplate that a straighforward autoreconf will replace.

> > running dh_autoreconf (or dh --with autoreconf) doesn't do anything 
> >   different with respect to config.* file updating than autoreconf?
> 
> I believe that's currently correct, and I think you've identified good
> reasons for changing that.

Good, we appear to be in agreement :-)
 
Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, emai

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

[Russ Allbery]

Wookey  writes:

> It may be that libgc upstream's autogen.sh script is not really 'right'
> in some way. But there may well be a lot of upstreams like that, which
> is why maintainers need clear guidance on how to deal with this, without
> having to become autotools experts. i.e how to determine when they can
> just run dh_autoreconf and when they need to do something more involved.

> The script basically does:
> aclocal$am_version
> autoconf
> autoheader
> automake$am_version -ac
> libtoolize --automake --force

> is that equivalent to dh_autoreconf?

I took a deeper look.  The problem is that --force is only passed to
libtoolize, which means that the Libtool files are updated but other files
are not replaced if they are present but out of date.

If dh_autoreconf is run without using the upstream autogen.sh,
config.guess and config.sub are correctly updated.  So this is indeed a
problem with using the upstream autogen.sh instead of dh_autoreconf's
default action (which is autoreconf --force -i).

The equivalent change to the upstream autogen.sh script is to add --force
to the automake command line.

> That's fine in theory, but in order to convert from what your package
> currently does to this new way you need to know enough to understand if
> your autofoo is set up right, and that any package-specific macros or
> configure snippets or whatever end up in the right places.

True.

> OK, but again maintainers needs enough info to judge whether there is
> something important in upstream's autogen.sh or if it's all effectively 
> boilerplate that a straighforward autoreconf will replace.

I think what I'm arguing for is just running both.  Run upstream's autogen
first and then run autoreconf.  Maybe that's a bad idea, though.  It would
be if upstream's autogen.sh is working around some bug in autoreconf and
autoreconf would leave things in a broken state.

Regardless, though, I will say that the autogen.sh script in libgc looks
completely pointless to me in Debian and I would ignore it and just run
autoreconf.  The only value it's adding is probing for specific versions
of the tools and aborting on 1.7 versions, which are irrelevant actions
for Debian.  (It's also running things in the "wrong" order, calling
libtoolize last, so autoreconf may actually produce more reliable
results.)

-- 
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/87lhv2me9r@windlord.stanford.edu

Re: automatic autoconf config file updating

[Steve McIntyre]

Paul Wise wrote:
>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.

Why? I've not seen any good arguments as to why they're right here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
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/e1wbhn8-00020t...@mail.einval.com

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

[Matthias Klose]

Am 19.04.2014 01:03, schrieb Russ Allbery:
>> OK, but again maintainers needs enough info to judge whether there is
>> something important in upstream's autogen.sh or if it's all effectively 
>> boilerplate that a straighforward autoreconf will replace.
> 
> I think what I'm arguing for is just running both.  Run upstream's autogen
> first and then run autoreconf.  Maybe that's a bad idea, though.  It would
> be if upstream's autogen.sh is working around some bug in autoreconf and
> autoreconf would leave things in a broken state.

Not only this, but assuming you configure to run dh-autoreconf with specific
versions to run automake and aclocal, you run them with different versions in
the end, or you have to patch the autogen.sh file.

> Regardless, though, I will say that the autogen.sh script in libgc looks
> completely pointless to me in Debian and I would ignore it and just run
> autoreconf.  The only value it's adding is probing for specific versions
> of the tools and aborting on 1.7 versions, which are irrelevant actions
> for Debian.  (It's also running things in the "wrong" order, calling
> libtoolize last, so autoreconf may actually produce more reliable
> results.)

There are scripts doing localization, which fail with dh-autoreconf and succeed
with the autogen.sh script. Can't remember exactly which ones but it was in the
xfce4 stack.

  Matthias


-- 
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/5351c51a.7090...@debian.org

Re: Debian business card with qr-code

[Paul Wise]

On Sat, Apr 19, 2014 at 4:06 AM, Xavier Roche wrote:

> In addition to the various business card samples at
> https://www.debian.org/events/materials/business-cards/, I slightly
> modified the "traditional-new" version to have a two-sided version, with
> an optional QR-code.
> http://debian.httrack.com/card-traditional-new-2/
>
> (Not sure if this is really worth posting an email to this list, but who
> knows, it might be useful to a fellow DD.)

You might want to get that included on the website.

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

Re: automatic autoconf config file updating

[Paul Wise]

On Sat, Apr 19, 2014 at 7:01 AM, Steve McIntyre wrote:

> Why? I've not seen any good arguments as to why they're right here.

It would be pointless. We are never going to have 100% of upstream
tarballs generated by the Debian version of autoconf and so we are
always going to need a mechanism in debhelper/dpkg-buildpackage or
similar to do the same thing for tarballs generated on systems running
other distros. If we have such a mechanism, we don't need the
autoconf-internal mechanism. In addition tarballs generated on Debian
systems would then be looking in Debian specific paths on non-Debian
systems. Having two sets of behaviour out in the wild doesn't sound
useful to me.

-- 
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/caktje6g2zrlsqbvns_pgw+-+n02xueif-beoeroqv+aa8sb...@mail.gmail.com