Re: Favoring systemd timers over cron files Re: Removing sysV init files

[Alexandre Detiste]

Le vendredi 15 janvier 2016, 21:58:18 Anthony DeRobertis a écrit :
> On 01/15/2016 09:29 PM, Jens Reyer wrote:
> > Does this also work somehow for e.g. foo-daily.service + 
> > foo-daily.timer being favored over /etc/cron.daily/foo? Next to a 
> > foo.service being favored over /etc/init.d/foo. Thanks and greets jre 

Hi,

systemd-cron does that:

https://sources.debian.net/src/systemd-cron/1.5.3-1/src/bin/systemd-crontab-generator.py/#L473

I also wrote a proposal for the policy here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770440

The only thing that systemd-cron needs to close last remaining bugs
is a rewrite in a lower level language with a smaller runtime
(C or C++) there's a rewrite done in Rust; butI have no
idea on how to package that in Debian & the runtime is huge.

That's only about 550 lines of python code to rewrite that
read some textfiles in /etc/cron.d (crontabs)
& output other text files in /run (systemd timers & service);
I'll do that "someday".

Then crontab would need to be spun out of cron.deb so that
it could be shared by two implementations.

> No, it won't work automatically. Cron doesn't look at systemd units. 

Vixie cron could be patched to also work this way to avoid noise in log files.

> You could of course put something like this at the top of your 
> /etc/cron.daily/foo:
> 
> if [ -d /run/systemd/system ]; then
>  exit 0;
> fi
> 

Re: Removing sysV init files

[Jonathan Dowland]

On Fri, Jan 15, 2016 at 10:07:11AM -0500, The Wanderer wrote:
> It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
> Debian-Hurd?

Debian/kFreeBSD is a supported architecture, but Debian-Hurd is currently
unofficial.

Bug#811169: ITP: colorfultabs -- Color tabs differently and make them easy to distinguish

[Ximin Luo]

Package: wnpp
Severity: wishlist
Owner: Ximin Luo 

* Package name: colorfultabs
  Version : 29.7
  Upstream Author : Shivanand Sharma 
* URL : https://addons.mozilla.org/en-US/firefox/addon/colorfultabs/
* License : CC-BY-NC-ND-3.0-US
  Programming Lang: JS
  Description : Color tabs differently and make them easy to distinguish

 ColorfulTabs is a Firefox extension that colors every tab in a different color
 and makes them easy to distinguish. It also beautifying the overall appearance
 of Firefox. ColorfulTabs does one and/or more of the following:
 .
  * Colors each tab using pre selected colors in a definite order starting from
the left.
  * Colors each tab using a unique and randomly generated color.
  * Colors each tab using a unique color depending on the site domain using a
formula.
  * Allows user to chose colors.
  * Allows one to fade the background tabs for easy identification of the
selected tab.
  * Allows quick identification of the tabs.
  * Allows quick identification of tab boundaries.
  * Increases usability and visibility for people with visual challenges.

The author has given me an exception (via private email, which I will reproduce
in debian/copyright) to create a derivative work for Debian. I understand that
this is not DFSG and will be problematic for other distributions to work on top
of - I will try to persuade him to re-license under a proper FOSS license;
failing that I will upload to non-free instead.

Re: IMPORTEND squid3 stable needs update

[David Bremner]

startrekfan  writes:

> *squid3 Version 3.4.8* is deployed in the Jessie stable repository.* This
> version is outdated and has some security risks!!*. Version 3.5 is more
> secure but unfortunately it's only marked as unstable

If there are security bugs in squid3 (or in any other debian package),
please write with specifics to

   secur...@debian.org or t...@security.debian.org

For more details, see

https://www.debian.org/security/faq#contact



signature.asc
Description: PGP signature

Re: default softphone in Debian stretch

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/01/16 14:20, Bas Wijnen wrote:
> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
> 
> 
>> On 15/01/16 04:00, Paul Wise wrote:
>>> On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
>>> 
 default softphone in Debian[1]
>>> 
>>> It should be up to the user what communications tools they want
>>> to use and or have installed (if any), that is none of our
>>> business, other than perhaps informing them of the security
>>> properties of what is available and or providing the default
>>> upstream tool choices via metapackages where available.
> 
> I strongly disagree.  Users should be able to choose, and we should
> not force one option on them.  But users should not be forced to
> choose.  A major feature of using a distribution is that you don't
> need to choose individual programs to install, but get a well
> functioning system.
> 
> Don't confuse the freedom to choose with the obligation to choose.
> Freedom is good, and so is having good defaults.

Yes, I wasn't insisting that every user should be forced to install
something or even worse, forcing users to create a SIP or XMPP account
in some designated service provider.

Making it as easy as possible for those who do want such things and
helping them make a good choice on their first attempt are the things
I'm concerned with.

> 
>> If there are meta-packages (e.g. sip-client, xmpp-client), should
>> any softphone be able to assert that it provides sip-client?  Or
>> should there be some quality threshold?
> 
> I think there should be a threshold.  Failing to meet that should
> be ground for an RC bug.  In other words, the package can be in
> unstable, but not in testing (or stable).
> 


Is this approach used in a formal manner with any other sets of
packages, meta-packages or tags in Debian?


>> For example, WebRTC browsers must officially support G.711 and
>> Opus codecs.  Many softphones don't support Opus yet.  Should we
>> say that support for Opus is mandatory for any package that
>> provides sip-client or xmpp-client and any package that falls
>> short has to remove the Provides line from debian/control or be
>> hit with an RC bug?
> 
> Yes, that sounds reasonable.  If a package Depends: sip-client,
> things are expected to work well.
> 

I'll make a wiki with my own ideas about this and maybe the details
can be discussed on the debian-rtc list (it is lower volume than the
pkg-voip[1] list)
https://lists.debian.org/debian-rtc/


>> Using some threshold for quality and interoperability will help
>> the majority of users to choose from the more desirable
>> softphones, but no softphone would be excluded from the
>> distribution.
> 
> Also, an RC bug is not always a problem.  If a maintainer believes
> that it is useful to have a work in progress program in Debian, it
> can be in unstable, with an RC bug to prevent it from entering
> testing.
> 

Yes, that is why I thought this would be a useful approach.
Maintainers could also upload a version of the package without the
metapackage name and then downgrade the RC bug.

Regards,

Daniel

1. http://pkg-voip.alioth.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWmjwuAAoJEGxlgOd711bEptQP/2D3zHREhJ26Cn4xJAqQr0Fi
AL9KJYYYGqWqmbEW9fKnkv257e51mIdqAWmzaewoCraQmXE1UajmxpkkVlwONdPU
f17Dc5YzG7JNJYaLUDuIqa24itxdhZJ3c9ZQPneVOYeS7t5j1gAyALZquzBIF8pD
SZEFv7LUfwy1BG0di4wPZ2mnTOjl59rE6/R6WHnBR1nuqrTw31kbkOR1yToylZWf
gj+top6pL82eC6xvfc7L0ssUgnz1Xwos/4/EnmBMC8Ac/y/fsR5XquT3DRxenJsI
JUerMkbacOeWAQC5Rqj7ILyhSU6UF65ClbWbGB+xJ6IF1Lf7UWJoc13D7qvD+XJs
e5NvFsqU8SCcM2zucW7/75+WBPRci7fe+E3exL6jS5tCujhMP3MgyYyWFcS6hjRD
7wc/wGbUsJcat+rOeojJGkeYBFBcrBIdfPAU6WMGe7gM8qYGgrkcrWMBcUmog8Dk
Iek3ieZF0uMst2Qfrf2yCwjyz2t0YhPjLYeCnC2Q9a0qwuN4QrXr4K2vVAv2Wa/N
n1Wu7ayathBEwZHM+uEZ5uamLOcj+1xbzOYCuoBysgBLyOqWSh+fuy9wEowVF107
mca5iW2Itpp0y2ZPg3rNzGGOkv6vhWY0nAszm+pC0PtdKF0ualXJvN+ACOnH912G
PCN6EXc+yFn8w0y28pL3
=Iuhj
-END PGP SIGNATURE-

Re: default softphone in Debian stretch

[Ansgar Burchardt]

Daniel Pocock  writes:
> On 15/01/16 14:20, Bas Wijnen wrote:
>> On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
>>> If there are meta-packages (e.g. sip-client, xmpp-client), should
>>> any softphone be able to assert that it provides sip-client?  Or
>>> should there be some quality threshold?
>>
>> I think there should be a threshold.  Failing to meet that should
>> be ground for an RC bug.  In other words, the package can be in
>> unstable, but not in testing (or stable).
>
> Is this approach used in a formal manner with any other sets of
> packages, meta-packages or tags in Debian?

No, I don't think we have some sort of "quality" level for providing a
virtual package.  Just take a look at www-browser which is provided by
packages not getting any security updates at all or implementing SSL in
very broken ways (I remember reading about browsers that would just
accept any certificate silently).

Ansgar

Re: Libre graphics could become the standard if we push right now

[shawn wilson]

On Jan 16, 2016 1:30 AM, "gaffa"  wrote:
>
> The firmware has a free license if you are to believe the WENCE file in
the
> kernel.
>

Ummm, just a guess but I think that would be talking about transferring
ownership and not on reverse engineering (for instance).

Re: tyr-quake both quake1 & quakewolrd close to conservative engine stable-based

[PICCORO McKAY Lenz]

>I packaged and uploaded ezquake, a different quakeworld client.  It
...
>It's been waiting for ftp master review for about a month now [0].
> [0] https://ftp-master.debian.org/new/ezquake_2.2+git20150324-1.html

the point of the tyrquake its that WORKS IN NON OPENGL supported GPU's
taking in consideration that recent version of debian only supports
directly intel gpu's

so my matrox gpu (not reconised ) can play 99% of games, and either my
old VIA unichrome not dri2 supported!

that's why linux not have good suport for most used targets in desktop users!

tyrquake works perfectly in my older good machine with newer debian
(now more slowly) jeesie release

if nobody have time, i made a preliminay dsc ITP package of! only need
and sponsored!
-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Defaults and virtual package rules (was: default softphone in Debian stretch)

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 01:48:46PM +0100, Daniel Pocock wrote:
> On 15/01/16 14:20, Bas Wijnen wrote:
> > On Fri, Jan 15, 2016 at 11:08:35AM +0100, Daniel Pocock wrote:
> >> On 15/01/16 04:00, Paul Wise wrote:
> >>> On Tue, Jan 12, 2016 at 5:42 PM, Daniel Pocock wrote:
> >>> 
>  default softphone in Debian[1]
> >>> 
> >>> It should be up to the user what communications tools they want
> >>> to use and or have installed (if any), that is none of our
> >>> business, other than perhaps informing them of the security
> >>> properties of what is available and or providing the default
> >>> upstream tool choices via metapackages where available.
> > 
> > I strongly disagree.  Users should be able to choose, and we should
> > not force one option on them.  But users should not be forced to
> > choose.  A major feature of using a distribution is that you don't
> > need to choose individual programs to install, but get a well
> > functioning system.
> > 
> > Don't confuse the freedom to choose with the obligation to choose.
> > Freedom is good, and so is having good defaults.
> 
> Yes, I wasn't insisting that every user should be forced to install
> something or even worse, forcing users to create a SIP or XMPP account
> in some designated service provider.

I wasn't disagreeing with you, but with Paul.  AIUI, he wants to force users to
choose which softphone they want.  I understand the resistance against forcing
users to install one softphone and not allowing them to use any other.  But
that doesn't mean there shouldn't be a default.  If a user wants a softphone
and doesn't care which, they should be getting a good default.

In short, if a user wants a softphone, Paul says: we give the options and they
_must_ study those options and choose one.  I say: we give them one that works
well, plus a list of options.  They can ignore the list of options if they
don't care about it, or use it to get exactly what they want if they do care.

> Making it as easy as possible for those who do want such things and
> helping them make a good choice on their first attempt are the things
> I'm concerned with.

I almost agree.  On their first attempt, I don't want to help them make a good
choice; I want to make the choice for them.  Unless they want to choose
themselves, of course; I'm not saying we should stop that.  But I think most
people just want it to work.  They don't care what the program is called, and
they don't want to spend their time on choosing one.

> >> I think there should be a threshold.  Failing to meet that should
> >> be ground for an RC bug.  In other words, the package can be in
> >> unstable, but not in testing (or stable).
> >
> > Is this approach used in a formal manner with any other sets of
> > packages, meta-packages or tags in Debian?
> 
> No, I don't think we have some sort of "quality" level for providing a
> virtual package.  Just take a look at www-browser which is provided by
> packages not getting any security updates at all or implementing SSL in
> very broken ways (I remember reading about browsers that would just
> accept any certificate silently).

Perhaps it would be good to allow virtual packages to have a description where
they can specify rules that providers must follow in order to be allowed to
provide it.  And in some cases, it may be possible to run automated tests (if
one of the rules is to implement some protocol).  This could be implemented by
creating a package that is used as a Build-Depends, which adds the virtual
package to the Depends of selected packages through substvars.  Lintian can
check that packages don't have hardcoded Depends on the virtual packages.

Would this be useful for more virtual packages, or not?

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmlsEAAoJEJzRfVgHwHE6vH8QAJ1PDeJ6/R5Yoh0S661eDlvP
TwqwLQqABMRnnUKi1+MYHNTUfxT13hbfSVcymEvlQJ9xQvYAE8H6DUKr43eyzOmJ
d0UBNOc9HI/5rx9A2nyY9Pz7u09StLzy1btD1rZUa9LaCzZm2WAj0HtWSpsH27yq
tOAB9nObLj01ZOANotP6VpIX2lUm2G85ROGgivv4pkhDVEAzgzPX1mRTOrYX/y2E
FPtdcdanWrqKgQuIgxhQAkzcOk4ylnU4DOqdSlHgwWlaQ/KJVG95awqI1D83DqbZ
EyKsezbD6rV6k9+FuGgb6xou6/xPxNM8e0ogZwWSOiuz0GdV9ap5P1tTUtO71iqu
jsDndRFFoOKhbGuCHYAqYLEToOxKbgGlc8nKm7b2GzxqefJVkcoP8UdZZFNNqEr3
Y0lNFbSYdwjMGalMbsEt2hpizUQDOZLi6FMC42TRGlqLycPg9fg5GTR4dzdamtj+
ZfYjLu/zw+562fWJqyJZLFEBkIyZIIuAhXcQwLZSh9+1OYfeLwgmZgIx2bjvkKkL
zohrbHLtc3ozQAV1SKCMUSRkzAQQguq2MxGu7+8D4EYShj8uNGA2hoZbTu6iPKLM
XE1Ef+ceg+j9ji9DifRILV6TaIGv2thl1TqAijjTBAgGSWQhv3srejchvCHYwxe0
jxMPCZfwt+Et43WEx8OV
=8mga
-END PGP SIGNATURE-

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 11:12:37 +, Jonathan McDowell
 wrote:
>On Fri, Jan 08, 2016 at 07:09:59PM +0100, Marc Haber wrote:
>> On Fri, 8 Jan 2016 17:54:49 +, Jonathan McDowell
>>  wrote:
>> >You're not communicating clearly and this is indeed causing problems
>> >in this thread. You said "all my clients run unstable", not "all my
>> >client machines run unstable". You've also later said "I've not
>> >installed any new Debian systems at any client site". It is not
>> >unreasonable that the casual reader will assume you are using the
>> >term to mean a 3rd party who you are managing system for.
>> 
>> You're right to blame for only speaking english for 30 years of my
>> life and living in a country where TV programs are dubbed. I am also
>> deeply worried about the Operating System I still care about after 15
>> years and which works so hard to feel not like a home any more.
>
>I'm not sure how you've taken any of this meaning from my message. You
>have inconsistently used certain terms such that it's not surprising
>they have been misunderstood by others in this thread. I am not in any
>way complaining about your grasp of the English language.

And it happened again in the very next message. My bad. A client is a
computer, a customer is a company or an individual. In German, there
is a clear distinction between that since one also says "client" for
the computer and "Kunde" for the customer.

>> >As far as I can tell what he wants to happen is a) files in / and
>> >/usr locations not to conflict and b) policy to state that this
>> >should be the case.
>> 
>> If that is really the gist of those editorial changes[1], then this is
>> actually a misunderstanding. Maybe UsrMerge is even a misnomer.
>
>These are not editorial changes. There's a clear desire for a change in
>the way things are handled, and I don't believe there is any need to
>ascribe an ulterior motive to it. Marco wants to be able to merge / and
>/usr on his systems. Various other people do as well. If we, as a
>project, say that we should not have duplicate file names between these
>portions of the file system then they can have their desire and the rest
>of us can continue to keep them separate.

And I fear that the current motive will only be step one, with maybe
step three being the really harmful step. I'd like to stop an avalange
before it gets moving.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 11:14:53 +, Neil Williams 
wrote:
>On Sat, 9 Jan 2016 18:32:28 +0800
>Paul Wise  wrote:
>> On Sat, Jan 9, 2016 at 1:41 AM, Marc Haber wrote:
>> 
>> > Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
>> > took with me that you plan to adopt a "once you're out of testing,
>> > you're out of stable for the next release, unless you're really
>> > really important" policy for stretch, which has put me in deep
>> > worry.  
>> 
>> Packages often get autoremoved from testing and then go back in
>> quickly once they are fixed, so I'm not sure that is correct.
>
>So this phrase:
>
>[during the latter half of our freeze] 
>> > "once you're out of testing,
>> > you're out of stable for the next release, unless you're really
>> > really important"
>
>*is* correct *if* the original prefix is retained - and it shouldn't
>overly worry any developers. It's a necessary step to actually getting a
>release.

Are you actually saying that hamm, slink, woody, sarge, lenny,
squeeze, wheezy and jessie haven't been releases? We actually did
pretty well without that rule, and I find it deeply disturbing that
people are suddenly claiming that this - imo harmful - rule is
absolutely necessary to get a release.

There was a time when we released when it was finished. Now it seems
like we aim to release at all cost when the calendar says that we
should.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 09:31:36 +0200, Lars Wirzenius  wrote:
>On Fri, Jan 08, 2016 at 01:31:12PM -0800, Russ Allbery wrote:
>> What will kill Debian faster than anything else is to have every idea for
>> changing something large, interesting, or possibly revolutionary in Debian
>> be met with anger, derision, and attacks.
>
>Hear, hear. I snipped out the rest of Russ's mail, but only for
>brevity: I fully agree with all of it. Extremely well said, Russ.
>
>I feel that there is fair bit of unresolved conflict sloshing around
>the project. This happens when people have a disagreement, and it's
>not handled properly on an emotional level: even though the
>disagreement is resolved on a technical level, and a decision is made
>and implemented, those who didn't agree with it don't get proper
>emotional closure, they feel put upon and rejected, that their
>concerns do not matter. It's like they are wounded, and the wound
>never gets to heal, and if there's any future disagreement, the old
>wound gets torn open again. That's not healthy.

Yes, that's pretty well said as well. Exactly how I feel. And I am not
even a systemd opponent.

>What could we do instead, to prevent and to handle these things?

It would help to be friendly to each other. No CoC needed by that,
it's just basic common sense.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 9 Jan 2016 15:59:33 +, Ian Jackson
 wrote:
>But I have had, in general, good support from almost all quarters.
>Almost no-one has tried to discourage me, and there has been no anger,
>derision, or attacks.  The main limiting factor has been my own
>available effort, and the complexity of the task.
>
>Why do you think I have had such an `easy ride' ?  I doubt it's
>because I'm popular and everyone just naturally wants to help  me.
>
>It sees to me that it is because:
>
>* I haven't been giving talks (or writing mailing list messages or
>  manpages) where I attack people's beloved tools, data formats, or
>  source code management practices.  I could certainly give such
>  talks, but it would just serve to make me (more) enemies.
>
>* The new mechanisms I am developing and implementing are designed, on
>  a technical level, to interoperate with existing systems.
>
>* Insofar I foresee that anything that currently exists may eventually
>  be obsoleted, I am avoiding talking about it (except perhaps if you
>  catch me in the bar or the pub).  In large part this is because I
>  recognise that existing things should be deliberately removed only
>  when the their users and developers will be happy with the
>  replacement.
>
>In short, I haven't been throwing my weight around.

I think it is mainly interoperability. dgit can safely be ignored,
everyone can continue as usual and only take a look a dgit when one
feels like it. Also, dgit doesn't make me lose features of my favorite
toolchain that I deem important to me.

Migrations such as systemd and UsrMerge do hit all of us, without us
wanting or not. This is a completely different deal, especially when
one knows that the people behind those migrations are not easy to deal
with. Additionally, beloved and important functionality is lost in
those migrations, and the people behind them saying "everythin you
have done up to now has been wrong for all the time, you're lucky that
it didn't explode before, be happy that we make it deliberately
explode" causes a great deal of distrust.

>I could mention a couple of other projects in Debian that are fairly
>big changes: source-only uploads, and reproducible builds.  It seems
>to me that the folks doing those exciting and worthwhile projects are,
>in general, getting support and encouragement from the project as a
>whole.

All of them can safely be ignored in daily packaging practice. I don't
mind adding a few patches to help, but I don't need to change my work
so severely as systemd/UsrMerge wants me to do.

I am not saying that source-only uploads and reproducible builds don't
make me lose features. Actually, making one of my packages build
reproducibly forced me to remove a sanity check that alerts a package
builder if some vital part of the documentation changed upstream.

>Even multiarch, which is very complicated and was fiercely contested
>on the technical level, has now made it in and even involved
>relatively low levels of aggro - even though on a technical level we
>are even now still working through some of fallout.

I have never understood why multiarch was so much fought about, the
migration was rather pretty painless and it was not such big change.

>I think that people who want to change Debian should take care to:
>
>  - Communicate respectfully;
>  - Ensure technical interoperability between different
> approaches and different tools;
>  - Carefully plan necessary transitions;
>  - Approach change in a consensual manner;
>  - Particularly, avoid hostile acts like publicly declaring
> other people's code or configurations dead or unsupported.

- don't deliberately break other people's setups just beause you think
the way those setups were made was broken anyhow for years.

Amen.

>It is not necessary to declare other people's code or configurations
>dead in order to make progress.  New things can sit alongside old
>things.  Eventually the new things will be overwhelmingly popular
>because they are better, and no-one will want to work on the old
>things, which can then wither away.  And if the old things don't
>wither away because a few people still want to maintain them, well,
>fine - that's them exercising their software freedom.

Right!

And don't reduce people's freedom from "having the configuration a tad
bit different" to "you're free to use an entirely different software",
especially if that really means going away from Debian.

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

Re: support for merged /usr in Debian

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Jan 16, 2016 at 04:09:00PM +0100, Marc Haber wrote:
> It would help to be friendly to each other. No CoC needed by that,
> it's just basic common sense.

The meaning of "friendly" and "common sense" is different for different people.
If you write down what you mean by that, it's called a CoC.  If you use it as a
guideline, and not a stick to beat with, it is exactly what you ask for.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWmmHXAAoJEJzRfVgHwHE6E0cQAIKVkbk+jucSMCHj7fuhGRRb
VoS8lM0xDsMnh5pA3aVPtROXI8XTJOyGIRikr6g1q/vFJtEhDvkSIbJD9m2WfmXk
h2qXSAeXbR+xEZLPI3UlqL/8PvoNhczOQ09xKD5rqncL2KyRfSSWQQe53KN6l9MI
fMXwChpO8yzC29nn5KnMr8eSPjlhK+spOTZNj50YVZW6J6DkGvTQ8y8yHn0aDclp
iL8yKle1wKH981gJgMl3iUOWm/FLXUXQDknysapvXVN2T4R/rPiW+SVm080BKadh
Jy+JfTR0BKPfq2QZ0DJbuG6HWvmHCqZPJ6dbuxFnIqEgYsZOJglJQZD4CDGoQ/mQ
zWI9DkAYYf6CTLvhn6DVuw9vXxUHYhg4i//8vMMc0V5gloF5rVnhef8hLZtMIDnb
mUN5FH7qAQiNfq+CCAYDN3EzkPVKEc2s1Ce8qRDN1TN6Jn+YnXYjxKce2oysx8d6
sb9cSmS7YOlvpo73at3PKZGFvlu41j5Sc2irspESGR2Onyt1jlgkemAsi7a01u7m
cO3wXuiKJgth0DNgKpRIPTK0bciYX9zq2rYKsSfYCoVDkXU/gdEtLmQqjciPUJuH
we6ptGhDjUv7GIYr3Tpny6IUmVO5AnA1T2tF5T0BTcSgRpmsOnpRW3TrDhHDD2Sf
E1WwGO9UJ8cevTy0RLeT
=VTdd
-END PGP SIGNATURE-

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 09 Jan 2016 11:09:00 -0800, Russ Allbery 
wrote:
>For one specific example, it's become quite clear over the past year that
>systemd has achieved the same status as abortion debates in US politics.
>Not only is it clear that we will *never* stop arguing about systemd,
>opposition to or support of systemd has turned into a tribal identity
>marker for at least some people.  Those who disagree aren't just
>prioritizing different things, or even just wrong, but are actively evil,
>horrible people who should be shunned.  This is hugely demoralizing and
>hugely off-putting.  While it is by far not the only thing that has led to
>me not spending as much time on Debian over the past year plus, it's
>certainly been a factor.

I disagree with this point of view.

The technical problem with systemd is its inflexibility. It can do
about 80 % of things that the alternatives were able to. It does those
80 % exceptionally well, with clear design and good documentation.

Unfortunately, getting the 20 % to reach the old feature set is almost
impossible since systemd's upstream is fiercely opposed to implement
things that they themselves don't deem necesary, and they're also
opposed to add documented interfaces that would allow local additions
to be hooked in.

I am not even talking to go beyond the 100 % that we used to have with
the alternatives by using _their_ interfaces because systemd doesn't
have those interfaces.

It's simply unproductive to first having to argue with upstream if one
needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
to wait for the next Debian stable release for this possibility to
become available, if I need to set this option for my network to work
_now_.

And it's simply frustrating to instinctively think "here should be a
variable" when writing a systemd unit because one cannot use a
variable here since systemd upstream thinks that it is unnecesary.

And it's quite arrogant to not implement things that ease starting
daeons that don't have their own configuration files, saying the
daemons should have configuration files and not rely on their command
line, hence systemd should not have features to make building daemon
command lines easier. Heck, some of those daemons have been around
since before systemd upsteam was born.

>This is obviously one of the biggest examples, but I don't think it's the
>only one.  There are numerous large and small examples that show up when
>people want to change how something has historically worked.

There is nothing wrong with change. There is a lot wrong with changes
that makes a significant portion of people's work harder and more
clumsy in the name of making things easier.

Of course this is something that will be discussed over and over again
because it makes people's live harder over and over again. One never
praises things that have become easier. But one will always blame
things that have become (unnecessaryil) harder, especially if the
hardship could be reduced by a bit more cooperation instead of
arrogance and dogmatism.

>And the pattern I've seen, time and time again, is that someone will come
>forward and say "look, I think this aspect of Debian is kind of broken,
>and has no real plausible path for getting better, and I think we should
>embrace this other way of solving the same problem."  And is met by people
>who are furious about the fact that the thing that is currently broken is
>not being fixed instead of putting effort into something new.

I think that greatly depends on how much existing functionality is
lost by this other way of solving the same problem.

>> It sees to me that it is because:
>
>> * I haven't been giving talks (or writing mailing list messages or
>>   manpages) where I attack people's beloved tools, data formats, or
>>   source code management practices.  I could certainly give such
>>   talks, but it would just serve to make me (more) enemies.
>
>In fact, you *have* done this occasionally.  You've been vocal about
>things that you think are broken or insane or horrible, using terms like
>that.  I remember hearing several of them in person.  :)  For example, I
>recall you not being much of a fan of how 3.0 (quilt) packages work.

And, additionally, Ian sounds pretty different when one _reads_ what
he wrote or when he is _heard_ saying those exact same words. My
perception of Ian has changed a lot (in a positive way!) when meeting
him in person at Debconf.

>Another good recent example (well, "recent"; the debate has drug out over
>*years*, which is typical) is the Debian menu vs. desktop files argument,
>which went all the way to the TC, got a TC decision, and now still isn't
>completely settled because there's a separate Policy argument.

Yes, it's another change that kills existing functionality without a
real replacement.

Or can I have an executable that generates virtual .desktop files on
the fly as I can with Debian menu?

>To me, this is far more of a social issue than a technical issue: we're

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 21:58, Stefan Lippers-Hollmann wrote:

Hi

On 2016-01-15, Alec Leamas wrote:

On 15/01/16 21:06, Michael Biebl wrote:

Am 15.01.2016 um 21:01 schrieb Alec Leamas:

On 15/01/16 19:04, Russ Allbery wrote:

[...]

If the names do not match, you can ship a (static) symlink in the
package, say you have
/etc/init.d/foo and /lib/systemd/system/bar.service.
Then ship a symlink like this
/lib/systemd/system/foo.service → /lib/systemd/system/bar.service


It's more complicated. The systemd setup is three different services,
the sysV one. There is no systemd service  directly corresponding  to
the sysV one.  In other words, here is two things taking place  at once:
a major upgrade + sysV -> systemd.


No, actually it's not more complicated. There are two options to fix/
avoid this:


[snip]

Thanks for all replies! I think the conclusion here is clear: the 
scripts should be kept, possibly with some minimal updates.


Cheers!

--alec

Bug#811186: ITP: keysnail -- bind commands to key sequences in Iceweasel

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: keysnail
  Version : 2.1.9
  Upstream Author : Masafumi Oyamada 
* URL : https://github.com/mooz/keysnail/wiki
* License : MIT
  Programming Lang: JavaScript
  Description : bind commands to key sequences in Iceweasel

KeySnail is an add-on for Mozilla Firefox that aims to be a
competitor and lightweight alternative to Vimperator.  Unlike
Vimperator, KeySnail provides a comfortable browsing experience
for Emacs users (but its target users are not limited to Emacs
users).  (description adapted from upstream).

I intend to maintain this package as part of the pkg-emacsen team.

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 16 janvier 2016 16:38 +0100, Marc Haber  :

> It's simply unproductive to first having to argue with upstream if one
> needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
> to wait for the next Debian stable release for this possibility to
> become available, if I need to set this option for my network to work
> _now_.

You seem to always take vague examples to avoid being contradicted. You
can execute any unit before and after network is setup through the
dependency system. If you need to set some sysctl after an interface has
been configured, just do it:

#v+
[Service]
Type=oneshot
ExecStart=/sbin/sysctl -w net.=...
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]
Description=Enable some unknown IPv6 feature now
After=sys-subsystem-net-devices-eth0.device
#v-

> And it's quite arrogant to not implement things that ease starting
> daeons that don't have their own configuration files, saying the
> daemons should have configuration files and not rely on their command
> line, hence systemd should not have features to make building daemon
> command lines easier. Heck, some of those daemons have been around
> since before systemd upsteam was born.

And they seem to work fine with systemd. Upstream is pushing for people
to just write an override. But we are free to use EnvironmentFile=.
-- 
And do you think (fop that I am) that I could be the Scarlet
Pumpernickel?


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 16 Jan 2016 17:12:02 +0100, Vincent Bernat 
wrote:
> ? 16 janvier 2016 16:38 +0100, Marc Haber  :
>> It's simply unproductive to first having to argue with upstream if one
>> needs one certain IPv6 /proc/sys/net option in systemd-networkd _and_
>> to wait for the next Debian stable release for this possibility to
>> become available, if I need to set this option for my network to work
>> _now_.
>
>You seem to always take vague examples to avoid being contradicted. You
>can execute any unit before and after network is setup through the
>dependency system.

Show me how to set a certain option to a VLAN interface that is
created by /etc/systemd/network/foo.netdev and needs to be set before
the interface is taken "up" by /etc/systemd/network/foo.network. Both
unit files are processed by the same systemd-networkd.service with no
hook in between.

>If you need to set some sysctl after an interface has
>been configured, just do it:

Yes. Easy in theory.

>> And it's quite arrogant to not implement things that ease starting
>> daeons that don't have their own configuration files, saying the
>> daemons should have configuration files and not rely on their command
>> line, hence systemd should not have features to make building daemon
>> command lines easier. Heck, some of those daemons have been around
>> since before systemd upsteam was born.
>
>And they seem to work fine with systemd. Upstream is pushing for people
>to just write an override. But we are free to use EnvironmentFile=.

People in the systemd community are asking us to not use
EnvironmentFile or otherwise Lennart might feel forced to remove it
since we're all using it wrong.

This is what gets me absolutely furious.

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

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 16 janvier 2016 17:37 +0100, Marc Haber  :

>>You seem to always take vague examples to avoid being contradicted. You
>>can execute any unit before and after network is setup through the
>>dependency system.
>
> Show me how to set a certain option to a VLAN interface that is
> created by /etc/systemd/network/foo.netdev and needs to be set before
> the interface is taken "up" by /etc/systemd/network/foo.network. Both
> unit files are processed by the same systemd-networkd.service with no
> hook in between.

#v+
[Service]
Type=oneshot
ExecStart=/usr/bin/ip a l
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

[Unit]
Description=Enable some unknown IPv6 feature now
After=sys-subsystem-net-devices-vlan1.device
Requires=sys-subsystem-net-devices-vlan1.device
Before=sys-devices-virtual-net-vlan1.device
Conflicts=sys-devices-virtual-net-vlan1.device
#v-

(I am using /usr/bin/ip because I am testing this on CoreOS which comes
with networkd already enabled and they have a merged /usr).

#v+
[Match]
Name=vlan1

[Network]
Address=10.1.10.9/24
#v-

In journalctl:

Jan 16 19:09:18 localhost ip[494]: 3: vlan1@eth0: 
 mtu 1500 q
Jan 16 19:09:18 localhost ip[494]: link/ether b2:2b:bb:35:34:85 brd 
ff:ff:ff:ff:ff:ff
Jan 16 19:09:18 localhost ip[494]: inet6 fe80::b02b:bbff:fe35:3485/64 scope 
link tentative
Jan 16 19:09:18 localhost ip[494]: valid_lft forever preferred_lft forever

Of course, vlan1 is up because with networkd, configuring the "netdev" makes
it up while in Debian, setting the IP makes it up. However, I don't see
you whining about the lack of flexibility in Debian where you cannot
execute a command when the interface is up but before it gets an IP. If
you needed to do that, you would just use "inet manual" and do whatever
you want. That's the same with systemd, just use a unit.

>>And they seem to work fine with systemd. Upstream is pushing for people
>>to just write an override. But we are free to use EnvironmentFile=.
>
> People in the systemd community are asking us to not use
> EnvironmentFile or otherwise Lennart might feel forced to remove it
> since we're all using it wrong.
>
> This is what gets me absolutely furious.

Already debunked here:
 https://lists.debian.org/debian-devel/2016/01/msg00384.html

Also:
 https://lists.debian.org/debian-devel/2016/01/msg00075.html

I hope that the systemd community doesn't see you as representative of
the Debian community.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Luca Capello]

Hi there,

On Tue, 12 Jan 2016 10:39:00 -0700, Sean Whitton wrote:
> * Package name: let-alist
>   Version : 1.0.4
>   Upstream Author : Artur Malabarba 
> * URL : https://elpa.gnu.org/packages/let-alist.html
[...]
> let-alist is a useful macro for programming in Emacs Lisp.

Nothing against you, but a .deb for an 89-line macro sounds a bit
overkill to me:
=
$ wget http://elpa.gnu.org/packages/let-alist-1.0.3.el
[...]
$ wc -l let-alist-1.0.3.el 
162 let-alist-1.0.3.el
$ grep -v '^;' -c let-alist-1.0.3.el 
89
$
=

JFTR, I needed it as well as a dependency for Flycheck and ended up
installing everything from (M)ELPA :-(

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Philipp Kern]

On Sat, Jan 16, 2016 at 04:07:12PM +0100, Marc Haber wrote:
> There was a time when we released when it was finished. Now it seems
> like we aim to release at all cost when the calendar says that we
> should.

No. We always ignored the last bunch of bugs. At some point you need to
make the call that we're going to release. The freeze is a burden on
the developers, so getting rid of packages the maintainers do not care
about and nobody else knows how to rescue or to argue why the problem
should be ignored for $release is one way to relieve the burden on
others. In short you cannot hold the project hostage.

Kind regards
Philipp Kern

Re: support for merged /usr in Debian

[Michael Biebl]

Am 16.01.2016 um 23:38 schrieb Philipp Kern:
> On Sat, Jan 16, 2016 at 04:07:12PM +0100, Marc Haber wrote:
>> There was a time when we released when it was finished. Now it seems
>> like we aim to release at all cost when the calendar says that we
>> should.
> 
> No. We always ignored the last bunch of bugs. At some point you need to
> make the call that we're going to release. The freeze is a burden on
> the developers, so getting rid of packages the maintainers do not care
> about and nobody else knows how to rescue or to argue why the problem
> should be ignored for $release is one way to relieve the burden on
> others. In short you cannot hold the project hostage.

Amen. I'm much happier how the last couple of releases were handled. The
release team(s) did an outstanding job.
And things like autoremovals are a god send. I'd like to see more of
those automated QA checks which weed out unmaintained packages.

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: MIA team still alive?

[Ricardo Mones]

Hi Norbert,

On Fri, Jan 15, 2016 at 11:32:08PM +0900, Norbert Preining wrote:
> Dear all,
> 
> I have contacted the MIA team about a missing dev
>   Known as: Jörg Sommer
>   Using emails: jo...@alea.gnuu.de
> about two weeks ago, and before that other people have done the
> same. According to mia-query he is missing since 2012:
> 2012-09-14: inactive, nice; nothing since 01/12, 9 NMus, 5 UUVs {from 
> mo...@debian.org}
> 2012-09-24: out; 1 member has no time, waiting for more responses {from 
> mo...@debian.org}
> 2013-09-16: unresponsive, last-warning; orphaning next week {from 
> mo...@debian.org}
> 
> I haven;t got any answer, but if there is none in the very near future
> I / the Debian TeX Team will take over xindy and upload a version that
> fixes RC bugs.

We're not MIA, but I'm pretty busy IRL, so not much activity. I guess
the same happens to other members.

Given the last-warning I think it's obvious the package must have been
orphaned, which I just probably forgot to do ;-), so feel free to take
over and fix those bugs.

Thanks in advance,
-- 
  Ricardo Mones 
  ~
  bash: ./signature: No such file or directory  /bin/bash



signature.asc
Description: Digital signature

Re: MIA team still alive?

[Norbert Preining]

Hi Ricardo,

Thanks for your answer.

> Given the last-warning I think it's obvious the package must have been
> orphaned, which I just probably forgot to do ;-), so feel free to take
> over and fix those bugs.

Already uploaded with take-over of maintainership.


Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Re: Bug#810835: ITP: let-alist -- let-bind values of an assoc-list by their names in Emacs Lisp

[Sean Whitton]

Hello,

On Sat, Jan 16, 2016 at 10:34:04PM +0100, Luca Capello wrote:
> Nothing against you, but a .deb for an 89-line macro sounds a bit
> overkill to me.

I want to package emacs-pdf-tools [1] because it combines Emacs Lisp
with a C program.  It would be very useful for users to be able to just
apt-get a tricky combination like that.  So I need to package let-alist
as a dependency.

> JFTR, I needed it as well as a dependency for Flycheck and ended up
> installing everything from (M)ELPA :-(

That's what I want to avoid!

Sean

[1] https://github.com/politza/pdf-tools


signature.asc
Description: PGP signature

Re: Removing sysV init files

[Jonathan de Boyne Pollard]

Michael Biebl:

I wonder if nosh could be an option for non-linux. According to its 
website it supports native systemd service files. I have to admit 
though, I never looked at nosh myself, so I have no idea how far that 
"systemd support" goes.


This caught my eye, so I thought that I'd demonstrate.  Before getting 
to what I did, let's clear up some tangential points.


Alec Leamas:

The systemd setup [for lirc] is three different services, the sysV 
[setup] one. There is no systemd service directly corresponding to the 
sysV one.


The Debian revision log says that that's not in fact true.

   http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521

There have been three System 5 rc scripts since May 2014; precisely so 
that there *is* a correspondence between service names, according to the 
commentary.


From a Debian point of view, I suspect that the answer that you'll get 
from all of the Debian people who actually look into the situation is 
that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue 
doing this work to maintain System 5 rc scripts for your software, you 
should let xem.  (-:


I suggest that you should probably pay more attention to the System 5 rc 
scripts, because your systemd units aren't up to scratch and don't do as 
good a job.  I discovered this by running your |lircd.socket| and 
|lircd.service| unit files through the nosh conversion process and 
seeing what resulted.  Your "bad gut feeling" about your System 5 rc 
files is, ironically, misplaced and should be about your systemd mechanisms.


Yes the nosh package can take this sort of thing and convert it to 
native form.  There's a detailed worked example of doing so on the nosh 
WWW pages.


   
http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/worked-example.html

For lirc it was almost as easy as:

   JdeBP /tmp $ fetch 
'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.socket?format=raw'
 -o lircd.socket
   JdeBP /tmp $ fetch 
'http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/lircd.service?format=raw'
 -o lircd.service
   JdeBP /tmp $ convert-systemd-units ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

What resulted was a service that didn't start.  Hence "almost".

   JdeBP /tmp $ svstat /tmp/lircd
   /tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , initially 
started
   JdeBP /tmp $

It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to create 
a local-domain socket at |/run/lirc/lircd| . But there was no 
|/run/lirc/| directory on my system to contain that.  Your systemd units 
didn't make one; and one doesn't appear by telepathy.  (-:  Stefan 
Lippers-Hollmann's System 5 rc scripts *do* make this directory, 
however.  They have this near the start:


   [ -d "/run/lirc" ] || mkdir -p "/run/lirc"

The systemd service unit file way of doing the same thing is:

   [Service]
   RuntimeDirectory=lirc

So I edited that into your |lircd.service| and had another go.  This 
time I was hit by a problem with "quirks mode" conversion (which I don't 
use all that often).  Since your |lircd| program doesn't actually rely 
upon any systemd quirks as far as I can see, I simply switched to "ideal 
mode" conversion and converted a third time:


   JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

Now I was hit by the fact that you'd hardwired the pathname 
|/usr/sbin/lircd| into your service unit.  This isn't wrong from a Linux 
systemd operating system perspective.  But I'm doing this on FreeBSD 
(PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much 
does provide the tools for non-Linux operating systems.  The 
FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|, 
because that's the rule for non-operating-system stuff.  Fortunately, 
there are at least two ways around this.  I took the one that uses 
|$PATH|. The conversion tool can be told |ExecStart=lircd| and that will 
make a service bundle that will just work for either |/usr/sbin/lircd| 
or |/usr/local/sbin/lircd| .  So I edited that into your |lircd.service| 
and had another go.


   JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
   JdeBP /tmp $ sudo system-control start /tmp/lircd

And it's up and running, converted from your socket and service units 
into native service bundles, on nosh-managed PC-BSD 10.2.


   JdeBP /tmp $ svstat /tmp/lircd
   /tmp/lircd: running (pid 50174) since 2016-01-16 23:39:56 +; 6s ago.
   JdeBP /tmp $

There are several things that you probably should take note of here.

The converted service bundle uses UCSPI-TCP tools from the toolset to 
set up the listening socket for lircd to inherit. Unfortunately, even 
though this is lirc version 0.9.0, built straight from the FreeBSD port 
today, it doesn't have the code that takes the socket as an