Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Steve Langasek (2014-07-07 20:22:42)
> Ah.  No, it only means that the package build does not *fail* if the
> build-dependency is removed.  That is not the same thing as saying that the
> build-dependency is not used.
> 
> It would of course be better if packages were resilient against breakage in
> their build-dependencies, instead of misbuilding with features disabled or
> with wrong fallback code.  But this isn't easy to do in all build systems,
> and anyway this isn't something we routinely audit about our packages; we
> shouldn't regard this as a bug to be reported without a lot more discussion
> of how we're going to systematically stay on top of those issues in the
> future.
> 
> For your purposes, a better method would be:
> 
>  - identify those build-dependencies which are empty except for
>/usr/share/doc
>  - for each such package, look at the contents of its direct dependencies
>  - check the build against those contents

it turns out that 13% of my results are packages with no other content than in
/usr/share/doc. Namely:

libreadline-dev, default-jdk-doc, doxygen-latex, gcj-native-helper,
g++-multilib, gobjc, libboost-dev, libboost-system-dev, libgmp3-dev,
libgphoto2-2-dev, libopenais-dev, libtasn1-3-dev, libxmlrpc-c3-dev, lynx,
mysql-server, python3-all-dbg, python3-all-dev, libdb-dev, python-all,
python-gobject, python-all-dbg, python-all-dev

I'll re-run the whole caboodle later this year but consider the file content of
empty packages to be the sum of the content of packages it depends on. This
should reduce the number of this kind of false positives.

Do you think I should fill bugs for all non-empty packages that were already
found? Or do you think there is another high chance of false positives for that
kind of packages too?

cheers, josch


--
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/20140708074302.14505.28772@hoothoot

Running autopkgtest at package upload time

[Andreas Tille]

Hi,

I had some workshop at LSM[1] and I was mentioning autopkgtest as new
and interesting feature.  To my astonishment the audience was not
perfectly happy that it might last some time until a package test is
performed and the developer gets some response.  Since I think that the
person who raised this has some point I wonder whether there is a chance
to implement autopkttest-ing right after a package was uploaded.

Kind regards

  Andreas.

[1] https://2014.rmll.info/schedule/rooms/5.07%20TD?lang=en

-- 
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/20140708080658.gf22...@an3as.eu

Bug#754154: ITP: r-bioc-genomicalignments -- BioConductor representation and manipulation of short genomic alignments

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-bioc-genomicalignments
  Version : 1.0.2
  Upstream Author : Hervè Pagès, Valerie Obenchain, Martin Morgan
* URL : 
http://bioconductor.org/packages/release/bioc/html/GenomicAlignments.html
* License : Artistic-2.0
  Programming Lang: R
  Description : BioConductor representation and manipulation of short 
genomic alignments
 This BioConductor package provides efficient containers for storing and
 manipulating short genomic alignments (typically obtained by aligning
 short reads to a reference genome). This includes read counting,
 computing the coverage, junction detection, and working with the
 nucleotide content of the alignments.


Remark: This package is a precondition to upgrade a set of other BioConductor
 packages in Debian.  It is maintained by the Debian Med team at

   
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-genomicalignments/trunk/


-- 
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/20140708083617.24478.23505.report...@mail.an3as.eu

Re: systemd is here to stay, get over it now

[Thorsten Glaser]

Norbert Preining wrote:

>On Mon, 07 Jul 2014, Josselin Mouette wrote:
>> If they don’t need any of the systemd features, I guess they don’t need
>> any of its reverse dependencies either.
>
>Rubbish. I want network-manager, but I don't want systemd.

I don’t, but I want most KDE packages, so I installed the
relevant metapackage (now removed, so…).

bye,
//mirabilos


-- 
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/lpgauv$3mh$1...@ger.gmane.org

Re: systemd is here to stay, get over it now

[Josselin Mouette]

Le mardi 08 juillet 2014 à 08:13 +0900, Norbert Preining a écrit : 
> On Mon, 07 Jul 2014, Josselin Mouette wrote:
> > If they don’t need any of the systemd features, I guess they don’t need
> > any of its reverse dependencies either.
> 
> Rubbish. I want network-manager, but I don't want systemd.
> NM was working long time without systemd.

NM was working with ConsoleKit.
ConsoleKit is no longer maintained.

I’m starting to get a feeling of déjà vu.

> Don't spread wrong information.

Stop making a fool of yourself.

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1404810180.14436.865.camel@dsp0698014

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Charles Plessy]

Hi Lars,

thanks for your well-argumented and detailed position on this subject.  The
problems that you describe can be roughly summarised by “principle of least
surprise” and “slippery slope”.  In this particular case, I quite disagree with
the first, but of course can not entirely dismiss the second.

Le Sun, Jul 06, 2014 at 04:02:05PM +0100, Lars Wirzenius a écrit :
> 
> The standards FHS directory layout gives us four locations in which to
> put executabes: /bin, /sbin, /usr/bin, /usr/sbin. In theory we could
> then have four providers of yoyo, but that would be very confusing.
> Even using bin vs sbin is confusing: if you're used to running foo's
> yoyo as your normal user, it'll be quite a surprise when you try to
> run it as root and get bar's yoyo instead.

Here, both programs have narrow and non-overlaping user bases, and are
not installed on fresh standard Debian systems. 

This said, you made a good point that one has to consider if programs can be
accidentally called with root priviledges, and what will happen in that case.

I think that it would be a good element for a checklist, rather than a good
reason to forbid any name conflict at all.

We also have to consider that large multi-user, multi-purpose systems are
becoming rare because it is easier to have virtual servers, chroots, and other
container solutions.  To the practical possibility of needing both programs at
the same time is even lower than when the Policy was written.

Here the surprise would come only if there were a system that is set up for
both the purpose of bioinformatics and security port scanning, without the
users being aware that there can be one or the other alternative installed.  I
think that it is very unlikely.

> We could have the foo and bar packages conflict with each other, and
> in some cases that might not be too bad. However, it would be really
> unfortunate for long-term quality, in my opinion, if Debian would
> start choosing to compromise like that. It may be true that the
> intersection of users of foo and bar are really rare, and that nobody
> much would suffer if they conflicted, but it sets a bad precedent.
> Conflicts in Debian are meant to be used for a specific reason: when
> two packages _can't_ be used together (at least not as packaged). If
> we use conflicts to resolve the yoyo for foo and bar, it means that we
> are willing to change the meaning of conflicts to also be allowed when
> we just can't be bothered to make difficult distro level integration
> decisions.

Indeed, we should avoid situations where taking bad technical decisions in the
short term is way easier than solving problems in the long term, and our
draconian policy is efficient for that goal.

However, I think that it is efficient to the point of being too strict (zero
tolerance).  We now have frequent rebuilds and other quality controls that
were not available when the Policy was written, and it I think that if we were
on a slippy slope, we would see an accumulation of increasingly worrying cases,
and there would be enough time to implement stricter rules.

Lastly, one of the reasons I take a non-cooperative standpoint here is that the
debian-devel mailing list tends to be the place where some developers call veto
on the choices other developers, and this done too cheaply on my opinion.  So
for renamings that will annoy users for sure and solve problems that are only
hypothethical, the question will be “who did it ?”.  And I think that those who
call for these renamings should do them themselves and stand at the front for
the possibility of receiving rotten tomatoes from our users.  If they are
willing to do this, that would convince me that they are not just talking.  On
my side, while I can not be convinced to rename programs in a situation like
this one, I will not block people doing it.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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/20140708112434.ge10...@falafel.plessy.net

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Mika Pflüger]

Hi Charles,

Charles Plessy  wrote:
> Here, both programs have narrow and non-overlaping user bases, and are
> not installed on fresh standard Debian systems. 
> 
> This said, you made a good point that one has to consider if programs
> can be accidentally called with root priviledges, and what will
> happen in that case.
> 
> I think that it would be a good element for a checklist, rather than
> a good reason to forbid any name conflict at all.
> 
> We also have to consider that large multi-user, multi-purpose systems
> are becoming rare because it is easier to have virtual servers,
> chroots, and other container solutions.  To the practical possibility
> of needing both programs at the same time is even lower than when the
> Policy was written.
> 
> Here the surprise would come only if there were a system that is set
> up for both the purpose of bioinformatics and security port scanning,
> without the users being aware that there can be one or the other
> alternative installed.  I think that it is very unlikely.

Note that another use case, which will produce conflicts even if
neither package is installed is searching for a particular binary. Say,
I want to install the bioinformatics tool, and search for it using:
$ apt-file search bin/amap
if this search returns multiple packages providing bin/amap, I will be
a bit confused. Maybe I even think both would fit my purpose and will
install one randomly; however, I guess I will also be confused if this
search turns up /usr/bin/amap-bio and /usr/bin/amap-pt and no
/usr/bin/amap, so renaming does not necessarily help for this. So
while this is not really a point supporting always forbidding common
binary names, I just wanted to point out that two packages do not need
to be installed in order for their binary names to clash and
archive-wide operations such as apt-file have to be considered as well.

Cheers,

Mika

-- 



signature.asc
Description: PGP signature

Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Jonas Smedegaard]

Hi Charles,

Quoting Charles Plessy (2014-07-08 13:24:34)
> We also have to consider that large multi-user, multi-purpose systems 
> are becoming rare because it is easier to have virtual servers, 
> chroots, and other container solutions.  To the practical possibility 
> of needing both programs at the same time is even lower than when the 
> Policy was written.

I disagree with your reasoning here.

Yes, computers become steadily more powerful, but no, it is not always 
the case that the added power is used to virtualize and compartmentalize 
- parallel to that, some also use it to shrink their systems - even down 
to wearable computing.


> Here the surprise would come only if there were a system that is set 
> up for both the purpose of bioinformatics and security port scanning, 
> without the users being aware that there can be one or the other 
> alternative installed.  I think that it is very unlikely.

I do not find it hard to imagine some of our users being interested in 
both bioinformatics and security, and I don't find it hard to imagine 
some of those being interested in pocket-sized computers either.

Let's try hard to leave to our users how they an combine the features we 
provide them, not take limiting decisions that rules out flexibility in 
their possible use of Debian.

It might be possible to "reboot into the security inspection OS" on a 
pocket device like a Nokia N900, but it certainly is less intuitive than 
"starting the port scanner".


 - 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: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Оlе Ѕtrеісhеr]

Charles Plessy  writes:
> Here the surprise would come only if there were a system that is set
> up for both the purpose of bioinformatics and security port scanning,
> without the users being aware that there can be one or the other
> alternative installed.  I think that it is very unlikely.

I think this is not so unlikely as you might think. I am not sure about
bioinformatics, but I am used to have a lot of astronomy (an even
narrower field of science) related tools on my laptop, and once in a
while I like to do a security port scan. I would call a system broken
that then tells me "You can't do this unless you uninstall some
completely unrelated other program" -- especially if the uninstallation
of the conflicting program then leads to the removal of some dozen other
packages.

This is really not unlikely. Security tools are of potential interest of
quite a large group of people, including scientists (of any field).

And, especially in science, you may just need something that at the
first glance looks completely unrelated to the usual stuff, just because
someone had a brilliant idea how to combine things.

I actually like that Debian does not allow unnecessary conflicts here.

Best regards

Ole


-- 
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/ytz61j8jclr@news.ole.ath.cx

Bug#754175: ITP: lpctools -- Interface to NXP LPC Microcontrollers ISP (In-System Programming) serial interface

[Sophie Brun]

Package: wnpp
Severity: wishlist
Owner: Sophie Brun 

* Package name: lpctools
  Version : 1.04
  Upstream Author : Nathael Pajani 
* URL : http://git.techno-innov.fr/?p=lpctools;a=summary
* License : GPL
  Programming Lang: C
  Description : Interface to NXP LPC Microcontrollers ISP (In-System 
Programming) serial interface

lpctools is split in two programms: lpcisp and lpcprog
* lpcisp:
This tool gives access to each of the usefull isp commands on LPC
devices. It does not provide wrappers for flashing a device.
* lpcprog:
This tool does not give access to each isp command, instead it
provides wrappers for flashing a device.

Both programms were originally written because existing programms were 
published under non-free licences, did not allow comercial use, or did not 
provide source code.


-- 
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/20140708115030.3896.18014.reportbug@pcfreexian

Re: Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters

[Jonathan Dowland]

On Mon, Jul 07, 2014 at 11:12:23PM -0700, Vincent Cheng wrote:
> On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it
>  wrote:
> >
> > Hi Steffen and all,
> >
> > today while talking with a backbox project administrator I discovered that
> > popular tools such as openvas directly calls the amap binary.
> >
> > I never talked with them, but I don't think it is feasible to ask to every
> > security tool provider to patch their code for the only debian benefit.
> >
> > I think I'm then changing again my opinion: the conflict field might be the
> > only proper way to be sure such popular tools (not packaged in debian and
> > some of them not even free) continue to work.
> >
> > Is this one a good reason for a conflict?
> 
> Again, according to Policy 10.1, as well as precedent that was established by
> the CTTE decision regarding the namespace collision between ax25-node vs.
> nodejs, no, it isn't; your argument is no different from that of the nodejs
> maintainers, arguing that /usr/bin/node should be taken over by nodejs simply
> because it's already widely used by the nodejs community.
> 
> If you feel strongly enough about this issue, I'd suggest filing a bug
> against debian-policy, going through the process and gathering consensus to
> change 10.1 (e.g. perhaps by weakening it to a "should" instead of a "must",
> or by proposing a carefully-worded exception to existing policy).

But just to be clear, the odds of changing policy are vanishingly small.

Rename the binary in Debian, do whatever foo is necessary to provide a PATH
that doesn't rename the binary that can be injected in the right place for
callers/environments that won't accept a renamed binary, or give up on
packaging it in Debian.


-- 
Jonathan Dowland


-- 
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/20140708125908.gb30...@bryant.redmars.org

grub-mkconfig loop

[Heimo Stranner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I use a self compiled linux kernel (make-kpkg) with a somewhat unusual
name (/boot/vmlinuz-3.15.4+ and /boot/initrd.img-3.15.4+) on debian sid.

It worked previously (sadly I can't be more precise here) but today
update-grub ran into a loop where my custom kernel was detected by
/etc/grub.d/10_linux over and over again.
The variable $list contained the correctly detected installed kernels
but my kernel would not be removed from $list at the end of the big
while loop in the line with "list=`echo $list | tr ' ' '\n' | grep -vx
$linux | tr '\n' ' '` . (line 349 for me)
Therefore $linux in the next round of this big while loop would be my
custom kernel again and again.

For me changing the line to "list=`echo $list | tr ' ' '\n' | grep -v
$linux | tr '\n' ' '` fixed the problem.
Is there any reason the x option was used in the first place or $linux
was not put in quotes? Is my fix a bad idea for some reason?

Best regards
Heimo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJTu+IzAAoJEJz2q6aG5VRzU3cQALlqZNHq41j5Plz3CHUY/I41
w5r/sH1vkVCYquF5qxU2YCA/pjnwBYEE7p5QNJoRWuGSU7A890N19Lyi01lu12oF
A6/ezrQIokNyeC0utrR6Fkb095v6yAVHgnDpHcLo0VAKqtc4CK3nfPPT+1/5+xD6
RJ1i/fSkwI1OtKNapDNP0lVKLUH6RPHYThq3zIcvFusPKbnx9CbOO9zb9pVuDs8M
j+misgxtsHHNuBD8mbhtR5Wt5ZuADLviCcu4vQO39YSs2BwtbbuyM2hCLYNFWRAj
vdB1vStCVtnkfWKlGI8ouv4SntlPWlSWkTKk0vs9xb3zkSCyi3ToijPTSG8m7/KV
FhZWkmrAwRfNkvbeLUFUHUTma/lSBccOJzTxUT/B+zIfJn94R5Nosj3Pn9OLHou5
mSuU6ofoibiqD6hV+Ba5EGxUIweYWLZfmvHs5WpbBb77/VilNIn0URzqxFt2LVyj
PbYcNS98X17+xelD4PiuikTgAMbuZMObNRxzRx65a1urzX9wuwMU/QWlfv5w8qbp
0TPd3fyqtoacsZv/AP4UA8pK5zACQOH2xjG4Va4aWDUMz+VSrLHDsPakjGDHFLNF
39QM7JEIhib8aHF4m4zIzKocHU6+2tMmO/5TuQScHtKWCKUZAhGEKedu/boesUjx
U6ZYjld8c5tFIjpVg8sV
=eD/l
-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/53bbe238.6020...@stranner.org

Re: Sources licensed under PHP License and not being PHP are not distributable

[Thomas Goirand]

On 07/08/2014 02:19 AM, Paul Tagliamonte wrote:
> On Mon, Jul 07, 2014 at 11:16:37PM +0800, Thomas Goirand wrote:
>> Unless I'm mistaking, there's no sign that the PHP license prevents
>> derivative work (even under a different license for your patch, if you
>> feel like it).
> 
> It's my reading that this is the case if you rename your project to not
> contain PHP (if it does), which would otherwise be violation of the license.
> 
> /
> |  4. Products derived from this software may not be called "PHP", nor
> | may "PHP" appear in their name, without prior written permission
> | from gr...@php.net.  You may indicate that your software works in
> | conjunction with PHP by saying "Foo for PHP" instead of calling
> | it "PHP Foo" or "phpfoo"
> \

Yes. The only restriction is to not use php-* for derivative packages.
That's very close to what we have with Firefox^WIceweasel. Maybe we
shouldn't have named all of our PEAR package php-*, but pear-* at least,
to avoid the issue. Though I'm not going to be the one working on all
the renaming ... :/

Thomas


-- 
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/53bbfb43.5040...@debian.org

Re: dpkg-source to automatically add a Testsuite field

[Antonio Terceiro]

On Tue, Jul 08, 2014 at 03:06:14AM +0200, Guillem Jover wrote:
> > How will it handle an existing value in that field? In the future, we
> > might have other forms of test suite, thus requiring different items in
> > the Testsuite: field.  What happens when there is already
> > 
> >   Testsuite: foo
> > 
> > and dpkg-source detects the presence of debian/tests/control? Will it
> > merge `autopkgtest` into the list, or will it replace the existing
> > value?
> 
> Ah indeed, here's the current behavior:
> 
> The field is parsed as a comma-separated list of values (as per the
> spec). If the debian/tests/control file is present then the value will
> be added to the list. The values will always get emitted in alphabetical
> order as a comma-separated list, any dupes squashed, so that the output
> is reproducible. Unknown values are emitted untouched.
> 
> If the field contains “autopkgtest”, but the debian/tests/control file
> is not present, then a warning will be issued, and the value preserved,
> as in “the maintainer knows better!?”. But maybe it is actually better
> to warn and just trim the “autopkgtest” value?
> 
> Does this resolve your concern?

Absolutely.

Thanks,

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Running autopkgtest at package upload time

[Antonio Terceiro]

On Tue, Jul 08, 2014 at 10:06:58AM +0200, Andreas Tille wrote:
> Hi,
> 
> I had some workshop at LSM[1] and I was mentioning autopkgtest as new
> and interesting feature.  To my astonishment the audience was not
> perfectly happy that it might last some time until a package test is
> performed and the developer gets some response.  Since I think that the
> person who raised this has some point I wonder whether there is a chance
> to implement autopkttest-ing right after a package was uploaded.

It is possible, yes.

Today debci runs in batch mode, reading the Source index from the
repository, detecting which packages need a test run (what includes
packages with new versions), and then running running the tests for all
packages in the batch that need a test run.

The support for distributed setups in debci in being worked on (thus
separating putting packages to a queue from actually running their
tests). When it's ready, we can implement a separate daemon that will
listen to fedmsg¹ and enqueue packages right away when they are
uploaded.

¹ https://wiki.debian.org/FedMsg

Of course, from there we would also need an APT repository from where to
actually get the uploaded packages. I remember a discussion about
turning the incoming location into a proper APT repository, but I don't
know in which stage that effort is.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Running autopkgtest at package upload time

[Ansgar Burchardt]

Hi,

On 07/08/2014 16:57, Antonio Terceiro wrote:
> Of course, from there we would also need an APT repository from where to
> actually get the uploaded packages. I remember a discussion about
> turning the incoming location into a proper APT repository, but I don't
> know in which stage that effort is.

incoming.d.o has a proper APT repository which has, amongst others, a
buildd-unstable suite including the last uploads. It's not not
accessible by the general public, but I'm sure we can arrange for debci
to get access if that's helpful for you.

Note that buildd-unstable looks similar to experimental in that it
doesn't include the full unstable suite, but rather acts as an addon to
the regular unstable.

Ansgar


-- 
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/53bc0bbd.9010...@debian.org

Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Eric Cooper]

Since Debian package names must already be unique, we ought to be able
to leverage that to avoid having to fight over which package gets to
claim which binary name.

What about making it into a user's install-time decision,
rather than a developer's packaging-time decision?

As a proof of concept, I copied each package's binaries on my machine
into /opt//bin/.  Then I union-mounted all these /opt/*/bin
directories into a single /ubin (for "unified /bin"), and set my PATH
to just that.  I've been using it (lightly) for a couple of days
without problems.

I just union-mounted them in alphabetical order, but in the case of
conflicts it would be easy to use a site-specific prioritization,
analagous to mailcap.order, to control the shadowing.

My apologies if this has already been proposed and rejected before.

Cheers,
Eric

-- 
Eric Cooper e c c @ c m u . e d u


-- 
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/20140708153112.gb30...@google.com

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Don Armstrong]

On Tue, 08 Jul 2014, Eric Cooper wrote:
> What about making it into a user's install-time decision, rather than
> a developer's packaging-time decision?

Any user who wants to can override the rename by using dpkg-divert.

-- 
Don Armstrong  http://www.donarmstrong.com

We were at a chinese restaurant.
He was yelling at the waitress because there was a typo in his fortune
cookie.
 -- hugh http://www.gapingvoid.com/Moveable_Type/archives/000321.html


-- 
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/20140708160457.gr9...@teltox.donarmstrong.com

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Jérémy Lal]

Le mardi 08 juillet 2014 à 09:04 -0700, Don Armstrong a écrit :
> On Tue, 08 Jul 2014, Eric Cooper wrote:
> > What about making it into a user's install-time decision, rather than
> > a developer's packaging-time decision?
> 
> Any user who wants to can override the rename by using dpkg-divert.

But most users won't have the skills to use that workaround.
I appreciated the idea in
https://lists.debian.org/debian-devel-announce/2012/07/msg2.html
that packages must be made non-conflicting, but still the end user
can install a conflicting 'legacy' package (upon which no other packages
are allowed to depend).

Jérémy.



-- 
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/1404836655.18025.3.camel@imac.chaumes

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Josselin Mouette]

Le mardi 08 juillet 2014 à 11:31 -0400, Eric Cooper a écrit : 
> Since Debian package names must already be unique, we ought to be able
> to leverage that to avoid having to fight over which package gets to
> claim which binary name.
> 
> What about making it into a user's install-time decision,
> rather than a developer's packaging-time decision?

It sounds silly because the behavior becomes non-predictable.

The correct solution is Solomon’s judgment: whenever such name clashes
occur, force *both* packages to rename the binary, and have all reverse
dependencies in Debian use the renamed path.

This way, the user can add a symbolic link in /usr/local/bin if he wants
to use a third-party package that requires the use of a generic name.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1404838654.14436.876.camel@dsp0698014

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

On Tue, Jul 08, 2014 at 09:43:02AM +0200, Johannes Schauer wrote:
> Do you think I should fill bugs for all non-empty packages that were
> already found?  Or do you think there is another high chance of false
> positives for that kind of packages too?

The only other likely sources of false positives I can think of would also
be bugs, just bugs of a different sort - i.e., if you're build-depending on
a -dev package which you don't use and which is not a metapackage, but you
are using its dependencies.  So I think it's fine to file bugs for the
others, unless someone else raises objections here.

-- 
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: Proposal to avoid executable naming conflicts

[Russ Allbery]

Josselin Mouette  writes:
> Le mardi 08 juillet 2014 à 11:31 -0400, Eric Cooper a écrit : 

>> Since Debian package names must already be unique, we ought to be able
>> to leverage that to avoid having to fight over which package gets to
>> claim which binary name.
>> 
>> What about making it into a user's install-time decision,
>> rather than a developer's packaging-time decision?

> It sounds silly because the behavior becomes non-predictable.

> The correct solution is Solomon’s judgment: whenever such name clashes
> occur, force *both* packages to rename the binary, and have all reverse
> dependencies in Debian use the renamed path.

I do think this is context-dependent.  Some programs are so widely and
heavily used outside of Debian that people familiar with Linux expect them
to be available with a particular name.  In cases like that, I don't think
renaming the commonly-used program makes sense.  I understand the appeal
of strict fairness, and that by not renaming we're letting upstream "get
away" with camping on namespace, but I think the disservice to our users
outweighs the somewhat dubious benefits of having that fight.

That doesn't apply in this particular case, but I think that point was
relevant to both git and node.

(I made this argument at the time, with respect to node, in the TC, so
this is probably not a new viewpoint to folks.)

-- 
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/8761j73gmb@windlord.stanford.edu

Re: Running autopkgtest at package upload time

[Antonio Terceiro]

On Tue, Jul 08, 2014 at 05:18:21PM +0200, Ansgar Burchardt wrote:
> Hi,
> 
> On 07/08/2014 16:57, Antonio Terceiro wrote:
> > Of course, from there we would also need an APT repository from where to
> > actually get the uploaded packages. I remember a discussion about
> > turning the incoming location into a proper APT repository, but I don't
> > know in which stage that effort is.
> 
> incoming.d.o has a proper APT repository which has, amongst others, a
> buildd-unstable suite including the last uploads. It's not not
> accessible by the general public,

Right.

> but I'm sure we can arrange for debci to get access if that's helpful
> for you.

That will be really nice. When I have the code working we will talk. :-)

> Note that buildd-unstable looks similar to experimental in that it
> doesn't include the full unstable suite, but rather acts as an addon to
> the regular unstable.

Noted.

When a package leaves buildd-unstable, does it imediately appear in
unstable? Is there a time window between the package disappearing from
buildd-unstable and appearing in the primary mirrors? If there is one,
how long is it?

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#754216: ITP: libnanomsg-raw-perl -- low-level interface to nanomsg for Perl

[Harlan Lieberman-Berg]

Package: wnpp
Severity: wishlist
Owner: "Harlan Lieberman-Berg" 

* Package name: libnanomsg-raw-perl
  Version : 0.02
  Upstream Author : Florian Ragwitz 
* URL : https://metacpan.org/pod/NanoMsg::Raw
* License : Expat
  Programming Lang: Perl / XS
  Description : low-level interface to nanomsg for Perl

NanoMsg::Raw is a binding directly to the underlying nanomsg C library.  
It is intended to provide a very low-level and manual interface; it does 
not provide a convenient high-level API, integration with event loops, 
or any other abstractions.


-- 
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/20140708185349.10316.96132.report...@debian.bos.chitika.net

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Chris Bannister]

On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> Since Debian package names must already be unique, we ought to be able
> to leverage that to avoid having to fight over which package gets to
> claim which binary name.
> 
> What about making it into a user's install-time decision,
> rather than a developer's packaging-time decision?

Wouldn't you get sick of 'that name has already been taken, please
try another.' message? 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20140708185702.GI13825@tal

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Eric Cooper]

On Wed, Jul 09, 2014 at 06:57:02AM +1200, Chris Bannister wrote:
> On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> > Since Debian package names must already be unique, we ought to be able
> > to leverage that to avoid having to fight over which package gets to
> > claim which binary name.
> > 
> > What about making it into a user's install-time decision,
> > rather than a developer's packaging-time decision?
> 
> Wouldn't you get sick of 'that name has already been taken, please
> try another.' message? 

Given how infrequently this issue has cropped up over the years, no.
And a prioritization (like mailcap.order) would limit it to once per
conflict.

-- 
Eric Cooper e c c @ c m u . e d u


-- 
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/20140708195720.ga8...@google.com

Re: Proposal to avoid executable naming conflicts (was: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters)

[Paul Tagliamonte]

On Tue, Jul 08, 2014 at 03:57:20PM -0400, Eric Cooper wrote:
> On Wed, Jul 09, 2014 at 06:57:02AM +1200, Chris Bannister wrote:
> > On Tue, Jul 08, 2014 at 11:31:12AM -0400, Eric Cooper wrote:
> > > Since Debian package names must already be unique, we ought to be able
> > > to leverage that to avoid having to fight over which package gets to
> > > claim which binary name.
> > > 
> > > What about making it into a user's install-time decision,
> > > rather than a developer's packaging-time decision?
> > 
> > Wouldn't you get sick of 'that name has already been taken, please
> > try another.' message? 
> 
> Given how infrequently this issue has cropped up over the years, no.
> And a prioritization (like mailcap.order) would limit it to once per
> conflict.

Only off the top of my head:

git/git, chromium/chromium, docker/docker, node/node

Those are all pretty big packages.

It'd be really annoying for a script to misuse a binary, which was
expecting node to be, well, node, or git to be git.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: possible MBF: automatically detecting unused build dependencies

[Kurt Roeckx]

On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> Kurt Roeckx 
>libtool

==> libtool_2.4.2-1.7.arch-all.unusedbd <==
gfortran=4:4.8.2-4

gfortran Depends on gfortran-4.8, and that is being used.

>openssl (U)
==> openssl_1.0.1g-4.arch-all.unusedbd <==
m4=1.4.17-4

>From the changelog:
  * Add Build-Dependency on m4, since sparc needs it to generate
it's assembler files.  (Closes: #334542)


Kurt


-- 
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/20140708223637.ga14...@roeckx.be

Re: possible MBF: automatically detecting unused build dependencies

[Steve Langasek]

On Tue, Jul 08, 2014 at 06:22:49AM +0200, Johannes Schauer wrote:
> Quoting Steve Langasek (2014-07-08 00:07:29)
> > On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:
> > > Nevertheless, those "false positives" that were generated this way are
> > > still useful to be later marked with  once build profiles
> > > are allowed in the archive because they are obviously droppable.

> > No, marking build-dependencies with build profiles should be driven by what
> > is needed to break build-dep loops, not by what build-deps are "droppable"
> > without further modification of the packages.  Excessive stage1 profile
> > tagging will result in unnecessary extra builds during a bootstrap.

> Bootstrapping should not get into the way of the normal packaging.

But it absolutely does have this effect if we add bootstrap-specific
metadata unnecessarily, because:

 - it introduces a syntax incompatibility with older versions of the package
   tools
 - it makes the packaging more complex to understand

The latter point is as likely to cause problems for the bootstrappers
themselves as it is for the maintainers, since the more maintainers who have
to get this metadata right and keep it up to date, the more it's going to
bitrot.

> The downside you list "unnecessary extra builds" are easy to avoid in
> practice.  Botch contains algorithms to find a close to minimum set of
> source packages to modify to make a dependency graph acyclic (a feedback
> vertex set).  Even if all source packages in the dependency graph had
> removable build dependencies it would only choose a small set of them
> (currently 60-70 are needed) to actually build with a stage1 profile
> active.

I'm happy that tools like botch exist and think botch has been a useful
accelerator for bootstrappability of Debian.  However, my own goal is to see
that future port bootstraps can be done using the standard buildd
infrastructure (for each of Debian and Ubuntu), which doesn't currently make
use of such techniques - rather, they work by building everything which is
buildable.  If you plan to wire up botch to wanna-build for archive-friendly
bootstrappability, that would be great to see!  But until that's happened, I
stand by my claim that stage1 data not needed for breaking build-dep loops
is counterproductive for bootstrapping ports.

> > > I did not plan to run this script more often yet. I'll probably do another
> > > run after having added a detection for meta packages as suggested by you
> > > below.

> > > Running it more regularly might not require any big discussion because the
> > > "problem size" might be small enough that maintaining a white list would 
> > > be
> > > enough.

> > If you really want to systematically detect misbuilds on missing
> > build-dependencies, it's a much bigger problem than just detecting this for
> > the build-dependencies which are metapackages.

> Why? The build dependencies which are not metapackages are not listed as
> false positives because they get weeded out in the first phase.

Because "package misbuilds when a metapackage it build-depends on is broken"
is an arbitrary subset of "package misbuilds when build-depends are broken",
and it does not benefit Debian to have maintainers focusing on such an
arbitrary subset.

Cheers,
-- 
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: grub-mkconfig loop

[Colin Watson]

[For the future, it's generally better to file bug reports about this
kind of thing.  As luck would have it I manage to read -devel
occasionally ...]

On Tue, Jul 08, 2014 at 02:21:12PM +0200, Heimo Stranner wrote:
> I use a self compiled linux kernel (make-kpkg) with a somewhat unusual
> name (/boot/vmlinuz-3.15.4+ and /boot/initrd.img-3.15.4+) on debian sid.
>
> It worked previously (sadly I can't be more precise here) but today
> update-grub ran into a loop where my custom kernel was detected by
> /etc/grub.d/10_linux over and over again.
> The variable $list contained the correctly detected installed kernels
> but my kernel would not be removed from $list at the end of the big
> while loop in the line with "list=`echo $list | tr ' ' '\n' | grep -vx
> $linux | tr '\n' ' '` . (line 349 for me)
> Therefore $linux in the next round of this big while loop would be my
> custom kernel again and again.
>
> For me changing the line to "list=`echo $list | tr ' ' '\n' | grep -v
> $linux | tr '\n' ' '` fixed the problem.
> Is there any reason the x option was used in the first place or $linux
> was not put in quotes? Is my fix a bad idea for some reason?

Thanks for your report.  Dropping -x isn't quite the right answer.  The
bug is that using grep for this interprets regular expression
metacharacters in the path.  Using fgrep instead fixes this (and quoting
is of course a good idea too; the whole loop could probably use a
rewrite IMO, but this will do for now).  I've fixed this upstream:

  
http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=0901e7855f922e770cbfeb58262cb8fded518190

... and cherry-picked it into the Debian packaging for my next upload:

  
http://anonscm.debian.org/gitweb/?p=pkg-grub/grub.git;a=commitdiff;h=4bea8b3e2d4718fca3625d6e9707cbf249cb7aa6;hp=3d7a403d28c23372a4ef17c27622366bd2196670

-- 
Colin Watson   [cjwat...@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/20140708230502.ga31...@riva.ucam.org

Re: possible MBF: automatically detecting unused build dependencies

[Johannes Schauer]

Hi,

Quoting Kurt Roeckx (2014-07-09 00:36:37)
> On Mon, Jul 07, 2014 at 01:51:00PM +0200, Johannes Schauer wrote:
> > Kurt Roeckx 
> >libtool
> 
> ==> libtool_2.4.2-1.7.arch-all.unusedbd <==
> gfortran=4:4.8.2-4
> 
> gfortran Depends on gfortran-4.8, and that is being used.

indeed this is then a false positive of a nearly-meta package. Unfortunately
the gfortran package does ship some files besides /usr/share/doc (both
symlinks) and would thus not be classified as a meta package.

Maybe I should also check debtags. gfortran is tagged role::dummy. I also found
role::metapackage. Is there another debtag or method in general that would
allow to consider the dependencies of a package instead and avoid this kind of
false positive?

Maybe a package shipping only symlinks besides /usr/share/doc is another way of
finding meta packages. On the other hand it's harder to check the type of file
a package ships as it needs downloading and unpacking first. I'm not aware
whether tools like apt-file display information about the file type.

> 
> >openssl (U)
> ==> openssl_1.0.1g-4.arch-all.unusedbd <==
> m4=1.4.17-4
> 
> >From the changelog:
>   * Add Build-Dependency on m4, since sparc needs it to generate
> it's assembler files.  (Closes: #334542)

Then it makes sense that my amd64 build caught that. Could you make m4 an
architecture specific dependency if it's only used on sparc?

cheers, josch


--
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/20140709043719.14505.38892@hoothoot