Re: Going ahead with non-free-firmware

[Lucas Nussbaum]

On 11/01/16 at 10:49 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > > So you don't want another component, but something that looks like a
> > > component in some places only?  I.e. it behaves like a component in that
> > > it gets its own Packages (and Sources?) indices, but it has neither its
> > > own area in pool/ nor is it used in packages' Section field.
> > 
> > Right. This would be nice for some other use-cases too, like cut-down
> > Packages/Sources files for special-purpose systems.
> 
> Correct.  And that's why I was actually hoping that something like this
> could actually be a *generalization* of how Packages/Sources files are
> being generated, rather than a new special case to be added---which
> would certainly be a sign of bad design for this proposal.

Right, it would be nice to implement something similar to SQL VIEWs vs
SQL TABLEs: the underlying data (packages) would be exactly the same,
but dak would generate an additional Sources/Packages with a restricted
set of packages, based on a filter on packages' fields (here, the
packages' section).

The same idea could be used for LTS support, to expose Sources/Packages
files with only supported packages.

Lucas


signature.asc
Description: PGP signature

Re: debian/control: enhanced version dependencies?

[Harald Dunkel]

On 01/14/2016 10:11 AM, Andrey Rahmatullin wrote:
> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
>> For running a local set of meta packages I would like to
>> express package dependencies depending upon other packages
>> installed, e.g.
>>
>> Package: xyz
>> Version: all
>> Depends: ${misc:Depends}
>>  , dbus (systemd >= 215)
>>
>> Hopefully you get the meaning. 
> I'm not sure I do.
> 
>> Package xyz could make sure
>> that dbus is installed, if systemd is installed. (systemd
>> version 215 itself just recommends dbus.)
> What if systemd isn't installed? Nothing happens?
> 

Thats what I was trying to express.

>>
>>
>> Another example:
>>
>> Package: mykde
>> Version: all
>> Depends: ${misc:Depends}
>>  . kde-full
>>  , mykde1 (kde-full >= 5:66)
>>  , mykde2 (kde-full >= 5:77)
>>  , mykde3 (kde-full >= 5:84)
>>
>> Package mykde1
>> :
>> :
> This is even less clear.
> 

In this example mykde depends upon kde-full and a set of other
packages, depending upon the version of kde-full.

I am not proud of the syntax, either. Surely you have a better
suggestion about how to express this kind of package dependencies.


Regards
Harri

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

[shawn wilson]

On Jan 14, 2016 5:11 PM, "Zlatan Todoric"  wrote:
>
>
>
> On 01/14/2016 09:11 PM, Alberto Salvia Novella wrote:
> > Nearly all compact Linux computers feasible for gaming are sold
> > exclusively using NVIDIA graphics, and that company is hostile to libre
> > software.
> >
> > So I think it is very important that we support AMD right now on what we
> > can, and ask manufacturers to include AMD graphics in those products.
> >
>
> You do realize that AMD graphics need proprietary firmware to have
> proper 3D acceleration without which you probably couldn't run any game
> at all - so goodbye Libre graphics.
>

Besides that, AMD's fglrx require X to be running in order to run while
nVidia does not (kinda sucks if you have a bunch of 8 card nodes using the
cards for scientific applications). Also, in this setting, there were a lot
more issues with AMD than nVidia (soft crashes, hard crashes, cards going
offline until reboot).

I'm not a big gamer, so maybe there are less issues with AMD in this
setting. And I'd be thrilled if either fglrx or nv were OSS (would weigh
heavily on purchasing decisions). However, because AMD really pissed me off
here, I had to say something here.

> > Because of that I have started campaigning for it:
> > http://steamcommunity.com/discussions/forum/11/458606248621316073/
> >

Bug#811062: ITP: golang-github-pkg-sftp -- SFTP support for the golang.org/x/crypto/ssh package

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-pkg-sftp
  Version : 0.0~git20160111.0.8a7343c-1
  Upstream Author : 
* URL : https://github.com/pkg/sftp
* License : BSD-2-clause
  Programming Lang: Go
  Description : SFTP support for the golang.org/x/crypto/ssh package

 The sftp package provides support for file system operations on
 remote ssh servers using the SFTP subsystem.

Reason for packaging:

 Needed by newer versions of golang-github-spf13-afero, which is
 needed by newer versions of hugo.

Re: default softphone in Debian stretch

[Daniel Pocock]

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

That is not the status-quo however.  Are you saying that somebody
installing a default GNOME desktop should not automatically have Empathy
any more?  That is actually what upstream discussed (link in the message
that started this thread), but without any conclusion.

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?

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?

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.

Regards,

Daniel

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

[Svante Signell]

On Fri, 2016-01-15 at 04:57 -0500, shawn wilson wrote:
> 
> On Jan 14, 2016 5:11 PM, "Zlatan Todoric"  wrote:
> 
> > > So I think it is very important that we support AMD right now on what we
> > > can, and ask manufacturers to include AMD graphics in those products.
> > >
> >
> > You do realize that AMD graphics need proprietary firmware to have
> > proper 3D acceleration without which you probably couldn't run any game
> > at all - so goodbye Libre graphics.
> >
> Besides that, AMD's fglrx require X to be running in order to run while nVidia
> does not (kinda sucks if you have a bunch of 8 card nodes using the cards for
> scientific applications). Also, in this setting, there were a lot more issues
> with AMD than nVidia (soft crashes, hard crashes, cards going offline until
> reboot).
> I'm not a big gamer, so maybe there are less issues with AMD in this setting.
> And I'd be thrilled if either fglrx or nv were OSS (would weigh heavily on
> purchasing decisions). However, because AMD really pissed me off here, I had
> to say something here.

Well, I don't think the issue is about the non-free driver fglrx, but the open
source radeon drivers. fglrx is as bad as the nVidia non-free ones. BTW: nv is
OSS (Open Source Software), however with limited performance due to lacking open
documentation of the nVidia graphics hardware. The closed firmware issue is
another story...

Re: debian/control: enhanced version dependencies?

[Steffen Möller]

On 15/01/16 09:33, Harald Dunkel wrote:
> On 01/14/2016 10:11 AM, Andrey Rahmatullin wrote:
>> On Thu, Jan 14, 2016 at 09:35:31AM +0100, Harald Dunkel wrote:
>>> For running a local set of meta packages I would like to
>>> express package dependencies depending upon other packages
>>> installed, e.g.
>>>
>>> Package: xyz
>>> Version: all
>>> Depends: ${misc:Depends}
>>> , dbus (systemd >= 215)
>>>
>>> Hopefully you get the meaning. 
>> I'm not sure I do.
>>
>>> Package xyz could make sure
>>> that dbus is installed, if systemd is installed. (systemd
>>> version 215 itself just recommends dbus.)
>> What if systemd isn't installed? Nothing happens?
>>
> Thats what I was trying to express.
>
>>>
>>> Another example:
>>>
>>> Package: mykde
>>> Version: all
>>> Depends: ${misc:Depends}
>>> . kde-full
>>> , mykde1 (kde-full >= 5:66)
>>> , mykde2 (kde-full >= 5:77)
>>> , mykde3 (kde-full >= 5:84)
>>>
>>> Package mykde1
>>> :
>>> :
>> This is even less clear.
>>
> In this example mykde depends upon kde-full and a set of other
> packages, depending upon the version of kde-full.
>
> I am not proud of the syntax, either. Surely you have a better
> suggestion about how to express this kind of package dependencies.
>
The '|' character to express a condition is already taken,
and so are the parentheses.

How about some Perl-like post-annotation as in

Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 if kde-full >= 5:66
, mykde2 if kde-full >= 5:77
, mykde3 if kde-full >= 5:84

This way you can mix the two semantics

Package: mykde
Version: all
Depends: ${misc:Depends}
. kde-full
, mykde1 (>= 4.99)if kde-full >= 5:66
, mykde1 (>= 5.0) if kde-full >= 5:77

How long will it take until someone implements tic-tac-toe
with Debian package dependencies? Just kidding.

If the package maintainers get this right, then I
think these logics would indeed help to get Debian systems
leaner and possibly also more stable. But I primarily see
some beauty that intrigues me.

Steffen

Bug#811069: ITP: lbfgsb -- Limited-memory quasi-Newton bound-constrained optimization

[Gard Spreemann]

Package: wnpp
Severity: wishlist
Owner: Gard Spreemann 

* Package name: lbfgsb
  Version : 3.0
  Upstream Author : Ciyou Zhu, Richard Byrd, Jorge Nocedal, Jose Luis Morales
* URL : http://users.iems.northwestern.edu/~nocedal/lbfgsb.html
* License : BSD-3-clause
  Programming Lang: Fortran
  Description : Limited-memory quasi-Newton bound-constrained optimization

The library is a widely used implementation of a bounded,
limited-memory BFGS algorithm.

A search on codesearch.debian.net reveals that at least the following
packages in Debian bundle duplicates of the code:
- python-scipy (see also #778635)
- vxl
- nwchem
- plastimatch
- psi4

I believe that Debian should provide lbfgsb as a standalone library,
as it is useful in its own right and its presence could lead to code
deduplication in the future.

Note that upstream's tarball
(http://users.iems.northwestern.edu/~nocedal/Software/Lbfgsb.3.0.tar.gz)
contains a few prebuilt binaries, and is also a minor tarbomb.

Upstream seems very inactive in the sense that the code appears to be
"done". I have maintained a package for personal use since 2013 and
have never experienced problems. I thus feel I could handle maintaing
the package also for a wider user base going forward.

I would need a sponsor.

Re: debian/control: enhanced version dependencies?

[Felipe Sateler]

On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:

> Hi folks,
> 
> For running a local set of meta packages I would like to express package
> dependencies depending upon other packages installed, e.g.
> 
> Package: xyz
> Version: all 
> Depends: ${misc:Depends}
>   , dbus (systemd >= 215)

dbus | systemd < 215

> 
> Hopefully you get the meaning. Package xyz could make sure that dbus is
> installed, if systemd is installed. (systemd version 215 itself just
> recommends dbus.)
> 
> 
> Another example:
> 
> Package: mykde
> Version: all
> Depends: ${misc:Depends}
>   . kde-full
>   , mykde1 (kde-full >= 5:66)

kde-full < 5:66 | mykde1

>   , mykde2 (kde-full >= 5:77)

kde-full < 5:77 | mykde2

>   , mykde3 (kde-full >= 5:84)

kde-full < 5:84 | mykde3

> 
> Package mykde1 :
> :
> 
> Do you think this could be possible? Are there other options for
> debian/control to express complex package dependencies?


You are trying to create implications. a => b is the same as !a || b, 
which is how I expressed the dependencies above. This is easy to do for 
versioned dependencies, but not so easy for non-versioned ones (you 
cannot have !package in the Depends field, there is the Conflicts field 
but that is another grouping). You could work around that limitation by 
imposing a (<< 0~) restriction to packages that should not be installed 
in any version.

This may make the package difficult to install, however, because apt only 
considers one version per package as candidate.

-- 
Saludos,
Felipe Sateler

Re: Going ahead with non-free-firmware

[chrysn]

On Mon, Jan 11, 2016 at 09:34:07AM -0800, Nikolaus Rath wrote:
> On Jan 09 2016, Dominic Hargreaves  wrote:
> > I think the *policy* for this section should be firmware, as defined
> > as code not executing on the main CPU, or something like that.
> 
> Uh, so intel-microcode is still out? 

From that description, yes, and I appreciate that.

FWICT, nonfree-firmware aims to find a middle ground between

1) security issues with non-free system components, and
2) hardware being unusable without nonfree blobs.

Right now microcode does not fit in that middle ground from either 1)
(because no DMA to protect us) nor 2) (because things work without as
well). If, at some future point in time, CPUs do require microcode
updates, we might need to revisit this.

best regards
chrysn

-- 
A beginning is the time for taking the most delicate care that the
balances are correct.
  -- Princess Irulan, Manual of Muad'Dib


signature.asc
Description: PGP signature

Removing sysV init files

[Alec Leamas]

Dear list,

In the process of a complicated update, there is a question about how to 
handle the systemV init scripts when doing the systemd transition.


The package (lirc) has upstream systemd scripts which of course are 
packaged. The existing Debian version has sysV scripts. However, these 
are quite a pain to maintain.


Given all this: would it be OK to drop the sysV files in a stretch update?


Cheers!

--alec

Re: debian/control: enhanced version dependencies?

[Samuel Thibault]

Felipe Sateler, on Fri 15 Jan 2016 12:33:37 +, wrote:
> On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:
> 
> > Hi folks,
> > 
> > For running a local set of meta packages I would like to express package
> > dependencies depending upon other packages installed, e.g.
> > 
> > Package: xyz
> > Version: all 
> > Depends: ${misc:Depends}
> > , dbus (systemd >= 215)
> 
> dbus | systemd < 215

In the meant purpose you'd need also

| !systemd

which is not supported.

Samuel

Bug#811074: ITP: libjsonp-java -- Java API for JSON Processing

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libjsonp-java
  Version : 1.0.4
  Upstream Author : Jitendra Kotamraju
* URL : http://jsonp.java.net
* License : GPL
  Programming Lang: Java
  Description : Java API for JSON Processing
 JSON Processing project is the open source reference implementation of
 JSR 353 - Java API for JSON Processing. The JSR provides portable APIs
 to parse, generate, transform, and query JSON using the streaming API or
 the object model API.


Remark: This package will be maintained in the Debian Java team at
   git://anonscm.debian.org/pkg-java/libjsonp-java.git

My initial motivation for this package is that the new version of
the Debian Med package pixelmed needs it as a precondition.

Re: Going ahead with non-free-firmware

[Marco d'Itri]

On Jan 15, chrysn  wrote:

> Right now microcode does not fit in that middle ground from either 1)
> (because no DMA to protect us) nor 2) (because things work without as
> well). If, at some future point in time, CPUs do require microcode
> updates, we might need to revisit this.
CPUs *do* require microcode updates: to fix bugs.
You can pretend that they still work well enough without updates, or 
hope that they will come from the BIOS anyway, but this is something 
that I recommend to my competitors.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Removing sysV init files

[Dmitrii Kashin]

Alec Leamas  writes:

> Dear list,
>
> In the process of a complicated update, there is a question about how
> to handle the systemV init scripts when doing the systemd transition.
>
> The package (lirc) has upstream systemd scripts which of course are
> packaged. The existing Debian version has sysV scripts. However, these
> are quite a pain to maintain.
>
> Given all this: would it be OK to drop the sysV files in a stretch update?

I suppose it's not okay, because you'll get a lot of bug reports from
non-linux based debian distributions. And if it's not your business, and
you don't support sysv scripts, then it will eventually become a problem
for developers of these distributions.

I wanna remind that systemd as the default is an experiment. It can be
finished in a while. So it's important to safe the support for other
init systems.

Btw, I'm a user of Debian Jessie, and I see then now Debian keep an
ability to work without systemd. I'd like it to be so in the future.

Re: default softphone in Debian stretch

[Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

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

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

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

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

iQIcBAEBAgAGBQJWmPIrAAoJEJzRfVgHwHE6ZpMP/0/EEjPpfCBTu479xUqDMZFr
g3/7qjPVUhD7DI6SIez55Rav8YC7UiS+khwb4emlmT/olk18nfdpYEVwhkniv4vN
pxDE8YerOUAqs3ZqicbhwsNx1SRw+rHnurJfJFUEldw5+M1hnLTnSZ3NCpoS1IUI
06VLw6yuKa2udwaP+JpXyBVrRceRXWti9gU5xHCO2VgsDol6ug1jHWGZq8tugPqL
QLBeWzswFszAhSp81SIY8Ez9DvIIXBrQrVzUCUly/yaSAzOHUi5hD88KHaMSZrzt
DLx8yAVM6iG4fVYD7f6VzRTCl55YMKJIU2XuH19efI94/5WEZTumPEL19RrRe+8u
Bo+xzlFd346skNp+cT8ytHyGlXHUQCbPp9GxAPMbNeoal/DF7zFgTudDcNPnyPb4
cJOnUfhFbfekr3l3ETfwMyuf0Awv2SGmY2XaS5mqxdMNuRsCWbGp0AJTI7nR4Lil
wAeZW1HWS2cE0r3cd3Te99O7jC6loDgPXAb/BrWLSEBpR2TqXzBEnR6q712JezMK
pkoelAiFaJ3DKtx4ONp/hyC5D6Zr2u1j83dGACZamlzfJ3UFTqVfHsuNu2f/VPjA
Q2Y5vtjBE3IyS2FZX8K2Y3t2FTmuhHKhGiUh44opkgyH5kOh4ATBHEwp2VtOP4eI
2qQfoqbIzezKrYmeYOgx
=iUqi
-END PGP SIGNATURE-

Re: Going ahead with non-free-firmware

[Ben Hutchings]

On Fri, 2016-01-15 at 14:07 +0100, Marco d'Itri wrote:
> On Jan 15, chrysn  wrote:
> 
> > Right now microcode does not fit in that middle ground from either 1)
> > (because no DMA to protect us) nor 2) (because things work without as
> > well). If, at some future point in time, CPUs do require microcode
> > updates, we might need to revisit this.
> CPUs *do* require microcode updates: to fix bugs.
> You can pretend that they still work well enough without updates, or 
> hope that they will come from the BIOS anyway, but this is something 
> that I recommend to my competitors.

Right.  Microcode bugs can cause data corruption and security holes -
both of which we consider RC.

Ben.

-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

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

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

[Stefan Monnier]

>> So I think it is very important that we support AMD right now on what we
>> can, and ask manufacturers to include AMD graphics in those products.
> You do realize that AMD graphics need proprietary firmware to have
> proper 3D acceleration without which you probably couldn't run any game
> at all - so goodbye Libre graphics.

That's still much better than the situation with Nvidia.
But your point is well taken: we should put most pressure on Nvidia
while keeping the pressure on AMD.


Stefan

Re: debian/control: enhanced version dependencies?

[Felipe Sateler]

On Fri, 15 Jan 2016 13:56:55 +0100, Samuel Thibault wrote:

> Felipe Sateler, on Fri 15 Jan 2016 12:33:37 +, wrote:
>> On Thu, 14 Jan 2016 09:35:31 +0100, Harald Dunkel wrote:
>> 
>> > Hi folks,
>> > 
>> > For running a local set of meta packages I would like to express
>> > package dependencies depending upon other packages installed, e.g.
>> > 
>> > Package: xyz Version: all Depends: ${misc:Depends}
>> >, dbus (systemd >= 215)
>> 
>> dbus | systemd < 215
> 
> In the meant purpose you'd need also
> 
> | !systemd
> 
> which is not supported.

Ah, you are correct.  !(x (>> v)) is not (x (<= v)). It doesn't seem to 
be possible then.



-- 
Saludos,
Felipe Sateler

Bug#811081: ITP: ruby-alsa-rawmidi -- Realtime MIDI IO with Ruby for Linux via the ALSA RawMIDI API.

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-alsa-rawmidi
  Version : 0.3.1
  Upstream Author : Ari Russo
* URL : https://rubygems.org/gems/alsa-rawmidi
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Realtime MIDI IO with Ruby for Linux via the ALSA RawMIDI 
API.

Packaging as dependency of Sonic Pi (ITP #796550)

MIA team still alive?

[Norbert Preining]

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.

Thanks

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

Bug#811084: ITP: ruby-rubame -- Ruby Websocket Game Server

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-rubame
  Version : 0.0.2
  Upstream Author : Mark Saward
* URL : https://rubygems.org/gems/rubame
* License : MIT
  Programming Lang: Ruby
  Description : Ruby Websocket Game Server

Packaging as dependency of Sonic Pi (ITP #796550)

Bug#811086: ITP: ruby-wavefile -- You can use this gem to create Ruby programs that produce audio.

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-wavefile
  Version : 0.6.0
  Upstream Author : Joel Strait
* URL : https://rubygems.org/gems/wavefile
* License : MIT
  Programming Lang: Ruby
  Description : You can use this gem to create Ruby programs that produce 
audio.

Packaging as dependency of Sonic Pi (ITP #796550)

Re: Removing sysV init files

[Alec Leamas]

On 15/01/16 14:13, Dmitrii Kashin wrote:

Alec Leamas  writes:


Dear list,




Given all this: would it be OK to drop the sysV files in a stretch update?


I suppose it's not okay, because you'll get a lot of bug reports from
non-linux based debian distributions. And if it's not your business, and
you don't support sysv scripts, then it will eventually become a problem
for developers of these distributions.

I wanna remind that systemd as the default is an experiment. It can be
finished in a while. So it's important to safe the support for other
init systems.

Btw, I'm a user of Debian Jessie, and I see then now Debian keep an
ability to work without systemd. I'd like it to be so in the future.



So, here is three things:

Support for non-linux based debian distributions. Perhaps this could be 
handled by packing current scripts in /usr/share/doc, so they are 
available for downstream packaging? Besides that, what says policy 
decisions on this issue?


Support for users not using systemd. I understand that such users will 
be unhappy without the scripts - but am I obliged under current policy 
decisions to maintain this configuration?


"systemd is an experiment". Well, the future can bring any changes. 
Frankly, we need to adapt when the changes come, if they come. IMHO, 
what we can about this is, again, to ship the unmaintained scripts in 
/usr/share doc.


I might add that this is not as simple as some service changing from an 
init.d script to a corresponding .service files. The upstream package 
has another service structure, socket activation and other things which 
are not easily reflected in the sysV scripts. Also, all existing 
documentation presumes systemd. So, while the sysV scripts exists and 
perhaps "works" in a  basic sense they represent sub-optimal user 
experience. This is what makes this hard.


Thoughts?


--alec

Bug#811088: ITP: ruby-midilib -- A pure Ruby MIDI library.

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-midilib
  Version : 2.0.5
  Upstream Author : Jim Menard
* URL : https://rubygems.org/gems/midilib
* License : Ruby License
  Programming Lang: Ruby
  Description : A pure Ruby MIDI library.

Packaging as dependency of Sonic Pi (ITP #796550)

Re: Removing sysV init files

[The Wanderer]

On 2016-01-15 at 09:45, Alec Leamas wrote:

> On 15/01/16 14:13, Dmitrii Kashin wrote:
> 
>> Alec Leamas  writes:
>> 
>>> Dear list,

>>> Given all this: would it be OK to drop the sysV files in a
>>> stretch update?
>> 
>> I suppose it's not okay, because you'll get a lot of bug reports
>> from non-linux based debian distributions. And if it's not your
>> business, and you don't support sysv scripts, then it will
>> eventually become a problem for developers of these distributions.
>> 
>> I wanna remind that systemd as the default is an experiment. It can
>> be finished in a while. So it's important to safe the support for
>> other init systems.

While I agree with the sentiment, I'm not sure I've heard that choosing
systemd as default was an "experiment" before now, at least any more
than any Debian choice is an experiment (in that the project can decide
to switch away from it if it doesn't work out well).

>> Btw, I'm a user of Debian Jessie, and I see then now Debian keep
>> an ability to work without systemd. I'd like it to be so in the
>> future.
> 
> So, here is three things:
> 
> Support for non-linux based debian distributions. Perhaps this could
> be handled by packing current scripts in /usr/share/doc, so they are
> available for downstream packaging? Besides that, what says policy
> decisions on this issue?

It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
Debian-Hurd? Both are theoretically official Debian, as far as I
understand matters, rather than being downstream distros - but neither
one is supported by systemd.

> Support for users not using systemd. I understand that such users
> will be unhappy without the scripts - but am I obliged under current
> policy decisions to maintain this configuration?

My understanding from the past debates is that you're not obliged to
maintain sysvinit scripts, but that if other people want to do the work
and send in patches to add / update / maintain such scripts, you don't
get to reject them - or at least not on the grounds that sysvinit is not
supported.

That would seem to imply, in turn, that you shouldn't drop existing
sysvinit scripts from the package, unless they're known to already be
broken badly enough that not having any would be an improvement
(although I don't think I've seen this specifically addressed in past
discussions). You wouldn't be obliged to continue to maintain and update
them, however, and IMO - in the absence of someone who _is_ doing that -
you'd be fine to put in a warning that using them is unsupported and not
recommended.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Removing sysV init files

[Guus Sliepen]

On Fri, Jan 15, 2016 at 03:45:30PM +0100, Alec Leamas wrote:

> Support for users not using systemd. I understand that such users will be
> unhappy without the scripts - but am I obliged under current policy
> decisions to maintain this configuration?

Up until the next stable release at least, you are strongly advised to
keep the sysvinit files in place. If you cannot maintain them yourself,
ask for help.

> [...] the sysV scripts exists and perhaps "works" in a
> basic sense [...]

That is already much better than not having a SysV script. But at this
point I don't think you have to spend a lot of effort to try to get it
to feature parity with the systemd service. Though if someone sends you
a patch to improve the SysV script, you should accept it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: MIA team still alive?

[Amaya]

Norbert Preining wrote:
> 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.

Please go ahead. He's clearly MIA.

-- 
 .''`.The world breaks everyone, and afterward, some are
: :' :strong at the broken places.- Ernest Hemingway
`. `'   
  `-Proudly running Debian GNU/Linux

Re: debian/control: enhanced version dependencies?

[Johannes Schauer]

Hi,

Quoting Felipe Sateler (2016-01-15 13:33:37)
> You are trying to create implications. a => b is the same as !a || b, which
> is how I expressed the dependencies above. This is easy to do for versioned
> dependencies, but not so easy for non-versioned ones (you cannot have
> !package in the Depends field, there is the Conflicts field but that is
> another grouping). You could work around that limitation by imposing a (<<
> 0~) restriction to packages that should not be installed in any version.

Implications like a=>b can be expressed via a third package c which conflicts
with a. You'd then have:

Package: xyz
Depends: c | b

Package: c
Conflicts: a

Whenever discussions about new dependency syntax come up I like to remind
people of all the time (about six years now) and effort it took to get the
build profile syntax [1] accepted by the archive, supported by all tools and to
sufficiently discuss this with everybody involved to get general agreement that
this is necessary and we're doing it the right way. And this is not even over
yet as that syntax has to be documented in policy as well! Plus, we are only
talking about Build-Depends syntax here.  I'd assume that there are even more
tools that handle binary package Depends syntax that the 19 that handle source
package dependency syntax.

In this case, the desired effect can be achieved using existing elements of the
dependency syntax and without any unreadable version quirks. A new syntax would
*only* be acceptable if there were hundreds if not thousands of packages that
would benefit from an easier way to express such a conditional and in which
case having all these meta-packages I proposed as a solution above would become
infeasible.

Thanks!

cheers, josch

[1] https://wiki.debian.org/BuildProfileSpec


signature.asc
Description: signature

Re: Removing sysV init files

[Russ Allbery]

Alec Leamas  writes:

> In the process of a complicated update, there is a question about how to
> handle the systemV init scripts when doing the systemd transition.

> The package (lirc) has upstream systemd scripts which of course are
> packaged. The existing Debian version has sysV scripts. However, these
> are quite a pain to maintain.

> Given all this: would it be OK to drop the sysV files in a stretch
> update?

It sounds like the primary concern you have around keeping the files is
keeping them up-to-date.  If you don't have the resources to do that (or
prefer to spend them on other parts of the package), let me suggest a
third option: ship the sysvinit scripts as-is in the package, and solicit
help from users of the package to update them.  You could put a large
comment at the top of the script plus a notice in changelog saying that
you're happy to keep including the sysvinit scripts, but don't use or test
them yourself, so are entirely reliant on other people submitting fixes.
You can then continue to make any obvious fixes (if the path to some
executable changes, etc.), but if no one steps forward, the more subtle
things are likely to degrade.

We had some really extended discussions about exactly this problem prior
to the init system discussion before the jessie release, and the above
approach seemed to have the most consensus.

I think this is also consistent with the TC decision (#746715):

The issue of init system support recently came to the Technical
Committee's attention again.[1]

For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian.  That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.

I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.  Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.

-- 
Russ Allbery (r...@debian.org)   

Bug#811110: ITP: dirtbike -- convert installed Python packages to wheels

[Barry Warsaw]

Package: wnpp
Severity: wishlist
Owner: Barry Warsaw 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: dirtbike
  Version : 0.1
  Upstream Author : Asheesh Laroia
* URL : https://github.com/paulproteus/dirtbike
* License : Expat/MIT
  Programming Lang: Python
  Description : convert installed Python packages to wheels

The purpose of this package is to make it easier to devendorize other
packages which bundle various upstream packages.  An example of this
is pip, which bundles a half-dozen or so other upstream packages.  In
Debian and other distros, such vendoring is frowned upon.  To make it
easier to devendorize, dirtbike turns installed system packages into
wheels, and these wheels can then be used instead of the vendored
packages.
 
The intent is for dirtbike to be solely a Build-Depends for a limited
set of other packages such as python-pip, python-virtualenv, and any
other packages which vendorize their dependencies.

For now, I plan to maintain this myself (perhaps with other upstream
authors who are also Debian Developers), but it may eventually migrate
to the Python Applications Packaging Team (PAPT).

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWmUMBAAoJEBJutWOnSwa/lfYQAIyU7m8ZLFdqar3z9jDhnmLz
cEttYUzvFFsinpyZhuoR23khyONNi0BaqNBB8ftZ5FR37G6qKtYA/BBiPv74SXxM
ATXhNDrlGxbkrTpP3tem8rTIAbCy3DreJdF+ka+IXLraObnywoH0SgiICNpJBUsi
M1R51GO3a/t1tsgTsnnGTXlqTDEtHJfAiqTFZDxuoPdQlIq721N0/U1QrsURRJvP
d7hfJjS18R7dSWd/3giqdfwqjdNHj5CIZ2+AlloxIQBUedk+e7aiCnKy7+oI0NrN
OT+y6dn1ajfpp1QKnVO8Rbxebeu7AuERxEUUGaa3BAPNczj71q/8XJ5xZTRs4pVY
0t7Cnj9T80xRY60qbGcrTifilLqI+wZ7pC1yS4JfUJWON5HvLQ/XVNd6jJtBY+4T
JnJ7TY5MBnGClyFgJhH7G3eRO3fjV8NIb7zZHaIAhfokHJMTGed37ZVfdXUvDmTS
zQiAJt/uw/3nyT6WL4UBiVT3pgUP1qEG9u7z3Qk891a0jIQW1HdMpQt5xdtXV0bh
xltw+pgdkU07KAyS+KUwL+1OxhQM+D5JNw8mJNvo0UgvjI2WV7WO/G2/xXf5YAn1
8aZ4jG6tKd5Bp32Lq1N2WzVIXx7E5dUoGK4SKo6Gzs81rwV2AmdBlPBMTAiZkAAY
A6KI8oonwFtiIIStwuED
=7AwS
-END PGP SIGNATURE-

high quality websites posts sell

[gulnaz khan]

hey sir
check my quality web sites
www.hr.com656

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 16:07 schrieb The Wanderer:
> It's not only about downstreams. What about e.g. Debian-kFreeBSD, or
> Debian-Hurd? Both are theoretically official Debian, as far as I
> understand matters, rather than being downstream distros - but neither
> one is supported by systemd.

I wonder if nosh [1] 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.


Michael


[1] http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
-- 
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: Removing sysV init files

[Alec Leamas]

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


I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.  Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.


OK, seems that all agree that the scripts should be kept in the package. 
So the question then becomes how. As you might have understood I have a 
bad gut feeling about them.


Given this, would it be OK to put  the sysV scripts in a separate 
subpackage which can be properly commented?



Cheers!

--alec

IMPORTEND squid3 stable needs update

[startrekfan]

Hello,

I'm not sure which mailing list I should chose. So I'll try my luck here.

I didn't subscribed to the mailing list. So* please put my mail address
into cc*. thanks.

*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

So I'd like to request to mark Version 3.5 as stable.(But Version 3.5 in
stable state)

thank you

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:01 schrieb Alec Leamas:
> On 15/01/16 19:04, Russ Allbery wrote:
>>
>> I feel like removing the sysvinit scripts entirely would be "reverting
>> existing support without a compelling reason."  But I also think that
>> people who want to use sysvinit (or upstart, or any other init system)
>> will have to contribute some support there in the form of bug reports and
>> patches, just as with any other non-default configuration in Debian. 
>> Your
>> obligation as maintainer is to "merge reasonable contributions" as
>> mentioned above.
> 
> OK, seems that all agree that the scripts should be kept in the package.
> So the question then becomes how. As you might have understood I have a
> bad gut feeling about them.
> 
> Given this, would it be OK to put  the sysV scripts in a separate
> subpackage which can be properly commented?
> 

I think a sub package is overkill and up until now, this has been
avoided in Debian.

If your package ships both a systemd service unit and a sysv init
script, you need to make sure that under systemd the native service file
is used.
The easiest way to achieve that is to use the same names for the unit
file and the init script, i.e.
/etc/init.d/foo should match /lib/systemd/system/foo.service

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




-- 
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: IMPORTEND squid3 stable needs update

[Ben Hutchings]

On Fri, 2016-01-15 at 19:47 +, startrekfan wrote:
> Hello,
> 
> I'm not sure which mailing list I should chose. So I'll try my luck here.
> 
> I didn't subscribed to the mailing list. So* please put my mail address
> into cc*. thanks.
> 
> *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

You seem a bit confused about how Debian releases work.  Within any
stable release, we apply bug fixes only - unless it's impossible for us
to provide security support for the old upstream version.

Our package of squid 3.4.8 does have a security fix on top of the
upstream version: https://tracker.debian.org/news/702659

So far as we know, there are no important security issues still
affecting the version in jessie:
https://security-tracker.debian.org/tracker/source-package/squid3

Do you know otherwise?

Ben.

> So I'd like to request to mark Version 3.5 as stable.(But Version 3.5 in
> stable state)
> 
> thank you
-- 
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.

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

Re: Removing sysV init files

[Alec Leamas]

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:


I feel like removing the sysvinit scripts entirely would be "reverting
existing support without a compelling reason."  But I also think that
people who want to use sysvinit (or upstart, or any other init system)
will have to contribute some support there in the form of bug reports and
patches, just as with any other non-default configuration in Debian.
Your
obligation as maintainer is to "merge reasonable contributions" as
mentioned above.


OK, seems that all agree that the scripts should be kept in the package.
So the question then becomes how. As you might have understood I have a
bad gut feeling about them.

Given this, would it be OK to put  the sysV scripts in a separate
subpackage which can be properly commented?



I think a sub package is overkill and up until now, this has been
avoided in Debian.

If your package ships both a systemd service unit and a sysv init
script, you need to make sure that under systemd the native service file
is used.
The easiest way to achieve that is to use the same names for the unit
file and the init script, i.e.
/etc/init.d/foo should match /lib/systemd/system/foo.service

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.


Cheers

--alec

Re: Removing sysV init files

[Stefan Lippers-Hollmann]

Hi

On 2016-01-15, Alec Leamas wrote:
> On 15/01/16 19:04, Russ Allbery wrote:
> >
> > I feel like removing the sysvinit scripts entirely would be "reverting
> > existing support without a compelling reason."  But I also think that
> > people who want to use sysvinit (or upstart, or any other init system)
> > will have to contribute some support there in the form of bug reports and
> > patches, just as with any other non-default configuration in Debian.  Your
> > obligation as maintainer is to "merge reasonable contributions" as
> > mentioned above.  
> 
> OK, seems that all agree that the scripts should be kept in the package. 
> So the question then becomes how. As you might have understood I have a 
> bad gut feeling about them.
> 
> Given this, would it be OK to put  the sysV scripts in a separate 
> subpackage which can be properly commented?

As Michael Biebl already mentioned, this is overkill (and borderline 
broken, because the hypothetical 'lirc-sysv' won't be pulled in by 
upgrades, thereby breaking kfreebsd-any and hurd).

Working sysv initscripts for lircd/ lircmd/ irexec:

http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircd.init?view=markup
http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircmd.init?view=markup
http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.irexec.init?view=markup

which are masked by the according, upstream provided, systemd units,
therefore being a no-op on systems using systemd and drop-in 
replacements for systems not using it (respectively not being able
to use systemd yet, namely kfreebsd-amd64, kfreebsd-i386 and hurd).
The maintenance overhead for these is minimal, at least for the time
being, unless there are significant (upstream) changes in the queue 
for lirc and there is little excuse to intentionally break support
for sysvinit (== non-linux ports).

Combined, these three initscripts (including lots of whitespace) are 
5 KB in size, the packaging overhead (/usr/share/doc// and
the space this required in the package indices, e.g. Packages.gz) for 
these would far bigger than the potential gain of stripping them out 
(the only advantage would be being able to drop the dependency on 
lsb-base, a whopping 51 KB installed package size --> not worth it, 
even assuming lsb-base wouldn't be required by many other core packages
anyways).

Regards
Stefan Lippers-Hollmann


pgpPJNl3LgbCu.pgp
Description: Digitale Signatur von OpenPGP

Re: Removing sysV init files

[Michael Biebl]

Hi Alec

Am 15.01.2016 um 21:42 schrieb Alec Leamas:
> 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.

In that case, I would probably mask the sysv init script under systemd,
i.e ship a symlink /lib/systemd/systemd/sysvinitname → /dev/null

This way, it is prevented, that the sysv init script is run (by
accident) under systemd.


-- 
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: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:48 schrieb Michael Biebl:
> Hi Alec
> 
> Am 15.01.2016 um 21:42 schrieb Alec Leamas:
>> 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.
> 
> In that case, I would probably mask the sysv init script under systemd,
> i.e ship a symlink /lib/systemd/systemd/sysvinitname → /dev/null
> 
> This way, it is prevented, that the sysv init script is run (by
> accident) under systemd.

An example for that is alsa-utils:
The sysv init script is named

/etc/init.d/alsa-utils

The systemd service units:
/lib/systemd/system/alsa-store.service
/lib/systemd/system/alsa-state.service
/lib/systemd/system/alsa-restore.service

And /lib/systemd/system/alsa-utils.service is a symlink pointing at
/dev/null.


Another approach, as e.g. used by openvpn, where /etc/init.d/openvpn
corresponds to a multitude of systemd service units, is to to use a
dummy service or target, which represents the old sysv name.

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: Removing sysV init files

[Stefan Lippers-Hollmann]

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:
- split the old initscript /etc/init.d/lirc into three, e.g.
  /etc/init.d/lircd, /etc/init.d/lircmd and /etc/init.d/irexec
  as I've shown in my previous mail (<20160115214556.25012e2e@mir>).
  This way both systemd and sysvinit have the same services to
  work with and the sysv initscripts are automatically masked on
  a system using systemd, favouring the corresponding systemd units 
  instead.
- XOR approach this as Michael Biebl suggested, keep the old initscript
  as /etc/init.d/lirc and hard-mask it for systemd so (which means 
  systemd won't look at it and use the native systemd units instead, 
  while non-systemd doesn't know about the masking (nor the three native 
  systemd units) and just keeps using the old sysv initscripts as before).

The result is basically the same for both options, but doing the trivial
split achieves the same behaviour for all init systems - which can help
potential future debugging significantly (and is a cleaner/ safer solution
if other init systems would gain basic or partial support for systemd units
(e.g on kfreebsd)).

Regards
Stefan Lippers-Hollmann


pgpKxndgICXp4.pgp
Description: Digitale Signatur von OpenPGP

Re: Removing sysV init files

[Michael Biebl]

Am 15.01.2016 um 21:56 schrieb Michael Biebl:
> An example for that is alsa-utils:
> The sysv init script is named
> 
> /etc/init.d/alsa-utils
> 
> The systemd service units:
> /lib/systemd/system/alsa-store.service
> /lib/systemd/system/alsa-state.service
> /lib/systemd/system/alsa-restore.service
> 
> And /lib/systemd/system/alsa-utils.service is a symlink pointing at
> /dev/null.
> 
> 
> Another approach, as e.g. used by openvpn, where /etc/init.d/openvpn
> corresponds to a multitude of systemd service units, is to to use a
> dummy service or target, which represents the old sysv name.

That all said, I can very well understand, if you are concerned about
the additional complexity introduced by this.
If you don't have a single service unit which exactly matches the sysv
init script name, it can get tricky to get right, and blindly shipping a
(user) provided sysv init script in your package can actually break your
systemd service unit in such a case, as systemd would try to start both.


-- 
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: IMPORTEND squid3 stable needs update

[startrekfan]

squid3 3.4.8 has some security issues(risks)/bugs so an upgrade to 3.5 is
actually only a fix of this bugs/security issues. There is no patch for
3.4.8 because it's outdated. Debian Jessie is the current active release.
So why not fixing squid3 in Debian Jessie with an stable 3.5 update?

Ben Hutchings  schrieb am Fr., 15. Jan. 2016 um
21:26 Uhr:

> On Fri, 2016-01-15 at 19:47 +, startrekfan wrote:
> > Hello,
> >
> > I'm not sure which mailing list I should chose. So I'll try my luck here.
> >
> > I didn't subscribed to the mailing list. So* please put my mail address
> > into cc*. thanks.
> >
> > *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
>
> You seem a bit confused about how Debian releases work.  Within any
> stable release, we apply bug fixes only - unless it's impossible for us
> to provide security support for the old upstream version.
>
> Our package of squid 3.4.8 does have a security fix on top of the
> upstream version: https://tracker.debian.org/news/702659
>
> So far as we know, there are no important security issues still
> affecting the version in jessie:
> https://security-tracker.debian.org/tracker/source-package/squid3
>
> Do you know otherwise?
>
> Ben.
>
> > So I'd like to request to mark Version 3.5 as stable.(But Version 3.5 in
> > stable state)
> >
> > thank you
> --
> Ben Hutchings
> The program is absolutely right; therefore, the computer must be wrong.

Re: IMPORTEND squid3 stable needs update

[Carsten Schoenert]

Hello startrekfan,

please don't do top posting.

Am 15.01.2016 um 23:19 schrieb startrekfan:
> squid3 3.4.8 has some security issues(risks)/bugs so an upgrade to 3.5 is
> actually only a fix of this bugs/security issues.

Which issues do you refer? What bugs in detail? Have you looked into the
links Ben was providing? If you are talking about CVE-2015-5400 you will
it is fixed and there are no other open issues, but Ben was already
talking about that.

> There is no patch for 3.4.8 because it's outdated.

But it's not impossible to do such a patch, isn't it? And that's what
maintainer of Debian packages do on their own if upstream isn't very
helpful. This work ends in security updates. You use this feature in
your sources list to get them via apt?

> Debian Jessie is the current active release. So why not fixing squid3
> in Debian Jessie with an stable 3.5 update?>

Because this isn't needed if you can patch such issues and will probably
break other packages if you do such updates without further testing.
Please remind there are over 40.000 packages in the release which need
time to test all such side effects.
Of course not all other packages within Debian depending on squid but
there are enough. Try out yourself 'apt-cache rdepends squid3'.

-- 
Regards
Carsten Schoenert

Re: Removing sysV init files

[Wookey]

+++ Russ Allbery [2016-01-15 10:04 -0800]:
> Alec Leamas  writes:
> 
> > Given all this: would it be OK to drop the sysV files in a stretch
> > update?

Please don't. Some people still use sysVinit and expect things to work
more-or-less as they did previously.
 
> I feel like removing the sysvinit scripts entirely would be "reverting
> existing support without a compelling reason."  But I also think that
> people who want to use sysvinit (or upstart, or any other init system)
> will have to contribute some support there in the form of bug reports and
> patches, just as with any other non-default configuration in Debian. 

Exactly. We'll submit bugs if we notice breakage. And fixes if they
are sufficiently obvious.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

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

[Jens Reyer]

On 01/15/2016 09:06 PM, Michael Biebl wrote:
> If your package ships both a systemd service unit and a sysv init
> script, you need to make sure that under systemd the native service file
> is used.
> The easiest way to achieve that is to use the same names for the unit
> file and the init script, i.e.
> /etc/init.d/foo should match /lib/systemd/system/foo.service
> 
> 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

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

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

[Anthony DeRobertis]

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 


No, it won't work automatically. Cron doesn't look at systemd units. 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

Bug#811150: ITP: python-reno -- RElease NOtes manager

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-reno
  Version : 1.3.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/reno
* License : Apache-2.0
  Programming Lang: Python
  Description : RElease NOtes manager

 Reno is a release notes manager for storing release notes in a git
 repository and then building documentation from them.

This is a new OpenStack dependency (currently needed by os-client-config).

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

[gaffa]

The firmware has a free license if you are to believe the WENCE file in the
kernel.

Bug#811154: ITP: poretools -- toolkit for nanopore nucleotide sequencing data

[Afif Elghraoui]

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 

* Package name: poretools
  Version : 0.5.1
  Upstream Author : Aaron Quinlan  & Nick Loman
* URL : http://poretools.readthedocs.org
* License : GPL
  Programming Lang: Python
  Description : toolkit for nanopore nucleotide sequencing data

poretools is a flexible toolkit for exploring datasets generated by
nanopore sequencing devices from MinION for the purposes of quality
control and downstream analysis. Poretools operates directly on the
native FAST5 (a variant of the HDF5 standard) file format produced by
ONT and provides a wealth of format conversion utilities and data
exploration and visualization tools.

This package will be maintained by the Debian Med team.
git://anonscm.debian.org/debian-med/poretools.git
http://anonscm.debian.org/cgit/debian-med/poretools.git