Re: mass bug filing about packages manipulating/deleting shipped files

[Thomas Goirand]

On 09/20/2012 12:25 AM, Philipp Kern wrote:

I've never seen somebody starting to use "conffile" when he really meant
"configuration file".

I've never seen it either.

But I've seen many instances of the following:
- A knowledgeable DD write about "conffiles"
- a newbie writing "yes but my configuration files"
- Then the DD writing "I really meant conffiles, not configuration file"

As Jakub wrote: search for "conffiles" in the -mentors list, and I guess 
you'll see.


So this *is* a confusing word which I don't like.

Thomas


--
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/505c1eeb.6090...@debian.org

conffiles

[Ivan Shmakov]

> Thomas Goirand  writes:

[…]

 > BTW, "conffiles" is a pretty bad name.  It's confusing, as you can
 > see once more.

 > I thought about calling it "dpkg-conffiles" which has the advantage
 > of underlying that we leave the handling of the file to the
 > responsibility of dpkg, keeps the same old "conffiles" name.  But
 > people will continue to use the older short version of it, so...

 > Anyone with a better idea?

umdekfiles, perhaps?  (For “User modifies, dpkg keeps [the
changes.]”)  At the very least, I don't think anyone with half
the sane mind will confuse them with “configuration files.”

-- 
FSF associate member #7257


-- 
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/86zk4j237k.fsf...@gray.siamics.net

Re: packages with E: md5sum-mismatch in the archive

[Andreas Beckmann]

On 2012-09-20 19:20, Jakub Wilk wrote:
> A binNMU would just paper over the actual bug. guile-1.6 debian/rules
> has this:
> 
> dh_md5sums
> sed -i "/dependency_libs/ s/'.*'/''/" `find $(CURDIR)/debian/ -name
> '*.la'`
> dh_builddeb

Thanks for looking into the source. I skipped this after my rebuild had
no errors, but perhaps the toolchain has changed inbetween to produce
empty dependency_libs, so the sed becomes a no-op.

Two bugs filed:

http://bugs.debian.org/688288
guile-1.6: modifies *.la after calling dh_md5sums, resulting in
md5sum-mismatch lintian error

http://bugs.debian.org/688300
ftp.debian.org: please reject packages with md5sum-mismatch lintian error


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/505c302c.9070...@abeckmann.de

Re: Conflict usr/bin/ninja vs usr/sbin/ninja ?

[Adam Borowski]

On Wed, Sep 19, 2012 at 11:41:05AM +0200, Mathieu Malaterre wrote:
>   I just sponsored the ninja-build package. I realize now that I may
> have missed one point: does it need to conflict with package ninja ?
> ninja-build will provide usr/bin/ninja, while ninja provides
> usr/sbin/ninja.
> 
>   The policy requires a Conflicts only when two packages provide the
> same file [1]. It is implicitly assumed that file means full path to
> file IMHO. However for filename in PATH, this might be an issue.

While, as Arno mentioned, you are not allowed to use that name, this is
a case where it would be good to ask the maintainer of "ninja" the root
process logger to migrate his executable to something else.

As a "make" replacement, "ninja"[-build] is something one runs from the
command line tens or hundreds of times a day.  The other ninja is a daemon
that's never run interactively, and its executable is referenced only from
an init script.

One such case in the past was "git" vs "gnuit" -- and there, the other tool
is something interactive, with 1367 popcon score.  "ninja" has mere 39
installs.


-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

Re: mass bug filing about packages manipulating/deleting shipped files

[Andreas Beckmann]

On 2012-09-18 09:53, Andreas Beckmann wrote:
>> mirror_2.9-62
>>   /usr/share/doc/mirror/mirror.txt.gz
>>   /usr/share/doc/mirror/html/mirror-ref.html
>>   /usr/share/mirror/mirror.pl
>>   /usr/share/mirror/dateconv.pl
>>   /usr/share/mirror/lchat.pl
>>   /usr/share/mirror/lsparse.pl
>>   /usr/share/mirror/ftp.pl
>>   /usr/bin/do_unlinks
>>   /usr/bin/mirror-master
>>   /usr/bin/pkgs_to_mmin

The mirror package applies some patches during postinst to conform with
the license.

Wouldn't it be better to ship the "source" in /usr/share/mirror/source/,
copy these to /var/lib/mirror/ during postinst and apply the patch there
and ship symlinks to /var/lib/mirror/* in /usr/bin, /usr/share/mirror?


> fsl_4.1.9-6
>   /usr/share/fsl/4.1/tcl/tclIndex

smlnj-runtime_110.74-1
  /usr/lib/smlnj/lib/pathconfig

swi-prolog-nox_5.10.4-3
 /usr/lib/swi-prolog/library/INDEX.pl

xine-ui_0.99.7-1
  /var/lib/xine/xine.desktop


These seem to be some state/registry/... files that are updated during
postinst.


What should we do with these? Unfortunately I didn't find a policy
reference that forbids this ...


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/505c5dfa.9060...@abeckmann.de

Re: mass bug filing about packages with empty /usr/share/doc/$package/ (no copyright file)?

[Andreas Beckmann]

On 2012-09-16 18:36, Bart Martens wrote:
>> I'm offering help, but only for part of the work : I could write a perl 
>> script
>> that periodically scans the logfiles and submits additional bugs.
> 
> I have written that script, and I think it's ready for use.

Thanks a lot for filing these bugs! Would you mind sharing the script?
Perhaps we could reuse it for future piuparts MBFs.

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/505c5f1c.8070...@abeckmann.de

Re: mass bug filing about packages manipulating/deleting shipped files

[Jakub Wilk]

* Andreas Beckmann , 2012-09-21, 14:30:

mirror_2.9-62
  /usr/share/doc/mirror/mirror.txt.gz
  /usr/share/doc/mirror/html/mirror-ref.html
  /usr/share/mirror/mirror.pl
  /usr/share/mirror/dateconv.pl
  /usr/share/mirror/lchat.pl
  /usr/share/mirror/lsparse.pl
  /usr/share/mirror/ftp.pl
  /usr/bin/do_unlinks
  /usr/bin/mirror-master
  /usr/bin/pkgs_to_mmin


The mirror package applies some patches during postinst to conform with 
the license.


Really? I didn't read the license, but either it's not neccessary, or 
it's a DFSG§4 violation: “The license must explicitly permit 
distribution of software built from modified source code.”


--
Jakub Wilk


--
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/20120921125714.ga...@jwilk.net

Re: Comments on Mate DE

[Thomas Goirand]

On 09/20/2012 01:58 AM, superuserlaptop wrote:

This to me is a form of sabotage.

It turns out that "superuserlaptop" is using a Squeeze system,
half upgraded, with a MATE Wheezy unofficial repository, both
Stable, Wheezy and SID repositories in his sources.list but
without doing a dist-upgrade, which obviously can't work.

So, no sabotage here from Debian, only a user that doesn't
know how to use Debian and its stable/testing/sid flavors
properly.

Thomas


--
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/505c6843.4030...@debian.org

Re: Comments on Mate DE

[Jon Dowland]

That's not really of any interest to -devel, and I guess you're quoting
info from private mail here. Please let's keep this list useful.


-- 
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/20120921144100.GC1374@debian

Re: Debian Policy 3.9.4.0 released

[Ian Jackson]

Joey Hess writes ("Re: Debian Policy 3.9.4.0 released"):
> That would include large numbers of haskell libraries and binaries that
> statically link other haskell libraries. Even though most such
> libraries actually have no source license requirements.

The requirement to ship the source for the binaries we ship is not
something we do (only) for licensing reasons.  It is something we do
because it's necessary if our output is to be Free.

If the corresponding versions of the libraries have been deleted from
the archive then the user will not be able to fix bugs or whatever and
rebuild their binaries, without upgrading to new libraries too.

> For that matter, don't all executables statically link to small portions
> of libgcc and libc? It seems beyond redundant to require that be listed
> every time.

This is a bit different I think, mainly because these bits of libgcc
are very small.

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

Re: node-like file conflicts

[Jakub Wilk]

* Jakub Wilk , 2012-08-06, 15:37:

The following package pairs:
1) are co-installable,
2) both ship binaries with the same name, but in different 
directories within $PATH (e.g. one in /usr/bin, another in 
/usr/sbin):


There's a few more if you take alternatives into account:

boom: alliance prboom
lft: lft traceroute
tf: tf tf5
vi: elvis-tiny vim (+ a bunch of other vi clones)

(The format is: ":  
".)


--
Jakub Wilk


--
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/20120921154242.ga...@jwilk.net

Re: mass bug filing about packages manipulating/deleting shipped files

[Russ Allbery]

Jakub Wilk  writes:

> Really? I didn't read the license, but either it's not neccessary, or
> it's a DFSG§4 violation: “The license must explicitly permit
> distribution of software built from modified source code.”

I'm not sure why mirror is still doing this, given the correspondence
recorded in the mirror copyright file which says that patching in the
Debian *.diff.gz file is perfectly fine.

The license is not particularly well-written, but given the clarifying
correspondence, the intent appears to be to allow distributing of the
pristine source plus patch files.

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

Re: node-like file conflicts

[Russ Allbery]

Jakub Wilk  writes:

> There's a few more if you take alternatives into account:

> tf: tf tf5

(Speaking with my tf5 maintainer hat on.)  The current arrangement of
these packages is weird, but I'm not sure how much trouble it's causing.
tf ships /usr/games/tf and tf5 ships /usr/bin/tf5.  Both of them manage
the /usr/bin/tf alternative.  So you do get different things depending on
whether you have /usr/games before /usr/bin in your path.

My preference would be to retire the /usr/games path entirely and have tf
install itself as /usr/bin/tf4, but I'm not responsible for the tf
package.  (TinyFugue is no more a "game" than irssi is.  I use it all the
time to connect to work chatservers that we use instead of IRC.)

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

assumptions about the build environment.

[peter green]

While working on debian one thing I have not managed to find is 
documentation on what packages can and can't assume about the build 
environment. Does such documentation exist and if not should it be created.


Some specific cases i'm wondering about:

I just discovered that on my beagleboard XM (under armhf sid) nacl 
(which previously build on a debian experimental armhf buildd but not a 
debian unstable armhf buildd) will build if /sys is mounted but will not 
build if it is not mounted. Can packages assume that /sys will be 
mounted in the build environment or not?


IIRC it is generally established that packages are not allowed to rely 
on an internet connection during build but if one is present are they 
allowed to assume it's non-broken. I recently came accross a package ( 
sslh ) which fails to build in the presense of nxdomain hijacking. Is 
that a bug?


Some time ago I found that a package (I think it was openjdk but I don't 
remember for sure) which relied on uname -r such that linux32 had to be 
used to build it in an i386 chroot on an amd64. However since then I'm 
pretty sure i've seen similar cases with other packages on other 
architectures being treated as bugs.




--
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/505cbf60.5020...@p10link.net

Re: assumptions about the build environment.

[peter green]

peter green wrote:
Some time ago I found that a package (I think it was openjdk but I 
don't remember for sure) which relied on uname -r

sorry I meam -m not -r


--
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/505cc36b.6010...@p10link.net

Re: assumptions about the build environment.

[Ben Hutchings]

On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> While working on debian one thing I have not managed to find is
> documentation on what packages can and can't assume about the build
> environment. Does such documentation exist and if not should it be
> created.
> 
> Some specific cases i'm wondering about:
> 
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume that
> /sys will be mounted in the build environment or not?
 
I consider /sys almost as essential as /proc.  However I wonder
what a build process would need it for.

> IIRC it is generally established that packages are not allowed to
> rely on an internet connection during build but if one is present
> are they allowed to assume it's non-broken.

No, because a 'non-broken' connection would include some particular
hosts being available and there is no way an auto-builder can ensure
that is true.

> I recently came accross
> a package ( sslh ) which fails to build in the presense of nxdomain
> hijacking. Is that a bug?

Yes.

> Some time ago I found that a package (I think it was openjdk but I
> don't remember for sure) which relied on uname -r such that linux32
> had to be used to build it in an i386 chroot on an amd64. However
> since then I'm pretty sure i've seen similar cases with other
> packages on other architectures being treated as bugs.
 
I think confusion between kernel vs userland architecture is so
widespread that we should consider this a necessary part of doing a
native build.

(It should preferably be fixed upstream, to benefit users who build
from either Debian or upstream source on a 32/64 environment.  But I
don't know a simple way to find the 'primary userland architecture'
that is not distribution-specific.)

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20120921200757.gf29...@decadent.org.uk

Re: assumptions about the build environment.

[Adam Borowski]

On Fri, Sep 21, 2012 at 09:07:57PM +0100, Ben Hutchings wrote:
> On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > Some time ago I found that a package (I think it was openjdk but I
> > don't remember for sure) which relied on uname -r such that linux32
> > had to be used to build it in an i386 chroot on an amd64. However
> > since then I'm pretty sure i've seen similar cases with other
> > packages on other architectures being treated as bugs.
>  
> I think confusion between kernel vs userland architecture is so
> widespread that we should consider this a necessary part of doing a
> native build.

Please, don't.  This breaks cross building.  Any use of uname during build
other than for logging purposes is a bug.
 
> (It should preferably be fixed upstream, to benefit users who build
> from either Debian or upstream source on a 32/64 environment.  But I
> don't know a simple way to find the 'primary userland architecture'
> that is not distribution-specific.)

There's more than just 32/64.

Try this: amd64 kernel, i386 host (and compiler), armel chroot, multiarch
with armhf.  What should uname report?

And this is not even an artificial example: you can't really buy a real i386
machine anymore, yet most semi-proprietary (maemo, android) SDKs ship only
i386 binaries, if you want to develop a Debian guest you'd better use armhf
instead of armel, and semi-emulated scratchbox style builds can take 44
seconds compared to 8 hours native[1].

I don't do android so never went 4-way, but played with wine on armhf
earlier this very week... thanks to how wine is set up in wheezy, that's
3-way.  The result of uname wouldn't be too meaningful.

In a multiarch world, you can't speak of "environment" for more than a
single executable[2].

One of portable ways to check your target platform is:
$CC -dumpmachine
(assuming a typical build scheme).



[1]. A not so new amd64 box with make -j6 vs armel -j1, on C++ code that
caused a swappeathon on the latter.

[2]. And even that only because ELF doesn't support fat binaries.

-- 
Copyright and patents were never about promoting culture and innovations;
from the very start they were legalized bribes to give the king some income
and to let businesses get rid of competition.  For some history, please read
https://en.wikipedia.org/wiki/Statute_of_Monopolies_1623


signature.asc
Description: Digital signature

Re: assumptions about the build environment.

[Roger Leigh]

On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume that
> /sys will be mounted in the build environment or not?

By default, you get /proc, /dev/pts and /sys mounted.  Unless the
buildd admin specifically configured they system differently than
the defaults (/etc/schroot/buildd/fstab).

> IIRC it is generally established that packages are not allowed to
> rely on an internet connection during build but if one is present
> are they allowed to assume it's non-broken. I recently came accross
> a package ( sslh ) which fails to build in the presense of nxdomain
> hijacking. Is that a bug?

You are not supposed to rely on any network connectivity during a
package build.  If it's present, that's just happenstance; it's
not guaranteed to be present and/or functional, and you should not
be using it under any circumstances.  Local loopback is OK though
for e.g. unit testing services.

Just for the record, I'm planning on adding support for
unshare(CLONE_NEWNET) in schroot post wheezy.  This will allow
the buildd (sbuild) to request that networking be explicitly
turned off (bar localhost) during a package build.  This will
break any buggy packages which are relying on networking during
a build.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120921211314.gb18...@codelibre.net

Bug#688352: ITP: libhttp-cookiemonster-perl -- module for easy read/write access to HTTP::Cookies jar

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libhttp-cookiemonster-perl
  Version : 0.4
  Upstream Author : Olaf Alders 
* URL : http://search.cpan.org/dist/HTTP-CookieMonster/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for easy read/write access to HTTP::Cookies jar

HTTP::CookieMonster was created because messing around with HTTP::Cookies is
non-trivial. HTTP::Cookies a very useful module, but using it is not always
as easy and clean as it could be. HTTP::CookieMonster gives you a simple
interface for getting and setting cookies.

Warning: this is BETA code which is still subject to change.


-- 
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/20120921215454.ga1...@jadzia.comodo.priv.at

Re: mass bug filing about packages with empty /usr/share/doc/$package/ (no copyright file)?

[Bart Martens]

On Fri, Sep 21, 2012 at 02:35:40PM +0200, Andreas Beckmann wrote:
> On 2012-09-16 18:36, Bart Martens wrote:
> >> I'm offering help, but only for part of the work : I could write a perl 
> >> script
> >> that periodically scans the logfiles and submits additional bugs.
> > 
> > I have written that script, and I think it's ready for use.
> 
> Thanks a lot for filing these bugs!

My pleasure.

> Would you mind sharing the script?

Yes of course.  It's on quantz in /home/bartm/src/misscopyfile and it's GPL.

> Perhaps we could reuse it for future piuparts MBFs.

Sure why not.

Regards,

Bart Martens


-- 
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/20120921221300.ga9...@master.debian.org

Re: assumptions about the build environment.

[Kurt Roeckx]

On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> While working on debian one thing I have not managed to find is
> documentation on what packages can and can't assume about the build
> environment. Does such documentation exist and if not should it be
> created.

One thing that is at least documented in policy is that the only
packages that it can rely on being installed are essential,
build-essential and the packages's build-depends.

> Some specific cases i'm wondering about:
> 
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume that
> /sys will be mounted in the build environment or not?

As far as I know, on all the buildds /sys, /proc, /dev/pts and
/dev/shm are available and we get complaints if some of them
aren't there.  At least /proc and /dev/pts will frequently results
in errors, I think there are also at least some packages that
require /dev/shm/.  I don't remember anything about /sys.

I think it would also be a good idea to have this documented in
policy if it's not already.

> IIRC it is generally established that packages are not allowed to
> rely on an internet connection during build but if one is present
> are they allowed to assume it's non-broken. I recently came accross
> a package ( sslh ) which fails to build in the presense of nxdomain
> hijacking. Is that a bug?

It basicly comes down to if they try to download something as
source to be build.  In that case it's clearly a violation of
policy because the source is not in the archive.  Some packages
then fall back to the source file that's in the package, but
they should have always used that in the first place.

I know there are also some packages that have a test suite that
connects to something on the internet.  This doesn't result in
changes to the binaries, it just checks that it works properly.
You can argue wheter that should be allowed or not, or that the test
server should run on localhost.  In any case packages doing that
shouldn't fail to build because of that and should just skip that
test in case the network is down.

> Some time ago I found that a package (I think it was openjdk but I
> don't remember for sure) which relied on uname -r such that linux32
> had to be used to build it in an i386 chroot on an amd64. However
> since then I'm pretty sure i've seen similar cases with other
> packages on other architectures being treated as bugs.

They probably should try to use the output of dpkg-architecture to
select the arch.  Then should never check that output of uname -m.

On the buildds we work around this by using linux32 because there
were a lot of packages that were broken, and it was easier to work
around it.  Maybe we should stop doing that.


Kurt


-- 
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/20120921222336.ga31...@roeckx.be

Re: assumptions about the build environment.

[Bernhard R. Link]

* peter green  [120921 21:26]:
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume that
> /sys will be mounted in the build environment or not?

I'm quite suprised to see /sys to be mounted in chroots. Wasn't one
of the reasons to start /sys and not put the info there in /proc to
not have to have it available in chroots? Shouldn't that information
about hardware usually be kept away from chroots?

Bernhard R. Link


-- 
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/20120921232531.ga20...@client.brlink.eu

python-twitter is not maintained

[Koichi Akabe]

Hi,

I want to use python-twitter package [1], but this package is old and
it's not able to be used [2]. The current maintainer said he will
update it in the following days, but it has never updated for one and
a half years. I think he is not active now [3].

Can I take over this package?

[1] http://packages.debian.org/sid/python-twitter
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587749
[3] http://qa.debian.org/developer.php?login=ma...@cacavoladora.org

Regards,
-- 
Koichi Akabe
 vbkaisetsu at {gmail.com, debian.or.jp}


pgpwVL4nFwJ9w.pgp
Description: PGP signature

Bug#688362: ITP: glogic -- logic circuit simulator for students

[Koichi Akabe]

Package: wnpp
Severity: wishlist
Owner: Koichi Akabe 

* Package name: glogic
  Version : 2.4
  Upstream Author : Koichi Akabe 
* URL : https://launchpad.net/glogic
* License : GPL-3+
  Programming Lang: Python
  Description : logic circuit simulator for students

gLogic is a cross-platform logic circuit simulator. This program simulates
logic circuits containing basic components (e.g. NOR, AND, OR) and many
advanced components like flip-flop and creates a timing-chart.


-- 
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/20120922023727.18416.37037.reportbug@vbk27182818

Re: python-twitter is not maintained

[Charles Plessy]

Le Sat, Sep 22, 2012 at 10:38:06AM +0900, Koichi Akabe a écrit :
> 
> I want to use python-twitter package [1], but this package is old and
> it's not able to be used [2]. The current maintainer said he will
> update it in the following days, but it has never updated for one and
> a half years. I think he is not active now [3].
> 
> Can I take over this package?
> 
> [1] http://packages.debian.org/sid/python-twitter
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587749
> [3] http://qa.debian.org/developer.php?login=ma...@cacavoladora.org

Hi,

this is a team-maintained package, so the best place to ask is the team's
mailing list (debian-python in that case).

  http://wiki.debian.org/Teams/PythonModulesTeam/

Have a nice week-end,

-- 
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/20120922031616.gc8...@falafel.plessy.net

Bug#688363: Document assumptions about the build environment.

[Charles Plessy]

Package: debian-policy
Severity: whishlist
Version: 3.9.4.0
X-Debbugs-CC: debian-devel@lists.debian.org

Le Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx a écrit :
> 
> I think it would also be a good idea to have this documented in
> policy if it's not already.

I totally agree.  I created a bug (see the number in the title)
to track this suggestion.

Any volunteer ?

-- 
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/20120922032033.gd8...@falafel.plessy.net

Re: python-twitter is not maintained

[Koichi Akabe]

Hi, 

On Sat, 22 Sep 2012 12:16:16 +0900
Charles Plessy  wrote:

> this is a team-maintained package, so the best place to ask is the team's
> mailing list (debian-python in that case).
> 
>   http://wiki.debian.org/Teams/PythonModulesTeam/

Okay, I forwarded it to: 
http://lists.debian.org/debian-python/2012/09/msg00023.html
Thanks.

-- 
Koichi Akabe
 vbkaisetsu at {gmail.com, debian.or.jp}


-- 
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/20120922132355.d4c805fbae8351f9caab7...@gmail.com

Re: assumptions about the build environment.

[Ben Hutchings]

On Sat, 2012-09-22 at 01:25 +0200, Bernhard R. Link wrote:
> * peter green  [120921 21:26]:
> > I just discovered that on my beagleboard XM (under armhf sid) nacl
> > (which previously build on a debian experimental armhf buildd but
> > not a debian unstable armhf buildd) will build if /sys is mounted
> > but will not build if it is not mounted. Can packages assume that
> > /sys will be mounted in the build environment or not?
> 
> I'm quite suprised to see /sys to be mounted in chroots. Wasn't one
> of the reasons to start /sys and not put the info there in /proc to
> not have to have it available in chroots?

I've never heard that claimed.

> Shouldn't that information about hardware usually be kept away from
> chroots?

Chroots aren't containers.  A chrooted environment can use all CPUs and
all network devices, and programs may expect to find information about
them under sysfs.

If you're concerned about leaking sensitive information to untrusted
processes then procfs is a far, far bigger problem (somewhat mitigated
by hidepid or pid namespaces).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Re: assumptions about the build environment.

[Ben Hutchings]

On Fri, 2012-09-21 at 23:06 +0200, Adam Borowski wrote:
> On Fri, Sep 21, 2012 at 09:07:57PM +0100, Ben Hutchings wrote:
> > On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> > > Some time ago I found that a package (I think it was openjdk but I
> > > don't remember for sure) which relied on uname -r such that linux32
> > > had to be used to build it in an i386 chroot on an amd64. However
> > > since then I'm pretty sure i've seen similar cases with other
> > > packages on other architectures being treated as bugs.
> >  
> > I think confusion between kernel vs userland architecture is so
> > widespread that we should consider this a necessary part of doing a
> > native build.
> 
> Please, don't.  This breaks cross building.  Any use of uname during build
> other than for logging purposes is a bug.

Certainly build systems should support cross-building and should not
rely on uname -m.  And cross-building is useful for derivatives.

But since not all build systems do that, and Debian does not attempt to
cross-build its own packages, we should not compromise the reliability
of the native build environments.  An i386 chroot on an x86_64 kernel
should look as much like a plain i386 environment as possible.

[...]
> semi-emulated scratchbox style builds can take 44
> seconds compared to 8 hours native[1].
[...]

And scratchbox makes cross-build more reliable by presenting a native-
looking environment... e.g. by making uname report whatever you want:

http://scratchbox.org/documentation/user/scratchbox-1.0/html/installdoc.html#AEN707

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part

Bug#688367: ITP: erlang-bear -- set of statistics functions for erlang

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: erlang-bear
  Version : 0.1
  Upstream Author : Joe Williams 
* URL : https://github.com/boundary/bear.git
* License : Apache 2.0
  Programming Lang: erlang
  Description : Set of statistics functions for erlang

Currently bear is focused on use inside the Folsom Erlang metrics
library, but all of these functions are generic and useful in other
situations.


-- 
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/20120922053449.22926.48637.reportbug@chimagu