date:20140205

control: subscribe -1

> "Charles" == Charles Plessy writes:

Charles> The 3.0 (native) format is useful when packaging a work
Charles> that is developped and distributed in a Git repository.
Charles> Please leave us this possibility.

Let me describe the use case I have which is an expansion on the above.
I have a bunch of software that I perform daily builds for out of
version control (git in my case but the issue applies to other vcs as
well).
The software does have upstream versions but is not stable enough that
upstream release tarballs are useful to anyone.
Honestly at this point, I'm not sure anyone will ever find upstream
tarballs useful; anyone who is likely to want to build this from source
probably has a copy of git and can checkout a tag.

There is a packaging branch and an upstream branch.
Changes made on the packaging branch increment the debian revision;
changes made on the ustream branch eventually involve an increment to
the upstream version.

Things get dumped into a Debian reprepro repository, and into Ubuntu
PPAs.
Eventually, things will get stable enough that I'll upload to a PPA.

Prior to that, I need a way to build a Debian package including source
from a directory without an upstream tar ball. 3.0(git) is not a
reasonable option because archive management programs have very little
support for it, and because package download tools probably aren't well
tested with it.

I'm happy to entertain other options rather than 3.0(native) but my
requirements are:

* support for upstream version
* support for debian revision

* No need to have upstream sources available to dpkg-buildpackage prior
to running it

* No need to maintain .orig.tar.gz artifacts produced by dpkg-source
and keep the checksums of these artifacts consistent between packages
with the same upstream versions.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/0144017b42b6-b65ba883-c94b-472c-89b7-7341c14ce8ab-000...@email.amazonses.com

Re: File naming of scripts in /etc/init.d

2014-02-05 Thread heroxbd

Petter Reinholdtsen  writes:

> Before concurrent running of init.d scripts were implemented in sysv-rc,
> the .sh scripts would be sourced by /etc/init.d/rc and /etc/init.d/rcS
> while the non-.sh scripts would be executed.  This distinciton were
> removed when sysv-rc started to run scripts in parallell, as it no
> longer made sense.

What a history! Provided that all the scripts are executed, is there any
plan to strip the .sh suffix?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86zjm5yexc@moguhome00.in.awa.tohoku.ac.jp

Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

2014-02-05 Thread Andreas Beckmann

On 2014-02-05 10:57, Sam Hartman wrote:
> tarballs useful; anyone who is likely to want to build this from source
> probably has a copy of git and can checkout a tag.

Such a tag corresponds to an upstrema version?

> I'm happy to entertain other options rather than 3.0(native) but my
> requirements are:
> 
> * support for upstream version
> * support for debian revision
> 
> * No need to have upstream sources available to dpkg-buildpackage prior
>   to running it
> 
> * No need to maintain .orig.tar.gz artifacts  produced by dpkg-source
>   and keep the checksums of these artifacts consistent between packages
>   with the same upstream versions.

All this sounds like it can be done with git-buildpackage
--git-pristine-tar --git-pristine-tar-commit. Can be set in
debian/gbp.conf. And maybe dpkg-source --single-debian-patch.
And if this doesn't work for you, we should enhance the tools e.g.
git-buildpackage, to better support the desired workflows (i.e. what you
really want to achieve), not the workarounds (the way you used achieve
this today^Wyesterday^Wbefore dpkg 1.17).

And your goal seems to be: "I have a git repository with upstream
branch, tags, debian branch and I want an easy solution (command) to
build conforming packages without having to worry about details like
creating upstream tarballs." and not "I need to upload foo 1.2-3 with
source format 3.0 (native)".

Andreas


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

Re: File naming of scripts in /etc/init.d

[Benda]
> What a history! Provided that all the scripts are executed, is there
> any plan to strip the .sh suffix?

Not from me, at least.  The advantage would be purely cosmetic, and
the effort to make sure every upgrade problem is handled would be
significant.  But new scripts will not get the .sh ending, and in
time, I guess the current init.d/*.sh scripts will become obsolete and
go away.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205115808.gp13...@ulrik.uio.no

Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

> "Andreas" == Andreas Beckmann  writes:

Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
>> tarballs useful; anyone who is likely to want to build this from
>> source probably has a copy of git and can checkout a tag.

Andreas> Such a tag corresponds to an upstrema version?

yes.

>> I'm happy to entertain other options rather than 3.0(native) but
>> my requirements are:
>> 
>> * support for upstream version * support for debian revision
>> 
>> * No need to have upstream sources available to dpkg-buildpackage
>> prior to running it
>> 
>> * No need to maintain .orig.tar.gz artifacts produced by
>> dpkg-source and keep the checksums of these artifacts consistent
>> between packages with the same upstream versions.

Andreas> All this sounds like it can be done with git-buildpackage
Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set in
Andreas> debian/gbp.conf. And maybe dpkg-source
Andreas> --single-debian-patch.  

no, that means I have to maintain the artifact (namely the
.orig.tar.gz).
The archive software (both reprepro and dak were I to use that) require
that the .orig.tar.gz not change checksums.

I don't want my build machines to be able to push back to my master
repository.
Nor do I want to have to release upstream versions if I lose state on my
build machines.
So this violates my requirements because I have to maintain  an artifact
of dpkg-source (the .orig.tar.gz) and makesure its checksum never
changes.

Also, using git-buildpackage is difficult.
The build is done by sbuild, which does not call git-buildpackage.

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/014401fef5be-d5d021c8-b29f-48df-bfe9-91ce164a4899-000...@email.amazonses.com

Re: debconf managed configuration files

I've tried to do a reasonable job with the krb5-config package of
updating a user-managed krb5.conf and keeping it in sync with debconf
data.
It's quite old and I doubt it's best practice any more but it is an
example of how to approach a non-shell-script package.

The debconf-managed comment is an inadequate solution.  Better than just
somping on things and if that's all you have time for, then go for it.
However if you can do better please do!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/01440205931b-e931214c-cd15-4377-8835-b4a2e2dcb10d-000...@email.amazonses.com

Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

2014-02-05 Thread Neil Williams

On Wed, 5 Feb 2014 12:21:30 +
Sam Hartman  wrote:

> > "Andreas" == Andreas Beckmann  writes:
> 
> Andreas> On 2014-02-05 10:57, Sam Hartman wrote:
> >> tarballs useful; anyone who is likely to want to build this
> >> from source probably has a copy of git and can checkout a tag.
> 
> Andreas> Such a tag corresponds to an upstrema version?
> 
> yes.
> 
> >> I'm happy to entertain other options rather than 3.0(native)
> >> but my requirements are:
> >> 
> >> * support for upstream version * support for debian revision
> >> 
> >> * No need to have upstream sources available to
> >> dpkg-buildpackage prior to running it
> >> 
> >> * No need to maintain .orig.tar.gz artifacts produced by
> >> dpkg-source and keep the checksums of these artifacts
> >> consistent between packages with the same upstream versions.
> 
> Andreas> All this sounds like it can be done with git-buildpackage
> Andreas> --git-pristine-tar --git-pristine-tar-commit. Can be set
> Andreas> in debian/gbp.conf. And maybe dpkg-source
> Andreas> --single-debian-patch.  
> 
> no, that means I have to maintain the artifact (namely the
> .orig.tar.gz).
> The archive software (both reprepro and dak were I to use that)
> require that the .orig.tar.gz not change checksums.

Using packages to support upstream development is a common problem and
this is exactly where things get awkward.

For my own role within an upstream team, I'm considering using
"unofficial" or "developer" upstream tarball releases. We'll probably
use a date based tag 2014.02 etc for the main monthly release.
Developer builds will have a shortened git hash appended (this happens
to match our existing deployment method) like 2014.02.234fdga2 and
incremental upstream releases will use tag.01 etc. so 2014.02.01

This has advantages that developers self-verify that the tarballs work
which finds problems due to new files not being included in the
tarball. It also retains the upstream packaging behaviour.

> I don't want my build machines to be able to push back to my master
> repository.
> Nor do I want to have to release upstream versions if I lose state on
> my build machines.
> So this violates my requirements because I have to maintain  an
> artifact of dpkg-source (the .orig.tar.gz) and makesure its checksum
> never changes.
> 
> Also, using git-buildpackage is difficult.
> The build is done by sbuild, which does not call git-buildpackage.

Not true. There are options to use debuild or pdebuild or
dpkg-buildpackage in-place.

e.g. I use:

[DEFAULT]
#builder = git-pbuilder
builder = debuild
cleaner = fakeroot debian/rules clean
pristine-tar = True

[git-buildpackage]
export-dir = ../build-area/
tarball-dir = ../tarballs/

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

2014-02-05 Thread Charles Plessy

Le Wed, Feb 05, 2014 at 12:46:09PM +0100, Andreas Beckmann a écrit :
> 
> All this sounds like it can be done with git-buildpackage

Hello everybody,

I have the impression that we are arguing because of solution in search for a
problem.

Some things worked with the previous version of dpkg, with no extra work for
anybody.

Who benefited directly from the change of behavior ?  Nobody ?  Then please
revert it; it was not necessary.

I propose a compromise.

 - First, somebody convinces Joey to switch the ikiwiki to a non-native
   format.  If you can twist the arm of a highly reputed developer, it means
   that the problem that you attempted to solve (a stricter distinction between
   native and non-native packages) was really important.

 - Then, we consider that others can follow.

 - In the meantime, please revert the change in dpkg.  There is no need to
   prevent packages in the 3.0 (native) format to use non-native version
   number.

Alternatively, please rename the "3.0 (native)" format to "3.0 (tarball)" or
anything elese, and we are done.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Best-practice / howto packaging of CGI-based Web app ?

2014-02-05 Thread Olivier Berger

Hi.

I must be very bad at discriminating search engines results, but
couldn't spot any howto for packaging CGI-based Web apps in Debian (the
web apps policy somehow addresses CGIsn but not in a straightforward way,
an is really old :-/).

I'd welcome any such docs or at least examples of maintained packages in
Debian which provide CGI-based Web applications, from wich I could
borrow much of the packaging, instead of re-doing mistakes.

I guess I could try to summarize the results in a wiki page.

Thanks in advance for any pointers.

Best regards,
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n4dbs2u@inf-8660.int-evry.fr

dpkg: is_native version checks in dpkg 3.0 Native

2014-02-05 Thread Ian Jackson

Guillem writes, on the bug but not on debian-devel:
> Part of the definition of what's and what's not a native package is
> the version scheme, and I've never considered that a Debian specific
> thing specified by its policy. The fact that dpkg-source has been
> sloppy in the past for format 1.0 does not mean newer formats should
> not behave better in that respect, and when the change was done it
> was "pretty early" as to not have any major impact, because the
> current state had not been dregraded.
> 
> This change does not affect extraction in any way, so backward
> compatibility is preserved. If a maintainer is going to rebuild the
> _source_ package, that means they have changed it, at which point they
> might as well fix the bogus version. There's also no connection
> whatsoever between the source and binary versions, so you can still use
> stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10
> produced from the same source package, for example.
> 
> Given the above, I don't see any reason at all to support this, and
> I'm thus marking this report as wontfix, and will be closing in a bit.

(I reproduce the whole message so that -devel can see it.)

Guillem, please reconsider.

Firstly, as people have illustrated, there are situations where a
native format package with a Debian revision is a useful thing to
have.

Secondly, there doesn't appear to be any support in policy for this
restriction.

Thirdly, notwithstanding your comments, I think this change is a
problem for backwards-compatibility.  People modifying source packages
might be doing so in a context where they don't want to, or can't
conveniently, change the version number of the source format.  They
might also be using dpkg-source to prepare packages for a downstream
distro who don't have the same fixed opinion about the versions.

Can you please explain what you think the concrete benefit is of this
change ?  At the moment we have numerous packages in this state and
they don't cause any problems.

As you can see from debian-devel, there is a clear consensus that this
change should be reverted.

Thanks,
Ian.


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

Bug#737732: ITP: online-python-tutor -- Online Python Tutor helps learn how to program in Python by visualizing code execution

2014-02-05 Thread Olivier Berger

Package: wnpp
Severity: wishlist
Owner: Olivier Berger 

* Package name: online-python-tutor
  Version : 3
  Upstream Author : Philip Guo (http://www.pgbovine.net/)
* URL : http://www.pythontutor.com/
* License : BSD
  Programming Lang: Python, Javascript
  Description : Online Python Tutor helps learn how to program in Python by 
visualizing code execution

Online Python Tutor is a free educational tool created by Philip Guo that helps 
students overcome a fundamental barrier to learning programming: understanding 
what happens as the computer executes each line of a program's source code. 
Using this tool, a teacher or student can write a Python program in the Web 
browser and visualize what the computer is doing step-by-step as it executes 
the program.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140205140013.15461.55470.report...@inf-8660.int-evry.fr

Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

> "Neil" == Neil Williams  writes:


That makes sense and I do something similar as appropriate.  Even so, I
do not wish to maintain the upstream tarball as a maintained artifact.
There are cases where packaging release releases are made.  Maintaining
pristine-tar commits for daily builds is a worse solution than
3.0(native) or not including source packages in the resulting Debian
archive.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/014402578b78-e77d4d79-35bc-4e7f-8a9a-311d3b59207f-000...@email.amazonses.com

Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

2014-02-05 Thread Bernhard R. Link

* Sam Hartman  [140205 13:27]:
> no, that means I have to maintain the artifact (namely the
> .orig.tar.gz).
> The archive software (both reprepro and dak were I to use that) require
> that the .orig.tar.gz not change checksums.
> 
> I don't want my build machines to be able to push back to my master
> repository.
> Nor do I want to have to release upstream versions if I lose state on my
> build machines.
> So this violates my requirements because I have to maintain  an artifact
> of dpkg-source (the .orig.tar.gz) and makesure its checksum never
> changes.

This answers the question why you want to use a 3.0 (native) package.
But the real question here is: Why do you want to use a version with "-"
for such a package?

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205171418.ga1...@client.brlink.eu

Re: dpkg-dev: please reject native/non-native version when building native/non-native source packages

2014-02-05 Thread Bernhard R. Link

* Charles Plessy  [140205 14:18]:
> Who benefited directly from the change of behavior ?  Nobody ?  Then please
> revert it; it was not necessary.

Most import are people starting to create Debian packages.
At least with 3.0 source packages they no longer have to care about the
different meanings of native vs non-native. A package either is native,
then both the version and the package reflect this, or they are
non-native. No more chances to only switch one of the fields but not the
other by mistake.

It also helps users, as it makes it easier to guess what things look
like, from only looking at the version.

Finally it makes it easier for writers of tools to deal with Debian
packages, as there are some absurd corner cases fewer. (The most absurd
one is a 3.0(quilt) with a package without hyphen. The resulting
filenames are simply ...).

> Alternatively, please rename the "3.0 (native)" format to "3.0 (tarball)" or
> anything elese, and we are done.

And brake almost everything? That suggestion is almost equivalent to
just forbidding 3.0 (native) packages completely for the next decade.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205172131.gb1...@client.brlink.eu

Re: Bug#737634: dpkg-dev: please reject native/non-native version when building native/non-native source packages

> "Bernhard" == Bernhard R Link writes:

As I mentioned I have a packaging branch and an upstream branch.
I wish to use debian revisions to reflect packaging changes.

It's slightly more complex than changes to debian directory involve a
debian revision change; changes to other things involve a upstream
version change.

As an example I produce both RPMs and Debs. Just as I don't want to
increment the upstream version number because of a spec file change, I
don't want to increment the upstream version number because I updtaded
build-depends in debian/control.
Especially when the debian directory isn't even on the upstream master
branch. Incrementing the upstream version number (which appears in
configure.ac among other places) so I could make changes to files that
don't even appear on that branch is an undesirable work flow.

I guess I could have a debian upstream version number that differed from
the actual upstream version number.
That seems undesirable from a user expectations standpoint as well as
potentially impacting things in unexpected ways.

The bug claims that it is a violation of policy to use 3.0(native)
without a.orig.tar.something.
I'm actually failing to find that in policy at all.
I'm finding some SHOULD level recommendations, but certainly not MUST
level recommendations, I can think of reasons why a maintainer might
want to voiolate those shoulds.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/014403490b5a-5b32fbed-1099-44ca-b73d-5c1d3514336c-000...@email.amazonses.com

Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

2014-02-05 Thread Guillem Jover

Hi!

On Wed, 2014-02-05 at 13:54:17 +, Ian Jackson wrote:
> Guillem writes, on the bug but not on debian-devel:
> > Part of the definition of what's and what's not a native package is
> > the version scheme, and I've never considered that a Debian specific
> > thing specified by its policy. The fact that dpkg-source has been
> > sloppy in the past for format 1.0 does not mean newer formats should
> > not behave better in that respect, and when the change was done it
> > was "pretty early" as to not have any major impact, because the
> > current state had not been dregraded.
> > 
> > This change does not affect extraction in any way, so backward
> > compatibility is preserved. If a maintainer is going to rebuild the
> > _source_ package, that means they have changed it, at which point they
> > might as well fix the bogus version. There's also no connection
> > whatsoever between the source and binary versions, so you can still use
> > stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10
> > produced from the same source package, for example.
> > 
> > Given the above, I don't see any reason at all to support this, and
> > I'm thus marking this report as wontfix, and will be closing in a bit.

> Guillem, please reconsider.

Sorry, I should have added here my usual note about being open to
reconsideration *if* convincing arguments are put forward. But I
was pretty much unimpressed with the way this had been brought up.
Way more so now with the threats of TC force, but I guess that's
the new Debian-way…

> Firstly, as people have illustrated, there are situations where a
> native format package with a Debian revision is a useful thing to
> have.

What I get from that thread and previous ones is that our tools might
be suboptimal, simply suck or might make things difficult when it
comes to some specific workflows. In my book the way to fix that is to
improve the tools, create new ones or new formats, not to workaround
and shoehorn stuff into them (at least for the new formats, the old
one is incurable at this point).

> Secondly, there doesn't appear to be any support in policy for this
> restriction.

§3.2.1

  “If punctuation is desired between the date components, remember
   that hyphen (`-') cannot be used in native package versions.”

§5.6.12

  “If there is no  then hyphens are not allowed;”

  “This part of the version number specifies the version of the
   Debian package based on the upstream version.”
  …
  “It is optional; if it isn't present then the 
   may not contain a hyphen.  This format represents the case where
   a piece of software was written specifically to be a Debian
   package, where the Debian package source must always be identical
   to the pristine source and therefore no revision indication is
   required.”

> Thirdly, notwithstanding your comments, I think this change is a
> problem for backwards-compatibility.  People modifying source packages
> might be doing so in a context where they don't want to, or can't
> conveniently, change the version number of the source format. They
> might also be using dpkg-source to prepare packages for a downstream
> distro who don't have the same fixed opinion about the versions.

If people are preparing stable updates, I'd expect them to do that in
a stable system, no problem here. If people are updating ancient
source packages in a modern system they will need to change way more
things anyway (due to compilers, deprecated stuff, etc). If people
are updating someone else's package (say an NMU) for a bogus native
package, they have to create an entire new source package with new
upstream tarball(s) anyway, switching the source format is a very
tiny change in comparison, and this type of change is pretty common
when transitions or unrelated FTBFS bugs are involved. If the context
is completely outside of Debian, and neither the source version nor
the source format can/wants to be changed (?), that _might_ call at
most for a force option allowing bogus versions, but certainly not
for a revert. But please, see below for how big of a problem this
currently is in Debian.

And this is a bit of a tangent, but IMO changing the source format
(from native to non-native) is the correct thing to do anyway for
native packages when modified by someone else than the author,
because I find it's pretty inappropriate to release a new upstream
release on behalf of the upstream author, taking over the version
namespace and file release namespace when those changes might not
even survive, which can be confusing towards downstreams in other
distributions who might not be aware of these nuances, or those
changes might be part of a derivative, in which case taking over
those namespaces would be inappropriate too.

> Can you please explain what you think the concrete benefit is of this
> change ?

Our source packages are already pretty complicated, mixing native
packages with non-native versions (and the reverse which is even worse)
adds to t

upgrade problem

2014-02-05 Thread Roelof Wobben

When I do apt-get dist-upgrade I see this happen:

Use 'apt-get autoremove' to remove it.
The following packages will be upgraded:
  linux-image-3.12-1-amd64
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
49 not fully installed or removed.
Need to get 0 B/29.6 MB of archives.
After this operation, 3414 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 146026 files and directories currently installed.)
Preparing to unpack .../linux-image-3.12-1-amd64_3.12.9-1_amd64.deb ...
Unpacking linux-image-3.12-1-amd64 (3.12.9-1) over (3.12.6-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/linux-image-3.12-1-amd64_3.12.9-1_amd64.deb (--unpack):
 cannot copy extracted data for 
'./lib/modules/3.12-1-amd64/kernel/net/l2tp/l2tp_ip6.ko' to 
'/lib/modules/3.12-1-amd64/kernel/net/l2tp/l2tp_ip6.ko.dpkg-new': failed to 
write (No space left on device)
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-3.12-1-amd64_3.12.9-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

I see a no space left on device. Which is wierd because I did a install on a 
80G disk.

Roelof

Bug#737776: ITP: qpid-dispatch -- Dispatch router for Qpid and AMQP

2014-02-05 Thread Darryl L. Pierce

Package: wnpp
Severity: wishlist
Owner: "Darryl L. Pierce" 

* Package name: qpid-dispatch
  Version : 0.1
  Upstream Author : Qpid Team 
* URL : http://qpid.apache.org/
* License : Apache License, Version 2.0
  Programming Lang: C/Python
  Description : Dispatch router for Qpid and AMQP

A lightweight message router, written in C and built on Qpid Proton, that 
provides flexible and scalable interconnect between AMQP endpoints or between 
endpoints and brokers.


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

Re: upgrade problem

2014-02-05 Thread Markus Frosch

Hey Roelof,

> When I do apt-get dist-upgrade I see this happen:
> 
>  cannot copy extracted data for
> './lib/modules/3.12-1-amd64/kernel/net/l2tp/l2tp_ip6.ko' to
> '/lib/modules/3.12-1-amd64/kernel/net/l2tp/l2tp_ip6.ko.dpkg-new': 
> I see a no space left on device. Which is wierd because I did a
> install on a 80G disk.
> 
Have you checked the inode usage of your drive?

$ df -i

Please note that this is a Debian developer mailing list, you should use
one of the users lists.

https://lists.debian.org/users.html

Cheers
Markus


-- 
Markus Frosch
mar...@lazyfrosch.de
http://www.lazyfrosch.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1391634279.22592.2.ca...@frosch-nb.lazyfrosch.de

Two line init.d scripts? Sure, that will work!

Hi.

A few months ago I drafted an idea to rewrite init.d scripts to use a
common implementation and only specify the unique parts in the init.d
scripts themselves. That draft can be found on
http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>.

The idea is to let init.d scripts look like this:

#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides: daemon
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: nice daemon
# Description: Provide service to others
### END INIT INFO
DAEMON=/usr/sbin/daemond

Short and to the point, and in the simple case only list the path to
the daemon to start. The code to implement init.d scripts is moved to
/lib/init/init-d-script, and the redundant code spread across
/etc/init.d/ can be dropped.

A few days ago I picked up the idea again, and wrote a more complete
draft of the /lib/init/init-d-script. The code is available in the
simpler-init-scripts in the sysvinit GIT repository, available from
http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts
>.
I've tested it on a few packages, and believe the code is ready for
wider testing.

The main target group for this feature are the majority of packages
with init.d scripts, the ones starting a single daemon. There are
around 1000 packages in Debian with init.d scripts. Around 100 of
them start stuff using rcS.d/, and tend to be quite complex. Most of
the rest start a simple daemon and are based on different generations
of /etc/init.d/skeleton. The target for this feature is the latter
group.

The reason I bring this up on debian-devel@ is twofold. First, I want
to gather feedback on the idea. Will it work for your package, or are
some more hooks needed? Second, I wonder where such script best would
belong. My initial idea is to put it in the initscripts package,
installed on almost all Debian systems, but I suspect sysvinit-utils
is a good place too. I plan to use the system in the initscripts
package, and am relucant to add new dependencies to it, as this would
make the new dependency a required package.

Comments?

CC to pkg-sysvinit-de...@lists.alioth.debian.org, where the system is
being drafted these days.

As for the line counting in the subject, I decided to ignore commented
lines. Including those, we end up on 11 lines. :)

--
Happy hacking
Petter Reinholdtsen

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205213109.gb1...@ulrik.uio.no

Re: dpkg: is_native version checks in dpkg 3.0 Native

Ian Jackson  writes:

> Secondly, there doesn't appear to be any support in policy for this
> restriction.

Policy definitely supports this restriction, as Guillem pointed out.  I
want to echo that analysis as one of the people to have touched that
portion of the Policy document.

I have always considered native packages with non-native versioning to be
a bug, and Lintian has treated them accordingly for quite some time.

This thread has surfaced a few interesting use cases that it would be nice
to handle, and I'm agnostic about the specific change to dpkg, but I
concur with Guillem's analysis of what Policy says.  Policy says such
packages are not correct.  (Note that is not definitive for what dpkg
should accept or not accept, as dpkg is intentionally a broader tool than
Debian Policy and is used in some situations for which Debian Policy is
not applicable.)

-- 
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: http://lists.debian.org/87vbwtqm6u@windlord.stanford.edu

Re: Two line init.d scripts? Sure, that will work!

2014-02-05 Thread Neil Williams

On Wed, 5 Feb 2014 22:31:09 +0100
Petter Reinholdtsen  wrote:

> Hi.
> 
> A few months ago I drafted an idea to rewrite init.d scripts to use a
> common implementation and only specify the unique parts in the init.d
> scripts themselves.  That draft can be found on
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
> >.
> 
> The idea is to let init.d scripts look like this:
> 
>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond

Interesting idea - will there be a half-way implementation for daemons
which require at least some command line options? e.g. logfile and
loglevel? pidfile?

> Short and to the point, and in the simple case only list the path to
> the daemon to start.  The code to implement init.d scripts is moved to
> /lib/init/init-d-script, and the redundant code spread across
> /etc/init.d/ can be dropped.
> 
> A few days ago I picked up the idea again, and wrote a more complete
> draft of the /lib/init/init-d-script.  The code is available in the
> simpler-init-scripts in the sysvinit GIT repository, available from
>  http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts
> >. I've tested it on a few packages, and believe the code is ready
> >for wider testing.
> 
> The main target group for this feature are the majority of packages
> with init.d scripts, the ones starting a single daemon.  There are
> around 1000 packages in Debian with init.d scripts.  Around 100 of
> them start stuff using rcS.d/, and tend to be quite complex.  Most of
> the rest start a simple daemon and are based on different generations
> of /etc/init.d/skeleton.  The target for this feature is the latter
> group.

I've got a few of those... some in Debian, others not in Debian yet.
 
> The reason I bring this up on debian-devel@ is twofold.  First, I want
> to gather feedback on the idea.  Will it work for your package, or are
> some more hooks needed?  Second, I wonder where such script best would
> belong.  My initial idea is to put it in the initscripts package,
> installed on almost all Debian systems, but I suspect sysvinit-utils
> is a good place too.  I plan to use the system in the initscripts
> package, and am relucant to add new dependencies to it, as this would
> make the new dependency a required package.

sysvinit-utils sounds good to me.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: dpkg: is_native version checks in dpkg 3.0 Native

Sam Hartman  writes:
>> "Russ" == Russ Allbery  writes:

> Russ> Ian Jackson  writes:
> >> Secondly, there doesn't appear to be any support in policy for
> >> this restriction.

> Russ> Policy definitely supports this restriction, as Guillem
> Russ> pointed out.  I want to echo that analysis as one of the
> Russ> people to have touched that portion of the Policy document.

> Citation requested.
> I looked for this today and couldn't find it.

Policy lacks a section that clearly defines native and non-native
packages, which is a long-standing bug in Policy.  Currently, that
information is in Policy 5.6.12, which is an inobvious place for it, and
worse, is hidden in the definition of the debian_revision component.
However, the intent is to define native vs. non-native by the version
number format used:

This part of the version number specifies the version of the Debian
package based on the upstream version. It may contain only
alphanumerics and the characters + . ~ (plus, full stop, tilde) and is
compared in the same way as the upstream_version is.

It is optional; if it isn't present then the upstream_version may not
contain a hyphen. This format represents the case where a piece of
software was written specifically to be a Debian package, where the
Debian package source must always be identical to the pristine source
and therefore no revision indication is required.

-- 
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: http://lists.debian.org/877g99qkyx@windlord.stanford.edu

Re: dpkg: is_native version checks in dpkg 3.0 Native

> "Russ" == Russ Allbery  writes:

Russ> Ian Jackson  writes:
>> Secondly, there doesn't appear to be any support in policy for
>> this restriction.

Russ> Policy definitely supports this restriction, as Guillem
Russ> pointed out.  I want to echo that analysis as one of the
Russ> people to have touched that portion of the Policy document.

Citation requested.
I looked for this today and couldn't find it.

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/014404036284-6388572e-e02b-400f-b378-bfbcd745ff2c-000...@email.amazonses.com

Re: Two line init.d scripts? Sure, that will work!

[Neil Williams]
> Interesting idea - will there be a half-way implementation for daemons
> which require at least some command line options? e.g. logfile and
> loglevel? pidfile?

Sure.  It should already support that, like this:

  DAEMON_ARGS="-some option"
  PIDFILE="/var/run/my.pid

Everything should be configurable or overridable, so those with more
complex needs could be able to use it too.

> I've got a few of those... some in Debian, others not in Debian yet.

Great.  Please try to convert them to this new approach and let me know
if you run into problems.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2fl8utptbk0@diskless.uio.no

Re: dpkg: is_native version checks in dpkg 3.0 Native

> "Russ" == Russ Allbery writes:

>> Citation requested. I looked for this today and couldn't find
>> it.

Russ> Policy lacks a section that clearly defines native and
Russ> non-native packages, which is a long-standing bug in Policy.
Russ> Currently, that information is in Policy 5.6.12, which is an
Russ> inobvious place for it, and worse, is hidden in the definition
Russ> of the debian_revision component. However, the intent is to
Russ> define native vs. non-native by the version number format
Russ> used:

OK, we found the same section of policy.

Russ> This part of the version number specifies the version of
Russ> the Debian package based on the upstream version. It may
Russ> contain only alphanumerics and the characters + . ~ (plus,
Russ> full stop, tilde) and is compared in the same way as the
Russ> upstream_version is.

Russ> It is optional; if it isn't present then the
Russ> upstream_version may not contain a hyphen. This format
Russ> represents the case where a piece of software was written
Russ> specifically to be a Debian package, where the Debian package
Russ> source must always be identical to the pristine source and
Russ> therefore no revision indication is required.

OK.
I agree that policy 6.5.12 clearly states that if the debian revision is
absent:

* The software is written for Debian

* the source and upstream source must be the same

* No revision is required (i think this last is analysis not normative)

However, I cannot read that text to imply anything about what happens if
the Debian revision is present:

* Policy seems silent on whether the software MAY?SHOULD NOT/MUST NOT be
written explicitly for Debian (I consider this a feature)

* Policy appears silent about whether the source and upstream source are
the same/need be the same

* Policy seems very silent about whether technical mechanisms that would
make it difficult for the upstream source and source to differ are
appropriate with a debian revision present.
Clearly, if your source and upstream source differ, using technical
mechanisms incompatible with that is nonsensical.

I claim that 6.5.12 at least is silent on the treatment of packages that
have a Debian revision.

I agree that 6.5.12 strongly suggests that
3.0(QUILT) packages should have a debian revision. Any thought at all
about 3.0(QUILT) raises that to a requirement rather than a strong
suggestion.
However that seems unrelated to this bug.

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/0144044d1318-5b90edcf-54df-4368-8a94-4bf008381306-000...@email.amazonses.com

Re: dpkg: is_native version checks in dpkg 3.0 Native

Sam Hartman  writes:

> However, I cannot read that text to imply anything about what happens if
> the Debian revision is present:

> * Policy seems silent on whether the software MAY?SHOULD NOT/MUST NOT be
>   written explicitly for Debian (I consider this a feature)

> * Policy appears silent about whether the source and upstream source are
>   the same/need be the same

> * Policy seems very silent about whether technical mechanisms that would
>   make it difficult for the upstream source and source to differ are
>   appropriate with a debian revision present.  Clearly, if your source
>   and upstream source differ, using technical mechanisms incompatible
>   with that is nonsensical.

> I claim that 6.5.12 at least is silent on the treatment of packages that
> have a Debian revision.

Yeah, that's a good point.  And now that you bring that up, that all
sounds very familiar.  I suspect there's an open Policy bug somewhere that
makes much the same point.

We really need to create a separate Policy section that defines native and
non-native and deals with all of this directly, instead of drawing
inferences from the Version field specification.  This has been confusing
people for years; it's one of the common questions in debian-mentors.  Of
course, then we have to decide what that Policy section should say.

-- 
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: http://lists.debian.org/8761otp2r1@windlord.stanford.edu

Re: Two line init.d scripts? Sure, that will work!

Petter Reinholdtsen  writes:

> A few months ago I drafted an idea to rewrite init.d scripts to use a
> common implementation and only specify the unique parts in the init.d
> scripts themselves.  That draft can be found on
>  http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
>  >.

> The idea is to let init.d scripts look like this:

>   #!/lib/init/init-d-script
>   ### BEGIN INIT INFO
>   # Provides:  daemon
>   # Required-Start:$remote_fs $syslog
>   # Required-Stop: $remote_fs $syslog
>   # Default-Start: 2 3 4 5
>   # Default-Stop:  0 1 6
>   # Short-Description: nice daemon
>   # Description:   Provide service to others
>   ### END INIT INFO
>   DAEMON=/usr/sbin/daemond

> Short and to the point, and in the simple case only list the path to the
> daemon to start.  The code to implement init.d scripts is moved to
> /lib/init/init-d-script, and the redundant code spread across
> /etc/init.d/ can be dropped.

It's probably worth mentioning that this is basically the path down which
OpenRC went, except that OpenRC has taken the concept somewhat further to
allow the dependencies to be specified in code instead of comments (using
special shell functions).  You may want to take a look at their syntax,
since it's extremely close to what you're doing but possibly a bit more
fleshed out.

-- 
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: http://lists.debian.org/871tzhp2oa@windlord.stanford.edu

Re: Two line init.d scripts? Sure, that will work!

[Russ Allbery]
> It's probably worth mentioning that this is basically the path down
> which OpenRC went, except that OpenRC has taken the concept somewhat
> further to allow the dependencies to be specified in code instead of
> comments (using special shell functions).  You may want to take a
> look at their syntax, since it's extremely close to what you're
> doing but possibly a bit more fleshed out.

Yeah, I discovered that OpenRC had a similar approach, but without
staying compatible with our current set of scripts in /etc/init.d/.
The two goals I had in mind were to allow us to migrate individual
scripts to this system without having to replace sysv-rc, file-rc, or
any of the other implementations currently running init.d scripts (ie
stay compatible with the current LSB based init.d script format) and
reduce the code duplication between init.d scripts.  OpenRC can't
provide both these, as far as I can see.  It solve a lot of other
problems for sure. :)

This approach also make it easier to identify the "simple" init.d
scripts, and possibly also make it easier to integrate them with for
example systemd and upstart by providing a replacement for the
init-d-script script or by extending init-d-script.

-- 
Happy hacking
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140205233625.gd1...@ulrik.uio.no

amd64 arch and optimization flags?

2014-02-05 Thread Jaromír Mikeš

Hi all,

I would like to add some optimization flags for amd64 arch in some packages
(mostly LV2 nad LADSPA plugins).
I found these as candidates for amd64 arch:

-msse
-msse2
-mfpmath=sse
-ffast-math
-ftree-vectorize
-mtune=generic

Can some of them be safely added for amd64 or is just bad idea?
Some for other archs?

best regards

mira

Re: amd64 arch and optimization flags?

2014-02-05 Thread Julian Taylor

On 06.02.2014 00:39, Jaromír Mikeš wrote:
> 
> Hi all,
> 
> I would like to add some optimization flags for amd64 arch in some
> packages (mostly LV2 nad LADSPA plugins).
> I found these as candidates for amd64 arch:
> 
> -msse
> -msse2
> -mfpmath=sse

this is enabled by default on amd64

> -ffast-math

this is dangerous it changes results, sometimes significantly (e.g. for
complex numbers), only use if you don't care about correctness or have
verified its still correct.

> -ftree-vectorize

this does sometimes slow programs down, usually only programs doing
numeric work profit from it, these usually enable it by themselves.
It is enabled by the -O3 optimization level.
it is mostly safe to use if you follow the C standard strictly (i.e. no
unaligned access of aliased variables)

> -mtune=generic

should be the default, but you can safely change that to something else.
generic in gcc < 4.9 is I think pentium4 which is a very old chip.

gcc-4.9 will change the default of it to bulldozer/intel-core btw:
http://gcc.gnu.org/gcc-4.9/changes.html

-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f2cdaa.4090...@googlemail.com

Re: Best-practice / howto packaging of CGI-based Web app ?

2014-02-05 Thread Paul Wise

On Wed, Feb 5, 2014 at 9:35 PM, Olivier Berger wrote:

> Thanks in advance for any pointers.

General principles are the same for all web apps regardless of technology.

Ship the code and data in /usr/share/.

Ship a tool to create web server configuration (vhosts or subURLs) in
/usr/sbin. You can't know at what domain and URL the sysadmin is going
to want the CGI running at so leave it up to them.

Which CGI are we talking about? Perhaps we can give more specific advice.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6ga1gypq-qid1jdjxwvuvzhdh4egok3ggbsnayxwfa...@mail.gmail.com

Re: Best-practice / howto packaging of CGI-based Web app ?

2014-02-05 Thread Paul Wise

On Thu, Feb 6, 2014 at 8:43 AM, Paul Wise wrote:

> Which CGI are we talking about? Perhaps we can give more specific advice.

I guess you mean Online Python Tutor (#737732).

Looking at the git repo, it includes a lot of embedded code copies of
various JavaScript libraries and other code. As per policy 4.13 those
should be packaged separately.

https://wiki.debian.org/EmbeddedCodeCopies

I see some places where it uses os.system(). That should switch to
using the subprocess module with shell disabled.

The idea of this software is a bit concerning to me, it sounds like it
runs arbitrary Python code on the server and passes the results back
to the web. I would suggest auditing it to ensure that it isn't one
giant security hole. Please get CVEs for any issues that you find.

http://oss-security.openwall.org/wiki/disclosure/cve

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6Fni3EyW1tO7rOzvGGH500g=NHJ=qftehrnnxotu-v...@mail.gmail.com

Re: Bug#737634: dpkg: is_native version checks in dpkg 3.0 Native

2014-02-05 Thread Dimitri John Ledkov

On 5 February 2014 20:08, Guillem Jover  wrote:
> Hi!
>
> On Wed, 2014-02-05 at 13:54:17 +, Ian Jackson wrote:
>> Guillem writes, on the bug but not on debian-devel:
>> > Part of the definition of what's and what's not a native package is
>> > the version scheme, and I've never considered that a Debian specific
>> > thing specified by its policy. The fact that dpkg-source has been
>> > sloppy in the past for format 1.0 does not mean newer formats should
>> > not behave better in that respect, and when the change was done it
>> > was "pretty early" as to not have any major impact, because the
>> > current state had not been dregraded.
>> >
>> > This change does not affect extraction in any way, so backward
>> > compatibility is preserved. If a maintainer is going to rebuild the
>> > _source_ package, that means they have changed it, at which point they
>> > might as well fix the bogus version. There's also no connection
>> > whatsoever between the source and binary versions, so you can still use
>> > stuff like pkg-source_0 with pkg-binary1_2.0-1 and pkg-binary2_1:4.0-10
>> > produced from the same source package, for example.
>> >
>> > Given the above, I don't see any reason at all to support this, and
>> > I'm thus marking this report as wontfix, and will be closing in a bit.
>
>> Guillem, please reconsider.
>
> Sorry, I should have added here my usual note about being open to
> reconsideration *if* convincing arguments are put forward. But I
> was pretty much unimpressed with the way this had been brought up.
> Way more so now with the threats of TC force, but I guess that's
> the new Debian-way…

?!

If you interpreted any of my emails as threats, I'm deeply sorry and
in no way, I meant it this way.

>
>> Firstly, as people have illustrated, there are situations where a
>> native format package with a Debian revision is a useful thing to
>> have.
>
> What I get from that thread and previous ones is that our tools might
> be suboptimal, simply suck or might make things difficult when it
> comes to some specific workflows. In my book the way to fix that is to
> improve the tools, create new ones or new formats, not to workaround
> and shoehorn stuff into them (at least for the new formats, the old
> one is incurable at this point).
>
>> Secondly, there doesn't appear to be any support in policy for this
>> restriction.
>
> §3.2.1
>
>   “If punctuation is desired between the date components, remember
>that hyphen (`-') cannot be used in native package versions.”
>
> §5.6.12
>
>   
>   “If there is no  then hyphens are not allowed;”
>
>   
>   “This part of the version number specifies the version of the
>Debian package based on the upstream version.”
>   …
>   “It is optional; if it isn't present then the 
>may not contain a hyphen.  This format represents the case where
>a piece of software was written specifically to be a Debian
>package, where the Debian package source must always be identical
>to the pristine source and therefore no revision indication is
>required.”
>

This is how Debian Policy defines version numbers for the Debian
Project and the Debian Archive.
This is not always the case for derivatives, ISV developers, or others
using dpkg toolchain.
My particular use case falls outside of Debian Archive / Debian Policy.
Thus i'm asking to consider backwards compatibility, in a wider context.

I agree that for Debian Archive and Debian Policy it is probably the
right enforcmement. It's on a far lower level, than I'd expect it to
be.
Hence I did not propose the revert, and only proposed an optional
feature flag to enable this quirky behaviour to allow, specifically,
build a 3.0 (native) package with a non-native version number.

>> As you can see from debian-devel, there is a clear consensus that this
>> change should be reverted.
>
> Sorry, but I don't see a clear consensus there. I see some people that
> say this should be reverted, some that say the proposed usages are
> bogus anyway, and then some confused messages about what this affects
> or not. For example, what does ikiwiki (a native package with a native
> version) has to do with anything?
>
>

Can we all please back track a bit.

A particular use-case I have is that, at times, there is a need to
build a stand-alone src+binary packages with a strict one-to-one
mapping to the src+debs already in the official archive.
Especially when this strict matching source package, actually contains
non-reproducible / non-free / prebuild binaries exactly against the
free matching src+debs in the official archive.

e.g. linux 3.13.0-6 source package, which is uploaded into the
archive, built on the autobuilders.
Later it is fetched, taken offline for secure-boot signing, the
detached signatures stripped and assembled into a linux-signed
3.13.0-6 source package which only contains the detached signatures.
At build-time of linux-signed package, it can then depend on stricly
self-package version string to reattach secure-

Binary naming conflict

2014-02-05 Thread Bill Blough


Greetings,

I've started packaging PasswordSafe (a GUI password manager) which ships
a binary named pwsafe.  

Oldstable contains the pwsafe package (a command line password manager
based on an earlier version of PasswordSafe) which also ships a binary
named pwsafe.

The policy says: 

"Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled
via "alternatives" or the "Conflicts" mechanism."

My inital reaction is that both packages are PasswordSafe compatible
password managers, and that they differ in interface implementation.
If this is the accepted interpretation, the I believe I can just use
"Conflicts: pwsafe" and be ok, especially since pwsafe has been removed
from stable/testing/unstable and is (in my opinion) very unlikely to be
reintroduced.

On the other hand, I believe an argument could be made that user interface
style is a feature, and therefore the packages differ in functionality
and a rename must occur.

What's the right interpretation/approach here?

Thanks,
Bill



signature.asc
Description: Digital signature

Re: Binary naming conflict