Advertise at debian.com - Paid text links

[Franck White]

Dear Webmaster,

My name is Franck and i'm gaming SEO manager

I would like to purchase text links to one or more of our gaming websites
from your great website

*https://www.debian.org/ *

Feel free to contact me back with any thought you have on mind...

Regards,

Franck White,
franckwhit...@gmail.com
ᐧ

Re: JavaScript usage

[Thorsten Glaser]

On Sun, 31 Aug 2014, Octavio Alvarez wrote:

> Why don't you use JavaScript? I also don't like enabling JavaScript in

Because I use lynx as browser.

But then, this survey *does* work with Lynx. At least, I get a
success message at the end…

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409011035480.29...@tglase.lan.tarent.de

Keysigning at Linaro Connect US (Burlingame, 15 - 19th September 2014)

[Will Newton]

Hi all,

Due to the recent changes in keyring policy I need to get some
signatures on my 4096bit key. I'm going to be attending Linaro Connect
next month where I hope there should be a few DDs who I can either
track down individually in the hallways or if anyone else is in the
same situation as me we could organize a key signing session in one of
the hack rooms.

Thanks,


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

Bug#760143: ITP: cligh -- Command-line interface to GitHub

[Dmitry Bogatov]

Package: wnpp
Owner: Dmitry Bogatov 
Severity: wishlist

* Package name: cligh
  Version : 0.2
  Upstream Author : Christopher M. Brannon
* URL or Web page : http://the-brannons.com/software/cligh.html
* License : BSD
  Description : Command-line interface to GitHub

--
Best regards, Dmitry Bogatov ,
Free Software supporter, esperantisto and netiquette guardian.
GPG: 54B7F00D


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738cbelrp@self.kaction.name

Re: Jessie without systemd as PID 1?

[Mike Gabriel]

Hi Steven,

On  So 31 Aug 2014 02:20:08 CEST, Steven Chamberlain wrote:


Hi,

On Fri, 29 Aug 2014 10:46:28 +0200, Svante Signell wrote:

[...] only way to do that now is to install with the installer, getting
systemd-sysv as PID 1, and later install sysvinit-core, systemd-shim
etc?


I've been dreaming of #758116 (allowing to select Debian Blends
selection during installation) and having as one of the options, a new
Blend perhaps called "Debian alt-init", with one of more 'flavours' that
each would install an alternative init system and its dependencies.

That would happen after d-i has already installed the base system,
including systemd packages, but the idea is that those would be removed
before the installed system is booted for the first time.

Could it really be this simple?  Is anyone crazy enough to help make
this happen?  And a sponsor who could help with an ITP?  I've put
together the beginnings of a Blends package here, completely untested
yet but just in the hope of maybe getting something started:
http://pyro.eu.org/debian/pool/main/d/debian-altinit/

Thanks,
Regards,


as I am currently working on a thinclient environment for X2Go which  
needs such an alt-init approach beyond wheezy, I will be happy to  
help-out with sponsoring and testing.


Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpLhX9VwnpWS.pgp
Description: Digitale PGP-Signatur

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Ritesh Raj Sarraf]

On Sunday 31 August 2014 12:30 AM, Lucas Nussbaum wrote:

During a rebuild of all packages in sid, your package failed to build on
amd64.

Relevant part (hopefully):

>cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC 
-DLIB_STRING=\"lib\" -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE 
-DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c
>uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
>  #include 
>^
>compilation terminated.
>../Makefile.inc:57: recipe for target 'uxsock.o' failed
>make[2]: *** [uxsock.o] Error 1


I fixed this one by adding a build-dep to systemd dev library. But for 
some reason, the build is failing on all architectures. But the same 
builds fine in my pbuilder. Any help ??


--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Re: Jessie without systemd as PID 1?

[Michael Biebl]

Am 01.09.2014 12:42, schrieb Mike Gabriel:
> as I am currently working on a thinclient environment for X2Go which
> needs such an alt-init approach beyond wheezy, I will be happy to
> help-out with sponsoring and testing.

Just curious: Why does X2Go/your thinclient environment need an
alternative init? Would be interested to know more about the technical
problems you are having.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Jessie without systemd as PID 1?

[Steven Chamberlain]

Hello,

On 01/09/14 11:42, Mike Gabriel wrote:
> as I am currently working on a thinclient environment for X2Go which
> needs such an alt-init approach beyond wheezy, I will be happy to
> help-out with sponsoring and testing.

Great!  I was quite sure there will be users who need such a setup for
backward-compatibility.  d-i support for Blends sounds like a really
easy way that doesn't require custom install discs.

(If other people have good uses cases for this, please mention them).

The systemd-must-die 'anti-package' tried to do this another way and was
rejected.  I hope a Blend would be a more constructive approach.  I'm
thinking sysvinit would be the easiest 'flavour' to implement for
jessie, but others are possible, probably only using legacy Sys-V init
compatibility rather than native service files, for now.

sysvinit scripts will still be in use on the kfreebsd and hurd ports for
jessie, so most packages will still ship them even if they have systemd
units also.

We have a tech-ctte resolution in our favour, that reasonable changes
should be accepted into packages to make sure alternative init systems work.

I don't currently expect GNOME to work properly without systemd, I'd
prefer to focus on other desktops instead, but if GNOME's basic
functionality still works that would be nice.  (I wonder if the
bugreport template could mention if a non-default init system is used).

I'm going to have a read over ITP procedure, mentors.d.n and Blends
documentation and then I will get back to you.

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org



signature.asc
Description: OpenPGP digital signature

Base binary packages using xz instead of gzip

[Guillem Jover]

Hi!

It seems there's quite many binary packages in the base system using
xz as compressor instead of gzip, since the switch to xz as default,
which might make debootstrapping from non-Debian systems harder. After
running the follwing:

  $ debootstrap --download-only sid sid-root-path
  $ cd sid-root-path
  $ find -name '*.deb' | while read deb; do \
  if ar t $deb | grep -q data\.tar\.$COMP; then \
echo $deb; \
  fi \
done | sort

with COMP=xz gives 145 packages, with COMP=gz it gives 21. So I guess
it would make sense to decide if people still care about bootstrapping
from other systems where xz-utils might not be available. I think a
lintian check would be pretty easy (which could key on the Priority of
the packages), and might help people to know when to compress using
gzip, as long as the archive override is kept up-to-date, that is
(I've to file some bugs about that).

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901113335.ga8...@gaara.hadrons.org

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Michael Biebl]

Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf:
> I fixed this one by adding a build-dep to systemd dev library. But for
> some reason, the build is failing on all architectures. But the same
> builds fine in my pbuilder. Any help ??

Looking at the build logs [1], the package itself builds fine but you
have missing files, which dh_install --fail-missing complains about:

dh_install: multipath-tools missing files (/usr/lib/systemd/system/*),
aborting

Keep in mind, that in Debian the systemd service files are installed in
/lib/systemd/system.




[1]
https://buildd.debian.org/status/package.php?p=multipath-tools&suite=unstable


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Jakub Wilk]

* Ritesh Raj Sarraf , 2014-09-01, 16:20:

cc -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-D_FORTIFY_SOURCE=2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -Wunused -Wstrict-prototypes -fPIC 
-DLIB_STRING=\"lib\" -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE 
-DUSE_SYSTEMD=208 -c -o uxsock.o uxsock.c
uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory
 #include 
   ^
compilation terminated.
../Makefile.inc:57: recipe for target 'uxsock.o' failed
make[2]: *** [uxsock.o] Error 1


I fixed this one by adding a build-dep to systemd dev library. But for 
some reason, the build is failing on all architectures. But the same 
builds fine in my pbuilder. Any help ??


The error is:
| dh_install: multipath-tools missing files (/usr/lib/systemd/system/*), 
aborting
| make: *** [install] Error 2

Upstream build system uses systemctl(1) to decide whether or not build 
with systemd support enabled. Unsurprisingly, systemctl does not exist 
in buildd chroots. You should either add "systemd" to build-depends, or 
fix the build system to be less non-deterministic.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901112420.ga2...@jwilk.net

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Michael Biebl]

Am 01.09.2014 13:25, schrieb Michael Biebl:
> Am 01.09.2014 12:50, schrieb Ritesh Raj Sarraf:
>> I fixed this one by adding a build-dep to systemd dev library. But for
>> some reason, the build is failing on all architectures. But the same
>> builds fine in my pbuilder. Any help ??
> 
> Looking at the build logs [1], the package itself builds fine but you
> have missing files, which dh_install --fail-missing complains about:
> 
> dh_install: multipath-tools missing files (/usr/lib/systemd/system/*),
> aborting
> 
> Keep in mind, that in Debian the systemd service files are installed in
> /lib/systemd/system.

By quickly glancing over the package, I also noted that you ship a
systemd .service file named multipathd.service but the SysV init scripts
are named /etc/init.d/multipath-tools and
/etc/init.d/multipath-tools-boot (not quite sure why there are two).

systemd continues to start your SysV init scripts, but I assume this is
not wanted? Typically, the SysV init script and the systemd .service
file should have the same name, this way systemd will automatically pick
the native .service unit.
If you want to keep the upstream name for the .service, this is
absolutely file as well (and even encouraged), but you should make sure
the SysV init script is not run then.
There are two possible ways: Provide a symlink(alias)
/lib/systemd/system/.service →
/lib/systemd/system/
or mask the SysV init script by shipping a symlink pointing to /dev/null.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Jessie without systemd as PID 1?

[Mike Gabriel]

On  Mo 01 Sep 2014 13:10:21 CEST, Steven Chamberlain wrote:


[...]

I'm going to have a read over ITP procedure, mentors.d.n and Blends
documentation and then I will get back to you.


Great. Please do!

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpgqsMGP6PNz.pgp
Description: Digitale PGP-Signatur

Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Guillem Jover]

Hi!

I had noticed this a while ago while reading changelogs, but didn't
realize at the time this poses actual problems, besides being possibly
just a dubious practice.

There seems to be some packages overriding the default compression
level for xz to 9. This means dpkg-deb will require way more memory on
both compression and decompression usually for extremely little gain,
and might even fail on some systems with low memory (see #757740 for
an example). But the real issue is that (as mentioned on the xz man
page), using such high levels might actually make no sense at all
when being using with data that is smaller than the dictionary size.

From doing a quick search on  for
“dpkg-deb.*-z9” and “dh_builddeb.*-z9”, but w/o looking in detail, it
seems that most packages are or have been maintained by Daniel Baumann
or the Fonts Team (both CCed). Was there an actual reason to use -z9,
beside maybe trying to get the “bestest” compression possible? :)

This could be checked from lintian by using something like:

  $ ar x pkg.deb data.tar.xz
  $ xz --list --verbose --verbose --robot data.tar.xz

and comparing the file sizes with the dictionary size used. I'll be
filing a bug report about this.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901122030.ga25...@gaara.hadrons.org

Re: Base binary packages using xz instead of gzip

[Simon McVittie]

On 01/09/14 12:33, Guillem Jover wrote:
> It seems there's quite many binary packages in the base system using
> xz as compressor instead of gzip, since the switch to xz as default,
> which might make debootstrapping from non-Debian systems harder.

According to your report, 145 out of 166 base packages use xz, and
nobody seems to have even noticed until now? I think that could be
considered to be evidence in favour of "nobody actually minds; xz all
round!" and a smaller download for the remaining 21 base system packages...

As far as I can tell, the only additional requirement imposed on those
non-Debian systems is "you must have xzcat(1)"; and that could easily be
obtained by unpacking, for instance, wheezy's busybox-static. (sid's
busybox-static is xz-compressed.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540466ff.8080...@debian.org

Re: Base binary packages using xz instead of gzip

[Marco d'Itri]

On Sep 01, Guillem Jover  wrote:

> with COMP=xz gives 145 packages, with COMP=gz it gives 21. So I guess
> it would make sense to decide if people still care about bootstrapping
> from other systems where xz-utils might not be available. I think a
Not at all.
If anybody really cares then I suggest that they add support for xzdec 
to debootstrap.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Base binary packages using xz instead of gzip

[Guillem Jover]

Hi!

[ CCing Joey, as he was one of the people who seemed to care about this
  at the time, and might be able to improve the current situation, if
  he still cares, see below. ]

On Mon, 2014-09-01 at 13:30:55 +0100, Simon McVittie wrote:
> On 01/09/14 12:33, Guillem Jover wrote:
> > It seems there's quite many binary packages in the base system using
> > xz as compressor instead of gzip, since the switch to xz as default,
> > which might make debootstrapping from non-Debian systems harder.
> 
> According to your report, 145 out of 166 base packages use xz, and
> nobody seems to have even noticed until now? I think that could be
> considered to be evidence in favour of "nobody actually minds; xz all
> round!" and a smaller download for the remaining 21 base system packages...

Oh, but that could be simply because people on such systems debootstrap
stable and not unstable? Here the checks again but with stable instead.
With COMP=xz gives 5 with COMP=gz it gives 130, because the dpkg-deb
default only got switched in 1.17.0. The 5 affected packages in wheezy
are (which are not installed by all debootstrap variants):

  aptitude-common aptitude traceroute vim-common vim-tiny

> As far as I can tell, the only additional requirement imposed on those
> non-Debian systems is "you must have xzcat(1)"; and that could easily be
> obtained by unpacking, for instance, wheezy's busybox-static. (sid's
> busybox-static is xz-compressed.)

Yeah, as I mentioned at the time I don't really mind either way, it's
just something I noticed and wanted to let people who might care to
be aware of the current situation, some time before the freeze.

On Mon, 2014-09-01 at 13:33:35 +0200, Guillem Jover wrote:
> I think a
> lintian check would be pretty easy (which could key on the Priority of
> the packages), and might help people to know when to compress using
> gzip, as long as the archive override is kept up-to-date, that is
> (I've to file some bugs about that).

Actually this does not make sense, because lintian does not check the
archive, and only relies on the local packages. It would need to be
some other QA tool that performs such download-only debootstrap and
checks the binary packages.

Something that comes to mind, is that dh_builddeb could check the
package Priority field in DEBIAN/control and chose gzip if it's either
required or important. That might require to update any package with
a mismatched Priority from the archive though.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901131650.ga31...@gaara.hadrons.org

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Ritesh Raj Sarraf]

On Monday 01 September 2014 05:56 PM, Michael Biebl wrote:

>By quickly glancing over the package, I also noted that you ship a
>systemd .service file named multipathd.service but the SysV init scripts
>are named /etc/init.d/multipath-tools and
>/etc/init.d/multipath-tools-boot (not quite sure why there are two).
>


Yes. That's how they have been since beginning. Changing the init script 
now may break for users who may have been using it.



>systemd continues to start your SysV init scripts, but I assume this is
>not wanted? Typically, the SysV init script and the systemd .service
>file should have the same name, this way systemd will automatically pick
>the native .service unit.
>If you want to keep the upstream name for the .service, this is
>absolutely file as well (and even encouraged), but you should make sure
>the SysV init script is not run then.
>There are two possible ways: Provide a symlink(alias)
>/lib/systemd/system/.service →
>/lib/systemd/system/
>or mask the SysV init script by shipping a symlink pointing to /dev/null.


Okay.. I'll look into it.



Another issue: You install the native .service file but you aren't
actually enabling it. We recommend to use dh-systemd for that.



Thanks. Will look into it too.



Since ./multipathd/multipathd.service also references a
multipathd.socket unit, make sure this one is installed as well.



Yes. I'm installing them both.




If you have further questions, please don't hesitate to ask the
pkg-systemd-maintainers mailing list.


In native init scripts, we did a lot of check before starting and 
shutting down the daemon. Things like checking the root device, or 
tiggering LVM Volume Group activitation. They were easily done in shell.


What would the systemd team recommend for it ?

--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54046f17.6010...@debian.org

Bug#760166: ITP: libjs-elycharts -- javascript library to generate static and interactive charts

[Andreas Moog]

Package: wnpp
Severity: wishlist
Owner: Andreas Moog 

* Package name: libjs-elycharts
  Version : 2.1.5
  Upstream Author : Eric Goth 
Stefano Bagnara 
Void Labs s.n.c.
* URL : http://elycharts.com
* License : MIT
  Programming Lang: Javascript
  Description : javascript library to generate static and interactive charts

This javascript library is used to generate static and interactive charts. It
supports dynamic data modification, allows for mouse tracking and highlighting
of specific parts in the chart. It also includes a variety of animations and
transformations to show the chart evolution.

Notes:

The long description could use improvement (I'm not good with words), I will ask
debian-l10n-english for help with it.

One of the packages I maintain (nzbget) introduces a new dependency on elycharts
in its new version.

If it is possible, I'd like to maintain elycharts within the Debian-Javascript
packaging team.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140901135337.3382.53816.report...@anubis.sontra.warperbbs.de

Bug#760167: ITP: cligh -- Command-line interface to GitHub

[Dmitry Bogatov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Bogatov 

* Package name: cligh
  Version : 0.2
  Upstream Author : Christopher M. Brannon
* URL : http://the-brannons.com/software/cligh.html
* License : BSD
  Programming Lang: Python
  Description : Command-line interface to GitHub

This program allows working with GitHub from console.
..
Issues can be opened, closed, viewed, listed and commented. Repositories
can be created, listed and forked. Collaborators can be viewed,
added and removed.

Source package is already available at github: kaction/deb-cligh.

PS. Is it any tool to generate ITP bug from debian/ directory?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140901135817.16833.19820.report...@self.kaction.name

Re: Base binary packages using xz instead of gzip

[Colin Watson]

On Mon, Sep 01, 2014 at 01:57:10PM +0200, Marco d'Itri wrote:
> On Sep 01, Guillem Jover  wrote:
> > with COMP=xz gives 145 packages, with COMP=gz it gives 21. So I guess
> > it would make sense to decide if people still care about bootstrapping
> > from other systems where xz-utils might not be available. I think a
> 
> Not at all.
> If anybody really cares then I suggest that they add support for xzdec 
> to debootstrap.

debootstrap has supported data.tar.xz since 2010.  The thing that's
relevant here, which is outside our control, is whether the non-Debian
systems from which one might be running debootstrap have xz-utils
available.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901154514.ga28...@riva.ucam.org

Re: Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)

[Colin Watson]

On Sun, Aug 31, 2014 at 10:43:20PM +0200, Jakub Wilk wrote:
> * Philipp Kern , 2014-08-31, 12:09:
> >and might actually be different if we are talking about mirror
> >accesses. For instance d-i also builds that way if I don't
> >misremember. (Specifying a fallback mirror, though, I guess, which
> >then requires proper internets.)
> 
> Just look at this beautiful code:
> http://sources.debian.net/src/debian-installer/20140802/build/util/gen-sources.list.udeb/
> (Just kidding. It's not beautiful. Don't even try reading it without
> having large amounts of eyebleach in reserve.)
> 
> So yeah, d-i can't be built automatically without access to a
> mirror. Which is a bug, and not an easy one to fix.

What is actually technically wrong with this?  To build packages, you
have to have access to a mirror in order to acquire the source; using
the very same mirror during the build as well should not be a problem.
(This is of course quite different from the general case of network
access during a build.)  It has worked for many years.  Built-Using
gives us the ability to keep track of which versions of things are
involved.

I've never heard a reason to forbid this that's better than "it's ugly".
It is certainly a useful mode of operation in that it permits us to make
use of build-dependencies that aren't debs without having to
artificially repackage them as debs, or develop huge amounts of
infrastructure for the sake of a few special cases.  It should therefore
be permitted.

> Let's admit for the moment that d-i is spethial,

As an aside, the more I read from people affected by such issues the
more I realise that this term is ableist and offensive.  Could you
please not use it?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901155522.ga28...@riva.ucam.org

Re: Base binary packages using xz instead of gzip

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/01/2014 at 11:45 AM, Colin Watson wrote:

> On Mon, Sep 01, 2014 at 01:57:10PM +0200, Marco d'Itri wrote:
> 
>> On Sep 01, Guillem Jover  wrote:
>> 
>>> with COMP=xz gives 145 packages, with COMP=gz it gives 21. So I
>>> guess it would make sense to decide if people still care about
>>> bootstrapping from other systems where xz-utils might not be
>>> available. I think a
>> 
>> Not at all. If anybody really cares then I suggest that they add
>>  support for xzdec to debootstrap.
> 
> debootstrap has supported data.tar.xz since 2010.  The thing that's
> relevant here, which is outside our control, is whether the 
> non-Debian systems from which one might be running debootstrap have
> xz-utils available.

How so?

If debootstrap supports xz decompression, then surely it doesn't matter
whether some outside source for xz compression / decompression is
available.

Unless debootstrap relies on the outside source to perform that
decompression, of course, but in that case I'm not sure what it would
even mean to say that debootstrap "supports" xz in the first place.

- -- 
  The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


- -- 
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUBJeZAAoJEASpNY00KDJrr0UQAK1JNg4kvfQSyXH2p175m1IJ
Cqquz9ckaLU91vxraiOZEteslaWi4n1qCsQjueDLS9iCBBotTqWyVsGLpBf3Uhb3
2zMbElr7tLavUtcW4+3yfGVKjeQ8M3YtyV3z+SAJUIJmpKRNn2A0t1oWrDvmryRX
hd/8bht6wNN2NaWAx4RI8jNukGljQne8tKmf2OCPLvANBHcKEM4SO6Q1LmmRjGDp
UYKTh2+aFv/pwOGM1ndkYa2v8op6oXocbXm6DCi7fW1zXBZagApTms7dkSFmMOUV
skGZtOWWk58331PCw3jImBVacTMHQ2/avW9PrJD3GB3sRZbM//oAue5nMagPdOuZ
hVi8iEH6I0M4LQuknlNj6d7NP39oeB9kvzC4++xgvT8AYbSRsO36k+/+KynoK4c7
lD+2BsBJzgF04u/KpgzahIc0nyF4lozsSprH8xeZ3j+bdmy3SHzSPWyrzg5SQ/LA
TxUa3eBAh82lnplBQ9HUddf8LzUaC7c02q0zkU1vuURM6w2mbld3X1u12MY9b9JP
5wXSu9cvcjsvI3U34/YUDfJWMNM8TWf61tEv8UUmTFbM74tPgb4wgD/4DcIX1M8/
ONUvzvSZ7TJHhskSBpeLVWazrXZcDuV7s0ou24g0iJ7M9bWACdt8z6AwuwQZrYcv
5OxFPhq7qcPwXzSQiLAh
=r9e7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54049799.6020...@fastmail.fm

Re: Base binary packages using xz instead of gzip

[Simon McVittie]

On 01/09/14 16:58, The Wanderer wrote:
> Unless debootstrap relies on the outside source to perform that
> decompression, of course, but in that case I'm not sure what it would
> even mean to say that debootstrap "supports" xz in the first place.

In this case "debootstrap supports xz" means "debootstrap knows that if
the ar file contains *.tar.xz, it should be unpacked using xzcat". (See
debootstrap's source code.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54049b24.3040...@debian.org

Re: Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)

[Ansgar Burchardt]

On 09/01/2014 17:55, Colin Watson wrote:
> On Sun, Aug 31, 2014 at 10:43:20PM +0200, Jakub Wilk wrote:
>> So yeah, d-i can't be built automatically without access to a
>> mirror. Which is a bug, and not an easy one to fix.
> 
> What is actually technically wrong with this?  To build packages, you
> have to have access to a mirror in order to acquire the source; using
> the very same mirror during the build as well should not be a problem.

To build packages, you need to have the build dependencies installed. It
doesn't matter where they come from (network mirror, Debian CD, USB disk
with *.deb, ...).

You suggest to change this to require connectivity to a Debian mirror
instead. You also can no longer use versioned Build-Depends, but have to
about the build later instead (as you don't know which version you will
download in advance).

The package would also have to know which mirror to use (not trivial),
which suite it has to obtain the source from and so on.

> (This is of course quite different from the general case of network
> access during a build.)  It has worked for many years.  Built-Using
> gives us the ability to keep track of which versions of things are
> involved.

It also makes it hard to restict network access for buildds (in the
future): instead of only needing access to localhost, they would also
need access to DNS, and all mirrors given in sources.list. The last part
gets tricky once redirector services like http.debian.net are used.

It gets easier if you have one internal mirror all buildds can use
(which I think Canonical does have), but Debian's buildd network looks
nothing like that.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54049b59.1020...@debian.org

Re: people.debian.org will move from ravel to paradis and become HTTPS only

[Agustin Martin]

On Thu, Jul 31, 2014 at 01:26:09PM +0200, Jakub Wilk wrote:
> * Jakub Wilk , 2014-07-30, 22:26:
> >>WARNING: The following packages cannot be authenticated!
> >>apt-transport-https
> >>Install these packages without verification? [y/N]
> >>E: Some packages could not be authenticated
> [...]
> >But if the authentication troubles are really related to the
> >HTTP->HTTPS switch, then it's a bug in apt that should be fixed.
> 
> Filed as #756614.

Thanks for looking into this,

There is also a minor problem when used from wheezy, putting it here so it
gets indexed and more available to web searches.

Using wheezy apt 0.9.7.9 in a wheezy box,

# apt-get update
...
Err http://people.debian.org ./ Packages
  301  Moved Permanently [IP: 5.153.231.30 80]
...

# apt-get install apt-transport-https
...
Setting up apt-transport-https (0.9.7.9+deb7u2) ...

# apt-get update
Err http://people.debian.org ./ Packages
  301  Moved Permanently [IP: 5.153.231.30 80]

Changing http://people.debian.org to https://people.debian.org fixes the
problem, once apt-transport-https is installed. Not a big problem, I do not
think this worths a new bug report.

-- 
Agustin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901162037.ga7...@agmartin.aq.upm.es

Re: [Q] Can anyone connect to the paypal site with openssl 1.0.1i-2?

[Takahide Nojima]

Hello,

2014-08-31 11:06 -0700 Russ Allbery wrote:
> Takahide Nojima  writes:
> 
> >  Can anyone connect the paypal web site(https://www.paypal.com/) with
> > openssl 1.0.1i-2(sid)?
> 
> >  I tried to connect the paypal site like this,
> 
> >openssl s_client -connect www.paypal.com:443
> 
> Yes, it works here with that version with:
> 

 Thank you for this information. 

 As I reconsiderd as this, I changed global ip adress of my debian box.
Finally it worked! 

 Seeing this, I agree PayPal's web site has something transient bug as
you wrote.

 I will ask to PayPal support.

 Thanks!
 Regards,

Takahide Nojima




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

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Daniel Baumann]

On 09/01/2014 02:20 PM, Guillem Jover wrote:
> it seems that most packages are or have been maintained by Daniel Baumann
> or the Fonts Team (both CCed).

i've switched to the default compression december 2012/january 2013 in
all my packages (so they use an inherited -z6 as everyone else
uses/should use).

seems some packages that i've orphaned before that haven't been touched
since.

-- 
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:  daniel.baum...@progress-technologies.net
Internet:   http://people.progress-technologies.net/~daniel.baumann/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5404a6d1.5020...@progress-technologies.net

Bug#760188: ITP: scoop -- concurrent parallel programmming library

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: scoop
  Version : 0.7.1
  Upstream Author : SCOOP Development Team 
* URL : http://code.google.com/p/scoop/
* License : LPGL-3.0
  Description : concurrent parallel programmming library for Python

I'm working on packaging Scoop for Debian. For info on this, please cf. 
http://scoop.readthedocs.org/en/0.7/.

Thank you very much,
Daniel Stender


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140901175647.2545.19196.report...@varuna.fritz.box

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Bastien ROUCARIES]

Le 1 sept. 2014 14:21, "Guillem Jover"  a écrit :
>
> Hi!
>
> I had noticed this a while ago while reading changelogs, but didn't
> realize at the time this poses actual problems, besides being possibly
> just a dubious practice.
>
> There seems to be some packages overriding the default compression
> level for xz to 9. This means dpkg-deb will require way more memory on
> both compression and decompression usually for extremely little gain,
> and might even fail on some systems with low memory (see #757740 for
> an example). But the real issue is that (as mentioned on the xz man
> page), using such high levels might actually make no sense at all
> when being using with data that is smaller than the dictionary size.
Could you fill a bug against lintian ?
> From doing a quick search on  for
> “dpkg-deb.*-z9” and “dh_builddeb.*-z9”, but w/o looking in detail, it
> seems that most packages are or have been maintained by Daniel Baumann
> or the Fonts Team (both CCed). Was there an actual reason to use -z9,
> beside maybe trying to get the “bestest” compression possible? :)
>
> This could be checked from lintian by using something like:
>
>   $ ar x pkg.deb data.tar.xz
>   $ xz --list --verbose --verbose --robot data.tar.xz
>
> and comparing the file sizes with the dictionary size used. I'll be
> filing a bug report about this.
>
> Thanks,
> Guillem
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: https://lists.debian.org/20140901122030.ga25...@gaara.hadrons.org
>

Re: Bug#759849: multipath-tools: FTBFS: uxsock.c:20:31: fatal error: systemd/sd-daemon.h: No such file or directory

[Christian Hofstaedtler]

> In native init scripts, we did a lot of check before starting and shutting
> down the daemon. Things like checking the root device, or tiggering LVM
> Volume Group activitation. They were easily done in shell.
> 
> What would the systemd team recommend for it ?

That probably depends on why you were doing these things in the
first place. It'd be my understanding that udev should take care
about most stuff, and for the root device, your initramfs-tools hook
should do it.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901191619.GA44074@sx.local

Re: Bug#759762: ITP: libz-mingw-w64 -- compression library (targeting Windows)

[Adam Borowski]

On Sun, Aug 31, 2014 at 10:43:20PM +0200, Jakub Wilk wrote:
> * Philipp Kern , 2014-08-31, 12:09:
> >>Packages must mot access outside world at the build time.
> >
> >This is not enforced yet, though,
> 
> It's now enforced in pbuilder. Also in Jakub's sbuild. :-P
> I believe that it's indeed not enforced on buildds, which is a shame.

Just one of common annoyances that causes FTBFS and slows down things:
.
loading intersphinx inventory from http://docs.python.org/objects.inv...
`
In my ongoing armhf archive rebuild (88% complete) it happened 31 times so
far.  For some reason, on the very same machine with the same configuration,
it sometimes hangs until sbuild timeouts, yet it's stable for repeats of
the same package:
.-=[ deap_1.0.1-1
Running Sphinx v1.2.2
loading pickled environment... not yet created
loading intersphinx inventory from http://docs.python.org/objects.inv...
make: *** wait: No child processes.  Stop.
make: *** Waiting for unfinished jobs
make: *** wait: No child processes.  Stop.
make[1]: *** [html] Terminated
Makefile:34: recipe for target 'html' failed
Build killed with signal TERM after 300 minutes of inactivity
`
and sometimes succeeds:
.-=[ lava-server_2014.06.02.17-2
Running Sphinx v1.2.2
loading pickled environment... not yet created
loading intersphinx inventory from http://docs.python.org/objects.inv...
WARNING: intersphinx inventory 'http://docs.python.org/objects.inv' not
fetchable due to : 
[...]
Status: successful
`

So, what's the policy here?  Should I file bugs just for packages where
there's a FTBFS (without regard that for _some_ configuration elsewhere
it might build), or for all packages whose logs include this string?

Also, should we detect all other attempts to contact the outside network,
and swat such builds with extreme prejudice?

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140901203819.ga32...@angband.pl

Re: Unicode 7.0 released - some packages contain outdated embedded data copies

[Simon Josefsson]

Paul Wise  writes:

> Please ask your upstreams to remove the Unicode data files from their
> version control systems and source tarballs and instead check for and
> use external Unicode data files at build-time or run-time. Then your
> packages can Build-Depend or Depend on the unicode-data binary package.
> If your package converts the Unicode data to another format at build
> time you should add a Built-Using header to the relevant binary
> packages. The fntsample package is an example of how to do this.
...
> Anibal Monsalve Salazar 
>libidn (U)

This is a false positive -- libidn implements IDNA2003 (RFC3490 etc)
which has a hard dependency on Unicode 3.2.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738cbvyo8@latte.josefsson.org

Bug#760230: ITP: python-sk1libs -- Set of python non-GUI extensions for sK1 Project

[Javi Merino]

Package: wnpp
Severity: wishlist
Owner: Javi Merino 

* Package name: python-sk1libs
  Version : 0.9.1
  Upstream Author : Igor E. Novikov 
* URL : http://sk1project.org/modules.php?name=Products&product=sk1
* License : LGPL-2+
  Programming Lang: Python, C
  Description : Set of python non-GUI extensions for sK1 Project

sk1libs is a set of python non-GUI extensions for sK1 Project.
The package includes multiplatform non-GUI extensions which are
usually native extensions.

This package is a dependency of the new upstream version of
python-uniconvertor .  It'll be maintained in the Python Modules Team.


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

3 New Voicemail(s)

[Messaging Service WhatsApp]

WhatsApp

  
  
You have a new voicemail!

**Details:**

Time of Call: Aug-29 2013 06:12:14  
Lenth of Call: 28sec  
  

[Play](http://kook-genoten.nl/wp-
content/en.php?rec=Op1tCUTOQUgJtBQDnBOJJyXVpwG/xttmQgCEr8vAtng=)

*If you cannot play, move message to the "Inbox" folder. 

2014 WhatsApp Inc

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Changwoo Ryu]

2014-09-01 21:20 GMT+09:00 Guillem Jover :
> There seems to be some packages overriding the default compression
> level for xz to 9. This means dpkg-deb will require way more memory on
> both compression and decompression usually for extremely little gain,
> and might even fail on some systems with low memory (see #757740 for
> an example). But the real issue is that (as mentioned on the xz man
> page), using such high levels might actually make no sense at all
> when being using with data that is smaller than the dictionary size.
>
> From doing a quick search on  for
> “dpkg-deb.*-z9” and “dh_builddeb.*-z9”, but w/o looking in detail, it
> seems that most packages are or have been maintained by Daniel Baumann
> or the Fonts Team (both CCed). Was there an actual reason to use -z9,
> beside maybe trying to get the “bestest” compression possible? :)

"dh_builddeb -- -Zxz -Sextreme -z9" has been introduced to the
pkg-font team when dpkg-deb default is not xz.

In my quick experiments with some font packages, "-Sextream -z9"
option still gives  ~4% smaller size than the default. IMO this is
still significant for big font packages.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAEe2ifUQd55wfuaMXPNkdgjkX+=JQDEOj=yqdgygejqqwrk...@mail.gmail.com

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Christian PERRIER]

Quoting Changwoo Ryu (cw...@debian.org):

> In my quick experiments with some font packages, "-Sextream -z9"
> option still gives  ~4% smaller size than the default. IMO this is
> still significant for big font packages.

Yes, that choice of the fonts team is based on a detailed experiment
conducted by Hideki Yamane and presented at DebConf 12.

Yamane-san's presentation had many numbers which I personnally found
convincing.



signature.asc
Description: Digital signature