Re: Removing < 2048 bit keys from the Debian keyrings

[Manoj Srivastava]

On Tue, Sep 02 2014, Manoj Srivastava wrote:

> On Tue, Sep 02 2014, Jeremy T. Bouse wrote:
>
>
>>  I don't know how the *-cert-level options in gpg/gpg2 match up with
>> that section RFC480. Actually reading the sections in the man pages it
>> reads very differently.
>
> I stand corrected. Now I just need to figure out how to resign
>  the keys with the new options.

I figured out how to do the signatures; I am now torn between
 whether I should resign just to get the cert-level data in the
 signature, and effectively obscuring when the signature was actually
 made (well, or replacing the date when I had checked the ID with the
 current one). I'll re-sign the keys from the current debconf in a
 month, if they make their way to the keyservers, but i'll leave the
 historical signatures alone.

I learned something today :-)

manoj
-- 
If I have not seen so far it is because I stood in giant's footsteps.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


signature.asc
Description: PGP signature

Bug#760356: ITP: python-colorlog -- formatter to use with python's logging module

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: python-colorlog
  Version : 2.4.0
  Upstream Author : Sam Clements 
* URL : https://github.com/borntyping/python-colorlog
* License : MIT
  Programming Lang: Python
  Description : formatter to use with python's logging module

This library allows colors to be placed in the format string, which is mostly
useful when paired with a StreamHandler that is outputting to a terminal.
This is accomplished by adding a set of terminal color codes to the record
before it is used to format the string.


-- 
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/20140903073112.25193.33785.report...@emmagan.debalance.de

Re: calling maintainer scripts with a clean environment?

[Simon McVittie]

On 02/09/14 20:09, Evgeni Golov wrote:
> after reading #759590, I think it is time to consider calling maintainer 
> scripts in a (slightly) cleaned environment.

Another possibility would be to guarantee that init scripts will be
called in a cleaned environment. This seems like it will break fewer
expectations, because systemd and (AIUI) Upstart do this anyway, sysv-rc
does this during boot, and service(8) does this when a sysadmin uses it
to invoke an init script explicitly; the missing piece of the puzzle is
that invoke-rc.d(8) does not.

> I think systemd already does this, 
> but I'd love a more generic solution for the "problem".

The generic solution, IMO, is "use an init that can be directed via IPC
to run services in a clean environment, rather than running those
services as a child of some random sysadmin process". systemd does this;
I believe Upstart also does this. This is one of the factors that made
the ctte prefer systemd and Upstart over sysvinit.

To get as close to that as possible in sysvinit, environment variables
(but not other aspects of the inherited process environment, like ulimit
and capabilities!) are re-initialized by running /etc/init.d/foo via
service(8) (recommended[1]) instead of directly (deprecated[1]), with
only $LANG, $PATH and $TERM inherited. Maybe invoke-rc.d(8) should do
the same as service(8), or even chain to service(8) to do the actual
script execution?

S

[1] for a number of reasons, mainly "it clears the environment",
"it works in Upstart too", and "it works in systemd too, even if
the init script does not use the LSB init functions"


-- 
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/5406c5f1.1040...@debian.org

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

[Simon McVittie]

On 02/09/14 21:17, Changwoo Ryu wrote:
> For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e
> is not better than -8e.

I don't think anyone is arguing that higher compression settings don't
produce better compression ratios. However:

 Preset   DictSize   CompCPU   CompMem   DecMem
   ...
   -6   8 MiB   6   94 MiB9 MiB <-
   -7  16 MiB   6  186 MiB   17 MiB
   -8  32 MiB   6  370 MiB   33 MiB <-
   -9  64 MiB   6  674 MiB   65 MiB

... it's about cost/benefit. If we can save 300 KiB of compressed size,
but the cost is to more than triple the required memory to decompress
(from 9 MiB to 33 MiB), is that actually a worthwhile trade-off?

The d-i manual for wheezy on armel currently says that the bare minimum
RAM for wheezy is 31 MiB, the minimal recommended RAM is 64 MiB, and the
recommended RAM is 256 MiB or more. I'm sure those will increase
somewhat for jessie, but on a system with that sort of spec, packages
that need up to 65 MiB of RAM+swap to decompress (in addition to
whatever is needed for the kernel, and for the machine's actual
purpose!) seem rather greedy.

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/5406cba0.9000...@debian.org

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

[Thorsten Glaser]

On Wed, 3 Sep 2014, Changwoo Ryu wrote:

> I think 65MIB  for decompressing is OK with current hardwares as long
> as it saves good amount of space and bandwidth.

Not on avr32, and it hurts sh4, m68k and others as well.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
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.1409031059180.6...@tglase.lan.tarent.de

Re: Jessie without systemd as PID 1?

[Svante Signell]

On Tue, 2014-09-02 at 16:03 +0200, Thorsten Glaser wrote:
> Svante Signell dixit:
> 
> > It would be nice to have the same init system:sysv-core, as well as the
> > same default desktop:mate-desktop-environment (including accessibility
> > enhancements), for all arches: Linux, kFreeBSD and Hurd :-) If possible,
> > this could be an option in the advanced menu of the installer.
> 
> Right, but we need multiselect. For example, the user may want
> to choose a desktop, an init system, and another option.

Some food for thought about systemd:
You might have seen this http://ewontfix.com/14
but have you seen this http://ewontfix.com/15
or this http://boycottsystemd.org/

Having a systemd-free option for Debian Jessie is becoming more and more
important. Otherwise (Debian) users might do as recommended in the third
link: Boycott distros that use systemd.




-- 
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/1409735490.10679.32.ca...@g3620.my.own.domain

Bug#760364: ITP: python-elasticsearch -- Python client for Elasticsearch

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-elasticsearch
  Version : 1.2.0
  Upstream Author : Honza Král 
* URL : https://github.com/elasticsearch/elasticsearch-py
* License : Apache
  Programming Lang: Python
  Description : Python client for Elasticsearch

Official low-level client for Elasticsearch. Its goal is to provide common
ground for all Elasticsearch-related code in Python; because of this it tries
to be opinion-free and very extendable.

The client's features include:
  * translating basic Python data types to and from json (datetimes are not
decoded for performance reasons)
  * configurable automatic discovery of cluster nodes
  * persistent connections
  * load balancing (with pluggable selection strategy) across all available
nodes
  * failed connection penalization (time based - failed connections won't be
retried until a timeout is reached)
  * thread safety
  * pluggable architecture

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUBt48AAoJEGlMre9Rx7W2l3IQAKAg3CTH95+Sy4hT+cgVM1LZ
xfOcbyAN7+tgHGqeLu9rsh5BleyvQE9Miw8o/B2FIGTkCjGbZUo0Kj/bJufDYcgF
Vq9HuXdjZz7Bxim71K+EpQMktEM7/OaBzxVeSAJuO/0j9DPdKmi3v7YbZyARjkEq
Ie5MJgALbrTOhpFfvpuop2PhduUDBHFksHJ887kjTOSL13hy9gys5C5qfbtUVq+L
aSnUURTTuB2qoIvz5ta2GE4n91UIml09P5dSVKtij1DbTeEYOQsh6scmUUj7GH2m
0im1y2IHPNqkXQDKqpjOWNVk31KGEosOoQ722u17Vv5+nDWLoaBG5c+VNiMfYTEC
w0JZ4sPygrtDBU3cWhl85q/0zZW4c5z70TJGkkN3rO6I3fbxGHsuS2CjNbyM6tpV
TVatr9/0M+ykEffbQeX1AbevE23A5WQr1CcLbqB1kgDhG7TaT02pfUMHYa+zX1gx
ncSKVztPhPKmQ61gnyBIsRflm3Ipdc3FOza15MjPO6APav+tKrDRlh7verTj5hWC
jGsntar+Vv9Tm9TMy9EhaQQJB+ooWl8b0K358VlwcvnJYitQ6iOxmFXSQud0rUHx
CsnmDcWxnqPitbpEdZLmMYiTLgmLHqgxvcG26oYYSE1qj4z+oZck70Ey+YcAvA8r
wM9QYGFpcxyOw2iJxq8X
=2p9j
-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/20140903092415.20198.18062.reportbug@kashyyyk.local

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 Tuesday 02 September 2014 01:33 PM, Ritesh Raj Sarraf wrote:

Could you elaborate a bit more, why those are needed?
What is upstream doing about this?


The block storage has many components that work closely with one another.

Take an example, root fs on LVM on Multipath on iSCSI.

The flow for such a setup is to:
1) Start iSCSI and discover the LUNs
2) Detect and create mulitpath maps for matching LUNs in DM Multipath
3) Detect and Activate Volume Group out of the newly detected DM 
Multipath Physical Volumes

4) Mount the file system.

The same can be applied to the shutdown sequence. You want to have 
proper checks in place before initiating a shutdown of the service. 
One would argue that the service should not stop if it has active 
services.


Many of the services (mulitpath, iscsi, for example) have a 2 part 
component. One in the kernel and the other in userspace. The kernel 
space service will not terminate if any service is active. But the 
userspace is not so forgiving.


In open-iscsi, if you ask the daemon to shutdown, it will. If there 
are active sessions, the kernel component will not terminate the 
current sessions. But the userspace daemon will be shutdown. That 
means, that when there is the next state failure, open-iscsi will have 
no idea of determining that a LUN state has changed


Similar is the case with DM Multipath. The userspace DM Multipath 
daemon is responsible for polling and keeping an up-to-date status of 
the Device Mapper maps. If the userspace daemon is inactive, and 
underneath there is a fabric state change, there is no way to 
propagate that error to the upper layers.


These design issues, since they are part of the core storage stack, if 
triggered, leave you with a machine with no access to your root disk. 
Any process at that time, may get into a 'DI' process state or an 
immediate device failure. The only action then would be to hardware 
reset your machine.


This is why we do a lot of checks in the init scripts to warn the user.


Similar approaches were taken in RHEL (5 and 6) and SLES (10 and 11). 
I'm not sure what Red Hat or SUSE has chosen for their latest 
releases, as I don't work on those products any more.



My inclination is to ship both, the systemd service files and the init 
scripts, in their current form along with whatever limitations each 
may have, and let the user choose.


Hi,

I did not get any comment on this. How are others doing similar stuff 
while migrating to systemd ?


--
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/5406df56.6070...@debian.org

Re: Jessie without systemd as PID 1?

[Rens Houben]

In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell has 
been seen typing:

> Some food for thought about systemd:

... I thought we'd all agreed to stop bringing up tired arguments that
nobody but the "systemd MUST DIE" crowd really wants to hear anymore.

> You might have seen this http://ewontfix.com/14
> but have you seen this http://ewontfix.com/15
> or this http://boycottsystemd.org/

"Open source Tea Party". That explains *so* much...

> Having a systemd-free option for Debian Jessie is becoming more and more
> important. Otherwise (Debian) users might do as recommended in the third
> link: Boycott distros that use systemd.

"If we keep systemd, people who want to boycott systemd will boycott
us." Seriously, can we stop with the circular arguments as well?

-- 
Rens Houben   |opinions are mine
Resident linux guru and sysadmin  | if my employers have one
Systemec Internet Services.   |they'll tell you themselves
PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc


-- 
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/20140903093421.ga25...@proteus.systemec.nl

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

[Changwoo Ryu]

2014-09-03 17:04 GMT+09:00 Simon McVittie :
> On 02/09/14 21:17, Changwoo Ryu wrote:
>> For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e
>> is not better than -8e.
>
> I don't think anyone is arguing that higher compression settings don't
> produce better compression ratios. However:
>
>  Preset   DictSize   CompCPU   CompMem   DecMem
>...
>-6   8 MiB   6   94 MiB9 MiB <-
>-7  16 MiB   6  186 MiB   17 MiB
>-8  32 MiB   6  370 MiB   33 MiB <-
>-9  64 MiB   6  674 MiB   65 MiB
>
> ... it's about cost/benefit. If we can save 300 KiB of compressed size,
> but the cost is to more than triple the required memory to decompress
> (from 9 MiB to 33 MiB), is that actually a worthwhile trade-off?

I think yes. The cost is 24 MiB extra memory on installation, and
benefits are bandwidth and mirror size saving of big packages.

> The d-i manual for wheezy on armel currently says that the bare minimum
> RAM for wheezy is 31 MiB, the minimal recommended RAM is 64 MiB, and the
> recommended RAM is 256 MiB or more. I'm sure those will increase
> somewhat for jessie, but on a system with that sort of spec, packages
> that need up to 65 MiB of RAM+swap to decompress (in addition to
> whatever is needed for the kernel, and for the machine's actual
> purpose!) seem rather greedy.

I can't imagine any 31 MiB machine which needs to render megabytes of
Truetype fonts.

I think we can assume usual desktop machines for font packages.
According to the d-i manual, wheezy's minimum RAM "for desktop" is 128
MiB, and 512 MiB is recommended. For jessie, the minimum is 256 MiB
and 1 GiB is recommended. And these requirement/recommendation are far
behind of the current computer market. In practice, I have not found
any single report of OOM while installing such font packages for ~2
years.


-- 
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/caee2ifuw9wgo1__vl-nupq+vh1z7hfte5hemik0bqtvtj3e...@mail.gmail.com

Re: Jessie without systemd as PID 1?

[Martinx - ジェームズ]

Hi!

 I'm wondering here... Lets suppose I NEED to use sysvinit, with Debian 8.

 If so, can I just run: `apt-get install sysvinit-core` to get rid of
systemd as my INIT?

 If yes, will this be support until... Let's say, Debian kFreeBSD still
remains around...?

 Also, why not have a system like "/etc/alternatives", or "dpkg-reconfogure
alt-init" (just like "dpkg-reconfigure gdm/kdm"),so people can still choose
between sysvinit / systemd as their default INIT? Maybe during install
time!?

 Listen, I'm not a systemd-hater (or lover) but, I'm just saying that, for
safety, I think we need to keep `sysvinit-core` working until ~2020. Just
in case... I'm not saying NO to systemd, I'm just saying, not now
(specially if it if brings some level of instability here and there)...

 Long life to Debian / Ubuntu!

 BTW, my first message to this list...   :-)

Thanks!
Thiago


On 3 September 2014 06:34, Rens Houben  wrote:

> In other news for Wed, Sep 03, 2014 at 11:11:30AM +0200, Svante Signell
> has been seen typing:
>
> > Some food for thought about systemd:
>
> ... I thought we'd all agreed to stop bringing up tired arguments that
> nobody but the "systemd MUST DIE" crowd really wants to hear anymore.
>
> > You might have seen this http://ewontfix.com/14
> > but have you seen this http://ewontfix.com/15
> > or this http://boycottsystemd.org/
>
> "Open source Tea Party". That explains *so* much...
>
> > Having a systemd-free option for Debian Jessie is becoming more and more
> > important. Otherwise (Debian) users might do as recommended in the third
> > link: Boycott distros that use systemd.
>
> "If we keep systemd, people who want to boycott systemd will boycott
> us." Seriously, can we stop with the circular arguments as well?
>
> --
> Rens Houben   |opinions are mine
> Resident linux guru and sysadmin  | if my employers have one
> Systemec Internet Services.   |they'll tell you themselves
> PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc
>
>
> --
> 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/20140903093421.ga25...@proteus.systemec.nl
>
>

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

[Thorsten Glaser]

On Wed, 3 Sep 2014, Changwoo Ryu wrote:

> I can't imagine any 31 MiB machine which needs to render megabytes of

It’s *additional* memory. On top of kernel, libc, apt, dpkg, and
whatever the user is running in parallel.

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.1409031509430.6...@tglase.lan.tarent.de

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

[Henrique de Moraes Holschuh]

On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
> >My inclination is to ship both, the systemd service files and the
> >init scripts, in their current form along with whatever
> >limitations each may have, and let the user choose.
> 
> I did not get any comment on this. How are others doing similar
> stuff while migrating to systemd ?

Well, you can always separate the important setup/teardown logic in one or
more scripts, call them from the systemd unit and also from the initscript
to not have duplicated logic.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20140903132108.gb18...@khazad-dum.debian.net

Re: Jessie without systemd as PID 1?

[Simon McVittie]

I'm sure we've been over this many times already.

On 03/09/14 13:24, Martinx - ジェームズ wrote:
>  If so, can I just run: `apt-get install sysvinit-core` to get rid of
> systemd as my INIT?

Yes.

>  If yes, will this be support until... Let's say, Debian kFreeBSD still
> remains around...?

That's up to the sysvinit and systemd-shim maintainers and how well they
can keep those packages working. If systemd-shim ceases to be a viable
alternative way to run systemd-logind, then you might lose other
packages as a result of this dependency stack:

 (stuff that needs logind) -> libpam-systemd -> systemd-sysv |
systemd-shim

(as part of the general principles of "things that don't work get
dropped" and "things that depend on particular functionality should
depend on the package providing that functionality")

If your system doesn't contain anything that needs systemd-logind, then
that dependency stack doesn't exist on your system.

>  Also, why not have a system like "/etc/alternatives", or
> "dpkg-reconfogure alt-init" (just like "dpkg-reconfigure gdm/kdm")

Because not all of the alternatives are equally technically suitable for
everything. With alternatives, there would be no way to express the
dependency relationship "package foo really does need systemd to be pid
1" (or conversely, "foo needs sysvinit-core to be pid 1", which should
probably be the case where e.g. foo = rcconf).

Currently that's spelled like "foo Depends: systemd-sysv"; but if
systemd-sysv and sysvinit-core were co-installable, and you had
systemd-sysv and sysvinit-core installed and sysvinit-core selected to
provide the alternatives, then the dependency would be satisfied, but
foo wouldn't work.

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/540724f3.4080...@debian.org

Re: Jessie without systemd as PID 1?

[Holger Levsen]

Hi Svante,

On Mittwoch, 3. September 2014, Svante Signell wrote:
> Some food for thought about systemd:
> You might have seen this http://ewontfix.com/14
> but have you seen this http://ewontfix.com/15
> or this http://boycottsystemd.org/
> 
> Having a systemd-free option for Debian Jessie is becoming more and more
> important. Otherwise (Debian) users might do as recommended in the third
> link: Boycott distros that use systemd.

debian-devel@ is for the development of the Debian distribution, not for 
ranting. Please take your rants elsewhere. It's tiring and a waste of your and 
many other peoples time. But it wont change things. Code changes things in 
Debian.


thxgoodybe,
Holger




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

Re: calling maintainer scripts with a clean environment?

[Evgeni Golov]

Hi,

On 09/02/2014 11:06 PM, Bob Proulx wrote:
> Evgeni Golov wrote:
>> after reading #759590, I think it is time to consider calling maintainer 
>> scripts in a (slightly) cleaned environment.
> 
> Since I submitted Bug#759590 (however not the apt interaction aspect
> of it) let me say that I consider the ability of inheriting the
> environment for PATH and LD_PRELOAD to be a feature.  I would find it
> a tragedy if the bug under discussion caused this feature to be
> removed.

I can understand PATH, and I can understand LANG/LC_* at some degree.
But what would you need LD_PRELOAD in the maint-scripts?

> There is a long chain of unintended consequences in this problem that
> created a need for eatmydata.  I fear mentioning the chain because it
> will reopen old wounds.  So I won't.

For me it's either speeding up dpkg or an (throw-away) build.
My actual fear is not eatmydata, this will be fixed soon.
My fear is when you debug stuff, have some unclean environment, and then
decide to run apt, and some service gets restarted and suddenly runs
with OPENSSL_DEBUG=1 or somesuch... Or a DB server gets started with
eatmydata preloaded...

> But I vote not to continue the chain of unintended consequences by
> further modifying apt or dpkg.  The logical progression would be that
> dpkg would get an environment file where these settings would be set
> in order to accomplish the same result.  Because there is a need for
> the capability.  If it ends up being prevented one way then it will
> need to be enabled in another way.  In the end nothing would change
> except that it would be more painful, more rigid, more fragile.

And more "you explicitly said you want to shoot yourself in the foot".
(I'd totaly like a whitelist, like sudo's env_keep is).

> Therefore I think if an admin sets up a custom environment that this
> environment should be used.  Or at least not actively prevented from
> being used.

Unless he is using it by accident, which is what I fear of.

Greets and thanks for the feedback
Evgeni


-- 
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/54073119.9020...@debian.org

Re: Jessie without systemd as PID 1?

[Marco d'Itri]

On Sep 03, Svante Signell  wrote:

> Having a systemd-free option for Debian Jessie is becoming more and more
> important. Otherwise (Debian) users might do as recommended in the third
> link: Boycott distros that use systemd.
And I strongly encourage them to do this: we aim to be universal but we 
cannot reasonably fit everybody's needs.

https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Jessie without systemd as PID 1?

[Svante Signell]

On Wed, 2014-09-03 at 10:45 -0400, Holger Levsen wrote:
> Hi Svante,
> 
> On Mittwoch, 3. September 2014, Svante Signell wrote:
> > Some food for thought about systemd:
> > You might have seen this http://ewontfix.com/14
> > but have you seen this http://ewontfix.com/15
> > or this http://boycottsystemd.org/
> > 
> > Having a systemd-free option for Debian Jessie is becoming more and more
> > important. Otherwise (Debian) users might do as recommended in the third
> > link: Boycott distros that use systemd.
> 
> debian-devel@ is for the development of the Debian distribution, not for 
> ranting. Please take your rants elsewhere. It's tiring and a waste of your 
> and 
> many other peoples time. But it wont change things. Code changes things in 
> Debian.


Ok, these locks was maybe a little to much for some people. I'm sorry
for that. Anyway the TC decision remains that alternative init system
should be allowed, and I'm trying to find out how many of debian users
and developers are interested in working together with me on such a
solution. Best would be to have an option in the installer (hidden by
default). So this question _is_ relevant here for development of the
Debian distribution: debian-devel.


-- 
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/1409757691.10679.44.ca...@g3620.my.own.domain

Re: 2 months and no upload for pkg

[Ian Jackson]

Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
> It may not simply be the person
> 
> Somebody uploading packages where they are also the upstream may know
> the copyright situation inside out and just cut and paste
> debian/copyright from one package to the next and it is always correct.
> 
> Somebody ambitious who works on packages they are less familiar with
> or really monstrous packages may well miss things from time to time
> and be deterred by such a system.  Then we have less people willing to
> attack such monstrous packages.

There is a tradeoff here, between 1. the interests of users and
developers of the `monstrous' package, and 2. the interests of
ftpmaster and the users and developers of everything else.

The costs of such a `monstrous' package should be borne by those who
are working on it and want to see it in Debian.  It is true that that
means that such packages are less likely to be in Debian than smaller
or easier ones.  We should not try to fix that by redirecting core
team effort to fix big and difficult packages.

For the packager of such a `monstrous' package, there is a simple
answer: get someone else to review the package until you are
sufficiently confident about the package that the risk to your own
reputation is acceptable.

In general, if you are not confident that your package's copyright
licensing (and whatever else ftpmaster would be concerned about) is
correct, it is not fair or reasonable to upload it anyway and rely on
ftpmaster to find and fix your problems.

> Ultimately, the person who made the package may be using it anyway and
> such delays may only inconvenience other users of a package, including
> the rest of the community.

That is of course a matter for them.

Ian.


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

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

[Fabian Greffrath]

Hi Changwoo Ryu,

> I think yes. The cost is 24 MiB extra memory on installation, and
> benefits are bandwidth and mirror size saving of big packages.

I beg to differ. Those few kiB of bandwidth (yes, I mean it like that)
saved when downloading a package are worthless if the decompresion
routine forces the system onto its knees upon installation of that very
same package.

I will change it back to the default settings for the packages I
maintain.

Cheers,

- Fabian



-- 
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/1409761090.27788.153.camel@kff50

Re: Request for help: #757168 gamera: FTBFS on several architectures

[Fabian Greffrath]

Hi Daniel,

> 177>   color = size_t(*src) % COLOR_SET_SIZE;

sorry if this is trivial, but have you already checked that 
(src != NULL)?

- Fabian



-- 
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/1409760800.27788.150.camel@kff50

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 Wednesday 03 September 2014 06:51 PM, Henrique de Moraes Holschuh wrote:

On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:

> >My inclination is to ship both, the systemd service files and the
> >init scripts, in their current form along with whatever
> >limitations each may have, and let the user choose.

>
>I did not get any comment on this. How are others doing similar
>stuff while migrating to systemd ?

Well, you can always separate the important setup/teardown logic in one or
more scripts, call them from the systemd unit and also from the initscript
to not have duplicated logic.



Or better let it be as a shell init script and let systemd handle it in 
compatibility mode.


--
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/540751a0.4050...@debian.org

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

[Changwoo Ryu]

2014-09-04 1:18 GMT+09:00 Fabian Greffrath :
> Hi Changwoo Ryu,
>
>> I think yes. The cost is 24 MiB extra memory on installation, and
>> benefits are bandwidth and mirror size saving of big packages.
>
> I beg to differ. Those few kiB of bandwidth (yes, I mean it like that)
> saved when downloading a package are worthless if the decompresion
> routine forces the system onto its knees upon installation of that very
> same package.

As I posted in earlier mail, for *big* packages it could actually save
good amount of size  "per package". The total space save in the whole
archive could be a few gigabytes. And almost all desktop machines
don't fail to allocate additional memory xz needs.

OK, anyone could type "apt-get install texlive-latex-extra-doc" on
lowmem machines to install 400 MiB documents and fail on
decompressing. But for what purpose? Practically no one needs to
install such big packages on non-desktop lowmem machines. IMO
bandwidth and mirror space are much more valuable than supporting
unlikely lowmem install combinations.


-- 
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/caee2ifuzetmtaaxwv9wx_uxdgufj5bouq64oaraiu+rcfz7...@mail.gmail.com

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

[Christian Kastner]

On 2014-09-03 13:10, Changwoo Ryu wrote:
> 2014-09-03 17:04 GMT+09:00 Simon McVittie :
>> On 02/09/14 21:17, Changwoo Ryu wrote:
>>> For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e
>>> is not better than -8e.
>>
>> I don't think anyone is arguing that higher compression settings don't
>> produce better compression ratios. However:
>>
>>  Preset   DictSize   CompCPU   CompMem   DecMem
>>...
>>-6   8 MiB   6   94 MiB9 MiB <-
>>-7  16 MiB   6  186 MiB   17 MiB
>>-8  32 MiB   6  370 MiB   33 MiB <-
>>-9  64 MiB   6  674 MiB   65 MiB
>>
>> ... it's about cost/benefit. If we can save 300 KiB of compressed size,
>> but the cost is to more than triple the required memory to decompress
>> (from 9 MiB to 33 MiB), is that actually a worthwhile trade-off?

That is the key question, and I believe considering the worst possible
cost -- a package that cannot be unpacked, as in #757740 -- the
trade-off is not worth it.

> I think yes. The cost is 24 MiB extra memory on installation, and
> benefits are bandwidth and mirror size saving of big packages.

I think you are overestimating the benefits, and underestimating the costs.

Benefits: from the numbers posted in this thread, the size savings
compared to the default compression level for some sample packages are
somewhere around 3% to 4%. I claim that *practical* benefits from this
saving are insignificant to minor at best; counter-examples to this
claim are welcome.

Costs: The difference, to the default setting, in memory requirement may
be only 24MiB, but you forget that with this increase, you're definitely
crossing the 64MiB barrier. That is a common size for the amount of
physical RAM in embedded devices, and I believe that barrier should be
tested only for good reasons, otherwise stuff like #757740 happens.

And finally, the cost of deviating from a default setting itself, and
the implications for when that default changes, should be considered.

>> The d-i manual for wheezy on armel currently says that the bare minimum
>> RAM for wheezy is 31 MiB, the minimal recommended RAM is 64 MiB, and the
>> recommended RAM is 256 MiB or more. I'm sure those will increase
>> somewhat for jessie, but on a system with that sort of spec, packages
>> that need up to 65 MiB of RAM+swap to decompress (in addition to
>> whatever is needed for the kernel, and for the machine's actual
>> purpose!) seem rather greedy.
> 
> I can't imagine any 31 MiB machine which needs to render megabytes of
> Truetype fonts.

Fair enough.

> I think we can assume usual desktop machines for font packages.
> According to the d-i manual, wheezy's minimum RAM "for desktop" is 128
> MiB, and 512 MiB is recommended. For jessie, the minimum is 256 MiB
> and 1 GiB is recommended.

OK, but to me, that assumption seems contradictory to the motive of
reducing package size. If we are assuming a sufficiently spec'ed system,
say where at least 512MiB are the norm, then the cost might be
tolerable, but at the same time, the 3% to 4% savings in package size
will hardly benefit you.

> And these requirement/recommendation are far behind of the current
> computer market.

For desktop and laptop computers, yes. However, embedded devices, which
are becoming increasingly popular, are often memory-constrained.

Christian


-- 
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/540767a4.40...@kvr.at

Bug#760411: ITP: moonshot-ui -- Project Moonshot Identity Manager

[Sam Hartman]

package: wnpp
severity: wishlist
owner: hartm...@debian.org

URL: http://www.project-moonshot.org/
source: git://git.project-moonshot.org/moonshot-ui.git
license: BSD-3-Clause
Description: This package manages the Moonshot identity store,
 permitting users to add and remove identities as well as to select which
 identity is used ith a given service.

--Sam


-- 
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/01483cfe60fc-8bfa9c51-9af5-49b4-9f26-8f1da55f8e3d-000...@email.amazonses.com

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

[Jonathan Dowland]

On Wed, Sep 03, 2014 at 10:59:44AM +0200, Thorsten Glaser wrote:
> Not on avr32, and it hurts sh4, m68k and others as well.

I suppose we should always be sympathetic towards such architectures, but at
the end of the day we should primarily concern ourselves with release
architectures.


-- 
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/20140903194506.ga22...@bryant.redmars.org

Re: Jessie without systemd as PID 1?

[Steve Langasek]

On Wed, Sep 03, 2014 at 05:11:43PM +0200, Marco d'Itri wrote:
> On Sep 03, Svante Signell  wrote:

> > Having a systemd-free option for Debian Jessie is becoming more and more
> > important. Otherwise (Debian) users might do as recommended in the third
> > link: Boycott distros that use systemd.
> And I strongly encourage them to do this: we aim to be universal but we 
> cannot reasonably fit everybody's needs.

> https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Please stop using graphs showing how various teams have forced systemd onto
users' systems as if it is somehow a democratic endorsement of the outcome.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Request for help: #757168 gamera: FTBFS on several architectures

[Daniel Stender]

 Original Message 
Subject: Re: Request for help: #757168 gamera: FTBFS on several 
architectures

Date: Wed, 03 Sep 2014 19:22:00 +0200
From: Daniel Stender 
To: Fabian Greffrath 

With pleasure!

I've test patched this and rebuilded on i386 but remains failing so far. 
That's a persistent one!


Greetings,
Daniel

On 03.09.2014 18:59, Fabian Greffrath wrote:

Am Mittwoch, den 03.09.2014, 18:52 +0200 schrieb Fabian Greffrath:
In the for()-loop embracing that call in question (line 229), could you
move the "++" behind both src and dst?

- Fabian


--
https://qa.debian.org/developer.php?login=debian%40danielstender.com
PGP key: 2048R/E41BD2D0
C879 5E41 1ED7 EE80 0F2E 7D0C DBDD 4D96 E41B D2D0





--
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/540784b2.1000...@danielstender.com

Applying to Become a Maintainer

[FERNANDO CROWLEY]

Hello ,want to help i am  novice Linux love to learn more on the OS 
debianplease direct me

Re: Jessie without systemd as PID 1?

[Marco d'Itri]

On Sep 03, Steve Langasek  wrote:

> > https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> 
> Please stop using graphs showing how various teams have forced systemd onto
> users' systems as if it is somehow a democratic endorsement of the outcome.
I am not sure about how the concept of democracy applies to this, but 
the graph clearly shows that nobody is being forced to do anything and 
indeed about 4000 users choose to install systemd-shim and to not use 
systemd.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Jessie without systemd as PID 1?

[Cameron Norman]

El mié, 3 de sep 2014 a las 4:07 , Marco d'Itri  
escribió:

On Sep 03, Steve Langasek  wrote:

 > 
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
 
 Please stop using graphs showing how various teams have forced 
systemd onto users' systems as if it is somehow a democratic 
endorsement of the outcome.
I am not sure about how the concept of democracy applies to this, but 
the graph clearly shows that nobody is being forced to do anything 
and 
indeed about 4000 users choose to install systemd-shim and to not use 
systemd.


Ok, let me explain Steve's POV. Many packages depended on 
libpam-systemd before systemd-shim was ever in the archive, leading to 
systemd-sysv being installed by a normal dist-upgrade on Sid (and, 
although I am not sure, testing). The alternative was often to have 
GNOME or Network Manager removed, two very popular packages (and the 
latter quite important). Even after systemd-shim was uploaded to the 
archive (still at logind v204 here), libpam-systemd depended on 
"systemd-sysv | systemd-shim". This meant that users' systems would 
switch init systems on a normal dist-upgrade *unless* they manually 
intervened and knew which package they had to install to avoid that. 
Finally, systemd v208 was uploaded to unstable with an unconditional 
dependency on systemd-sysv. All of these actions led to users 
experiencing a change of init system before they had taken action to 
change init systems, which means that the graphs are not reliable in 
claiming that the majority of users wanted systemd as their init system.


I can not speak for Steve, but I recognize that some or all of those 
actions above were called for. The final one especially (systemd v208 
upload), since their was ample warning and communication (something 
like one or two months I think), the move was a long time coming, and 
systemd was chosen as the default init system by then (not true for the 
other two actions).


I hope that helps you understand how the graph does not depict how many 
users elected to use systemd as their init system.


Best regards,
--
Cameron Norman

Re: Jessie without systemd as PID 1?

[Marc Haber]

On Thu, 4 Sep 2014 01:07:20 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Sep 03, Steve Langasek  wrote:
>> Please stop using graphs showing how various teams have forced systemd onto
>> users' systems as if it is somehow a democratic endorsement of the outcome.
>I am not sure about how the concept of democracy applies to this, but 
>the graph clearly shows that nobody is being forced to do anything and 
>indeed about 4000 users choose to install systemd-shim and to not use 
>systemd.

I would like to know how many of those 4000 users had to install
systemd-shim to get vital functionality back that

  - originated from a Debianism in sysvinit
  - was - rightfully - not on the agenda of systemd since it was a
Debianism
  - is still being ignored by the people reponsible to _integrate_
systemd with Debian.

One example of such a Debianism is the support of the keyscript=
option in /etc/crypttab that is not available on Debian systems
running systemd with no viable alternatives available.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1xpqeb-0002bx...@swivel.zugschlus.de

Cinnamon environment now available in testing

[Margarita Manterola]

Hi all!

After quite a few months of polishing packages, fixing issues, and
making sure that everything builds where it's supposed to build,
cinnamon is now fully available in testing.

If you already have a desktop environment, you can install the
packages needed by cinnamon by doing: apt-get install cinnamon-core.

There's also cinnamon-desktop-environment, that pulls in usually
needed packages, for the users that don't have another desktop
environment installed.

There are likely quite a number of bugs that we haven't found yet, we
will welcome bug reports.

If you are interested in helping us out, we work through the
pkg-cinnamon project in alioth, which also includes it's own mailing
list, and you can contact us through #debian-cinnamon in OFTC.

-- 
Cheers,
Marga


-- 
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/cap+fksoksg-zfqvuryx7fn9ef6onpe-ew4fyujmfcdau9t1...@mail.gmail.com