Re: why are there /bin and /usr/bin...

[Bastien ROUCARIES]

> A better test might be to do this without /usr mounted.
>
> MfG
>        Goswin

Could we do automated testing using:
- creating a new mount namespace
- a bind mount of /usr on a empty directory ?

A second option will be to modify fakeroot in order to avoid the
/usr/binding and run some test like --version

Thanks

Bastien


--
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/aanlktinsxcw6vwo8zw72ys1rfdlgr+xmazxf-w1tu...@mail.gmail.com

Bug#548195: marked as done (Move cmap and cmap depend package to main)

[Debian Bug Tracking System]

Your message dated Thu, 12 Aug 2010 13:56:59 +0200
with message-id 
and subject line Cmap is in main
has caused the Debian Bug report #548195,
regarding Move cmap and cmap depend package to main
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
548195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548195
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist

The Adobe CMap resources are now free software and licensed under the
BSD license. More information about this can be found here:

http://bonedaddy.net/pabs3/log/2009/09/24/adobe-data-freed/
http://lists.debian.org/debian-legal/2009/09/msg00039.html

This a meta bug. Please correct each blocking bug, then close it

Bastien


--- End Message ---
--- Begin Message ---
This bug is done cmap is on main now

Bastien

--- End Message ---

QEMU HPPA image

[Bastien ROUCARIES]

Hi,

In order to chase a bug (#592712) on hppa, i try to run qemu on hppa.

I begin to try to download a qemu image on
http://people.debian.org/~aurel32/qemu but i could not found a qemu
image.

Do you know where to download such an image ? I will be handy to add
to usual place.

I will try tomorrow to build one if not found before.

Bastien


-- 
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/aanlktim354+z7atjdbnfj8zzsyp-avlmcw3kcoi0h...@mail.gmail.com

Re: Notes from the DebConf Source Format BoF

[Ian Jackson]

Giacomo A. Catenazzi writes ("Re: Notes from the DebConf Source Format BoF"):
> I think there are three usual use of the sources:
> - developers/bug trackers/...
> - users: to check and to learn the sources
> - admins: who need to recompile/backport/.. sources
> 
> Using git for the last two groups seems too much.

I've found that it works reasonably well, provided that: For users,
you assume that they know nothing about git and you just tell them
runes to type.  And for admins, that they are willing to learn git or
already know it.  For admins who don't want to learn git you do need
something else.

> Your solution will works only for master branch, but
> the other users will need the "stable" or testing branch.
> [Note: a wrapper could solve this]

This is easy: you just publish two trees, rather than two branches in
the same tree.  (It's a shame that there isn't a syntax for "git
clone" which checks out a particular branch.)

> Should sysadmin, which recompile a package, create
> a new branch and commit the changes?

If you're doing things that way, yes.

> dpkg-source will no more create a new source package?
> Do we really require sysadmin to learn the basic use of git?

I think you're misunderstanding me.  I'm certainly not saying we
should abandon everything we have and try to make everyone use git.

I'm trying help give motivation to ideas for improving the current
situation, and also give an idea of how some things can work very well
with modern tools.

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/19556.1800.933820.608...@chiark.greenend.org.uk

Re: Notes from the DebConf Source Format BoF

[Simon McVittie]

On Tue, 10 Aug 2010 at 20:27:24 -0700, Russ Allbery wrote:
> One issue with 3.0 (quilt) is that when you check it out when it's
> maintained in a VCS, you have two choices: commit the .pc directory and
> files, or leave it out and then have to run some magic
[...]
> - Why don't you just check in with patches not applied?
[...]
>   * You can do this with a rebased patch branch, but then you don't get
> history on modifications to the patch.

I've been playing with gbp-pq for some of my packages, and I've been somewhat
pleased with it:

* debian (or debian-squeeze or master etc.) branch contains an unapplied patch
  series
* patch-queue/debian branch is continually rebased, never pushed, and contains
  the patch series applied on top of the debian branch; you build from here
* to track modifications to the patches, use git commands on the patches
  themselves
* the patches are already in a suitable form to submit upstream
* as long as you do DEP-3 headers as a footer rather a header (in the style
  of kernel Signed-off-by footers), they'll round-trip through the patch queue

The problem is that if you build from the patch-queue/debian branch, and
fix something in the debian directory, you have to cherry-pick those changes
onto the debian branch later, then rebase the patch queue on top, then
reconstitute the patch series.

Simon


-- 
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/20100812150855.ga30...@reptile.pseudorandom.co.uk

My report after the BOF on distributed bugtrackers at DebConf

[Olivier Berger]

Hi.

Thanks to Don Armstrong, we have had an interesting BoF at debconf about
distributed bugtrackers (actually, I wasn only "participating" on
remote, thanks to the videoteam's streaming).

You'll find in [0] a report of mine with much of my own ideas on the
subject in addition to what was said during the BoF. This is in no way a
formal report. I hope it help continue some interesting discussions on
the subject anyway.

I'm not sure, but maybe these issues should be discussed on the
dist-bugs list [1]?

Best regards,

[0] 
http://www-public.it-sudparis.eu/~berger_o/weblog/2010/08/12/my-report-after-the-bof-on-distributed-bugtrackers-at-debconf/
[1] http://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), 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/1281626679.32080.53.ca...@inf-8657.int-evry.fr

Re: QEMU HPPA image

[Aurelien Jarno]

On Thu, Aug 12, 2010 at 04:02:18PM +0200, Bastien ROUCARIES wrote:
> Hi,
> 
> In order to chase a bug (#592712) on hppa, i try to run qemu on hppa.
> 
> I begin to try to download a qemu image on
> http://people.debian.org/~aurel32/qemu but i could not found a qemu
> image.
> 
> Do you know where to download such an image ? I will be handy to add
> to usual place.
> 

QEMU doesn't emulate HPPA, that's why you can't find such an image.

Aurelien

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100812170640.gg6...@volta.aurel32.net

Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Hello,

I know that there is a recent thread that talked about the status of
non-recompilable binaries in packages, with the common particular case
is Flash applets.

As I understood it, the overall conclusion was: even if their licence is
DFSG-free, according to the policy section 2.2, packages containing such
binaries cannot go to main and, if distributed, must go to contrib. I
agree with that, but I think the reality is more complex, as software
can be built of several, partly independant bricks.

Indeed, as a package can be a source package or a binary package, I
wonder how this applies. First of all, as the control file allows to set
the section both for the source package and for each binary package, can
a source package be in a different area than one of the binary packages
it generates?

Let us say an upstream tarball contains such a non-recompilable binary
as a minor component that can be stripped and maybe distributed by other
means. The debian/rules will not compile it (it cannot), but if it does
not even include it in the generated binary package, would such a
package (both source and binary) “not require a package outside of main
for compilation or execution”? In other words, to be in main, does the
maintainer have to strip the problematic file from the binary package,
or does he have to repack the original tarball stripping it?

Same case, but with two binary packages generated, one with the main
content, the other one with the problematic files appart: can the source
file be in main? That case does not apply if all the packages associated
to a single orig tarball must be in the same area.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Ian Jackson]

Tanguy Ortolo writes ("Non-recompilable binaries in source and binary packages 
(Adobe Flash strikes again)"):
> Let us say an upstream tarball contains such a non-recompilable binary
> as a minor component that can be stripped and maybe distributed by other
> means. The debian/rules will not compile it (it cannot), but if it does
> not even include it in the generated binary package, would such a
> package (both source and binary) ?not require a package outside of main
> for compilation or execution?? In other words, to be in main, does the
> maintainer have to strip the problematic file from the binary package,
> or does he have to repack the original tarball stripping it?

The current approach of the project in these cases seems to be that
the right thing to do is to rebuild the source package so that the
non-free pieces are removed.

Personally I think this is a complete waste of everyone's time;
particularly, rebuilding upstream source archives is troublesome and
doesn't really benefit anyone.

I'd much rather you could just write in your .dsc a set of glob
patterns for files to remove, somehow, which dpkg-source would remove
when you unpacked it (unless you told it not to).  That would prevent
the non-free files from being accidentally used during the build
process or shipped (eg when upstream Makefiles change), but would save
a lot of work.  It would also mean that the upstream tarball in our
archive would be the real upstream tarball.  

I can see that there might be the objection that we were then
distrubuting non-free stuff from our main archive section but given
that our archive is almost entirely used by people using our tools,
this is a small price worth paying for not obstructing our work on the
free parts of the package.  Obviously if the non-free parts are
significant in size this doesn't apply.

The benefit would be that we would no longer have to rebuild upstream
source packages where upstream has helpfully included files such as
RFCs (which we usually consider non-free) or other non-free stuff.
Upstreams normally regard it as a convenience for people, to provide
apocrypha etc. in their tarballs, and to be honest they're probably
right.  We are making a rod for our own back by our current practice
of insisting on repackaging their tarballs.

(I'm assuming that the non-recompilable binary is distributable.  If
it isn't then it can't be in our archive at all of course.)

> Same case, but with two binary packages generated, one with the main
> content, the other one with the problematic files appart: can the source
> file be in main? That case does not apply if all the packages associated
> to a single orig tarball must be in the same area.

No.  There is no sensible way to do this.  The problem is inherent:
the binary packages in main have to be rebuildable using the source
package (and supporting binary packages eg compilers) in main.

If you have this situation you have to have two separate source
packages; one in main which builds only the free parts, and one in
non-free which builds only the non-free parts.

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/19556.14016.688915.420...@chiark.greenend.org.uk

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Le jeudi 12 août 2010, Ian Jackson a écrit :
> The current approach of the project in these cases seems to be that
> the right thing to do is to rebuild the source package so that the
> non-free pieces are removed.
 
Non-free? According to the DFSG, are not they free? I cannot see any
point of the DFSG that such a program, distributed both in source and
compiled form, with a free license, compilable only with non-free tools,
would infringe.

I thought they were only failing one policy condition to be in the free
area, but not the DFSG. As the policy section 2.2.2 says:
> Every package in contrib must comply with the DFSG.

So if such a non-recompilable, free-licensed binary fails the DFSG, it
should not even go to contrib, but to non-free!

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Ian Jackson  writes:

> No.  There is no sensible way to do this.  The problem is inherent:
> the binary packages in main have to be rebuildable using the source
> package (and supporting binary packages eg compilers) in main.

> If you have this situation you have to have two separate source
> packages; one in main which builds only the free parts, and one in
> non-free which builds only the non-free parts.

I don't believe this is correct.  Source packages in main can build
binaries in contrib, and I believe the problem with not being able to
rebuild with free tools is more of a contrib thing than a non-free thing.

But I'm not certain, which is why I was hesitating to reply to the first
message.

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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Charlie Smotherman]

On Thu, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote:
> Le jeudi 12 août 2010, Ian Jackson a écrit :
> > The current approach of the project in these cases seems to be that
> > the right thing to do is to rebuild the source package so that the
> > non-free pieces are removed.
>  
> Non-free? According to the DFSG, are not they free? I cannot see any
> point of the DFSG that such a program, distributed both in source and
> compiled form, with a free license, compilable only with non-free tools,
> would infringe.
> 
> I thought they were only failing one policy condition to be in the free
> area, but not the DFSG. As the policy section 2.2.2 says:
> > Every package in contrib must comply with the DFSG.
> 
> So if such a non-recompilable, free-licensed binary fails the DFSG, it
> should not even go to contrib, but to non-free!
> 
Tanguy

You may want to look at this thread

http://lists.debian.org/debian-devel/2010/08/msg00082.html

Best regards
Charlie



--
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/1281639570.2772.27.ca...@debian

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Lars Wirzenius]

On to, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote:
> Le jeudi 12 août 2010, Ian Jackson a écrit :
> > The current approach of the project in these cases seems to be that
> > the right thing to do is to rebuild the source package so that the
> > non-free pieces are removed.
>  
> Non-free? According to the DFSG, are not they free? I cannot see any
> point of the DFSG that such a program, distributed both in source and
> compiled form, with a free license, compilable only with non-free tools,
> would infringe.

There's at least two requirements for software included in Debian main:

a) the license must be free according to the DFSG
b) all binaries in main must be built only from sources in main, using
only tools in main

If we don't have b), Debian is not self-sustaining: in order to build
Debian we would have to have access to other systems, or software from
outside of Debian. (Non-free being outside of Debian for the purpose of
this paragraph.)

Not being self-sustainable, in turn, means we are limited in how
efficiently we can fix bugs, especially security bugs.

Relying on tools package in Debian's non-free section might work,
technically, depending on the exact (and possibly changing) details of
the license. However, I doubt it's the kind of thing the project wants
to rely on.

To me, it sounds like you need to put your package into contrib,
including its binary packages, until you can convince upstream to fix
things so that they do not require non-free tools to build, or you
convince the upstreams of the non-free tools to free their software.



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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Le jeudi 12 août 2010, Charlie Smotherman a écrit :
> On Thu, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote:
>> I thought they were only failing one policy condition to be in the free
>> area, but not the DFSG. As the policy section 2.2.2 says:
>> > Every package in contrib must comply with the DFSG.
>> 
>> So if such a non-recompilable, free-licensed binary fails the DFSG, it
>> should not even go to contrib, but to non-free!
> 
> You may want to look at this thread
> http://lists.debian.org/debian-devel/2010/08/msg00082.html

I did. Especially to the message
.

I am just a newbie, so I shall not risk myself to interpret the DFSG,
but, if not being compilable with free tools is a DFSG failure, then,
according to the policy section 2.2.2:
>> Every package in contrib must comply with the DFSG.
then, with no possible ambiguity, such tools should not go to contrib,
but to non-free.

Anyway, this is just pure curiosity, and I have time to discover that,
as I am not facing this exact problem with any package, but a slightly
different one: should I strip non-recompilable binaries only from the
binary package or from the original tarball?

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Le vendredi 13 août 2010, Lars Wirzenius a écrit :
> On to, 2010-08-12 at 20:31 +0200, Tanguy Ortolo wrote:
>> Non-free? According to the DFSG, are not they free? I cannot see any
>> point of the DFSG that such a program, distributed both in source and
>> compiled form, with a free license, compilable only with non-free tools,
>> would infringe.
> 
> There's at least two requirements for software included in Debian main:
> 
> a) the license must be free according to the DFSG
> b) all binaries in main must be built only from sources in main, using
> only tools in main

I do agree. This is from the policy.

> To me, it sounds like you need to put your package into contrib,
> including its binary packages, until you can convince upstream to fix
> things so that they do not require non-free tools to build, or you
> convince the upstreams of the non-free tools to free their software.

I should rather strip the problematic file from the package, as it is
only a minor component, that one can very well live without, and that is
easy to install by other means.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Le jeudi 12 août 2010, Ian Jackson a écrit :
> I'd much rather you could just write in your .dsc a set of glob
> patterns for files to remove, somehow, which dpkg-source would remove
> when you unpacked it (unless you told it not to).

Is there a better way to achieve that than amnually editing the .dsc
file after each package build? By the way, I did not find the
documentation for the .dsc format, neither in the policy, nor in the
reference, nor in dpkg-source(1)…

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Tanguy Ortolo  writes:

> Is there a better way to achieve that than amnually editing the .dsc
> file after each package build? By the way, I did not find the
> documentation for the .dsc format, neither in the policy, nor in the
> reference, nor in dpkg-source(1)…

Policy 5.4.

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles

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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Russ Allbery wrote:
> Tanguy Ortolo  writes:
>> I did not find the documentation for the .dsc format, neither in the
>> policy, nor in the reference, nor in dpkg-source(1)…
> 
> Policy 5.4.
> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-debiansourcecontrolfiles

Thank you, I wonder how I could miss it.

Ian Jackson wrote:
>> I'd much rather you could just write in your .dsc a set of glob
>> patterns for files to remove, somehow, which dpkg-source would remove
>> when you unpacked it (unless you told it not to).

Well, I see no .dsc field that would allow such a thing. dpkg-source has
the options to ignore files when building a source package, but this is
the closest match I found, but I have only used it for a couple of
months, not developped it. :-)

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Tanguy Ortolo  writes:

> Ian Jackson wrote:
>>> I'd much rather you could just write in your .dsc a set of glob
>>> patterns for files to remove, somehow, which dpkg-source would remove
>>> when you unpacked it (unless you told it not to).

> Well, I see no .dsc field that would allow such a thing. dpkg-source has
> the options to ignore files when building a source package, but this is
> the closest match I found, but I have only used it for a couple of
> months, not developped it. :-)

I think Ian was saying that he'd like dpkg-source to add that feature, not
that it already existsed today and was something you could use.

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

Re: Notes from the DebConf Source Format BoF

[Russ Allbery]

Stefano Zacchiroli  writes:

> Thanks for this very detailed notes!  Can you please also upload them as
> attachment to the Penta event at
> http://penta.debconf.org/dc10_schedule/events/691.en.html ?

I've uploaded the notes as an attachment to the scheduled event inside
Penta.  They don't currently appear on that page, so I believe something
else (possibly just an automated rebuild) is required to get them to
appear on the public page, but they should now be in the system.  (I've
also done the same for all of my other events.)

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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

I would like to narrow the discussion to my specific problem, as I have
to make a decision to solve it.

The dokuwiki upstream tarball contains a Flash applet, in both source
and binary form. Only a proprietary tool can generate the binary from
the source. This applet is only a minor component, that can be stripped
without impacting the overall functionnality of the software.

Rather than keeping that file, moving dokuwiki to contrib, I would
rather strip it, document that, and explain how to install it manually
if needed. My question is: should I strip it from the original tarball,
repacking it, or only from the binary package? Technically, I prefer the
latter solution.

I think that this solution, stripping it only from the binary package,
is acceptable according to the Debian Policy. Here are the arguments I
identified agains that:
1. Policy §2.2.1 requires every package in main to compy with the DFSG,
   and DFSG §3 requires to allow the recipient to modify and rebuild.
2. Policy §2.2.1 forbids any package in main to require a package
   outside of main for compilation or execution.
Let me detail these arguments, and why I think they do not apply.

1. DFSG §3 is written as follows:
> The license must allow modifications and derived works, and must allow
> them to be distributed under the same terms as the license of the
> original software.
Well, first, this point does not require a free toolchain, as it does
not include a proposition such as: “by using only software that follow
these Guidelines”. Plus, it only speaks of the license, not about facts
outside of the licence that could forbid the compilation or the
execution, like: the user does not have a computer, does not have the
compiler, has an incompatible processor, etc. And here, the licence of
that Flash applet does allow modifications.

2. Policy §2.2.1 is about packages. A source package containing some
non-compilable-with-software-in-main code, but which rules do not make
use of that code, neither by compiling it, nor by copying it to the
binary package (that is, rules that /strip/ that code) needs, no package
outside of main for compilation or execution.

As I said, I am not very experienced with the DFSG and the Policy, so I
may be wrong, and I may miss some arguments. I told that I would not
risk myself to try and interpret these fundamental texts: in fact, I did
so, and I think it may be a good exercice. I just have a problem to
solve, and I wish to avoid an original tarball repacking if I can.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Peter Samuelson]

[Tanguy Ortolo]
> 2. Policy §2.2.1 is about packages. A source package containing some
> non-compilable-with-software-in-main code, but which rules do not make
> use of that code, neither by compiling it, nor by copying it to the
> binary package (that is, rules that /strip/ that code) needs, no package
> outside of main for compilation or execution.

I am inclined to agree with you.  This in fact reminds me of the issue
Steve Langasek brought up two years ago:

http://lists.debian.org/debian-project/2008/07/msg00017.html

wherein he complains that the ftpmasters were requiring him to document
licenses for things not shipped in binary packages, in the copyright
file.

I agreed with Steve at the time, that files not shipped in a .deb need
not be documented in /usr/share/doc/foo/copyright shipped in the .deb;
and I agree with you now, that files not shipped in a .deb need not be
subject to our rule about self-hosted building.  Of course they are
still subject to the DFSG.

As a service to the user, of course it's still helpful to document in
the source package why you aren't building or shipping the .swf file.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Matthew Johnson]

On Thu Aug 12 11:51, Russ Allbery wrote:
> > No.  There is no sensible way to do this.  The problem is inherent:
> > the binary packages in main have to be rebuildable using the source
> > package (and supporting binary packages eg compilers) in main.
> 
> > If you have this situation you have to have two separate source
> > packages; one in main which builds only the free parts, and one in
> > non-free which builds only the non-free parts.
> 
> I don't believe this is correct.  Source packages in main can build
> binaries in contrib, and I believe the problem with not being able to
> rebuild with free tools is more of a contrib thing than a non-free thing.
> 
> But I'm not certain, which is why I was hesitating to reply to the first
> message.

I think the difference here is between components which require
non-(free/debian) components to build and non-(free/debian) components to run.
It seems consistent, at least, that if you can build with only free tools then
the source package can be in main. If you can run with only free tools then the
binary package can be in main (although, of course, if you can build with
non-free tools but run with free tools, you still have to be in contrib).

If, as is the case here, the building can't be done in main, then it has to be
in contrib.

Matt


signature.asc
Description: Digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Felipe Sateler]

On 12/08/10 16:21, Russ Allbery wrote:
> Tanguy Ortolo  writes:
> 
>> Ian Jackson wrote:
 I'd much rather you could just write in your .dsc a set of glob
 patterns for files to remove, somehow, which dpkg-source would remove
 when you unpacked it (unless you told it not to).
> 
>> Well, I see no .dsc field that would allow such a thing. dpkg-source has
>> the options to ignore files when building a source package, but this is
>> the closest match I found, but I have only used it for a couple of
>> months, not developped it. :-)
> 
> I think Ian was saying that he'd like dpkg-source to add that feature, not
> that it already existsed today and was something you could use.

CDBS currently has get-orig-source rule which does that. You just define
a variable with a space separated list of globs and it excludes them
when fetching the source from the web.

-- 
Saludos,
Felipe Sateler



signature.asc
Description: OpenPGP digital signature

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Don Armstrong]

On Thu, 12 Aug 2010, Peter Samuelson wrote:
> [Tanguy Ortolo]
> > 2. Policy §2.2.1 is about packages. A source package containing some
> > non-compilable-with-software-in-main code, but which rules do not make
> > use of that code, neither by compiling it, nor by copying it to the
> > binary package (that is, rules that /strip/ that code) needs, no package
> > outside of main for compilation or execution.
> 
> I agreed with Steve at the time, that files not shipped in a .deb
> need not be documented in /usr/share/doc/foo/copyright shipped in
> the .deb; and I agree with you now, that files not shipped in a .deb
> need not be subject to our rule about self-hosted building. Of
> course they are still subject to the DFSG.

My understanding is that for those (programmatic?) works, source code
must be provided, and we certainly shouldn't be shipping them in the
binary part of the distribution if we cannot build them from that
source.

Assuming the source is present, we should just blow them away in the
clean rule to be sure that they aren't shipped by accident. If the
source isn't provided, we have to either provide it, or not ship it in
the source package.

Personally, I view that including things that don't get shipped or
used in an upstream source package is a minor bug that should be fixed
upstream. [With possible increase in severity if the useless bits are
large.]


Don Armstrong

-- 
More than any other time in history, mankind faces a crossroads.
One path leads to despair and utter hopelessness.
The other, to total extinction.
Let us pray we have the wisdom to choose correctly.
 -- Woody Allen

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
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/20100813000145.gx31...@rzlab.ucr.edu

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Felipe Sateler  writes:
> On 12/08/10 16:21, Russ Allbery wrote:
>> Tanguy Ortolo  writes:
>>> Ian Jackson wrote:

> I'd much rather you could just write in your .dsc a set of glob
> patterns for files to remove, somehow, which dpkg-source would
> remove when you unpacked it (unless you told it not to).

>>> Well, I see no .dsc field that would allow such a thing. dpkg-source
>>> has the options to ignore files when building a source package, but
>>> this is the closest match I found, but I have only used it for a
>>> couple of months, not developped it. :-)

>> I think Ian was saying that he'd like dpkg-source to add that feature,
>> not that it already existsed today and was something you could use.

> CDBS currently has get-orig-source rule which does that. You just define
> a variable with a space separated list of globs and it excludes them
> when fetching the source from the web.

I believe that's implemented by repacking the upstream source to omit
those files from the *.orig.tar.gz, which is exactly what Ian doesn't want
people to have to do.

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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Russ Allbery]

Peter Samuelson  writes:

> I agreed with Steve at the time, that files not shipped in a .deb need
> not be documented in /usr/share/doc/foo/copyright shipped in the .deb;

I don't think anyone disagrees with this, including the ftp-masters.  The
question is whether the source package also needs a copyright file of its
own.

In other words, if you created both debian/copyright and
debian/binary-package.copyright, where the latter contains only
information about what's in the binary package and is installed in that
binary package, I highly doubt ftp-master will complain.  However, they
currently still rely on debian/copyright documenting the entire source
package for the purposes of license review.

I think we need a broader discussion following the Policy process to work
out and reach consensus on exactly what copyright documentation we, as a
project, want to require in our packages, both source and binary.  We keep
having one-off, ad-hoc discussions without all the involved parties
participating, which is a large part of why we don't reach consensus.

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

Work-needing packages report for Aug 13, 2010

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 587 (new: 5)
Total number of packages offered up for adoption: 139 (new: 0)
Total number of packages requested help for: 68 (new: 2)

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



The following packages have been orphaned:

   deborphan (#592071), orphaned 5 days ago
 Description: program that can find unused packages, e.g. libraries
 Reverse Depends: gtkorphan upgrade-system
 Installations reported by Popcon: 19804

   ktranslator (#592296), orphaned 3 days ago
 Description: translate words from one language to another
 Installations reported by Popcon: 202

   lilo (#592200), orphaned 4 days ago
 Description: LInux LOader - The Classic OS loader can load Linux and
   others
 Installations reported by Popcon: 2507

   mol (#592034), orphaned 5 days ago
 Description: Mac-on-Linux emulator
 Reverse Depends: mol-drivers-linux mol-drivers-macos
   mol-drivers-macosx mol-modules-source
 Installations reported by Popcon: 24

   tcsh (#592093), orphaned 5 days ago
 Description: TENEX C Shell, an enhanced version of Berkeley csh
 Reverse Depends: afbackup afbackup-client fsl-4.1 gridengine-exec
   jemboss radiance tau-racy
 Installations reported by Popcon: 27677

582 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 139 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

[NEW] bastille (#592137), requested 5 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 445

[NEW] mol (#592034), requested 5 days ago
 Description: Mac-on-Linux emulator
 Reverse Depends: mol-drivers-linux mol-drivers-macos
   mol-drivers-macosx mol-modules-source
 Installations reported by Popcon: 24

   apt-cross (#540341), requested 370 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-crush
   mlton-target-alpha-linux-gnu mlton-target-arm-linux-gnueabi
   mlton-target-hppa-linux-gnu mlton-target-i486-linux-gnu
   mlton-target-ia64-linux-gnu mlton-target-mips-linux-gnu
   mlton-target-mipsel-linux-gnu mlton-target-powerpc-linux-gnu (3 more
   omitted)
 Installations reported by Popcon: 332

   apt-xapian-index (#567955), requested 192 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: adept ept-cache fuss-launcher packagesearch
 Installations reported by Popcon: 12515

   ara (#450876), requested 1005 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 102

   asymptote (#517342), requested 531 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1270

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

   boinc (#511243), requested 581 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1509

   chromium-browser (#583826), requested 74 days ago
 Description: Chromium browser
 Reverse Depends: chromium-browser chromium-browser-dbg
   chromium-browser-l10n gecko-mediaplayer sun-java6-plugin
 Installations reported by Popcon: 1697

   cobbler (#590044), requested 20 days ago
 Description: Install server

   cvs (#354176), requested 1631 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsps cvsservice (10
   more omitted)
 Installations reported by Popcon: 22312

   dctrl-tools (#448284), requested 1020 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts javahelper libsbuild-perl linux-patch-debianlogo
   simple-cdd ubuntu-dev-tools
 Installations reported by Popcon: 12497

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

   di

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Felipe Sateler]

On 12/08/10 20:18, Russ Allbery wrote:
> Felipe Sateler  writes:
>> On 12/08/10 16:21, Russ Allbery wrote:
>>> Tanguy Ortolo  writes:
 Ian Jackson wrote:
> 
>> I'd much rather you could just write in your .dsc a set of glob
>> patterns for files to remove, somehow, which dpkg-source would
>> remove when you unpacked it (unless you told it not to).
> 
 Well, I see no .dsc field that would allow such a thing. dpkg-source
 has the options to ignore files when building a source package, but
 this is the closest match I found, but I have only used it for a
 couple of months, not developped it. :-)
> 
>>> I think Ian was saying that he'd like dpkg-source to add that feature,
>>> not that it already existsed today and was something you could use.
> 
>> CDBS currently has get-orig-source rule which does that. You just define
>> a variable with a space separated list of globs and it excludes them
>> when fetching the source from the web.
> 
> I believe that's implemented by repacking the upstream source to omit
> those files from the *.orig.tar.gz, which is exactly what Ian doesn't want
> people to have to do.

As I understood it, Ian doesn't want people to waste time on it. Filling
a glob on the .dsc is the same work as putting the same glob in
debian/rules. While it is a bit more cumbersome to override than his
proposed method, it can still be easily done.


-- 
Saludos,
Felipe Sateler



signature.asc
Description: OpenPGP digital signature

Bug#592819: ITP: librivescript-perl -- Simple trigger/response language primarily used for the creation of chatting robots

[Onur Aslan]

Package: wnpp
Severity: wishlist
Owner: Onur Aslan 

* Package name: librivescript-perl
  Version : 1.20
  Upstream Author : Noah Petherbridge 
* URL : http://search.cpan.org/~kirsle/RiveScript-1.20/
* License : GPL2
  Programming Lang: Perl
  Description : Simple trigger/response language primarily used for the 
creation of chatting robots

RiveScript - Rendering Intelligence Very Easily
RiveScript is a simple trigger/response language primarily used for
the creation of chatting robots. It's designed to have an easy-to-learn
syntax but provide a lot of power and flexibility.



-- 
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/20100813012034.6019.94061.report...@localhost

Re: QEMU HPPA image

[Paul Wise]

On Fri, Aug 13, 2010 at 1:06 AM, Aurelien Jarno  wrote:

> QEMU doesn't emulate HPPA, that's why you can't find such an image.

Looks like there is/was work in progress to do so though:

http://hppaqemu.sourceforge.net/
http://sourceforge.net/projects/hppaqemu/
http://repo.or.cz/w/qemu/hppa.git

Seems like it needs folk to clean it up and get it merged though.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RFH: How to compile swf files from source

[Paul Wise]

On Thu, Aug 5, 2010 at 8:15 PM, Paul Wise  wrote:

> [Stuff about .FLA files]

As a follow-up, Martin Owens has written some code to extract FLA files:

http://doctormo.org/2010/08/06/fla-extract/
http://doctormo.org/2010/08/04/flash-sources/

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

Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)

[Tanguy Ortolo]

Le jeudi 12 août 2010, Russ Allbery a écrit :
> I don't think anyone disagrees with this, including the ftp-masters.  The
> question is whether the source package also needs a copyright file of its
> own.

As we are distributing these files, it seems reasonable to document their
licence. But the Policy is not clear about that requirement.


Now, about compilation issue, for me, compiling a package means applying
whatever rule is needed to produce the target binary package. In the
case of a non-recompilable binary that gets stripped during this
process, the “compilation” we apply to is is a deletion, that is done
using tools from main.

The problematic binary being only in the source package, I do not think
it is relevant to oppose that “I cannot build the original tarball from
source using free tools”, because the original tarball is not meant to
be built from source, as it is the source.


As I saw no opponent to such a solution, then I shall simply keep the
binary Flash file and its source code on the original tarball, and strip
them at build time. Let me see what happens next.

-- 
Tanguy Ortolo


signature.asc
Description: Digital signature

Re: Notes from the DebConf Source Format BoF

[Josef Spillner]

Am Donnerstag, 12. August 2010, 16:36:56 schrieb Ian Jackson:
> This is easy: you just publish two trees, rather than two branches in
> the same tree.  (It's a shame that there isn't a syntax for "git
> clone" which checks out a particular branch.)

The --branch option to git-clone is going to celebrate its birthday in about 
two weeks.
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=7a4ee28f41270bf032d0dd0bfb17f601b9b3971a

Josef


-- 
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/201008130839.35861.2...@kuarepoti-dju.net