Re: Algorithm for selecting between packages providing the same phpapi-20100525, change between squeeze -> wheezy

[Ondřej Surý]

On Tue, Jul 9, 2013 at 5:36 PM, Julien Cristau  wrote:

> On Tue, Jul  9, 2013 at 14:25:59 +0200, Ondřej Surý wrote:
>
> > David,
> >
> > will this bug get fixed in wheezy?
> >
> > More people are starting to complain they get libapache2-mod-php5filter
> > installed: #709027
> >
> > I am still have no idea how to fix that in wheezy apart from fixing the
> > selection algorithm in apt.
> >
> I'm pretty sure what needs to happen here is to have exactly one package
> providing phpapi-20121212.
>

You are quite right. I have prepared an php5 upload where only php5-common
package provide phpapi-20121212 and the Provides: part have been dropped
from various SAPIs.

This will of course break all packages depending only on php5-
without declaring dependency on php5 (or specific php5 SAPI). After
cleaning the list (grep-dctrl generated) by removing php libraries and
various optional modules, where the php5 dependency is provided by main
package (like fusionforge, mediawiki, nordugrid, horde), I have been left
with this list:

> Package: bandwidthd-pgsql
> Depends: dbconfig-common, php5-gd, postgresql-client, ucf, debconf (>=
0.5) | debconf-2.0, libc6 (>= 2.14), libgd3 (>= 2.1.0~alpha~), libpcap0.8
(>= 0.9.8), libpng12-0 (>= 1.2.13-4), libpq5

> Package: davical
> Depends: debconf (>= 1.0.32), php5-pgsql, postgresql-client (>= 8.1),
libawl-php (>= 0.53-1~), libawl-php (<< 0.54), libdbd-pg-perl, libyaml-perl

On the other hand it will fix all packages declaring "Depends:
php5-, php5" since the php5 SAPI dependency will be correctly
resolved by dependency order in php5.

We might be able to do the same for wheezy if we can push the fix for
bandwidth-pgsql and davical to wheezy in the same run. That's probably up
to release team to say if they would ack such action.

O.
-- 
Ondřej Surý 

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Gergely Nagy]

Thomas Goirand  writes:

> If OpenRC goes up to the shape I expect, it will have a huge advantage
> over systemd and Upstart: it will not be controversial,

If it would not be controversial, we wouldn't have this conversation
about whether it is worth it at all. Just saying.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwpmq53a.fsf@algernon.balabit

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/16/2013 04:30 PM, Gergely Nagy wrote:
> Thomas Goirand  writes:
> 
>> If OpenRC goes up to the shape I expect, it will have a huge advantage
>> over systemd and Upstart: it will not be controversial,
> 
> If it would not be controversial, we wouldn't have this conversation
> about whether it is worth it at all. Just saying.

What I was saying was that the upgrade to sysv-rc to OpenRC should be an
improvement, and that's it. Nothing should break in the process, and
nothing else than the init process will be affected. While with systemd
lots of components are affected, and with both Upstart and Systemd,
non-Linux wont be supported. That's why I was saying it would be a less
controversial choice.

However, I denied that there's a big controversy going on on this list! :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e51435.10...@debian.org

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Mathias Behrle]

* Geoffrey Thomas: " Re: Survey answers part 3: systemd is not portable and
  what this means for our ports" (Mon, 15 Jul 2013 19:57:52 -0700 (PDT)):

> There are ways to express this without calling anyone idiots.

+2


signature.asc
Description: PGP signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Marco d'Itri]

On Jul 16, Geoffrey Thomas  wrote:

> There are ways to express this without calling anyone "idiots". Or
> do you believe that Debian is incapable of making solid technical
> decisions without namecalling?
We may consider it as character evidence.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Thomas Goirand]

On 07/16/2013 05:36 PM, Thomas Goirand wrote:
> However, I denied that there's a big controversy going on on this list! :)

Everybody understood: of course, there's a heated debate.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e53011.7030...@debian.org

Bug#717065: ITP: python-netlib -- collection of network utility classes

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: python-netlib
  Version : 0.9.1
  Upstream Author : Aldo Cortesi 
* URL : http://github.com/cortesi/netlib
* License : MIT
  Programming Lang: Python
  Description : collection of network utility classes

Netlib is a collection of network utility classes, used by the pathod
and mitmproxy projects. It differs from other projects in some
fundamental respects, because both pathod and mitmproxy often need to
violate standards.  This means that protocols are implemented as
small, well-contained and flexible functions, and are designed to
allow misbehaviour when needed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130716125537.13847.43068.report...@centurion.befour.org

Re: Systemd support in Debian packages: how to help

[Lucas Nussbaum]

Hi,

On 15/07/13 at 21:39 +0200, Michael Stapelberg wrote:
> Hi,
> 
> I am sorry for starting yet another thread on systemd, but we feel this
> particular post is important and should spread as widely as possible
> (i.e. beyond just readers of planet debian):
> 
> http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html
> 
> tl;dr: whatever you end up doing, please coordinate with us first!

I decided to give it a try, and to create a service file for a small
package I maintain (marionnet). Here is some feedback:

1) booting with systemd.
It failed at first, because I was mounting the cgroup virtual fs under
/cgroup for some reason. The error message was not so obvious. I'm not
sure if it's a common problem. If it is, it might be worth checking for
that before it's too late.

2) creating a service file. 
http://wiki.debian.org/Systemd/Packaging points to
http://www.freedesktop.org/software/systemd/man/systemd.service.html,
but that manpage does not include any example. It would be nice to
provide a couple of very basic service files. Or a skeleton one, with
comments.

All in all, it was easier than I expected.

Is there a way to list services installed on my system that are managed
via service files, vs those that are managed using legacy init scripts?
I'm thinking of something like rc-alert or wnpp-alert.

Thanks

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716125020.ga23...@xanadu.blop.info

Re: Systemd support in Debian packages: how to help

[Michael Biebl]

Hi Lucas,

thanks for your input!

Am 16.07.2013 14:50, schrieb Lucas Nussbaum:
> Hi,
> 
> On 15/07/13 at 21:39 +0200, Michael Stapelberg wrote:
>> Hi,
>>
>> I am sorry for starting yet another thread on systemd, but we feel this
>> particular post is important and should spread as widely as possible
>> (i.e. beyond just readers of planet debian):
>>
>> http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html
>>
>> tl;dr: whatever you end up doing, please coordinate with us first!
> 
> I decided to give it a try, and to create a service file for a small
> package I maintain (marionnet). Here is some feedback:
> 
> 1) booting with systemd.
> It failed at first, because I was mounting the cgroup virtual fs under
> /cgroup for some reason. The error message was not so obvious. I'm not
> sure if it's a common problem. If it is, it might be worth checking for
> that before it's too late.

Did you have that mount point in /etc/fstab or was it another package
which setup the cgroupfs mount point at /cgroup?
That directory is long deprecated and shouldn't be used anymore.
If there is still software using that, it would be good to file bugs.

> 2) creating a service file. 
> http://wiki.debian.org/Systemd/Packaging points to
> http://www.freedesktop.org/software/systemd/man/systemd.service.html,
> but that manpage does not include any example. It would be nice to
> provide a couple of very basic service files. Or a skeleton one, with
> comments.

Good idea. We'll try to add a couple of simple examples to the wiki for
typical use cases.
If you have further ideas, how we can improve the documentation, please
let us [2] know.

> All in all, it was easier than I expected.

> Is there a way to list services installed on my system that are managed
> via service files, vs those that are managed using legacy init scripts?
> I'm thinking of something like rc-alert or wnpp-alert.

There isn't atm. We do have a dashboard [1] which we use to coordinate
our work and monitor progress.
Such an *-alert tool should be rather simple though. Do you have any
suggestion for the name and which package it should be added to?
We could even make it check the bts, to see if a package is being worked
on already. We try to properly user tag [3] every bug, so that shouldn't
be too hard.


Michael


[1] http://people.debian.org/~stapelberg/dashboard/
[2] mailto:pkg-systemd-maintain...@lists.alioth.debian.org
[3]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=systemd-units

-- 
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: Systemd support in Debian packages: how to help

[Simon McVittie]

On 16/07/13 13:50, Lucas Nussbaum wrote:
> Is there a way to list services installed on my system that are managed
> via service files, vs those that are managed using legacy init scripts?

If your pid 1 is systemd, "systemctl list-units | grep LSB:" should be
either the correct list or pretty close.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e54c0e.4020...@debian.org

Bug#717075: ITP: pagemap -- analyze and print the physical memory layout of a Linux process

[Vincent Danjean]

Package: wnpp
Severity: wishlist
Owner: Vincent Danjean 

* Package name: pagemap
  Version : 1.1
  Upstream Author : Brice Videau 
Vincent Danjean 
* URL : http://forge.imag.fr/projects/pagemap
* License : BSD
  Programming Lang: ruby
  Description : analyze and print the physical memory layout of a Linux 
process

 pagemap is a simple command line tool to analyze and print the physical memory
 layout of a Linux process. It is used to debug and interpret performances of
 standard or HPC applications.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130716140049.31746.58070.report...@eyak.inrialpes.fr

Re: jpeg8 vs jpeg-turbo

[Ondřej Surý]

On Thu, May 2, 2013 at 2:58 PM, Andrey Rahmatullin  wrote:

> On Wed, May 01, 2013 at 07:18:31PM -0400, Paul Tagliamonte wrote:
> > Why has this taken so long?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034#62
> And no one raised this to tech-ctte.


 And this has been done now: #717076

Ondrej
-- 
Ondřej Surý 

Bug#717077: ITP: eureka -- map editor for the classic DOOM games

[Fabian Greffrath]

Package: wnpp
Severity: wishlist
Owner: Fabian Greffrath 

* Package name: eureka
  Version : 0.95
  Upstream Author : Andrew Apted 
* URL : http://eureka-editor.sourceforge.net/
* License : GPL-2+
  Programming Lang: C++, FLTK
  Description : map editor for the classic DOOM games
 Eureka is a cross-platform map editor for the classic DOOM games.
 It started as a fork of the Yadex editor attempting to make it use the
 FLTK GUI toolkit and implement multiple Undo / Redo.
 .
 Supported games are DOOM, DOOM 2, Final Doom, FreeDoom, HacX and Heretic.
 Supported source ports are Boom, EDGE, Doom Legacy and Odamex.

I am going to package this under the umbrella of the Debian Games Team.

The following people are in CC: Darren Salt, because I have been told he has
once packaged Yadex, Eureka's predecessor, outside of Debian; Jon Dowland,
because he was the one who told me that and might want to sponsor this package
and Andrew Apted, because he is upstream and provides a Debian package on the
project's homepage.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130716143606.3604.41384.report...@kff50.ghi.rwth-aachen.de

Bug#717083: ITP: pychef -- Python library to interact with the Chef server API

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: pychef
  Version : 0.2.2
  Upstream Author : Noah Kantrowitz 
* URL : https://github.com/coderanger/pychef
* License : BSD
  Programming Lang: Python
  Description : Python library to interact with the Chef server API

(Include the long description here.)

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: Systemd support in Debian packages: how to help

[Lucas Nussbaum]

On 16/07/13 at 15:33 +0200, Michael Biebl wrote:
> Hi Lucas,
> 
> thanks for your input!
> 
> Am 16.07.2013 14:50, schrieb Lucas Nussbaum:
> > Hi,
> > 
> > On 15/07/13 at 21:39 +0200, Michael Stapelberg wrote:
> >> Hi,
> >>
> >> I am sorry for starting yet another thread on systemd, but we feel this
> >> particular post is important and should spread as widely as possible
> >> (i.e. beyond just readers of planet debian):
> >>
> >> http://people.debian.org/~stapelberg/2013/07/14/systemd-how-to-help.html
> >>
> >> tl;dr: whatever you end up doing, please coordinate with us first!
> > 
> > I decided to give it a try, and to create a service file for a small
> > package I maintain (marionnet). Here is some feedback:
> > 
> > 1) booting with systemd.
> > It failed at first, because I was mounting the cgroup virtual fs under
> > /cgroup for some reason. The error message was not so obvious. I'm not
> > sure if it's a common problem. If it is, it might be worth checking for
> > that before it's too late.
> 
> Did you have that mount point in /etc/fstab or was it another package
> which setup the cgroupfs mount point at /cgroup?
> That directory is long deprecated and shouldn't be used anymore.
> If there is still software using that, it would be good to file bugs.

I had it in /etc/fstab.

> > Is there a way to list services installed on my system that are managed
> > via service files, vs those that are managed using legacy init scripts?
> > I'm thinking of something like rc-alert or wnpp-alert.
> 
> There isn't atm. We do have a dashboard [1] which we use to coordinate
> our work and monitor progress.
> Such an *-alert tool should be rather simple though. Do you have any
> suggestion for the name and which package it should be added to?

I don't have any brilliant idea here. Maybe a standalone package,
such as systemd-migration-checker, would be better?

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716152121.ga1...@xanadu.blop.info

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Paul Wise]

On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote:

> I don't think that we agreed on merging /usr at all.  I have written
> some patches for initramfs-tools to permit fsck and mount of /usr
> in the initramfs in addition to the rootfs, but that's as far as this
> has gone.  There's no merging here, just changing where /usr is
> mounted in the boot process.

Is this implemented by just mounting /usr, by discovering which
partitions need mounting for each binary that is to be run from the
initramfs or by copying stuff from /usr into the initramfs too?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6FQ4_AW4+vCEoowZntFo6DGxTM1aVuqbro+h=ayt4m...@mail.gmail.com

Bug#717085: ITP: seahorse-adventures -- help Barbie the seahorse float on bubbles to the moon

[Markus Koschany]

Package: wnpp
Severity: wishlist
Owner: Markus Koschany 

* Package name: seahorse-adventures
  Version : 1.1
  Upstream Author : philhassey, trick, pekuja, tim, DrPetter
* URL : http://www.imitationpickles.org/barbie/
* License : GPL-2, LGPL-2.1
  Programming Lang: Python
  Description : help Barbie the seahorse float on bubbles to the moon

Barbie Seahorse Adventures is a retro style platform arcade game in
the spirit of Mario 3. You are Barbie the seahorse who travels
through the jungle, up to the volcano until you float on bubbles to
the moon. On the way to your final destination you will encounter
various enemies, servants of the evil overlord who has stolen the
galaxy crystal. Avoid getting hit and defeat them with your bubbles!


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

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Roger Leigh]

On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote:
> On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote:
> 
> > I don't think that we agreed on merging /usr at all.  I have written
> > some patches for initramfs-tools to permit fsck and mount of /usr
> > in the initramfs in addition to the rootfs, but that's as far as this
> > has gone.  There's no merging here, just changing where /usr is
> > mounted in the boot process.
> 
> Is this implemented by just mounting /usr, by discovering which
> partitions need mounting for each binary that is to be run from the
> initramfs or by copying stuff from /usr into the initramfs too?

Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
using that information.  When init starts, /usr is therefore
available from the beginning.  Note that the objective here isn't
to allow the initramfs to run binaries from /usr, but to ensure
that /usr is available at all times when the system is running--
this means that all programs, libraries, modules, datafiles etc.
are available before init starts.

There are some complicating details:
- we need to ensure that the modules needed to mount /usr are
  available in the initramfs (copy the needed modules and
  mount helpers into the initramfs)
- we can't fsck /usr when mounted, so this needs doing in the
  initramfs (/ and /usr are fscked, with the appropriate
  helpers copied into the initramfs)
- fsck's -R option updated to skip /usr as well as root.
- /etc/init.d/checkroot.sh updated to handle /usr as well
  as root (e.g. remounting r/w).

- using the same infrastructure, it's also possible to
  mount /etc in the initramfs so that you can have e.g. a
  separately encrypted /etc filesystem.  This is a separate
  feature though and can be split out.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716160739.gd4...@codelibre.net

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Dmitrijs Ledkovs]

On 16 July 2013 17:07, Roger Leigh  wrote:
> On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote:
>> On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote:
>>
>> > I don't think that we agreed on merging /usr at all.  I have written
>> > some patches for initramfs-tools to permit fsck and mount of /usr
>> > in the initramfs in addition to the rootfs, but that's as far as this
>> > has gone.  There's no merging here, just changing where /usr is
>> > mounted in the boot process.
>>
>> Is this implemented by just mounting /usr, by discovering which
>> partitions need mounting for each binary that is to be run from the
>> initramfs or by copying stuff from /usr into the initramfs too?
>
> Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
> using that information.  When init starts, /usr is therefore
> available from the beginning.  Note that the objective here isn't
> to allow the initramfs to run binaries from /usr, but to ensure
> that /usr is available at all times when the system is running--
> this means that all programs, libraries, modules, datafiles etc.
> are available before init starts.
>
> There are some complicating details:
> - we need to ensure that the modules needed to mount /usr are
>   available in the initramfs (copy the needed modules and
>   mount helpers into the initramfs)
> - we can't fsck /usr when mounted, so this needs doing in the
>   initramfs (/ and /usr are fscked, with the appropriate
>   helpers copied into the initramfs)
> - fsck's -R option updated to skip /usr as well as root.
> - /etc/init.d/checkroot.sh updated to handle /usr as well
>   as root (e.g. remounting r/w).
>

Up to here, all sounds good.

Making the $mountpoints which above are treated / mounted in
initramfs, makes sense.
To be able to default to "/" only and change to "/ and /usr" if one desires.
And even plugin in the feature below.

> - using the same infrastructure, it's also possible to
>   mount /etc in the initramfs so that you can have e.g. a
>   separately encrypted /etc filesystem.  This is a separate
>   feature though and can be split out.
>

Imho the overhead between having just "/etc" vs "/" encrypted is
small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
Thus to me, treating "/etc" separately is a misfeature, considering a
mounted "/" assumes /etc must be present.
At least, it would go against my expectation.

I haven't yet reviewed the 17 patches log patch series on [1]. But is
"/etc" handling clearly separated in it already, or some
rebasing/reshuffling needed?

Regards,

Dmitrijs.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459


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

Re: Systemd support in Debian packages: how to help

[Shawn]

On Tue, Jul 16, 2013 at 5:50 AM, Lucas Nussbaum  wrote:

>
> On 15/07/13 at 21:39 +0200, Michael Stapelberg wrote:
> Is there a way to list services installed on my system that are managed
> via service files, vs those that are managed using legacy init scripts?
> I'm thinking of something like rc-alert or wnpp-alert.

systemctl

without arguments. Those services whose descriptions start with "LSB:" are
sysvinit scripts

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Steve Langasek]

On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote:
> - using the same infrastructure, it's also possible to
>   mount /etc in the initramfs so that you can have e.g. a
>   separately encrypted /etc filesystem.  This is a separate
>   feature though and can be split out.

This reflects poorly on the infrastructure in question.  Handling /etc as a
separate filesystem from /, aside from not being a feature anyone else
has asked for and not being a requirement for reducing deltas with upstreams
/ other distros, implies that the initramfs has to have a copy of the
information from /etc/fstab.  This is *not* how this should be handled.  The
initramfs should take the information about the root filesystem from the
kernel commandline, and its information about /usr from /etc/fstab *on the
root filesystem once it has been mounted*.

Anything else is a wrong design.

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


signature.asc
Description: Digital signature

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Steve Langasek]

On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote:
> On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote:
> > On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote:

> > > I don't think that we agreed on merging /usr at all.  I have written
> > > some patches for initramfs-tools to permit fsck and mount of /usr
> > > in the initramfs in addition to the rootfs, but that's as far as this
> > > has gone.  There's no merging here, just changing where /usr is
> > > mounted in the boot process.

> > Is this implemented by just mounting /usr, by discovering which
> > partitions need mounting for each binary that is to be run from the
> > initramfs or by copying stuff from /usr into the initramfs too?

> Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
> using that information.  When init starts, /usr is therefore
> available from the beginning.  Note that the objective here isn't
> to allow the initramfs to run binaries from /usr, but to ensure
> that /usr is available at all times when the system is running--
> this means that all programs, libraries, modules, datafiles etc.
> are available before init starts.

> There are some complicating details:
> - we need to ensure that the modules needed to mount /usr are
>   available in the initramfs (copy the needed modules and
>   mount helpers into the initramfs)

Yes.

> - we can't fsck /usr when mounted, so this needs doing in the
>   initramfs (/ and /usr are fscked, with the appropriate
>   helpers copied into the initramfs)

I think this is a bug in e2fsprogs for treating / specially wrt fsck after
mount.  We should fix this in e2fsprogs, not work around it by changing the
semantics of fsck-at-boot.

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


signature.asc
Description: Digital signature

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Roger Leigh]

On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
> On 16 July 2013 17:07, Roger Leigh  wrote:
> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
> > using that information.  When init starts, /usr is therefore
> > available from the beginning.  Note that the objective here isn't
> > to allow the initramfs to run binaries from /usr, but to ensure
> > that /usr is available at all times when the system is running--
> > this means that all programs, libraries, modules, datafiles etc.
> > are available before init starts.
> >
> > There are some complicating details:
> > - we need to ensure that the modules needed to mount /usr are
> >   available in the initramfs (copy the needed modules and
> >   mount helpers into the initramfs)
> > - we can't fsck /usr when mounted, so this needs doing in the
> >   initramfs (/ and /usr are fscked, with the appropriate
> >   helpers copied into the initramfs)
> > - fsck's -R option updated to skip /usr as well as root.
> > - /etc/init.d/checkroot.sh updated to handle /usr as well
> >   as root (e.g. remounting r/w).
> 
> Up to here, all sounds good.
> 
> Making the $mountpoints which above are treated / mounted in
> initramfs, makes sense.
> To be able to default to "/" only and change to "/ and /usr" if one desires.
> And even plugin in the feature below.
> 
> > - using the same infrastructure, it's also possible to
> >   mount /etc in the initramfs so that you can have e.g. a
> >   separately encrypted /etc filesystem.  This is a separate
> >   feature though and can be split out.
> >
> 
> Imho the overhead between having just "/etc" vs "/" encrypted is
> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
> Thus to me, treating "/etc" separately is a misfeature, considering a
> mounted "/" assumes /etc must be present.
> At least, it would go against my expectation.

This is certainly the case at present.  The rationale for doing this
is that if you have / and /usr on a single filesystem, but you want
to encrypt the content of /etc, you can now encrypt just /etc.  It
also means you can have the rootfs read-only with a writable /etc,
have /etc as a writable overlay or separate fs on a common image for
cluster environments, etc.  For encrypting stuff, it's moving the
boundary from one of simple convienience (/usr) to where it's actually
needed.  But I can accept that this won't have universal appeal.

> I haven't yet reviewed the 17 patches log patch series on [1]. But is
> "/etc" handling clearly separated in it already, or some
> rebasing/reshuffling needed?

It's just patch number 11/17 with some minor documentation comments in
patch 12/17, so it can be easily dropped without problems (intentionally).
However, even if applied, it's a strictly optional feature that won't be
used by default unless you provide etc= options to match the root=
options on the kernel command-line.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716183945.ge4...@codelibre.net

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Roger Leigh]

On Tue, Jul 16, 2013 at 11:25:42AM -0700, Steve Langasek wrote:
> On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote:
> > - using the same infrastructure, it's also possible to
> >   mount /etc in the initramfs so that you can have e.g. a
> >   separately encrypted /etc filesystem.  This is a separate
> >   feature though and can be split out.
> 
> This reflects poorly on the infrastructure in question.

I'm merely referring to the generalisation of the local/nfs
scripts to allow mounting of arbitrary filesystems.  There's
nothing wrong with this this support code.

> Handling /etc as a
> separate filesystem from /, aside from not being a feature anyone else
> has asked for and not being a requirement for reducing deltas with upstreams
> / other distros, implies that the initramfs has to have a copy of the
> information from /etc/fstab.  This is *not* how this should be handled.

I certainly didn't mean to imply this, because this is not what
is being done here.  Nothing is stored in the initramfs.

> The
> initramfs should take the information about the root filesystem from the
> kernel commandline, and its information about /usr from /etc/fstab *on the
> root filesystem once it has been mounted*.
> 
> Anything else is a wrong design.

We certainly do this for / and /usr.

The information for mounting /etc is passed on the kernel command-line
exactly as for the rootfs; while I've so far only tested it by hand,
tools such as update-grub could potentially add it in the same way
they handle the rootfs, if such a feature was in use.

Note that this part was merely added as a proposal only as a
demonstration of what could be done /if this was desirable to have/.
If not, then it can be dropped.  It was included solely that it could
be reviewed.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716190627.gf4...@codelibre.net

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Roger Leigh]

On Tue, Jul 16, 2013 at 11:28:28AM -0700, Steve Langasek wrote:
> On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote:
> > - we can't fsck /usr when mounted, so this needs doing in the
> >   initramfs (/ and /usr are fscked, with the appropriate
> >   helpers copied into the initramfs)
> 
> I think this is a bug in e2fsprogs for treating / specially wrt fsck after
> mount.  We should fix this in e2fsprogs, not work around it by changing the
> semantics of fsck-at-boot.

I certainly support this point of view.  However, the scope of the
required changes isn't immediately clear to me.  We might potentially
need to patch every single fsck program; e2fsck is sort-of patchable
but Ted wasn't happy with the idea.  And worse, we have to deal with
btrfs, which currently isn't fsckable if mounted *at all*, let alone
read-only /.  While I live in the hope that one day btrfs will be
sane, I won't be holding my breath.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716191053.gg4...@codelibre.net

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Helmut Grohne]

On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
> Imho the overhead between having just "/etc" vs "/" encrypted is
> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
> Thus to me, treating "/etc" separately is a misfeature, considering a
> mounted "/" assumes /etc must be present.
> At least, it would go against my expectation.

Having /etc on a separate filesystem can have a different advantage. If
just /var and /home are on separate filesystems and RAMTMP is set to
yes, then / can possibly be mounted read-only. Having a read-only /etc
is still a difficult thing to do, because a number of packages assume it
to be writeable. Examples include cups, denyhosts, fake-hwclock, lvm2,
openvpn, passwd, samba, and util-linux. This list is not exhaustive.

I think that read-only / is an interesting feature to investigate.
Fixing all the packages above has been proven to be a hard thing to do.
Having a writeable /etc is different way to achieve the same thing, so I
think investigating that option should not be prematurely dismissed.

It is not like that the availability of this feature will suddenly make
everyone use it. Chances are you wouldn't notice when it is introduced.
So why complain?

Helmut


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130716191538.ga14...@alf.mars

Re: Survey answers part 3: systemd is not portable and what this means for our ports

[Florian Weimer]

* Thomas Goirand:

> On 07/15/2013 04:32 PM, Josselin Mouette wrote:
>> And now people who want to stick with buggy shell scripts instead of
>> migrating to a much simpler, declarative mechanism.
>
> Please point at a single person on any threads about init systems over
> the last year who wishes that. I haven't see any. Did I miss it?

Actually, this is a fairly common sentiment.  Here's an example I
could locate quickly:



(And yes, I believe there are more recent examples.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874nbui9wb@mid.deneb.enyo.de

Bug#717104: ITP: kio-mtp -- access to MTP devices for applications using the KDE Platform

[Felix Geyer]

Package: wnpp
Severity: wishlist
Owner: Debian KDE Extras Team 

* Package name: kio-mtp
  Version : 0.75
  Upstream Author : Philipp Schmidt 
* URL : https://projects.kde.org/kio-mtp
* License : GPL-2+
  Programming Lang: C++
  Description : access to MTP devices for applications using the KDE 
Platform

This package includes the MTP KIO plugin. It allows applications using
the KDE Platform to access files stored on devices that provide access to
them via the MTP protocol.

The Media Transfer Protocol (commonly referred to as MTP) is a devised set
of custom extensions to support the transfer of music files on USB digital
audio players and movie files on USB portable media players.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130716203902.28120.54189.reportbug@localhost6.localdomain6

Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports

[Dmitrijs Ledkovs]

On 16 July 2013 19:39, Roger Leigh  wrote:
> On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
>> On 16 July 2013 17:07, Roger Leigh  wrote:
>> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
>> > using that information.  When init starts, /usr is therefore
>> > available from the beginning.  Note that the objective here isn't
>> > to allow the initramfs to run binaries from /usr, but to ensure
>> > that /usr is available at all times when the system is running--
>> > this means that all programs, libraries, modules, datafiles etc.
>> > are available before init starts.
>> >
>> > There are some complicating details:
>> > - we need to ensure that the modules needed to mount /usr are
>> >   available in the initramfs (copy the needed modules and
>> >   mount helpers into the initramfs)
>> > - we can't fsck /usr when mounted, so this needs doing in the
>> >   initramfs (/ and /usr are fscked, with the appropriate
>> >   helpers copied into the initramfs)
>> > - fsck's -R option updated to skip /usr as well as root.
>> > - /etc/init.d/checkroot.sh updated to handle /usr as well
>> >   as root (e.g. remounting r/w).
>>
>> Up to here, all sounds good.
>>
>> Making the $mountpoints which above are treated / mounted in
>> initramfs, makes sense.
>> To be able to default to "/" only and change to "/ and /usr" if one desires.
>> And even plugin in the feature below.
>>
>> > - using the same infrastructure, it's also possible to
>> >   mount /etc in the initramfs so that you can have e.g. a
>> >   separately encrypted /etc filesystem.  This is a separate
>> >   feature though and can be split out.
>> >
>>
>> Imho the overhead between having just "/etc" vs "/" encrypted is
>> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
>> Thus to me, treating "/etc" separately is a misfeature, considering a
>> mounted "/" assumes /etc must be present.
>> At least, it would go against my expectation.
>
> This is certainly the case at present.  The rationale for doing this
> is that if you have / and /usr on a single filesystem, but you want
> to encrypt the content of /etc, you can now encrypt just /etc.  It
> also means you can have the rootfs read-only with a writable /etc,
> have /etc as a writable overlay or separate fs on a common image for
> cluster environments, etc.  For encrypting stuff, it's moving the
> boundary from one of simple convienience (/usr) to where it's actually
> needed.  But I can accept that this won't have universal appeal.
>

Thinking about it more, it's possibly not the encryption case which
might be most prominent here.
I have seen containers / images made readonly, with /etc mounted using
overlayfs to provide easily clonable machines (chroots,
lxc-containers, "cloud-images").
Not sure, but probably, capser was used to do the mounting there.


>> I haven't yet reviewed the 17 patches log patch series on [1]. But is
>> "/etc" handling clearly separated in it already, or some
>> rebasing/reshuffling needed?
>
> It's just patch number 11/17 with some minor documentation comments in
> patch 12/17, so it can be easily dropped without problems (intentionally).
> However, even if applied, it's a strictly optional feature that won't be
> used by default unless you provide etc= options to match the root=
> options on the kernel command-line.
>

Ok, thanks for the heads up.

Regards,

Dmitrijs.


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

Bug#717124: ITP: niceshaper -- Dynamic traffic shaper

[Mariusz Jedwabny]

Package: wnpp
Severity: wishlist
Owner: Mariusz Jedwabny 

* Package name: niceshaper
  Version : 1.0.0
  Upstream Author : Mariusz Jedwabny 
* URL : http://niceshaper.jedwabny.net/
* License : (GPL2)
  Programming Lang: (C++)
  Description : Dynamic traffic shaper

NiceShaper is a program working in a Linux router environment.
It uses a proven HTB QOS algorithm. Provides dynamic traffic shaping
which is more effective than traditional, static shaping.
By constantly monitoring packets flowing through the router in response to
changing load dynamically adjusts the bandwidth of acting classes to a level
enabling the fullest possible usage of a internet access.
At the same time does not allow for creation of congestion,
ensuring complete convenience of interactive services.

NiceShaper takes care of download when upload stops up.


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

Pulseaudio (was ... Re: Survey answers part 3: systemd is not portable and what this means for our ports)

[Chris Bannister]

On Mon, Jul 15, 2013 at 10:44:21AM -0400, The Wanderer wrote:
> My most recent experience with PulseAudio came when I noticed that WoW
> (run through Wine) was producing crackling, stuttering sound again; this
> was during the late months before the wheezy release.
> 
> I tried half-a-dozen things, without noticeable change (except for the
> things which led to no sound at all); eventually I noticed that some
> PulseAudio packages had been installed, apparently as recommendations or
> dependencies of other things. I tried a few things to disable use of
> PulseAudio without removing it, without affecting the problem; I then
> removed all *pulse* packages I could, and the problem was
> gone.

Me too, and I don't even use a DE! One day sound just stopped working.
Removing all of the *pulse* packages I could got sound working again.
I didn't mess with anything either.

If there _suddenly_ appears a bad smell in your house and you find the
cause, do you a) Remove the cause? b) Waste time by trying to find out why
it smells? 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130717042936.GC11770@tal