> 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 lik
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 th
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 tomorro
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
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 wi
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 du
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 t
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 co
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 compi
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
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
> pac
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? Acco
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? Accor
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 DF
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, compila
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
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.o
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 wond
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
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 current
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, tha
[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 p
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 h
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,
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 packag
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
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
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 request
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 wou
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 : Simpl
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
Se
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
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 Po
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 cele
34 matches
Mail list logo
