Bug#710756: ITP: libio-event-perl -- Perl module that ties filehandles for nonblocking IO with object callbacks

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libio-event-perl
  Version : 0.812
  Upstream Author : David Muir Sharnoff 
* URL : https://metacpan.org/release/IO-Event
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module that ties filehandles for nonblocking IO with 
object callbacks

IO::Event provides a object-based callback system for handling
nonblocking IO. The design goal is to provide a system that
just does the right thing w/o the user needing to think about
it much.


-- 
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/20130602071006.11459.55613.reportbug@localhost

Re: Feedback on Debian 7.0

[Andrei POPESCU]

On Du, 02 iun 13, 09:57:34, Daniel Hartwig wrote:
> 
> It doesn't, see .  As no mirror was
> chosen during the install, none is placed in sources.  A default can
> of course be selected and commented out, provided that such default
> agrees with the increase in load.

It could be the primary mirror for the country chosen during install. 
This should spread the load a bit.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Switching to mozilla ESR in stable-security

[Moritz Mühlenhoff]

Christoph Anton Mitterer  schrieb:
>
> --=-dGSWlplfgLb+HUgDia6J
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> Hi Moritz.
>
> Moritz Muehlenhoff wrote:
>> In the future the majority of packages should thus rather be installed
>> through http://addons.mozilla.org instead of Debian packages.
> Form a security POV, I think this is really quite dangerous... actually
> tendency should go towards the direction that users install plugins
> addons only via the package management system.
>
> These plug-in systems which come with their own "package/installation
> management" are IMHO also quite bad from a philosophical POV... I mean
> they try to replace the traditional package management system, which is
> there and superior for very good reasons.
>
> Of course this doesn't mean that I wouldn't see the problem you face
> with keeping that stuff running and security supported.

In think in the future providing the xul extensions through the Debian
Developer repositories provided by the FTP masters would be the most
elegant way: There's a one month overlap between ESR and ESR++, so there's
sufficient time to prepare/test extensions before the ESR++ hits users.

However, we don't currently have these repositories, so addons.mozilla.org
is the best we have for now.

Cheers,
Moritz







-- 
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/slrnkqm2a4.4u1@inutil.org

Re: Switching to mozilla ESR in stable-security

[Moritz Mühlenhoff]

Didier 'OdyX' Raboud  schrieb:
>> FWIW, I don't. I think the compromise that the security team is proposing is
>> much more reasonable than such an alternative.
>
> That compromise (which I do definitely support for wheezy) puzzles me most 
> for 
> the precedent it creates: if we "give up" [0] maintaining some of the most 
> security-sensitive softwares up to our stable policy, why should other 
> packages be bound to it?

- having a web browser in the distro is crucial and 
  $random-other-app-to-buggy-to-support isn't
- Mike has done a terrific job of backporting security fixes (up to 100
  security patches per month!), but modern web browsers expose a unique 
  environment on their own. Even if we backport security fixes (and we
  cannot continue any longer since the resources are not there anymore!)
  we still miss out important security enhancements (e.g. lenny-security
  missed CSP support). Not to mention the fast-moving browser requirements,
  which are not security related (e.g. HTML, WebGL).
- The policy we're following is the intended update policy for enterprise
  envionments (e.g. Ubuntu updates to the current upstream release even in
  their oldest supported distro)
- The ESR releases shipped by Mozilla receive more QA testing than we
  could possibly provide for our backports.

Cheers,
Moritz


-- 
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/slrnkqm1v1.4u1@inutil.org

Re: Switching to mozilla ESR in stable-security

[Thomas Goirand]

On 06/02/2013 01:35 AM, Florian Weimer wrote:
> I'm not sure if moving packages between repositories makes that much
> of a difference.  Either they work acceptably well, or they don't,
> independently of the delivery mechanism.

The main difference would be that we accept the fact that Mozilla
software aren't suitable to stay in the stable Debian, and that we
declare that they can only be sustainable through a repository that has
recent updates. Backports seems a way to me, though volatile maybe as
well, IMO.

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/51ab0ab6.90...@debian.org

Re: Switching to mozilla ESR in stable-security

[Andrei POPESCU]

On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote:
> 
> As such, we'll switch to releasing the ESR releases of iceweasel
> and icedove in stable-security. 

Would it be possible to switch to the Mozilla branding in this case?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: systemd .service file conversion

[Tollef Fog Heen]

]] Salvo Tomaselli 

> In data sabato 01 giugno 2013 22.02.25, Uoti Urpala ha scritto:
> 
> > So, to sum it up: Upstream systemd is ready for production and suitable
> > to be chosen as the default Debian init.
>
> Can you back up your claim somehow?

Could we please not be having this discussion at this time?  We're not
going to switch the default just right now and any discussions about it
is a waste of energy.

> > You mixed up these two things (you also talked
> > about use in Fedora, which obviously says nothing about Debian
> > packaging). It's also obvious your time figures were completely made up
>
> My figures come from the fact that any project with 2 new versions per week 
> can't be called "mature". Source: download page of systemd.

Since you repeat this claim: over the last year and a bit, systemd has
seen 21 releases.  I agree this is quite a lot, but it's hardly twice a
week.

-- 
Tollef Fog Heen, with his systemd maintainer team hat on
UNIX is user friendly, it's just picky about who its friends are


-- 
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/m28v2slvxt@rahvafeir.err.no

Re: Feedback on Debian 7.0

[Marcin Kulisz]

On 2013-06-02 11:06:40, Andrei POPESCU wrote:
> On Du, 02 iun 13, 09:57:34, Daniel Hartwig wrote:
> > 
> > It doesn't, see .  As no mirror was
> > chosen during the install, none is placed in sources.  A default can
> > of course be selected and commented out, provided that such default
> > agrees with the increase in load.
> 
> It could be the primary mirror for the country chosen during install. 
> This should spread the load a bit.

Why not to use http://http.debian.net/ ?
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Re: default MTA

[Jean-Christophe Dubacq]

Le 31/05/2013 13:10, Marc Haber a écrit :
> On Fri, 31 May 2013 08:41:56 +0200, Jean-Christophe Dubacq
>  wrote:
>> Le 30/05/2013 18:29, Marc Haber a écrit :
>>> On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters 
>>> wrote:
 Seems the solutions are very focussed on the assumption that things
 cannot be changed. E.g. programs currently send email, so email it has
 to be forever.
>>>
>>> It is not a good idea to drop the way that > 90 % of programs use to
>>> deliver messages. I really hate the idea of having a thing as fragile
>>> as dbus on a server just to collect status messages.
>>
>> 73.6% of all statistics are made up.
> 
> You have a point here. I shold have written the vast majority.
> 
>> The way most programs deliver messages is actually syslog.
> 
> Which is an epic nightmare to parse automatically if one needs to put
> messages in relation to each other and is only readable if all
> messages are shorter than, say, 160 characters. Even firewall log
> messages are way longer than that already.
> 

And yet, I remain convinced that I do redirect many root accounts to my
own account, and I have yet to see very important messages coming that way.

When I stop receiving useless messages from one machine, *that* means
something, namely, that the machine is broken. But anyone seriously
keeping an eye on server will install some kind of munin/nagios, and on
desktops, disk tools will notify the user when the computer is used.

All the rest belongs to syslog. I seem to recall that some init system
has a specific additional format to store logs and make them easily
searchable, by the way.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature

Re: Debian systemd survey

[Vincent Lefevre]

On 2013-05-30 13:59:09 -0700, Russ Allbery wrote:
> Also, determining which flags to pass to the daemon from some other
> configuration file, which is a common use of /etc/default files, is a hack
> to work around the fact that an init script is not really user-editable.
> We therefore move the parts that we expect users to change into a
> separate, simpler configuration file to avoid making them brave the
> dangers of the init script and deal with lots of dpkg configuration file
> prompts when we fix bugs in the init script.  But with a systemd or
> upstart configuration file, it becomes reasonable to have the user just
> edit that file directly to pass different parameters to the daemon, since
> the configuration file is already as simple, in many cases, as the
> /etc/default file was.

Most config files are not really user-editable under Debian. I mean:
they can be editable, but there are serious drawbacks during upgrades.
Indeed most often the user has the choice between installing the new
version (but his local changes are lost) and keeping the old version
(but he doesn't benefit from new features, and worse, the old version
of the config file is not guaranteed to work well with the new version
of the package). The user can also start a shell to do the merge on
his side, but this may take time... So, splitting config files is a
way to avoid that, not in all cases but in most cases (this is not
specific to sysvinit, apparently just a consequence of the old
wishlist bug 32877, from 1999!).

Aren't systemd and upstart config files affected by this problem?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130602121521.ga17...@xvii.vinc17.org

Re: Switching to mozilla ESR in stable-security

[Moritz Mühlenhoff]

Ansgar Burchardt  schrieb:
> Hi,
>
> On 05/28/2013 22:33, Moritz Muehlenhoff wrote:
>> As such, we'll switch to releasing the ESR releases of iceweasel
>> and icedove in stable-security. 
>> Reverse-deps of the older xulrunner libs have negligable security
>> impact and we won't update them any further.
>> 
>> One problematic aspect are the various xul-ext-* packages currently
>> packaged. It's very likely that some of them will break with ESR17
>> and ESR24 in the future.
>> 
>> However, there's not much we can do here. We can select a narrow (!)
>> set of important addons (e.g. enigmail for Icedove) that we will
>> keep in sync through stable-security, but that doesn't scale for
>> the full scale of Mozilla extensions currently packaged.
>> 
>> In the future the majority of packages should thus rather be installed
>> through http://addons.mozilla.org instead of Debian packages.
>
> As mentioned on IRC, I wonder what we should do with these extentions
> now and for future releases. There seem to be several options:
>
> a) Remove most Mozilla extensions from stable/testing/unstable and
>let users install them from addons.mozilla.org.
>
>Important addons could stay if agreed with release and/or security
>teams, e.g. enigmail (mentioned above) or adblock (part of the
>default Debian GNOME installation).
>
> b) Let maintainers update extensions via either -security or
>-(proposed-)updates.
>This causes additional work for the security team or the release
>team for at least coordinating updates. I wouldn't expect them to
>be able to review the changes which means a break from our current
>stable policy.
>
> b2) like b), but only do so for jessie and remove the extensions from
>testing/unstable.
>
> c) Let maintainers provide updated extensions via an additional
>repository (e.g. mozilla.d.n or some developer repository).

(c) is my prefered way to move forward. We'll release enigmail in sync
with icedove once icedove is ready.

Cheers,
Moritz


-- 
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/slrnkqm3qr.8tn@inutil.org

Re: Feedback on Debian 7.0

[Cyril Brulebois]

Marcin Kulisz  (02/06/2013):
> Why not to use http://http.debian.net/ ?

Surely the .net part of it?

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Feedback on Debian 7.0

[Didier 'OdyX' Raboud]

Le dimanche, 2 juin 2013 15.54:31, Cyril Brulebois a écrit :
> Marcin Kulisz  (02/06/2013):
> > Why not to use http://http.debian.net/ ?
> 
> Surely the .net part of it?

If that's the reason, why do we have cdn.debian.net in the list of mirrors 
used in d-i? I'm not against either but would prefer to see the same standards 
apply to both solutions.

Cheers,
OdyX


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

Re: systemd .service file conversion

[Stuart Prescott]

> FWIW, I happen to agree with Marc. Having everything in /etc makes it
> *much* clearer what the actual current configuration is; it also means
> that if the defaults change on upgrade, your environment doesn't
> suddenly start acting differently or inconsistently.

If we want everything that makes a configuration decision in our /etc then 
we would want all the source packages there. After all, every tool we use 
has some sort default behaviour compiled into it. If desired, it can (often) 
be overridden with a config file in /etc (perhaps setting the environment 
appropriately). Open just about any man page and look for the word "default" 
and ask if, when we say "all configuration in /etc", do we actually have 
that?

Is the configuration default that "ls --color" uses red for compressed files 
expressed in /etc? How about apt using priorities of 100 for installed 
packages and 500 for packages in repositories? Or grep(1) using basic regex 
not extended regex? Or find(1) not following symbolic links? Or that 
relatime is a default mount option for ext4?

But do we care? No. We're able to distinguish between defaults and local 
configuration for all these standard tools. We understand that there are 
defaults and if we don't like them we need to create a configuration file or 
change our set-up in some way. We don't demand that apt install a 
/etc/apt/preferences that contains that default pinning, we accept that 
there is a default and we know that, if we want to override it, we should 
create that file ourselves and configure away.

I idly wondered if perhaps /lib/udev just should be compiled into one (ugly) 
binary file so that it didn't *look* like a pile of text configuration 
files. Then, perhaps everyone would be happier as it would be easier to 
distinguish between "compiled in defaults" and local configuration. But even 
that isn't necessary -- we've already shown we can cope files that look like 
config files being in other locations to provide us with defaults -- xorg 
packages drop files with defaults in /usr/share/X11/xorg.conf.d/ that we can 
cheerfully override in /etc/X11/xorg.conf.d/ if we need to. The 1200 
packages that ship files in foo.d/ directories that aren't inside /etc would 
tend to suggest we can cope with this.

I think policy is quite clear -- configuration files live in /etc. This part 
of policy is designed to stop (for example) some silly web app having us 
hunt around to find /usr/share/foo/config.php instead of permitting us to 
configure the thing from /etc. It is not trying to conflate defaults with 
configuration files; I think we're good at misidentifying which files are 
configuration files. 

So in all these other cases including traditional unix tools and our own 
tools that we use on a daily basis, we manage to have defaults *not* in /etc 
and the local configuration files that change the defaults in /etc. I am 
left wondering why udev supposed to be different to that.


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8




-- 
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/kofjml$3np$1...@ger.gmane.org

kFreeBSD’s future [was: systemd .service file conversion]

[Josselin Mouette]

Le samedi 01 juin 2013 à 11:56 +0200, Marc Haber a écrit : 
> On Fri, 31 May 2013 14:08:01 +0200, Josselin Mouette 
> >I disagree with this claim. The wheezy release for kfreebsd is a joke,
> >and we should end it with jessie unless there are real users.
> 
> I find the way you're dismissing other people's work utterly
> offensive. Please think before you write thing like that.

How is that “other people’s” work?
I was among those who spent quite some time to fix packages so that they
build on kfreebsd, yet I can’t say I’m pleased with the result,
especially because nobody ever bothered to test anything.

Just look at popcon: 
* kfreebsd-* reports 183 users, 142 of which use stable.
* sparc reports 183 users, 42 of which use stable.

Graphs are very interesting too: compared to other architectures, there
is a peak of kfreebsd installations after the squeeze and wheezy
releases, something that other architectures don’t notice. So not only
kFreeBSD has just as many users as a dying port (that’s supposing the
same share use popcon), but figures prove these users don’t care about
testing and unstable.

Apart from packages which interact closely with the CPU features, such
as interpreters, there isn’t much doubt that a package that works on
amd64 will work on sparc or ia64. This doesn’t hold for kFreeBSD, for
which every package can fail (and often does fail). Unless we have MANY
more unstable users to ensure our packages work, including users for all
subsystems (not just pf), I don’t think we should release such ports.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1370182767.9583.16.camel@tomoyo

Re: systemd .service file conversion

[Josselin Mouette]

Le samedi 01 juin 2013 à 11:59 +0200, Marc Haber a écrit : 
> Before saying things like that, please file a GR removing the
> "universal" from Debian's claim.

Silly me. I thought “universal” was meant about usage, like the ability
to run the same OS on a supercomputer, a toaster, a smartphone and a
space station.

I hadn’t understood it was about being able to run all the kernels in
the universe. This makes all more sense now. Thanks for fixing this
misunderstanding.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1370183111.9583.19.camel@tomoyo

Re: docbook-xsl: why only one version ?

[Jerome BENOIT]

Hello Paul,

thanks for your reply.

On 02/06/13 08:57, Paul Gevers wrote:
> Hi Jerome,
> 
> On 02-06-13 06:30, Jerome BENOIT wrote:
>> I have to deal with docbook-xsl for one of my package.
>> I am not familiar with docbook-xsl stuff, so my question may sound naive.
>> It appears that the upstream stuff play with docbook-xsl version 1.75.2 ,
>> but not 1.76.1 : only the last one is available on Wheezy, so why only one
>> version is made available ? 
> 
> If we would keep all versions of all packages we ever had, our
> infrastructure would blow up,

I understand this part of the story.



 and also users wouldn't like the
> additional overhead.

But the final user is free to install, to uninstall and to purge.


 Usually you don't gain much by keeping old
> versions,

I am agree, but docbook-xsl does not seem a usual package in that matter:
keeping different version looks to be in its gene, so to speak,
as a `catalog' is maintained to deal easily with different versions.
In fact, the `catalog' part seems very important: does a `catalog'
with only one choice make sense ?
Second, different version of some packages with no `catalog' feature
already coexist in Debian: python, gcc, and certainly others.


 although we do have snapshot [1] for individual use.

My concern is not about keeping old versions of the packages but rather
of keeping a small set of still used version of docbook-xsl data: I guess
that [1] is rather meant to keep a trace of the past, what is very good
by the way.

> 
> So my guess is that you will have to patch your package (please send the
> patch upstream)

it is unlikely that the upstream team wants to (as it is non-free software).

 and use the latest version in sid (that is where you are
> building for). By the way, the version in Wheezy is nearly irrelevant
> for your software development, so you should work to get 1.78.1 working.

Thanks I have noticed. I have also observed that the code in the docbook-xsl
metadata (or whatever) does not seem as stable as a C standard, hence certainly
the `catalog' feature. 

In short, the initial question may be rephrase:
what there is no `catalog' policy for docbook-xsl on Debian ?


> 
> Paul

Jerome

> 
> [1] http://snapshot.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/51ab665a.7030...@rezozer.net

Re: Switching to mozilla ESR in stable-security

[brian m. carlson]

On Sun, Jun 02, 2013 at 12:10:56PM +0300, Andrei POPESCU wrote:
> On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote:
> > 
> > As such, we'll switch to releasing the ESR releases of iceweasel
> > and icedove in stable-security. 
> 
> Would it be possible to switch to the Mozilla branding in this case?

I suspect not, since we are likely still going to apply the 40 patches
that we currently apply.  Also, such a major change is likely to break
things in a security upload.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Switching to mozilla ESR in stable-security

[Moritz Mühlenhoff]

Andrei POPESCU  schrieb:
>
> --Yvzb+MHGXtbPBi5F
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote:
>>=20
>> As such, we'll switch to releasing the ESR releases of iceweasel
>> and icedove in stable-security.=20
>
> Would it be possible to switch to the Mozilla branding in this case?

No, that is unrelated.

Cheers,
Moritz


-- 
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/slrnkqmitk.5sd@inutil.org

Re: Debian systemd survey

[Simon McVittie]

On 02/06/13 13:15, Vincent Lefevre wrote:
> Most config files are not really user-editable under Debian.
...
> So, splitting config files is a
> way to avoid that, not in all cases but in most cases (this is not
> specific to sysvinit, apparently just a consequence of the old
> wishlist bug 32877, from 1999!).
> 
> Aren't systemd and upstart config files affected by this problem?

The current upstream systemd has an "include" mechanism by which the
unit in /etc can say "copy all keys from the upstream version in /lib,
then set Foo=bar", and also a mechanism by which individual keys in a
unit can be overridden by a separate file in a .d directory
corresponding to that unit. I think the older version currently in
Debian has the former, but not the latter.

I don't know about Upstart. If it doesn't have an equivalent of that
systemd feature, I'm sure one could be added.

S


-- 
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/51ab73d4.2050...@debian.org

Re: docbook-xsl: why only one version ?

[Mathieu Malaterre]

Jérome,

On Sun, Jun 2, 2013 at 5:35 PM, Jerome BENOIT  wrote:
[...]
> In short, the initial question may be rephrase:
> what there is no `catalog' policy for docbook-xsl on Debian ?

I believe there is a slight misunderstanding. /etc/xml/catalog is
properly setup on your debian system. However it is only used when
validating docbook 4.x or 5.x instances.

There should not be any difference in between using docbook-xsl 1.75
or docbook-xsl 1.76. Those are XSLT filters, they are only used during
the transformation of your docbook XML file into a different
representation (manpage, HTML, PDF ...).

If you believe you found an issue with docbook >> 1.75.2, please
report it using our BTS. docbook-xsl is pretty good at preserving
backward compatibility.

thanks.


--
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/ca+7wuszn4uknnpmy_2q0qtjsatmybc2xnzpovu4+70r9cjk...@mail.gmail.com

Re: Switching to mozilla ESR in stable-security

[Philipp Kern]

On Sun, Jun 02, 2013 at 05:04:54PM +0800, Thomas Goirand wrote:
> On 06/02/2013 01:35 AM, Florian Weimer wrote:
> > I'm not sure if moving packages between repositories makes that much
> > of a difference.  Either they work acceptably well, or they don't,
> > independently of the delivery mechanism.
> The main difference would be that we accept the fact that Mozilla
> software aren't suitable to stay in the stable Debian, and that we
> declare that they can only be sustainable through a repository that has
> recent updates. Backports seems a way to me, though volatile maybe as
> well, IMO.

Apparently it takes long to die/bury, but volatile as a separate thing
does not exist (anymore). It was replaced by a speedy way to bring
updates to stable users instead of an overlay with a different update
policy.

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

Re: Debian systemd survey

[Russ Allbery]

Vincent Lefevre  writes:

> Most config files are not really user-editable under Debian. I mean:
> they can be editable, but there are serious drawbacks during upgrades.
> Indeed most often the user has the choice between installing the new
> version (but his local changes are lost) and keeping the old version
> (but he doesn't benefit from new features, and worse, the old version of
> the config file is not guaranteed to work well with the new version of
> the package). The user can also start a shell to do the merge on his
> side, but this may take time... So, splitting config files is a way to
> avoid that, not in all cases but in most cases (this is not specific to
> sysvinit, apparently just a consequence of the old wishlist bug 32877,
> from 1999!).

> Aren't systemd and upstart config files affected by this problem?

They are somewhat, but it's much less bad because they're so simple.  You
don't have to write nearly as much there, and if you design them
carefully, you can reduce even that complexity.  My impression so far is
that systemd has taken this even farther than upstart, but I've not done
an exhaustive comparison.

As a result, the config files look rather a lot like /etc/default files,
and are amenable to a similar merge process: look at each setting, since
there's only a handful, and think about which setting you want.

For example, here's the complete systemd file for rsyncd:

[Unit]
Description=fast remote file copy program daemon
ConditionPathExists=/etc/rsyncd.conf

[Service]
ExecStart=/usr/bin/rsync --daemon --no-detach

[Install]
WantedBy=multi-user.target

There's really no reason to have something like an /etc/default setting
for that, the way there is for the rsyncd init script.  You can just edit
that directly (well, it's systemd, so you have to copy it into /etc and
make a new version and then won't know if anything about the default
changes -- a truly awful design, but that's another argument).

Now, rsyncd is one of the simplest init scripts, and more complicated
services aren't quite that nice.  But they stay surprisingly simple.

-- 
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/8761xwjvob@windlord.stanford.edu

Re: systemd .service file conversion

[John Paul Adrian Glaubitz]

On 06/02/2013 04:25 PM, Josselin Mouette wrote:

Le samedi 01 juin 2013 à 11:59 +0200, Marc Haber a écrit :

Before saying things like that, please file a GR removing the
"universal" from Debian's claim.


Silly me. I thought “universal” was meant about usage, like the ability
to run the same OS on a supercomputer, a toaster, a smartphone and a
space station.


I want that toaster :D.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/51ab82ae.8010...@physik.fu-berlin.de

Re: Debian systemd survey

[Michael Biebl]

Hi Russ,

Am 02.06.2013 18:59, schrieb Russ Allbery:
> For example, here's the complete systemd file for rsyncd:
> 
> [Unit]
> Description=fast remote file copy program daemon
> ConditionPathExists=/etc/rsyncd.conf
> 
> [Service]
> ExecStart=/usr/bin/rsync --daemon --no-detach
> 
> [Install]
> WantedBy=multi-user.target
> 
> There's really no reason to have something like an /etc/default setting
> for that, the way there is for the rsyncd init script.  You can just edit
> that directly (well, it's systemd, so you have to copy it into /etc and
> make a new version and then won't know if anything about the default
> changes -- a truly awful design, but that's another argument).

You do not necessarily have to copy the whole file. You can
override/amend the .service file by using a foo.service.d/*.conf snippet.
Say you just want to change the ExecStart line, you can do the following:

echo "ExecStart=/usr/bin/rsync --daemon --my-funky-param" >
/etc/systemd/system/rsync.service.d/my-override.conf

This mechanism is not yet in v44, but a newer version of systemd will be
uploaded to unstable soonish having this feature.

As for noticing upstream default changes: There is a tool called
systemd-delta, which can notify you about such differences.

That all said, I think one has to treat .service files more like
application ressource files. Having to change them should be the
exception rather then the norm. E.g., I see the need being able to
modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore
rsyslog.service) not so much.

Michael




-- 
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: Feedback on Debian 7.0

[Erik Heil]

Hello,
Thanks for your feedback. As a user, I think Debbie and 7.0 is great. Mia have 
the latest software install, but you have other options. As first graphical 
editors, you have choices like Ex DMACS. Also, there are others. If you install 
a desktop environment, we will certainly get a graphical text editor. As for 
editors, you have a lot of choices. It all depends on what sort of work was to 
accomplish. So, you need to search for what you need.

Sent from my iPad

On Jun 1, 2013, at 1:52 AM, Hashem Nasarat  wrote:

> 
> On 06/01/2013 01:06 AM, Nikolas Kallis wrote:
>> 
>> Another thing I am pissed off about is the lack of a graphical
>> text-editor being included in Debian 7.0. The last time I checked, my
>> calendar said 2013, and as so, would not expect a text-editor not
>> being included in a desktop-environment based operating system.
>> 
>> I know there is the 'nano' command line based text-editor included in
>> Debian 7.0, but I, along with 99.999% of the world uses their computer
>> in a desktop environment, so a text-editor should be included.
> gedit (though it's poorly named) is included
> 
> 
> -- 
> 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/51a98c1e.2040...@gmail.com
> 


--
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/1de15496-2bc7-43a3-883d-997753f85...@gmail.com

Re: Debian systemd survey

[Uoti Urpala]

Russ Allbery wrote:
> There's really no reason to have something like an /etc/default setting
> for that, the way there is for the rsyncd init script.  You can just edit
> that directly (well, it's systemd, so you have to copy it into /etc and
> make a new version and then won't know if anything about the default
> changes -- a truly awful design, but that's another argument).

You don't necessarily need to copy the file into /etc to change
something. Depending on the change, it may be more appropriate to create
a new file using ".include" for the old file and then overriding only
one particular setting. Telling people to blindly copy everything is bad
advice IMO - if you have even the settings you _don't_ want to override
in the /etc file, then merging is necessary on upgrades if you still
want to follow changes to those default settings.

Whether there are notifications from the packaging system when package
upgrades change the default file has nothing to do with systemd design.
That's up to the Debian packaging. Tollef Fog Heen just said in a post
yesterday "it's quite likely we'll go with an approach that uses ucf and
does notify on update-with-changes". Of course rsync has another
maintainer who might or might not choose the same behavior, and
obviously he hasn't enabled any notifications at the moment. But if you
disagree with that, blaming the design of upstream systemd is not the
right target.


-- 
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/1370196033.3628.343.camel@glyph.nonexistent.invalid

Re: Debian systemd survey

[Russ Allbery]

Michael Biebl  writes:
> Am 02.06.2013 18:59, schrieb Russ Allbery:

>> There's really no reason to have something like an /etc/default setting
>> for that, the way there is for the rsyncd init script.  You can just
>> edit that directly (well, it's systemd, so you have to copy it into
>> /etc and make a new version and then won't know if anything about the
>> default changes -- a truly awful design, but that's another argument).

> You do not necessarily have to copy the whole file. You can
> override/amend the .service file by using a foo.service.d/*.conf
> snippet.

That doesn't really help -- it's exactly changes to ExecStart that I want
to be informed of by dpkg.

Suppose that I modify the systemd file to add an additional command-line
flag, and the package maintainer separately changes the systemd file to
add a different command-line flag.  When I upgrade the package, I really
want both flags.  dpkg will at least warn me that this happened and show
me a diff, and I can then make the obvious change.  With the systemd
configuration strategy, this change is completely hidden to me.

There are many daemons in Debian that are configured with a variety of
command-line options in the package and that the end user will want to
customize with other command-line options without losing the ones provided
by the package maintainer.  This is a very common use case, and one that
we frequently handle poorly and awkwardly with /etc/default files right
now and could handle much better with upstart or systemd, except that
systemd's configuration handling shoots itself in the foot.

> As for noticing upstream default changes: There is a tool called
> systemd-delta, which can notify you about such differences.

Does it do the proper comparison?  I don't want to just be informed that
my version is different from the default version: I know that.  I want to
know if the package file has changed since I based my version on it.  This
is exactly the behavior that we get right now from dpkg configuration file
handling.  (Ideally, I also want to know *how* it's changed so that I get
a full three-way merge behavior, but that's a harder problem, and only ucf
sort of does that.  I wouldn't expect the change in init system to try to
tackle that problem, although of course it would be nice.)

> That all said, I think one has to treat .service files more like
> application ressource files. Having to change them should be the
> exception rather then the norm. E.g., I see the need being able to
> modify /etc/rsyslog.conf, but /etc/init.d/rsyslog (and therefore
> rsyslog.service) not so much.

No, I strongly disagree.  This defeats one of the primary gains from
moving to upstart or systemd as I've described at some length in this
thread.  One of the points is to get *away* from this broken situation
where the daemon initialization file is an uneditable blob.

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

Re: systemd .service file conversion

[Wouter Verhelst]

On 02-06-13 16:09, Stuart Prescott wrote:
> 
>> FWIW, I happen to agree with Marc. Having everything in /etc makes it
>> *much* clearer what the actual current configuration is; it also means
>> that if the defaults change on upgrade, your environment doesn't
>> suddenly start acting differently or inconsistently.
> 
> If we want everything that makes a configuration decision in our /etc then 
> we would want all the source packages there. After all, every tool we use 
> has some sort default behaviour compiled into it. If desired, it can (often) 
> be overridden with a config file in /etc (perhaps setting the environment 
> appropriately).
[...snip extreme example...]

I'm not saying it's wrong to have incomplete configuration files, or
that it's wrong to have defaults live elsewhere than in /etc.

I'm just saying that I prefer it if files in /etc contain "all" (to a
reasonable extent) configuration, including defaults, over having /etc
be "empty" by default and just existing to override the real
configuration which exists elsewhere, in places like /usr or similar.

That there are other possible ways is obvious; the fact that these other
ways behave differently, and that it is not my *preference* to have such
other ways was the point of my mail.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51ab8df5.1030...@debian.org

Re: Debian systemd survey

[Tollef Fog Heen]

]] Russ Allbery 

> There's really no reason to have something like an /etc/default
> setting for that, the way there is for the rsyncd init script.  You
> can just edit that directly (well, it's systemd, so you have to copy
> it into /etc and make a new version and then won't know if anything
> about the default changes -- a truly awful design, but that's another
> argument).

.. and to work around that, we're likely to tell people to use ucf for
the files, so you will get notification on updates.  (Or you can use the
.include syntax as smcv wrote about.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/878v2swerb@xoog.err.no

Re: Debian systemd survey

[Chow Loong Jin]

On 03/06/2013 00:33, Simon McVittie wrote:
> [...]
> The current upstream systemd has an "include" mechanism by which the
> unit in /etc can say "copy all keys from the upstream version in /lib,
> then set Foo=bar", and also a mechanism by which individual keys in a
> unit can be overridden by a separate file in a .d directory
> corresponding to that unit. I think the older version currently in
> Debian has the former, but not the latter.
> 
> I don't know about Upstart. If it doesn't have an equivalent of that
> systemd feature, I'm sure one could be added.

If it's just overriding statements in an init script, a .override file can be
dumped into /etc/init.

From init(5):
> ·   Files ending in .override are called override files. If an override file
> is present, the stanzas it contains take precedence over those
> equivalently named stanzas in the corresponding configuration file
> contents for a particular job. The main use for override files is to
> modify how a job will run without having to modify its configuration file
> directly. See the section Override File Handling below for further
> details.

-- 
Kind regards,
Loong Jin



signature.asc
Description: OpenPGP digital signature

Re: docbook-xsl: why only one version ?

[Jerome BENOIT]

Hello,

On 02/06/13 18:54, Mathieu Malaterre wrote:
> Jérome,
> 
> On Sun, Jun 2, 2013 at 5:35 PM, Jerome BENOIT  wrote:
> [...]
>> In short, the initial question may be rephrase:
>> what there is no `catalog' policy for docbook-xsl on Debian ?
> 
> I believe there is a slight misunderstanding. /etc/xml/catalog is
> properly setup on your debian system.

I have no doubt about it.

I guess that what I do not get is the meaning of docbook-xsl versionning
for the metadata 


 However it is only used when
> validating docbook 4.x or 5.x instances.
> 
> There should not be any difference in between using docbook-xsl 1.75
> or docbook-xsl 1.76. Those are XSLT filters, they are only used during
> the transformation of your docbook XML file into a different
> representation (manpage, HTML, PDF ...).

or imported inside other xsl filters.


> 
> If you believe you found an issue with docbook >> 1.75.2,


I guess it fine.

 please
> report it using our BTS. docbook-xsl is pretty good at preserving
> backward compatibility.
> 

I think I am getting a better idea of my issue:
the upstream furnished xsl files (XSLT filters ?) certainly depends
via `import' on the xsl files of docbook-xsl 1.72.2 material while
they should not: in short, they are (very) badly written in the sense
that they do not follows the basic docbook rules.
I guess I was misled by them.

Very sorry for the noise,
Jerome


> thanks.


-- 
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/51ab9691.70...@rezozer.net

Test suite best practices ?

[Xavier Roche]

Hi folks,

Are there any "best practices" on how to handle test suite in Debian ?

Currently the best way seems to use the automake's testsuite, and call
dh_auto_test after dh_auto_build - but it generally needs some hacking
wrt. library and binary pathes - ie. something ugly like:

# Makefile.am
TESTS_ENVIRONMENT =
LD_LIBRARY_PATH=$(top_builddir)/src/.libs:$$LD_LIBRARY_PATH
TESTS_ENVIRONMENT += PATH=$(top_builddir)/src/.libs:$$PATH
TESTS = *.test

There might be better ways (and more portable - are we sure that
LD_LIBRARY_PATH is awlays the right one ?) ?


Regards,
Xavier


-- 
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/51ab9601.7000...@httrack.com

Re: Test suite best practices ?

[Russ Allbery]

Xavier Roche  writes:

> Are there any "best practices" on how to handle test suite in Debian ?

> Currently the best way seems to use the automake's testsuite, and call
> dh_auto_test after dh_auto_build - but it generally needs some hacking
> wrt. library and binary pathes - ie. something ugly like:

> # Makefile.am
> TESTS_ENVIRONMENT =
> LD_LIBRARY_PATH=$(top_builddir)/src/.libs:$$LD_LIBRARY_PATH
> TESTS_ENVIRONMENT += PATH=$(top_builddir)/src/.libs:$$PATH
> TESTS = *.test

> There might be better ways (and more portable - are we sure that
> LD_LIBRARY_PATH is awlays the right one ?) ?

This shouldn't be necessary to run the compile-time test suite.  If it is,
that's a bug in the upstream build system.  Judging from the use of .libs,
upstream is using libtool; the test programs should be handled by libtool
(replaced with shell scripts that set LD_LIBRARY_PATH and invoke the right
binary) so that they can run successfully from the build tree.  In other
words, as long as the test suite is built with libtool like the rest of
the package, this should just work.

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

Bug#710827: ITP: r-cran-downloader -- GNU R package for downloading files over http and https

[Sebastian Gibb]

Package: wnpp
Severity: wishlist
Owner: Sebastian Gibb 

* Package name: r-cran-downloader
  Version : 0.3
  Upstream Author : Winston Chang 
* URL : http://cran.r-project.org/web/packages/downloader/index.html
* License : GPL-2
  Programming Lang: R
  Description : GNU R package for downloading files over http and https

This package provides a wrapper for the download.file function, making it
possible to download files over https on Windows, Mac OS X, and other
Unix-like platforms.


-- 
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/20130602193817.28554.25910.reportbug@tp

Re: systemd .service file conversion

[David Weinehall]

On Sat, Jun 01, 2013 at 03:39:44PM +0200, Salvo Tomaselli wrote:
> They release twice a week or so. That is another sign of a software you 
> shouldn't rely on too much

You mean like, say, the Linux kernel?


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20130602192742.ga26...@hirohito.acc.umu.se

Bug#710829: ITP: r-cran-base64enc -- GNU R package that provides tools for base64 encoding

[Sebastian Gibb]

Package: wnpp
Severity: wishlist
Owner: Sebastian Gibb 

* Package name: r-cran-base64enc
  Version : 0.1-1
  Upstream Author : Simon Urbanek 
* URL : http://cran.r-project.org/web/packages/base64enc/index.html
* License : GPL-2 or GPL-3
  Programming Lang: C, R
  Description : GNU R package that provides tools for base64 encoding

This package provides tools for handling base64 encoding. It is more flexible
than the orphaned base64 package.


-- 
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/20130602194401.28632.34824.reportbug@tp

Re: Test suite best practices ?

[Xavier Roche]

Le 02/06/2013 21:30, Russ Allbery a écrit :
> the test programs should be handled by libtool
> (replaced with shell scripts that set LD_LIBRARY_PATH and invoke the right
> binary) so that they can run successfully from the build tree. In other
> words, as long as the test suite is built with libtool like the rest of
> the package, this should just work.

To clarify, in this case, the upstream is me, and I just integrated the
test suite in libtool using the provided "testsuite" macros (TESTS,
TESTS_ENVIRONMENT etc.), and the dh_auto_test helper is running "make
check" during the build.

I wasn't sure if there was any additional debian-specific action do to ;
but as tests are part of the build, the answer is logical.


-- 
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/51aba2d1.60...@httrack.com

Re: Debian systemd survey

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Russ Allbery 

>> There's really no reason to have something like an /etc/default
>> setting for that, the way there is for the rsyncd init script.  You
>> can just edit that directly (well, it's systemd, so you have to copy
>> it into /etc and make a new version and then won't know if anything
>> about the default changes -- a truly awful design, but that's another
>> argument).

> .. and to work around that, we're likely to tell people to use ucf for
> the files, so you will get notification on updates.  (Or you can use the
> .include syntax as smcv wrote about.)

Yeah, I should be clear that this is certainly something we can fix.  It's
not intrinsic to the systemd software itself, only in the design of the
default configuration behavior.  The software itself supports both
configuration models, which actually makes it more flexible than designs
that only support one configuration model.  Also, to be fair, there are
some advantages to having a canonical and working version of the
configuration kept outside of configuration space where it won't be
modified and is available as a fallback in various situations.  There have
been times when I've wanted that for other Debian configuration files.

With some new tool development, we could do better than dpkg does with
straight /etc/default files.  The syntax is so much simpler that we could,
for instance, eventually develop quite intelligent three-way merge tools.

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

Re: Debian systemd survey

[Vincent Lefevre]

On 2013-06-02 11:10:34 -0700, Russ Allbery wrote:
> Michael Biebl  writes:
> > Am 02.06.2013 18:59, schrieb Russ Allbery:
> 
> >> There's really no reason to have something like an /etc/default setting
> >> for that, the way there is for the rsyncd init script.  You can just
> >> edit that directly (well, it's systemd, so you have to copy it into
> >> /etc and make a new version and then won't know if anything about the
> >> default changes -- a truly awful design, but that's another argument).
> 
> > You do not necessarily have to copy the whole file. You can
> > override/amend the .service file by using a foo.service.d/*.conf
> > snippet.
> 
> That doesn't really help -- it's exactly changes to ExecStart that I want
> to be informed of by dpkg.

Agreed. To give an example, /lib/systemd/system/wpa_supplicant.service
currently contains:

ExecStart=/sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant

What if the user wants his own ExecStart line, do does something
like the above?

echo "ExecStart=/sbin/wpa_supplicant -u -s -O /var/run/wpa_supplicant -foo" >
  /etc/systemd/system/wpa_supplicant.service

But if the /var/run symlink disappears some time in the future,
or if wpa_supplicant is moved to /usr/sbin (something that may
happen), the /lib/systemd/system/wpa_supplicant.service file
would have been updated, but the user wouldn't necessarily be
aware of such a change.

I hope the user isn't required to write config files that can
dynamically update themselves from new /lib/... files. :)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130602205105.ga15...@xvii.vinc17.org

Re: default MTA

[Marc Haber]

On Sat, 1 Jun 2013 15:06:40 -0400, Chris Knadle
 wrote:
>I can understand why one would want this, but I can also understand why it 
>hasn't been done.  Without first setting up TLS, this would involve passing a 
>username/password over the 'net in the clear, which is something I try hard to 
>never ever have happen.  This is especially something you don't want to do if 
>it's your own personal email login, which is a likely use case for this 
>proposed debconf code.  :-/

Exim's default in the packages is not to send authentication data over
a non-encrypted connection. The debconf code could try to check
whether the smarthost allowes TLS, and if not, query the user whether
it is ok to send the password over a non-encrypted connection.

>   In this example, the FQDN of the local machine is orac.example.com
>   and the smarthost machine is smtp.example.com
>
>   Create new file /etc/exim4/exim4.conf.localmacros containing:
>
>   MAIN_TLS_ENABLE = true
>   primary_hostname = orac.example.com

I don't think you need MAIN_TLS_ENABLE to to TLS as a client.

>   Modify /etc/exim4/exim4.conf.template for the remote_smtp_smarthost
>   to change the sending port to 587.  (In the U.S. there are a lot of
>   ISPs that block outbound port 25 except for the ISP's mail servers):
>
>   ...
>   remote_smtp_smarthost:
>  debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
>  driver = smtp
>port = 587# <--- add this line
>  ...

You can set sc_smarthost to hostname::587 without having to change the
transport, see update-exim4.conf(8) or the debconf template for
dc_smarthost.

>   Modify /etc/exim4/passwd.client to add a smarthost:username:password
>   triplet for sending email:
>
>   smtp.example.com:Orac:SillyPassword

That's what I'd want to be debconfed

>   On the mail server machine (i.e. smtp.example.com), make an MD5
>   passowrd hash of the password used on the client machine via command:
>
>   #mkpasswd -H md5 SillyPassword
>   $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1
>
>   Then modify /etc/exim4/passwd on the server to add a
>   username:hashed_passwd:passwd triplet for the client:
>
>   Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword

You also can a more modern hash if the server is Debian exim as well.

>As I mentioned previously, the reason I go through making a new 
>username/password pair for each client is so that I don't risk a personal 
>email account, and so that I can revoke any one machine's email login at the 
>server in case of a client compromise of some kind.

Wise.

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: http://lists.debian.org/e1ujfxo-0005bm...@swivel.zugschlus.de

Re: default MTA

[Marc Haber]

On Sat, 01 Jun 2013 12:16:11 -0700, Russ Allbery 
wrote:
>Marc Haber  writes:
>> Certificates are usually only used in E-Mail when a server authenticates
>> itself to a client before the client sends its authentication data. SMTP
>> with client certificates is possible, but I have only seen this two
>> times in 15 years of running E-Mail servers.
>
>All mail servers I run are configured with TLS certificates because that's
>how you encrypt SMTP traffic between servers. 

That's not a contradiction to what I have written.

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: http://lists.debian.org/e1ujfys-0005bv...@swivel.zugschlus.de

Re: systemd .service file conversion

[Marc Haber]

On Sat, 1 Jun 2013 21:26:32 +0200, Ond?ej Surý 
wrote:
>We have removed archs from release archs and moved them to ports and nobody 
>claimed we are less universal.

I did. I still think it is a pity that we removed them.

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: http://lists.debian.org/e1ujfo5-0005uf...@swivel.zugschlus.de

Re: default MTA

[Russ Allbery]

Marc Haber  writes:
> Russ Allbery  wrote:
>> Marc Haber  writes:

>>> Certificates are usually only used in E-Mail when a server authenticates
>>> itself to a client before the client sends its authentication data. SMTP
>>> with client certificates is possible, but I have only seen this two
>>> times in 15 years of running E-Mail servers.

>> All mail servers I run are configured with TLS certificates because
>> that's how you encrypt SMTP traffic between servers.

> That's not a contradiction to what I have written.

You said that certificates are usually only used in e-mail when a server
authenticates itself to a client.  That's the statement with which I'm
partly disagreeing.  I run multiple mail servers (and Stanford University
runs quite a few more) that have TLS certificates that have nothing to do
with authentication.

TLS certificates are a poor authentication system unless you restrict them
to only CAs under your control, but they're great as an easy way of
configuring effectively anonymous encryption.

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

Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11

[Eric Dorland]

Sorry about that. Generally how I transition to a new upstream version
is to update the automake package and then upload a new automake1.X
package after that. So I will be uploading an automake1.11 package
shortly to fix this. 

* Thorsten Glaser (t...@debian.org) wrote:
> Eric Dorland  debian.org> writes:
> 
> > at the very beginning of the jessie release cycle I'd like to propose
> > a mass bug filing to remove all the current automake packages in
> > unstable (automake1.13 is in the NEW queue). Automake 1.4 in
> 
> Erm. How about you’d have checked with the maintainers of those
> packages *before* shoving automake1.13 as “automake” into NEW,
> thus breaking the build of unrelated packages?
> 
> http://buildd.debian-ports.org/status/
> fetch.php?pkg=libnfsidmap&arch=m68k&ver=0.25-5&stamp=1369888632
> 
> Manual analysis:
> 
> (pbuild7107)aranym:/# apt-get install automake1.11
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> Package automake1.11 is a virtual package provided by:
>   automake 1:1.11.6-1 [Not candidate version]
> 
> E: Package 'automake1.11' has no installation candidate
> (pbuild7107)aranym:/# apt-cache policy automake
> automake:
>   Installed: (none)
>   Candidate: 1:1.13.2-1
>   Version table:
>  1:1.13.2-1 0
> 500 http://ftp.de.debian.org/debian-ports/ unstable/main m68k 
> Packages
>  1:1.11.6-1 0
> 500 http://ftp.de.debian.org/debian-ports/ unstable/main m68k 
> Packages
> 
> I expect more packages to FTBFS soonish.
> 
> There’s no existing bugreport against *either* libnfsidmap *or* automake,
> and I’m not filing one because I don’t know which of those packages is in
> the wrong, for now, since this apparently didn’t get discussed any further.
> 
> bye,
> //mirabilos
> 
> 

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com


--
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/20130602214316.GS32174@gambit

Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11

[Eric Dorland]

Having heard no real objection to the plan, I will begin filing minor
bugs for this transition.

I'm moving in a month so I may not have time to actually start until
July.

* Eric Dorland (e...@debian.org) wrote:
> Hello folks,
> 
> We've accumulated a lot of automake packages in main and since we're
> at the very beginning of the jessie release cycle I'd like to propose
> a mass bug filing to remove all the current automake packages in
> unstable (automake1.13 is in the NEW queue). Automake 1.4 in
> particular is very old at this point and is unsupported.
> 
> Automake is moving to a more rational versioning scheme so new,
> non-backwards compatible automake packages should be far less common
> now. See
> "New versioning scheme for Automake." here:
> http://gnu-automake.7480.n7.nabble.com/GNU-Automake-1-13-2-released-td20448.html.
>  So
> hopefully we can release jessie with one (or maybe two) automake
> package.
> 
> Attached are the package list generated from the command below (and
> that list run through dd-list): 
> 
> grep-dctrl -n -s Package \( -F Build-Depends,Build-Depends-Indep -w
> 'automake1.4|automake1.9|automake1.10|automake1.11' \) --and \( --not
> -F Build-Depends,Build-Depends-Indep -w 'automake' \) 
> /var/lib/apt/lists/ftp.us.debian.org_debian_dists_unstable_main_source_Sources

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature

Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11

[Alberto Garcia]

On Mon, May 27, 2013 at 02:38:48AM -0400, Eric Dorland wrote:

> We've accumulated a lot of automake packages in main and since
> we're at the very beginning of the jessie release cycle I'd like
> to propose a mass bug filing to remove all the current automake
> packages in unstable (automake1.13 is in the NEW queue).

Please make sure that gnome-autogen.sh (from gnome-common) is also
updated to support automake1.13, last time I checked it didn't.

Berto


-- 
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/20130602230656.ga26...@igalia.com

Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11

[Eric Dorland]

* Alberto Garcia (agar...@igalia.com) wrote:
> On Mon, May 27, 2013 at 02:38:48AM -0400, Eric Dorland wrote:
> 
> > We've accumulated a lot of automake packages in main and since
> > we're at the very beginning of the jessie release cycle I'd like
> > to propose a mass bug filing to remove all the current automake
> > packages in unstable (automake1.13 is in the NEW queue).
> 
> Please make sure that gnome-autogen.sh (from gnome-common) is also
> updated to support automake1.13, last time I checked it didn't.

I just had a brief glance but it mentions automake-1.13 so I think
it's supported.

-- 
Eric Dorland 
ICQ: #61138586, Jabber: ho...@jabber.com



signature.asc
Description: Digital signature

Re: default MTA

[Chris Knadle]

On Sunday, June 02, 2013 17:10:02, Marc Haber wrote:
> On Sat, 1 Jun 2013 15:06:40 -0400, Chris Knadle
> 
>  wrote:
> >I can understand why one would want this, but I can also understand why it
> >hasn't been done.  Without first setting up TLS, this would involve
> >passing a username/password over the 'net in the clear, which is
> >something I try hard to never ever have happen.  This is especially
> >something you don't want to do if it's your own personal email login,
> >which is a likely use case for this proposed debconf code.  :-/
> 
> Exim's default in the packages is not to send authentication data over
> a non-encrypted connection. The debconf code could try to check
> whether the smarthost allowes TLS, and if not, query the user whether
> it is ok to send the password over a non-encrypted connection.

Yeah I see why this test could be useful; gnutls-bin is listed as a Suggests 
by exim4-base, so the TLS libraries may not be locally available.

The normal way I know to check for TLS availability is to telnet to the SMTP 
port, give an "EHLO " (and it must be an EHLO) or "EHLO []", 
and then look for a "STARTTLS" advertisement in the response from the server.  
Unfortunately this isn't always possible; some systems filter telnet from 
reaching the MTA.  I don't yet know how to check a remote server for this 
using a local Exim binary; there's an -MCT option mentioned in the Exim man 
page for this, but it's an option used internally by Exim and not meant to be 
used by an external caller.

Attempting to use an FQDN is also troublesome, because Exim tries to use DNS 
to look up the FQDN, and falls back to using 'uname -n' which returns the 
local hostname without a domain name.  The SMTP RFCs require the HELO/HELO 
information to contain an FQDN or an IP address in [] brackets, and some mail 
systems reject connections containing non-conforming HELO/EHLO greetings.


I think swaks may be able to do this via something like:

   swaks --ehlo [192.168.1.1] --server  -p  \
 -tls -q TLS

... but swaks is a package Suggested by exim4-base rather than a Depends, so 
swaks may not be available for use with debconf.


Let me know if you have suggestions.

> >   In this example, the FQDN of the local machine is orac.example.com
> >   and the smarthost machine is smtp.example.com
> >   
> >   Create new file /etc/exim4/exim4.conf.localmacros containing:
> >   MAIN_TLS_ENABLE = true
> >   primary_hostname = orac.example.com
> 
> I don't think you need MAIN_TLS_ENABLE to to TLS as a client.

Tested this... looks like this is true.  :-)  Cool.  [I'm pretty sure this 
wasn't always the case, but I'm glad it is now.]

> >   Modify /etc/exim4/exim4.conf.template for the remote_smtp_smarthost
> >   to change the sending port to 587.  (In the U.S. there are a lot of
> >   
> >   ISPs that block outbound port 25 except for the ISP's mail servers):
> >   ...
> >   
> >   remote_smtp_smarthost:
> >  debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
> >  driver = smtp
> >  
> >port = 587# <--- add this line
> >  
> >  ...
> 
> You can set sc_smarthost to hostname::587 without having to change the
> transport, see update-exim4.conf(8) or the debconf template for
> dc_smarthost.

Sweet.  Thanks!  This really helps because it means I can avoid having to 
modify exim4.conf.template altogether, which will simplify upgrades.

> >   Modify /etc/exim4/passwd.client to add a smarthost:username:password
> >   
> >   triplet for sending email:
> >   smtp.example.com:Orac:SillyPassword
> 
> That's what I'd want to be debconfed

Right.

> >   On the mail server machine (i.e. smtp.example.com), make an MD5
> >   
> >   passowrd hash of the password used on the client machine via command:
> >   #mkpasswd -H md5 SillyPassword
> >   $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1
> >   
> >   Then modify /etc/exim4/passwd on the server to add a
> >   
> >   username:hashed_passwd:passwd triplet for the client:
> >   Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword
> 
> You also can a more modern hash if the server is Debian exim as well.

The exim4_files(5) man page recommends MD5, which is why I was using it, and 
thee README.Debian.gz document simply refers to this man page.  However 
crypt(3) indicates that sha-256 is supported too, so I tried it with Exim's 
passwd file... sure enough, that works.  ;-)

Thanks for letting me know about this.

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74


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

Re: Test suite best practices ?

[Paul Wise]

On Mon, Jun 3, 2013 at 2:59 AM, Xavier Roche wrote:

> Are there any "best practices" on how to handle test suite in Debian ?

In addition to what was already said, it is possible to define a set
of tests to be run on the package as it is installed on a Debian
system. We don't yet automatically run these tests though. See DEP-8
for more info:

http://dep.debian.net/deps/dep8/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gimjafnx_w7wn6m2cfd1ras+rfwg+-bjd2fpy3gif...@mail.gmail.com

Re: Switching to mozilla ESR in stable-security

[The Wanderer]

On 05/28/2013 04:33 PM, Moritz Muehlenhoff wrote:


Hi,
we need to change the way security fixes are handled for Mozilla in
stable-security. The backporting of security fixes is no longer
sustainable resource-wise.

As such, we'll switch to releasing the ESR releases of iceweasel and
icedove in stable-security.


One thing to be careful of in this regard:

The Firefox developers are intentionally dropping some features from the
main browser, for one reason or another. As far as I recall none have
been dropped yet, but several are in the pipeline.

Leaving aside any debate about whether this is a reasonable thing to do,
it means that moving from one ESR major release version to the next may
result in potentially significant functionality change - which, AFAIK,
is something we try to avoid with package updates in a stable release.

I don't have a problem with packaging the ESR in general, and if a given
ESR major release is in stable, I think it makes sense to ship the
associated minor/micro releases as security updates for stable as they
come out (since security fixes is generally what they are).
Transitioning between ESR major release versions, however, may well
warrant more care.

--
   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


--
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/51ac0e23.3090...@fastmail.fm

Re: systemd .service file conversion

[Ondřej Surý]

On 2. 6. 2013, at 23:00, Marc Haber  wrote:

> On Sat, 1 Jun 2013 21:26:32 +0200, Ond?ej Surý 
> wrote:
>> We have removed archs from release archs and moved them to ports and nobody 
>> claimed we are less universal.
> 
> I did. I still think it is a pity that we removed them.

You could have invested your time and energy in real work to save them. Same 
applies to non-linux kernel. Go and do. Clapping your mouth in philosophical 
dispute about the word universal and pushing your extreme views in debian-devel 
is only hurting your cause. Real work will help.

O.

--
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/4c63a30b-6736-4b9d-a2c2-efaf28839...@sury.org