Re: MBF Announcement: Transition libpng12 -> libpng16

[Tobias Frost]

Dear Debian-devel,

The preparation for the transition are going pretty much good.
In the meantime the bugs have been filed and there are already many
fixes uploaded. MANY THANKS for all of you.

I'm also rebuilding newly uploaded packages to keep libpng.sviech.de
somehow up to date.  

Of course, I take any help in NMUing the remaining cases, especially
the FTBFS ones: The bugs Nobuhiro filed years ago usually have patches
in them, so it is normally quite straight-forward. 

One reminder, as I saw this at now already in a few packages:

For uploads to sid, DO NOT USE 

 libpng16-dev | libpng-dev

The buildds will *always* take the first alternative, libpng16-dev in
this case. So this will FTBFS on the buildds.
In the (unlikely) case you can only be compatible with libpng16, upload
to experimental for now.

Thanks!

-- 
tobi

Bug#810311: ITP: field3d -- a library for storing voxel data on disk and in memory.

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: field3d
  Version : 1.6.1
  Upstream Author : Sony Pictures Imageworks Inc
* URL : https://github.com/imageworks/Field3D
* License : BSD
  Programming Lang: C++
  Description : a library for storing voxel data on disk and in memory.

Field3D is an open source library for storing voxel data. It provides C++
classes that handle in-memory storage and a file format based on HDF5 that
allows the C++ objects to be written to and read from disk.

NOTE: This package is an optional build dependency for OpenImageIO.

Re: support for merged /usr in Debian

[Simon McVittie]

On 08/01/16 03:03, Marco d'Itri wrote:
> It has been said that some have[citation needed] crappy boot loaders 
> that do not support loading an initramfs, but you can still embed one in 
> the kernel binary if you are building your own kernel

... and you'd need to build your own kernel on these platforms in any
case, because Debian kernels (like those in most distributions) are
heavily modularized, and can't see a disk or mount the root filesystem
without help from user-space anyway (CONFIG_SATA_AHCI=m,
CONFIG_EXT4_FS=m and the equivalents for other drive interfaces and
filesystems).

tiny-initramfs, mentioned elsewhere in this thread, seems an excellent
candidate for embedding in a kernel that doesn't need a "full-fat"
initramfs: it's around 16K when statically linked to a small libc, and
is configured via the kernel command-line (to mount the root) and the
root's /etc/fstab (to mount /usr if necessary).

S

Re: support for merged /usr in Debian

[Marc Haber]

On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
wrote:
>On 2016-01-04 11:30, Marc Haber wrote:
>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
>> wrote:
>>> System admins do like using absolute path
>>> for security reasons...
>> Please also notice that this is the only option for ExecStart in
>> systemd units. Well played, Lennart.
>
>Similarly skeleton-based init scripts use the full path as well. It 
>helps if you can stat() it. Which, I guess, you could by extension by 
>using "which" and the like.

In init scripts, I can do that. In a systemd unit, I cannot. If I can,
this brings an ugliness to systemd units I would rather not have, as
this would mean losing one of the nicer systemd features. It just
saddens me that I have to introduce ugliness because my upstream
doesn't share my opinions of prettiness.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 09:41 AM, Marc Haber wrote:
> On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
> wrote:
>> On 2016-01-04 11:30, Marc Haber wrote:
>>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
>>> wrote:
 System admins do like using absolute path
 for security reasons...
>>> Please also notice that this is the only option for ExecStart in
>>> systemd units. Well played, Lennart.
>>
>> Similarly skeleton-based init scripts use the full path as well. It 
>> helps if you can stat() it. Which, I guess, you could by extension by 
>> using "which" and the like.
> 
> In init scripts, I can do that. In a systemd unit, I cannot.

ExecStart=/bin/sh -c "something"

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 13:51:48 +0100, Christian Seiler
 wrote:
>On 01/04/2016 12:15 PM, Marc Haber wrote:
>> On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt
>>> Remember that / and /usr don't have to reside on the same partition with
>>> the usrmerge proposal: they only have to be both available
>>> post-initramfs.  The initramfs already takes care to mount /usr (for the
>>> systemd case as initscripts needs updates for sysvinit as was said
>>> elsewhere).  So no repartitioning should be required on upgrades.
>> 
>> I'd like to have a positive confirmation that systemd upstream intends
>> to continue supporting this scheme and that Debian will also.
>
>Separate partitions mounted in the initramfs? The whole reason for the
>UsrMerge is to make a separate /usr filesystem more interesting - see
>the things in the proposal itself and what I've reiterated in [1].

Actually, having /usr mounted earlier increases the possibility of
something going wrong in early boot. This is good, since early boot is
the only part of Debian's boot process that still is reasonably
debuggable, but that will go away as well as soon as we have systemd
inside the initramfs as well, which will undoubtedly come sooner or
later. Debugging late system boot with the method one has been used to
for decades has already become considerably harder. Thankfully doing
so has not been necessary yet, which might be caused by the solid work
of the systemd people in Debian, who cannot be blamed for the
premature, Ubuntu-like freeze of jessie.

I am just afraid that initramfs' functionality will dramatically
change when systemd takes over initramfs as well, with a lot of
important functionality maked as "broken", "obsolete" and eventually
removed, just as the keyscript= feature of /etc/crypttab was lost a
year ago (noone cared).

The loss of keyscript just broke my clients. I am really afraid of the
first system update breaking my _servers_, causing a resinstall to be
necessary. I know of one customer who already said that if a reinstall
will become necessary, the reinstalled distribution will be called Red
Hat Enterprise Linux. I'd like to postpone this as long as possible.

>And
>the systemd developers are actively interested in things such as
>stateless systems or sharing /usr in containers etc.

Too bad that they have so little interest in the things that are
important to me. I still have to go through painful contortions to
have basic IPv6 functionality and configurability.

>Also, just from a technical perspective: systemd is also designed to
>work in containers, where filesystems are often already pre-mounted to
>their respective locations. So systemd must already cope with the fact
>that when it's started some mounts may already be present. If you
>couple that with the idea that the initrd mounts /usr, then it is
>trivially true that /usr can be separate, as long as it's already
>mounted before systemd is executed. That will hold true even IF systemd
>developers decide to drop support for mounting /usr from a running
>system. I'm not saying that somebody couldn't break that scenario if
>they tried really hard, but from a technical perspective.

What I am missing is a clearly worded commitment from upstream or
Debian not to break existing systems during upgrades.

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

Re: support for merged /usr in Debian

[Tollef Fog Heen]

]] Christian Seiler 

> On 01/08/2016 09:41 AM, Marc Haber wrote:
> > On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
> > wrote:
> >> On 2016-01-04 11:30, Marc Haber wrote:
> >>> On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
> >>> wrote:
>  System admins do like using absolute path
>  for security reasons...
> >>> Please also notice that this is the only option for ExecStart in
> >>> systemd units. Well played, Lennart.
> >>
> >> Similarly skeleton-based init scripts use the full path as well. It 
> >> helps if you can stat() it. Which, I guess, you could by extension by 
> >> using "which" and the like.
> > 
> > In init scripts, I can do that. In a systemd unit, I cannot.
> 
> ExecStart=/bin/sh -c "something"

This, or «ExecStart=/usr/bin/env food bar baz»

This is, as folks might have noticed, exactly the same limitation and
workaround as we have for #! lines in scripts.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
 wrote:
>On 01/04/2016 11:41 AM, Marc Haber wrote:
>> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery 
>> wrote:
>>> I do understand why people working in the embedded space care about some
>>> unusual mount orderings, file system separations, and very light cores,
>>> and I hope that we can accomodate and support all of their use cases
>>> inside Debian.  I think that's the most productive part of this thread.
>> 
>> We have already shown how "much" we care about the users of non-Linux
>> kernels in Debian ("not at all, they can happily go fishing").
>
>So why aren't you on the list of porters for either Hurd of kFreeBSD?

Since when does one have to actually work on something to be allowed
to find it important and interesting. You would have a point if you
told me to put better maintenance on the packages that I have taken
responsibility for instead of telling me to commit to do _more_ work
than I am already not properly doing.

>You could also say the same (not caring about them) of HA users: Jessie
>has no Pacemaker, because nobody cared about that during the Jessie
>release cycle. It was completely broken at that point and thus removed
>from the release.

Yes, that's really a pity.

>> And we're all doing this to keep our upstreams and Ubuntu happy.
>
>Have you read *any* of the technical arguments in this thread?
>
>(Btw. Ubuntu does NOT have UsrMerge. Ubuntu switched to systemd AFTER
>Debian decided to use systemd as default.)

My beef with Ubuntu is their release cycle and the fact that Debian is
being slowly modified to suit their cycle. Leaving behind Debian's
core values in the process.

>Btw. Is Debian there to mindlessly follow RedHat or Ubuntu?

In my opinion, no. Debian used to be there for technical leadership
and stability, living up to the name of the Universal Operating
System. Even if that meant not releasing once a year. Alas, times are
changing.

>> I, for example, am afraid of having to merge /usr in existing systems
>> during upgrades, causing repartitions to be necessary. I am afraid of
>> partition layout suddenly not fitting any more during an upgrade,
>> causing downtimes and customers considering to take the opportunity to
>> migrate to a really supported enterprise distribution.
>
>Sorry, but this is bogus, because this is a problem you have on every
>every upgrade. In the past I've already had to repartition systems
>because / had become too small, because the amount of software required
>to be there had grown (to support more storage solutions for mounting
>/usr) and also the kernel modules had grown.

If hundreds of megabytes of software would get moved from /usr to /,
this would certainly overflow my root file systems. In fact, as I have
understood things, software will move from / to /usr, making the
system completely unuseable if the multi-gigabytes /usr does not mount
for some reason.

The upside of this is that this will free up space in / which will be
needed for a dedicated recovery image. Too bad that we don't have such
a thing ourselves and have to recommend third-party products like grml
while at the same time making development of those third-party
products considerably harder by our release decisions.

>deboostrap of lenny (via archive.d.o) + kernel:
>313 MiB in total, 99 MiB on /usr  => 214 MiB on /
>debootstrap of jessie + kernel:
>618 MiB in total, 203 MiB on /usr => 415 MiB on /
>
>And that's just ONE kernel, if you upgrade you usually have additional
>kernels lying around. Plus I didn't install a lot of other utilities
>that are present on many systems, this is really minimal.

My standard Debian server image is about this size in total.

>So let's say you installed lenny and had 512 MiB for / (with separate
>/usr) because you thought back then that it was more than enough (more
>than double the installed size) - and upgrade to Jessie will either run
>out of disk space or come very close to it.

Yes, this happens. Do we really have to _force_ this? It is annoying
enough when it happens caused by the normal flow of things. Even if
this is the case, not all systems will explode during the same system
upgrades, allowing the local admin to spread those changes over two or
even three releases. If we would, in some future, ship an upgrade that
uncaringly would _require_ a repartitioning, this spread would not be
possible, and it would undoubtedly call up management attention, which
could in turn lead to management taking vendor decisions that we don't
want.

>If you also separate out
>/var the numbers game changes a bit, but the principle remains.

/var is of couse separated out on all but the smallest boxes.

>Also, the amount of space software requires on /usr is larger on
>Jessie - so even if your / partition is large enough, /usr might
>already be too small un upgrades.

_This_ will become more a problem when we force things onto /usr.

>I've also had the case multiple times where the space I alloca

Re: support for merged /usr in Debian

[Andrew Shadura]

On 8 January 2016 at 10:21, Marc Haber  wrote:
>>So let's say you installed lenny and had 512 MiB for / (with separate
>>/usr) because you thought back then that it was more than enough (more
>>than double the installed size) - and upgrade to Jessie will either run
>>out of disk space or come very close to it.
>
> Yes, this happens. Do we really have to _force_ this? It is annoying
> enough when it happens caused by the normal flow of things. Even if
> this is the case, not all systems will explode during the same system
> upgrades, allowing the local admin to spread those changes over two or
> even three releases. If we would, in some future, ship an upgrade that
> uncaringly would _require_ a repartitioning, this spread would not be
> possible, and it would undoubtedly call up management attention, which
> could in turn lead to management taking vendor decisions that we don't
> want.

Marc, please re-read the whole thread from the very beginning. Nobody
forces merged /usr on you.

-- 
Cheers,
  Andrew

Re: support for merged /usr in Debian

[Marc Haber]

On Mon, 4 Jan 2016 14:15:21 +0100, Christian Seiler
 wrote:
>On 01/04/2016 11:44 AM, Marc Haber wrote:
>> On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler
>>  wrote:
>>> So that was the state in February of 2011, when the warning was added
>>> to systemd and the systemd developers recommended the use of the
>>> initrd: mounting /usr from a running system is broken. Either it is
>>> already completely broken in some cases - and for all other cases where
>>> it currently works it is broken maintenance-wise.
>> 
>> Declaring something that was the normal use case five years ago as
>> broken is a blatant sign of disrespect for users.
>
>Ok, so when Wheezy came around, 5 years before that a normal use case
>for init scripts was to have a fixed start/stop priority that was used
>when calling update-rc.d - and in Wheezy (this was pre-systemd!) the
>update-rc.d implementation completely ignores the start/stop priorities
>and says it only does dependency-based boot now (it shows a warning if
>priorities are still specified). Is that also a blatant sign of
>disrespect for users?

No, this change was largely painless. I had only systems with badly
maintained third-party packages break.

>With your argumentation you could argue that ANY
>change is a blatant disrespect for users.

No, this is only the case for really intrusive changes that noone had
asked for.

>I'm really curious: what's your solution?

Keep support for things that used to work for, say, at least three or
four stable releases, document that and commit to it. And, of course,
stick to it.

That way, a local admin can change installation to adapt to new ways
and to necessary migrations of existing systems on _her_ schedule.
Forcing intrusive and time-consuming changes with a single stable
release is bad bad bad.

>Diagnosis: mounting /usr from / doesn't work properly

It works fine for the vast majority of setups, including LVM and
crypted file systems. It breaks for important corner cases such as
having /usr on storage media that needs exotic drivers or the network.
I'd hardly call that "broken".

>Now what do do about it? You seem to be suggesting that people should
>try to maintain the current state of affairs regardless. There's ample
>evidence that that simply won't work.

I don't see this evidence as compelling as you do.

>Suggestion by other people: ok, so we still want to support a separate
>/usr partition, so what do we do now? Oh yes, we just mount it already
>in the initrd, because that already has support for mounting
>filesystems (such as the root filesystem). Now people can still have
>their separate partitions but we don't have to support the use case of
>mounting /usr from / anymore.

That's not nice, but fine and acceptable _IF_ there is commitment to
keep things this way. There are significant changes to the initrd on
the horizon, and those changes involve switching to a software with an
upstream that has a reputation about not giving a damn about existing
systems because they have been broken and maintained the wrong way all
time before and declaring having no hooks as design feature.

>Plus: if we do that, we get a exciting possibilities, because we can
>just put everything in /usr, which is what the UsrMerge is all about,
>so we can actually make lemonade from those lemons.

What about if I prefer something that tastes like oranges? Do I have
to change to lemonade when the release team pushes the button? An
Universal Operating System should not declare oranges as "obsolete"
just because lemons do have more vitamin C.

>Response: well, in some cases a full-blown initrd is not an option. I
>respond in this thread with providing a 300 LoC PoC for a minimalistic
>initrd that's *reall* small. I ask people who have been complaining
>here whether this would address their concerns. What do I get? Silence.

I appreciate that effort, but for me it misses the point. I have
always been using initramfs, initramfs-tools do a splendid job, and as
long as this functionality is preserved and Debian commits to this I
am just fine with a /usr merge stretched about a few releases. This is
nothing we have to force for stretch or buster.

>So really, what would you suggest? How would you solve this issue?

Documentation and commitment.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Tue, 5 Jan 2016 02:07:35 +0100, Christian Seiler
 wrote:
>On 01/05/2016 01:34 AM, Marc Haber wrote:
>> On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop 
>> wrote:
>>> On 2016-01-04 12:03:07, Marc Haber wrote:
 On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote:
> Anyway, if you think that the merged /usr scheme is about systemd then 
> you are automatically disqualified from taking part in this discussion 
> because you are not understanding the basic underlying issues.

 As friendly as always.
>>>
>>> Friendly? Maybe not. But correct? Yes.
>> 
>> Being right and unfriendly drives friends and users away. This
>> attitude is doing harm to Debian.
>
>Marco started this thread because he wanted to discuss a specific
>proposal - merging /bin, /lib and /sbin into /usr.

And people happen to disagree.

>But _after_ this thread, where lots of people have patiently tried to
>explain the issues again and again, and even tried to find ways of
>constructively coming to a compromise - don't you think that repeating
>the same talking points again in this very same thread instead of
>actually responding to the issues presented, don't you think that
>that is far more harmful to Debian than a single comment borne out
>of frustration?

The problem is not the single comment, which I meant with "as always".

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

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:
> The upside of this is that this will free up space in / which will be
> needed for a dedicated recovery image. Too bad that we don't have such
> a thing ourselves and have to recommend third-party products like grml

grml is packaged and is an apt-get away. It's third-party in just the
same way that the linux kernel, or exim are.

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 08:16:06AM +0100, Svante Signell wrote:
> The problem is that with Debian heading down this road, the Debian GNU/Linux
> distribution will not exist in 5 years from now. You will make yourselves
> extinct due to the competition from commercial alternatives.

You greatly overestimate Debian's capacity to do anything quickly, including
dying.

Re: support for merged /usr in Debian

[Stephan Seitz]

On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote:

grml is packaged and is an apt-get away. It's third-party in just the
same way that the linux kernel, or exim are.


Wrong. You have a wrapper package that adds grml iso from /boot/grml to 
the grub.cfg. You have to download the grml images yourself and you need 
the space to save the images in /boot/grml.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: support for merged /usr in Debian

[Brian May]

Marc Haber  writes:

> Keep support for things that used to work for, say, at least three or
> four stable releases, document that and commit to it. And, of course,
> stick to it.

So at approx 2 years per stable release, that would be around 6 to 8
years before we could get this optional change into Debian. Which in
turn mean we are 6 to 8 years behind the other major Linux
distributors. That would definitely put me off Debian.

Or maybe you can see into the future, and can see a time when the new
/usr will be mandatory for all users. Maybe this is your concern. You
want a commitment for it to remain optional for at least 6 to 8 years.

Do we want debian to be slow and conservative or fast and bleeding edge?

I would find 6 to 8 years far too long myself, by the time we get
changes in a stable release, it is likely they will already be obsolete
and replaced by something better. It would probably result in Debian
being forked by people who want to develop using the latest standards
but unable to do so in Debian.

Maybe what you are looking for is LTS support or extended LTS support on
our releases?
-- 
Brian May 

Re: support for merged /usr in Debian

[Michael Prokop]

* Stephan Seitz [Fri Jan 08, 2016 at 11:18:41AM +0100]:
> On Fri, Jan 08, 2016 at 10:11:07AM +, Jonathan Dowland wrote:
> >grml is packaged and is an apt-get away. It's third-party in just the
> >same way that the linux kernel, or exim are.

> Wrong. You have a wrapper package that adds grml iso from /boot/grml
> to the grub.cfg. You have to download the grml images yourself and
> you need the space to save the images in /boot/grml.

We've an open wishlist bug report for the "download the Grml ISO"
part (#754393) which we plan to resolve soonish, jfyi.

regards,
-mika-


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Ian Campbell]

On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote:
> On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:
> > The upside of this is that this will free up space in / which will be
> > needed for a dedicated recovery image. Too bad that we don't have such
> > a thing ourselves and have to recommend third-party products like grml
> 
> grml is packaged and is an apt-get away. It's third-party in just the
> same way that the linux kernel, or exim are.

What is the package called? By coincidence I was looking for it the other
day and all I found was:

$ apt-cache search grml
grml-debootstrap - wrapper around debootstrap for installing pure Debian
grml-rescueboot - Integrates Grml ISO booting into GRUB
grml2usb - install Grml system / ISO to usb device

The first and last are not relevant and AFAICT the middle one is support
for creating grub entries from files in /boot/grml which appear to get
there by some out of band means (i.e. by hand AFAICT). The
Depends/Recommends/Suggests of that package don't mention any other package
which might provide the actual download.

Ian.

Re: support for merged /usr in Debian

[Michael Prokop]

* Ian Campbell [Fri Jan 08, 2016 at 10:22:01AM +]:
> On Fri, 2016-01-08 at 10:11 +, Jonathan Dowland wrote:
> > On Fri, Jan 08, 2016 at 10:21:00AM +0100, Marc Haber wrote:

> > > The upside of this is that this will free up space in / which will be
> > > needed for a dedicated recovery image. Too bad that we don't have such
> > > a thing ourselves and have to recommend third-party products like grml

> > grml is packaged and is an apt-get away. It's third-party in just the
> > same way that the linux kernel, or exim are.

> What is the package called? By coincidence I was looking for it the other
> day and all I found was:

> $ apt-cache search grml
> grml-debootstrap - wrapper around debootstrap for installing pure Debian
> grml-rescueboot - Integrates Grml ISO booting into GRUB
> grml2usb - install Grml system / ISO to usb device

The grml-rescueboot package is the one which is meant here.

> The first and last are not relevant and AFAICT the middle one is support
> for creating grub entries from files in /boot/grml which appear to get
> there by some out of band means (i.e. by hand AFAICT). The
> Depends/Recommends/Suggests of that package don't mention any other package
> which might provide the actual download.

Exactly.

Once #754393 has been resolved the download of the ISO straight to
/boot/grml should be trivial. I'm even considering providing
packages named like grml-rescueboot-grml64-small which just execute
the said script with according parameters inside their postinst - so
once you install grml-rescueboot-grml64-small the ISO is put
automatically in place for you. (I highly appreciate any feedback,
further wishes, approaches + ideas regarding that.)

regards,
-mika-


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Marco d'Itri]

On Jan 08, Marc Haber  wrote:

> important functionality maked as "broken", "obsolete" and eventually
> removed, just as the keyscript= feature of /etc/crypttab was lost a
> year ago (noone cared).
Let's be clear here: nobody cared enough to implement it.
It was clearly explained by the upstream maintainers, multiple times, 
that they would have liked to have this feature.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Stephan Seitz]

On Fri, Jan 08, 2016 at 11:49:48AM +0100, Michael Prokop wrote:

We've an open wishlist bug report for the "download the Grml ISO"
part (#754393) which we plan to resolve soonish, jfyi.


Ah, thank you very much. That still leaves the space problem. Only my 
newer systems where I knew that I wanted to have grml in /boot are having 
enough space.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: PGP signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 09:44:17 +0100, Christian Seiler
 wrote:
>On 01/08/2016 09:41 AM, Marc Haber wrote:
>> On Wed, 06 Jan 2016 00:03:31 +0100, Philipp Kern 
>> wrote:
>>> On 2016-01-04 11:30, Marc Haber wrote:
 On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette 
 wrote:
> System admins do like using absolute path
> for security reasons...
 Please also notice that this is the only option for ExecStart in
 systemd units. Well played, Lennart.
>>>
>>> Similarly skeleton-based init scripts use the full path as well. It 
>>> helps if you can stat() it. Which, I guess, you could by extension by 
>>> using "which" and the like.
>> 
>> In init scripts, I can do that. In a systemd unit, I cannot.
>
>ExecStart=/bin/sh -c "something"

This brings an ugliness including quoting hell to systemd units that I
would rather not have. You missed to quote this.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 12:53:43 +0100, m...@linux.it (Marco d'Itri) wrote:
>On Jan 08, Marc Haber  wrote:
>> important functionality maked as "broken", "obsolete" and eventually
>> removed, just as the keyscript= feature of /etc/crypttab was lost a
>> year ago (noone cared).
>Let's be clear here: nobody cared enough to implement it.
>It was clearly explained by the upstream maintainers, multiple times, 
>that they would have liked to have this feature.

Citation please. I remembered getting something along the lines "this
is a Debianism, we don't care" as an answer. With a point, keyscript
_IS_ (resp was) a Debianism.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 10:32:03 +0100, Andrew Shadura 
wrote:
>Marc, please re-read the whole thread from the very beginning. Nobody
>forces merged /usr on you.

Enough trust has been lost in the past years that I'd like to have a
commitment for that. Write it down, and I'm fine.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 08 Jan 2016 21:20:21 +1100, Brian May  wrote:
>Marc Haber  writes:
>> Keep support for things that used to work for, say, at least three or
>> four stable releases, document that and commit to it. And, of course,
>> stick to it.
>
>So at approx 2 years per stable release, that would be around 6 to 8
>years before we could get this optional change into Debian.

No, you can opt to change right now. Just don't force others to do it.

>Or maybe you can see into the future, and can see a time when the new
>/usr will be mandatory for all users. Maybe this is your concern. You
>want a commitment for it to remain optional for at least 6 to 8 years.

yes.

>Do we want debian to be slow and conservative or fast and bleeding edge?

Conservative enough to stay useable for professional IT operations. At
last this is what I want Debian to be. We are already losing behind
the Enterprise Distributions because they look on paper as if one can
install and forget for ten years.

>I would find 6 to 8 years far too long myself, by the time we get
>changes in a stable release, it is likely they will already be obsolete
>and replaced by something better. It would probably result in Debian
>being forked by people who want to develop using the latest standards
>but unable to do so in Debian.

Debian has already been forked by people who found Debian's release
cycles too long. The result is called Ubuntu, and we lost many of the
users (and developers!) who want shorter release cycles to them.

Now, we aim for shorter release cycles ourselves, which won't bring
any of the users back we lost to Ubuntu. But it'll make us now lose
the users that think we release too often to the Enterprise Linuxes.

That's what happens when one blindly follows users' wishes while
neglecting old values.

>Maybe what you are looking for is LTS support or extended LTS support on
>our releases?

Maybe. Having this is also blindly doing what others do while we did
so fine in the past.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 12:53 PM, Marco d'Itri wrote:
> On Jan 08, Marc Haber  wrote:
> 
>> important functionality maked as "broken", "obsolete" and eventually
>> removed, just as the keyscript= feature of /etc/crypttab was lost a
>> year ago (noone cared).
> Let's be clear here: nobody cared enough to implement it.
> It was clearly explained by the upstream maintainers, multiple times, 
> that they would have liked to have this feature.

That's not really accurate. To make a long story *really* short:

 - Synchronous calls to an arbitrary executable is not something the
   systemd developers want to have in their code (see the linked
   posting). See e.g. [1], [2]

 - Instead it was proposed to use password agents (see [1]) for this.

 - Problem with that is that the password agents don't support
   arbitrary binary data, which is needed for keys (they only support
   plain text).

 - A patch for augmenting the password agent protocol to support
   binary data was rejected [3], with the idea that it would probably
   be better to use the kernel keyring instead of userspace to
   transmit these types of keys. Also, there have been strong hints
   (see e.g. [3], but also others that I can't find) that changing
   this would also require some early-available dbus, in form of
   kdbus, once that was done.

 - kdbus is not going to be here anytime soon.

So people actually did implement this and when the implementation was
available, the goal posts were moved by upstream.

As far as I can tell, this is a case where upstream's goal of creating
the best technical solution for a problem gets in the way of having
something that works at all.

The main problem is that there isn't any good way of getting a binary
key into systemd's cryptsetup implementation at all - so that it's
currently not possible to use anything other than passwords or
key files if one wants to use systemd-cryptsetup. This breaks a lot of
other use cases, such as two-factor authentication, using the TPM,
using external key hardware, etc. - and the reason why this didn't
affect Jessie much worse is that initramfs-tools still support
keyscript=, so unlocking the rootfs still works via this mechanism.

And it'd be one thing if a proper solution had been around the corner
and this feature had been missing for a couple of months, but it has
been years, and there is no perspective on when a patch for this would
be accepted upstream, because (from what I read on the mailing list)
they appear to want to have early-boot IPC before touching the
password agent code again - which means it could take another 2 or 3
years.

And yes, I get why what has been proposed upstream is better in the
long term, and if I had such a use case I personally wouldn't care
about what technical solution is used in the background (whether
keyscript or something else), and I wouldn't complain if I had to
change things on upgrade because of some new solution, but if I look
at the time scales involved, it seems very unreasonable to me to say
"in a couple of years your use case will be supported again" - and I
think that breaking very legitimate use cases without a sensible
recourse would be reason enough to say "well, let's support it at
least until we have a better solution available".

Regards,
Christian

[1] http://lists.freedesktop.org/archives/systemd-devel/2012-July/005835.html
[2] http://lists.freedesktop.org/archives/systemd-devel/2015-April/031173.html
[3] http://lists.freedesktop.org/archives/systemd-devel/2014-July/020880.html



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Riku Voipio]

On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
> The loss of keyscript just broke my clients. I am really afraid of the
> first system update breaking my _servers_, causing a resinstall to be
> necessary. I know of one customer who already said that if a reinstall
> will become necessary, the reinstalled distribution will be called Red
> Hat Enterprise Linux. I'd like to postpone this as long as possible.

If bug-free upgrades are valueble for you and your clients, it doesn't
seem wise to bet on luck that nothing will break. Debian has had
quite good record on successful in-place upgrades, but it mostly depends
on volunteers doing manual dist-upgrade tests during freeze. Which is often
too late and too little.

Settings up automated upgrade tests at jenkins.debian.net for both generic
installs and installs similar your setup would let you identify and fix
issues before they become problems in your production. 

Riku

Re: support for merged /usr in Debian

[Niels Thykier]

Riku Voipio:
> On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
>> The loss of keyscript just broke my clients. I am really afraid of the
>> first system update breaking my _servers_, causing a resinstall to be
>> necessary. I know of one customer who already said that if a reinstall
>> will become necessary, the reinstalled distribution will be called Red
>> Hat Enterprise Linux. I'd like to postpone this as long as possible.
> 
> If bug-free upgrades are valueble for you and your clients, it doesn't
> seem wise to bet on luck that nothing will break. Debian has had
> quite good record on successful in-place upgrades, but it mostly depends
> on volunteers doing manual dist-upgrade tests during freeze. Which is often
> too late and too little.
> 
> Settings up automated upgrade tests at jenkins.debian.net for both generic
> installs and installs similar your setup would let you identify and fix
> issues before they become problems in your production. 
> 
> Riku
> 

Just adding a data point to the discussion:

 * Every single release breaks something[1][2][3][4].
 * Stretch is of course no exception[5].

Releases are not a question of "if" but rather "what" breaks (and "to
which extend"/"how many use-cases").

Note, if any one is concerned with Jessie's list of issues being longer
than Wheezy's list.  That is more likely to be a result from us putting
more effort into documenting issues for Jessie compared to Wheezy.
  Of course, I only have a "gut feeling" backing my claim.  Please do
not take it as a fact (nor as a disapproval of the efforts for Wheezy).

Thanks,
~Niels

[1]
https://www.debian.org/releases/etch/amd64/release-notes/ch-information.en.html

[2]
https://www.debian.org/releases/squeeze/amd64/release-notes/ch-information.en.html

[3]
https://www.debian.org/releases/wheezy/amd64/release-notes/ch-information.en.html

[4]
https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html

[5]
https://www.debian.org/releases/stretch/amd64/release-notes/ch-information.en.html





signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 14:24:52 +0100, Christian Seiler
 wrote:
> - Instead it was proposed to use password agents (see [1]) for this.
>
> - Problem with that is that the password agents don't support
>   arbitrary binary data, which is needed for keys (they only support
>   plain text).

And there is no example code for a password agent aside of some proof
of concept code in python (which is not recommended to use in
production) and the whole concept breaks if the unlocking scheme for
filesystem A involves unlocking filesystem B because it has part of
the key.

This is not a replacement for keyscripts, it is a triangle instead of
a wheel.

>As far as I can tell, this is a case where upstream's goal of creating
>the best technical solution for a problem gets in the way of having
>something that works at all.

Amen.

>and the reason why this didn't
>affect Jessie much worse is that initramfs-tools still support
>keyscript=, so unlocking the rootfs still works via this mechanism.

Which leaves the issue of unlocking the other filesystems that need
unlocking for the system to run. I have resorted to unlocking
everything I need in the initramfs, which had the result of making
initramfs more complex, not easier. Well done, systemd.

>And it'd be one thing if a proper solution had been around the corner
>and this feature had been missing for a couple of months, but it has
>been years, and there is no perspective on when a patch for this would
>be accepted upstream, because (from what I read on the mailing list)
>they appear to want to have early-boot IPC before touching the
>password agent code again - which means it could take another 2 or 3
>years.

*sigh*

>And yes, I get why what has been proposed upstream is better in the
>long term,

I don't. It introduces thousands of lines of code of complexity in
early boot which already is hard enough to debug.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 13:04:16 +, Riku Voipio 
wrote:
>On Fri, Jan 08, 2016 at 09:50:56AM +0100, Marc Haber wrote:
>> The loss of keyscript just broke my clients. I am really afraid of the
>> first system update breaking my _servers_, causing a resinstall to be
>> necessary. I know of one customer who already said that if a reinstall
>> will become necessary, the reinstalled distribution will be called Red
>> Hat Enterprise Linux. I'd like to postpone this as long as possible.
>
>If bug-free upgrades are valueble for you and your clients, it doesn't
>seem wise to bet on luck that nothing will break. Debian has had
>quite good record on successful in-place upgrades, but it mostly depends
>on volunteers doing manual dist-upgrade tests during freeze. Which is often
>too late and too little.

All _my_ clients run unstable anyway, and it only really broke the
test system. It just ate a few days of tinkering at an inconvenient
time to get the test system to boot again and to upgrade the other
machines in the process.

>Settings up automated upgrade tests at jenkins.debian.net for both generic
>installs and installs similar your setup would let you identify and fix
>issues before they become problems in your production. 

I am doing this. I still hate the idea that my test systems break as
this means work and danger in production.

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

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 03:13:12PM +0100, Marc Haber wrote:
> All _my_ clients run unstable anyway

I'll leave the obvious response here to others.

But, what I find odd about this is you've suggested that there should be a
*multi-release* transition for a change like this, more than once in the
thread. Asking volunteers to coordinate a change over an unknown and unknowable
period of time (but that could feasibly be a decade!) is unreasonable IMHO,
and since you are running sid anyway, it wouldn't even help you, so I'm puzzled
why you suggested it.

Re: support for merged /usr in Debian

[Jonathan Dowland]

On Fri, Jan 08, 2016 at 11:18:41AM +0100, Stephan Seitz wrote:
> Wrong. You have a wrapper package that adds grml iso from /boot/grml to the
> grub.cfg. You have to download the grml images yourself and you need the
> space to save the images in /boot/grml.

Thanks for explaining: I was under the mistaken impression that the ISO was
packaged too.

> Shade and sweet water!

This (still) should go *below* your sig separator.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

Fwd: git URL wrong on anonscm.debian.org

[Roger Shimizu]

I want to report a bug regarding to {anonscm,git}.debian.org, but I
don't find a pseudo package to file bugreport to, so I contacted
ad...@alioth.debian.org, but no reply yet for nearly 1 month.

I hope maybe someone here can help. Thank you!

Cheers,
Roger

-- Forwarded message --
From: Roger Shimizu 
Date: Sun, Dec 20, 2015 at 1:11 AM
Subject: git URL wrong on anonscm.debian.org
To: ad...@alioth.debian.org


Dear Alioth Admin,

Hope I send the issue report here right.

the git URL of each project on anonscm.debian.org is like:
- https://anonscm.debian.org/git//.git

but actually above link is dead, and correct link is:
- https://anonscm.debian.org/cgit//.git

You can check the following page as example:
- http://anonscm.debian.org/cgit/kernel/linux.git

on the bottom of the page, it says:


Clone
https://anonscm.debian.org/git/kernel/linux.git
git://anonscm.debian.org/kernel/linux.git
ssh://git.debian.org/git/kernel/linux.git


Looking forward to the fix!

Cheers,
Roger

Re: Fwd: git URL wrong on anonscm.debian.org

[Alexander Wirt]

On Sat, 09 Jan 2016, Roger Shimizu wrote:

> I want to report a bug regarding to {anonscm,git}.debian.org, but I
> don't find a pseudo package to file bugreport to, so I contacted
> ad...@alioth.debian.org, but no reply yet for nearly 1 month.
> 
> I hope maybe someone here can help. Thank you!
> 
> Cheers,
> Roger
> 
> -- Forwarded message --
> From: Roger Shimizu 
> Date: Sun, Dec 20, 2015 at 1:11 AM
> Subject: git URL wrong on anonscm.debian.org
> To: ad...@alioth.debian.org
> 
> 
> Dear Alioth Admin,
> 
> Hope I send the issue report here right.
> 
> the git URL of each project on anonscm.debian.org is like:
> - https://anonscm.debian.org/git//.git
Thats about cloning. And it works. 
 git clone https://anonscm.debian.org/git/pkg-nagios/pkg-icinga2.git 
 Cloning into 'pkg-icinga2'...
 remote: Counting objects: 7767, done.


> but actually above link is dead, and correct link is:
Its not dead.
> - https://anonscm.debian.org/cgit//.git
> 
> You can check the following page as example:
> - http://anonscm.debian.org/cgit/kernel/linux.git
> 
> on the bottom of the page, it says:
> 
> 
> Clone
^
> https://anonscm.debian.org/git/kernel/linux.git
> git://anonscm.debian.org/kernel/linux.git
> ssh://git.debian.org/git/kernel/linux.git
All those urls work for cloning.

So what exactly is your problem? 

Alex

Re: Fwd: git URL wrong on anonscm.debian.org

[Roger Shimizu]

On Sat, Jan 9, 2016 at 12:19 AM, Alexander Wirt  wrote:
> On Sat, 09 Jan 2016, Roger Shimizu wrote:
>> https://anonscm.debian.org/git/kernel/linux.git
> All those urls work for cloning.
>
> So what exactly is your problem?

Thanks for your response!
In browser, you see an https link, click it then you get an empty
page, which I think user deserves better experience.

As kernel's upstream page,
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
The https link won't get an empty page.

Cheers,
Roger

Re: support for merged /usr in Debian

[Niels Thykier]

Marc Haber:
> Debian has already been forked by people who found Debian's release
> cycles too long. The result is called Ubuntu, and we lost many of the
> users (and developers!) who want shorter release cycles to them.
> 
> Now, we aim for shorter release cycles ourselves, which won't bring
> any of the users back we lost to Ubuntu. But it'll make us now lose
> the users that think we release too often to the Enterprise Linuxes.

Hi,

We have generally released every 2nd year for the past 3-4 releases, if
not more.  The release cycle will /probably/ also be around two years.

What a lot of people have desired is a shorter *freeze* - as in spending
less time frozen and more time developing.  Given the latter half of our
freeze tends to involve mostly frustration, fragmentation of developers
and very few bug fixes, I am personally one of the people, who would
like to see Debian have shorter freezes[1].

Thanks,
~Niels

[1] Notably by having fewer bugs that need to be fixed /when/ we freeze.






signature.asc
Description: OpenPGP digital signature

Death to git://! Long live git://!

[Paul Tagliamonte]

Hey devel,

We still have `git://` all over the place, for instance, on Vcs-Git on
control files. That makes me sad. Boo insecure transports.

`git://` is plaintext, and plaintext transports are bad.

I'd like to suggest we move all Vcs-Git entries to either `https` or
`ssh`.

Signing tags is a good step, yes, but there will always be unsigned
contents at the head of the branch, and users won't always check them
when cloning a package locally. I'm sure some DDs out there will even
debcheckout and upload after checking a `git diff` rather than a
`debdiff`, because git never lies, right?

Not everyone pulls down the package and uses debdiff, and it only takes
one mistake to own systems.

`git://` provides no upside and really shouldn't exist anymore. GitHub
has even turned it off[1]

Are we going to let GitHub do best practices better than Debian? Hello
no! Let's do this.

There's no downside, and `git://` provides no value. Let's kill it from
the archive.

Plus, `git://` is super blocked by port in a bunch of places `https`
isn't. So there's that.

Cheers,
  Paul

[1]: 
https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days


signature.asc
Description: PGP signature

Re: Death to git://! Long live git://!

[Paul Tagliamonte]

> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
>

As mapreri points out - this is for anon clone, so only https - as I
pointed out in a blog post years ago, ssh is a bad idea :)

http://blog.pault.ag/post/27268910152/usage-of-vcs-git-in-the-debian-archive



-- 
:wq

Re: Death to git://! Long live git://!

[Paul Tagliamonte]

Good point, and I stand corrected. Thanks!

Let's beat GitHub!
  Paul

On Fri, Jan 8, 2016 at 10:47 AM, Andrew Shadura  wrote:

> On 08/01/16 16:43, Paul Tagliamonte wrote:
> > `git://` provides no upside and really shouldn't exist anymore. GitHub
> > has even turned it off[1]
> >
> > Are we going to let GitHub do best practices better than Debian? Hello
> > no! Let's do this.
>
> > [1]:
> https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days
>
> That's not true: git:// still works on GitHub, and the post you linked
> to actually says they're switching off http://, the dumb one.
>
> --
> Cheers,
>   Andrew
>
>


-- 
:wq

Bug#810378: lintian: suggest to use https:// over git:// (was: Re: Death to git://! Long live git://!)

[Ansgar Burchardt]

Package: lintian
Severity: wishlist

Paul Tagliamonte  writes:
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
>
> `git://` is plaintext, and plaintext transports are bad.
>
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.

I think moving to https:// over git:// is a good idea.  lintian could
probably suggest this change, just like it did with canonical VCS URLs
before.

Ansgar

Re: Death to git://! Long live git://!

[Dominic Hargreaves]

On Fri, Jan 08, 2016 at 10:43:40AM -0500, Paul Tagliamonte wrote:
> Hey devel,
> 
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
> 
> `git://` is plaintext, and plaintext transports are bad.
> 
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
> 
> Signing tags is a good step, yes, but there will always be unsigned
> contents at the head of the branch, and users won't always check them
> when cloning a package locally. I'm sure some DDs out there will even
> debcheckout and upload after checking a `git diff` rather than a
> `debdiff`, because git never lies, right?
> 
> Not everyone pulls down the package and uses debdiff, and it only takes
> one mistake to own systems.

Switching to https does prevents some attacks and generally seems like a
good idea, but does not, of course, eliminate the possibility of rogue
code being committed to the source repository. Maintainers will still
need to judge whether the repository they are pulling from (both the
infrastructure and the push access) is sufficiently trustworthy to not
use without checking against packages (or previous versions of their
trusted local repo).

Cheers,
Dominic.

Re: Death to git://! Long live git://!

[Alexandre Detiste]

Hi,

> http://blog.pault.ag/post/27268910152/usage-of-vcs-git-in-the-debian-archive
>
> Enter github.com/debian
>
> – IMHO, we should consider putting the repos that are already on
> GitHub under Debian namespace, so that the team of maintainers
> may be able to add new collaborators.

I'd like to move my two native packages there:

 https://github.com/a-detiste/cruft
 https://github.com/a-detiste/cruft-ng

but GitHub only allows to 

  "Transfer this repository to another user or
  to an organization where you have admin rights."

and then later confirms it:

  "You don’t have admin rights to Debian"

So I could give personaly it to someone I trust from this
team who would move it again to github.com/debian;
that's weird.

Greets,

Alexandre



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

Re: Death to git://! Long live git://!

[Christoph Anton Mitterer]

On Fri, 2016-01-08 at 10:43 -0500, Paul Tagliamonte wrote:
> I'd like to suggest we move all Vcs-Git entries to either `https` or
I doubt https will give any real hard additional security, based on the
inherent problems of the X.509 CA system.

Per default, git would take the system CA store, which per default
contain some large number (IIRC ~100?) of CAs, some of them which have
already proven to be either incompetent or more likely malicious,
others from totalitarian countries or other countries known to most
likely make use of forged certificates for evil purposes.

And even if a CA could be assumed to not do bad things,... most CAs
offer certs based on some challenge response against whois data via
email.
The email which is completely unsecured as well as the whois..


Thus using ssh AND signed tags or even better signed commits seems to
be the best solution from a security PoV :)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Re: Death to git://! Long live git://!

[Scott Kitterman]

On Friday, January 08, 2016 10:43:40 AM Paul Tagliamonte wrote:
> Hey devel,
> 
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.
> 
> `git://` is plaintext, and plaintext transports are bad.
> 
> I'd like to suggest we move all Vcs-Git entries to either `https` or
> `ssh`.
...

As mentioned on #debian-devel, I filed #810381 against debian-policy to mention 
that the Vcs-$VCS entries ought to be secure.

Scott K

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

Re: support for merged /usr in Debian

[Nikolaus Rath]

On Jan 08 2016, Svante Signell  wrote:
> On Thu, 2016-01-07 at 22:46 +0100, Philip Hands wrote:
>> Marc Haber  writes:
>> 
>> > On Tue, 5 Jan 2016 19:37:03 +0100, Marco d'Itri  wrote:
>> > > On Jan 05, Ian Jackson  wrote:
>> > > 
>> > > > People who have been using a configuration for many years naturally
>> > > > become upset when they are told that it has been `unsupported' for all
>> > > > of this time and that, implicitly, changes are going to be made which
>> > > > will break it.
>> > > I think that your summary is correct, and I am quite sure that it would 
>> > > be a bad engineering practice to make technical decisions based on 
>> > > people's emotions.
>> > 
>> > Unfortunately, it's emotions that take vendor decisions. Your attitude
>> > is driving big users towards the paid-for Enterprise Linuxes, be it
>> > logical or not, be it good engineering or not.
>> 
>> Even if that were true, I fail to understand why we should be worried.
>
> The problem is that with Debian heading down this road, the Debian GNU/Linux
> distribution will not exist in 5 years from now.

Debian is developed by its developers, not by its users. Do you have any
evidence (other than your opinion) that loss of users would cause loss
of development work?


Best,
-Nikolaus

(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Death to git://! Long live git://!

[Mehdi Dogguy]

On 2016-01-08 16:43, Paul Tagliamonte wrote:

Hey devel,

We still have `git://` all over the place, for instance, on Vcs-Git on
control files. That makes me sad. Boo insecure transports.

`git://` is plaintext, and plaintext transports are bad.

I'd like to suggest we move all Vcs-Git entries to either `https` or
`ssh`.



Possibly also add a --secure flag to debcheckout so that git:// repos
are checked out using https:// if --secure if turned on? There exists
already an --auth flag which replaces git:// by git+ssh:// (also
configurable using the DEBCHECKOUT_AUTH_URLS environment variable).

The lintian flag is a good idea too.

--
Mehdi

Re: Death to git://! Long live git://!

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Fri, 2016-01-08 at 10:43 -0500, Paul Tagliamonte wrote:

>> I'd like to suggest we move all Vcs-Git entries to either `https` or

> I doubt https will give any real hard additional security, based on the
> inherent problems of the X.509 CA system.

Moving the goalposts from trivial MITM via a rogue AP to obtaining a
fradulent SSL certificate is probably not "hard" security, whatever that
means to you, but is a substantial increase the level of work required for
the attacker.  Given that it's a fairly trivial change in most cases,
since most Git services already expose the repository via HTTPS, I'm not
sure why you're objecting.

> Thus using ssh AND signed tags or even better signed commits seems to be
> the best solution from a security PoV :)

I'm not letting random Internet users ssh into my Git repository host,
thanks.  Securing untrusted ssh is a pain with a lot of fail-open
pitfalls.  I always tightly firewall ssh to only IP addresses I'm actually
using.

I'm also entertained that you think that the completely unchecked host
keys that everyone always approves without even looking at are better
security than X.509 CAs, for all the problems those have.

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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 15:01:53 +, Jonathan Dowland 
wrote:
>and since you are running sid anyway, it wouldn't even help you, so I'm puzzled
>why you suggested it.

You obviously don't see the difference between a customer, a client
machine and a server. This might be a matter of language, so I'll
explain it.

A customer is a company paying me to do things. This usually includes
building and/or running some services on Linux for them. Once upon a
time, this used to be 100 % Debian, but since Debian has started
shortening their release periods, two years later began freezing
distributions two days after changing the default init system to
something entirely different, resulting in a somewhat half-baked, but
surprisingly painless stable release, Enterprise Linuxes have begun to
take on share massively, much to my dismay.

A client is a system that has a human between chair and keyboard. This
includes notebooks and desktop PCs and is usually running Windows,
especially for technically uninterested people. "My" clients are a
small number, exactly three of them. One production notebook, a
desktop, and a secondary notebook for testing and reference purposes.
At least one of the notebooks needs to work at any time, and since I
am a DD, those are running Debian unstable. They do break from time to
time, sometimes due to software errors, sometimes due to surprising
changes to software (such as, no keyscript handling any more). Since
especially the notebooks are only updated when the other one is (a)
near and (b) working, one of them breaking is expected and not a big
problem.

A server is a system I get paid to keep it running. It usually doesn't
have chair, keyboard or screen, is either virtualized or stacked awary
in a datacenter that I have not even seen in most cases, and runs
Debian stable. Break one of them, and I am in trouble either way.
Those machines are those I worry about.

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

Re: support for merged /usr in Debian

[Christian Seiler]

On 01/08/2016 10:21 AM, Marc Haber wrote:
> On Mon, 4 Jan 2016 13:38:15 +0100, Christian Seiler
>  wrote:
>> On 01/04/2016 11:41 AM, Marc Haber wrote:
>>> We have already shown how "much" we care about the users of non-Linux
>>> kernels in Debian ("not at all, they can happily go fishing").
>>
>> So why aren't you on the list of porters for either Hurd of kFreeBSD?
> 
> Since when does one have to actually work on something to be allowed
> to find it important and interesting.

I'm apologize, I was being a bit too snarky here. I just had a lot of
experience with many people that don't care about non-Linux ports at
all (as evidenced by their other actions) but said things very similar
to what you said in order to complain louder. While that may not be
accurate in your case (again: sorry), I am a bit frustrated with that
type of comment when it comes from people who don't actually work on
those ports.

>> Sorry, but this is bogus, because this is a problem you have on every
>> every upgrade. In the past I've already had to repartition systems
>> because / had become too small, because the amount of software required
>> to be there had grown (to support more storage solutions for mounting
>> /usr) and also the kernel modules had grown.
> 
> If hundreds of megabytes of software would get moved from /usr to /,
> this would certainly overflow my root file systems.

That is not what is going to happen. Nobody ever proposed that. I
don't know where people constantly get this idea...

> In fact, as I have
> understood things, software will move from / to /usr,

Exactly, this is what is proposed.

> making the
> system completely unuseable if the multi-gigabytes /usr does not mount
> for some reason.

The system could also be unusable if / doesn't mount, or the kernel
image is damaged, or...

Note that on a typical system writes to / are more likely than writes
to /usr (usually only APT/dpkg writes to /usr), so one could argue
that /usr is typically a bit safer from corruption because it
experiences less writes than /.

 => In that scenario, with /usr being OK but / being corrupted,
UsrMerge would improve changes of having a bootable system.
(You don't necessarily need an intact /etc/fstab here, btw.,
since there are standards for how to auto-detect the /usr
partition according to the GPT partition type, if you use
that. Don't know what Debian's current support of that is,
but the idea exists in principle.)

Failure cases happen. Different file system layouts will have different
consequences for these - but there always will be some things better
and other things worse depending on what kind of failure you have with
which kind of configuration. So I don't think it's as clear-cut as you
may think it is when it comes to recovery.

>> [Repartitioning due to updates]
> 
> Yes, this happens. Do we really have to _force_ this? It is annoying
> enough when it happens caused by the normal flow of things. Even if
> this is the case, not all systems will explode during the same system
> upgrades, allowing the local admin to spread those changes over two or
> even three releases. If we would, in some future, ship an upgrade that
> uncaringly would _require_ a repartitioning, this spread would not be
> possible, and it would undoubtedly call up management attention, which
> could in turn lead to management taking vendor decisions that we don't
> want.

Well, but that can go both ways:

1. /usr is too small, then UsrMerge will require repartitioning
2. / is too small to handle the additional binaries that were added
   to / during the next release, then UsrMerge would prevent
   repartitioning, which you'd have to do without it

So also here it's not clear to me whether it will require more or
less repartitioning. Could go either way.

>>> And, I really don't want to have to adapt, test and verify scripts and
>>> backup schemes to changed partition layout. This will be necessary for
>>> new systems, and it is really a horror vision to have to do this for
>>> existing systems during upgrades.
>>
>> You will always have to adapt things to upgrades, because lots of small
>> details can change.
> 
> That does not mean that we're entitled to needlessly add a big detail
> that changes.

In some sense it's a big change, in some sense it's not. For most
software, it will be absolutely trivial, because the programs will
all still be available.

> [Potential problems with the backup]

I don't get your remarks:

If you back up every file system with --one-file-system separately,
(as you appear to be doing) other than the relative sizes of the
backups (the /usr part is going to be larger, the / part smaller by
the same amount) nothing at all should change.

> And I need
> to change documentation, which will probably trigger a review process
> with management attention.

This may be very unfortunate for you, but I don't think a
situation like yours should be the basis for deciding distribution
policy.

If you want to 

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 15:42:07 +, Niels Thykier 
wrote:
> Given the latter half of our
>freeze tends to involve mostly frustration, fragmentation of developers
>and very few bug fixes, I am personally one of the people, who would
>like to see Debian have shorter freezes[1].

Yes, I have heard your (it was you, wasn't it) talk in Heidelberg. I
took with me that you plan to adopt a "once you're out of testing,
you're out of stable for the next release, unless you're really really
important" policy for stretch, which has put me in deep worry.

I have not installed any new Debian systems at any client site since
hearing about these plans and I plan to keep it this way until I see
them fleshed out and lived.

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

keyscript (was: Re: support for merged /usr in Debian)

[Christian Seiler]

On 01/08/2016 09:50 AM, Marc Haber wrote:
> The loss of keyscript just broke my clients.

I had an inspiration earlier and hacked this together:
https://gist.github.com/chris-se/9c0def7dca60d023d188

(Warning: not thoroughly tested, code is a quick hack and awful, might
do unexpected things. Also not documented. Quick howto: run make, copy
systemd-keyscript-cryptsetup to /lib/cryptsetup/, copy keyscript-generator
to /lib/systemd/system-generators, do systemctl daemon-reload and hope
for the best. systemd-cryptsetup will still warn about 'unknown option',
but it should work.)

(Interactive scripts obviously don't work, same thing as with
interactive init scripts, but if you need a password you can just use
PASS=$(systemd-ask-password "Some Message").)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Jonathan McDowell]

On Fri, Jan 08, 2016 at 06:38:05PM +0100, Marc Haber wrote:
> On Fri, 8 Jan 2016 15:01:53 +, Jonathan Dowland 
> wrote:
> >and since you are running sid anyway, it wouldn't even help you, so
> >I'm puzzled why you suggested it.
> 
> You obviously don't see the difference between a customer, a client
> machine and a server. This might be a matter of language, so I'll
> explain it.

You're not communicating clearly and this is indeed causing problems in
this thread. You said "all my clients run unstable", not "all my client
machines run unstable". You've also later said "I've not installed any
new Debian systems at any client site". It is not unreasonable that the
casual reader will assume you are using the term to mean a 3rd party who
you are managing system for.

To attempt to add some signal to my noise, the gist of this thread seems
to be that Marco wants to make it easy for those who wish to have a
merged /usr to do so, and is not planning to force this upon anyone. As
far as I can tell what he wants to happen is a) files in / and /usr
locations not to conflict and b) policy to state that this should be the
case. I find it hard to object to this request, even without a merged
/usr approach.

There is a separate discussion which has been going on for much longer
which is about whether / and /usr are well supported as separate
filesystems, but that seems to have little to do with whether usrmerge
is undertaken or not.

J.

-- 
... "OK ... First I'll access the secret military spy satelite that is in
geosynchronous orbit over the midwest. Then I'll ID the limo by the
vanity plate "MR. BIGGG" and get his approximate position. Then I'll
reposition the transmission dish on the remote truck to 17.32 degrees
east, hit WESTAR 4 over the Atlantic, bounce the signal back into the
aerosphere up to COMSAT 6, beam it back to SATCOM 2 transmitter number
137 and down on the dish on the back of Mr. Big's limo... It's almost
too easy." -- Garth Algar, Wayne's World


signature.asc
Description: Digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 17:54:49 +, Jonathan McDowell
 wrote:
>You're not communicating clearly and this is indeed causing problems in
>this thread. You said "all my clients run unstable", not "all my client
>machines run unstable". You've also later said "I've not installed any
>new Debian systems at any client site". It is not unreasonable that the
>casual reader will assume you are using the term to mean a 3rd party who
>you are managing system for.

You're right to blame for only speaking english for 30 years of my
life and living in a country where TV programs are dubbed. I am also
deeply worried about the Operating System I still care about after 15
years and which works so hard to feel not like a home any more.

>To attempt to add some signal to my noise, the gist of this thread seems
>to be that Marco wants to make it easy for those who wish to have a
>merged /usr to do so, and is not planning to force this upon anyone.

I would believe that if it were somebody else.

>As
>far as I can tell what he wants to happen is a) files in / and /usr
>locations not to conflict and b) policy to state that this should be the
>case.

If that is really the gist of those editorial changes[1], then this is
actually a misunderstanding. Maybe UsrMerge is even a misnomer.

Greetings
Marc


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

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 08 Jan 2016 09:14:45 -0800, Nikolaus Rath 
wrote:
>On Jan 08 2016, Svante Signell  wrote:
>> The problem is that with Debian heading down this road, the Debian GNU/Linux
>> distribution will not exist in 5 years from now.
>
>Debian is developed by its developers, not by its users. Do you have any
>evidence (other than your opinion) that loss of users would cause loss
>of development work?

Quite some developers are getting paid to be Debian users or by Debian
users. We participate in Debian because it makes using Debian easier
for the people who pay us.

If these users stop being Debian users, they have no reason to pay
developers to make Debian better. This causes significant loss of
development work.

Not all Debian contributors are contributing because they're students
that need to get rid of free time. And, in fact, contributing to
Debian has significantly lost being fun over the last five years.

Alas, maybe I'm just too old.

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

Re: keyscript (was: Re: support for merged /usr in Debian)

[Marc Haber]

On Fri, 8 Jan 2016 18:51:20 +0100, Christian Seiler
 wrote:
>(Warning: not thoroughly tested, code is a quick hack and awful, might
>do unexpected things. Also not documented. Quick howto: run make, copy
>systemd-keyscript-cryptsetup to /lib/cryptsetup/, copy keyscript-generator
>to /lib/systemd/system-generators, do systemctl daemon-reload and hope
>for the best. systemd-cryptsetup will still warn about 'unknown option',
>but it should work.)
>
>(Interactive scripts obviously don't work, same thing as with
>interactive init scripts, but if you need a password you can just use
>PASS=$(systemd-ask-password "Some Message").)

You're amazingly constructive. I wish I had your output. Thanks!

Will this handle a keyscript that needs to unlock another crypto LV
which is unlocked with a a password?

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

Re: Fwd: git URL wrong on anonscm.debian.org

[Alexander Wirt]

On Sat, 09 Jan 2016, Roger Shimizu wrote:

> On Sat, Jan 9, 2016 at 12:19 AM, Alexander Wirt  wrote:
> > On Sat, 09 Jan 2016, Roger Shimizu wrote:
> >> https://anonscm.debian.org/git/kernel/linux.git
> > All those urls work for cloning.
> >
> > So what exactly is your problem?
> 
> Thanks for your response!
> In browser, you see an https link, click it then you get an empty
> page, which I think user deserves better experience.
> 
> As kernel's upstream page,
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> The https link won't get an empty page.
You are right. I added some more apache magic.

git clone https://anonscm.debian.org/git/kernel/linux.git
Cloning into 'linux'...
remote: Counting objects: 141055, done.

...

curl https://anonscm.debian.org/git/kernel/linux.git 2>&1 |grep -i \kernel/linux - Debian linux repository

I now gives you either git smart http transport or the cgit website of the
project, depending on what you are asking for. 

Thanks for your suggestion

Alex

Re: keyscript

[Christian Seiler]

On 01/08/2016 07:19 PM, Marc Haber wrote:
> On Fri, 8 Jan 2016 18:51:20 +0100, Christian Seiler
>  wrote:
>> (Warning: not thoroughly tested, code is a quick hack and awful, might
>> do unexpected things. Also not documented. Quick howto: run make, copy
>> systemd-keyscript-cryptsetup to /lib/cryptsetup/, copy keyscript-generator
>> to /lib/systemd/system-generators, do systemctl daemon-reload and hope
>> for the best. systemd-cryptsetup will still warn about 'unknown option',
>> but it should work.)
>>
>> (Interactive scripts obviously don't work, same thing as with
>> interactive init scripts, but if you need a password you can just use
>> PASS=$(systemd-ask-password "Some Message").)
> 
> You're amazingly constructive. I wish I had your output. Thanks!
> 
> Will this handle a keyscript that needs to unlock another crypto LV
> which is unlocked with a a password?

Well, if the other volume (that's locked with a password) is NOT in
/etc/crypttab, it should probably work, but you need to use
systemd-ask-password to ask for the password.

So this should *probably* work in the keyscript (not tested at all):

# lv1 NOT in crypttab, NOT in /etc/fstab
systemd-ask-password --no-tty "Secret Container" \
 | cryptsetup --key-file=- open /dev/disk/by-uuid/something lv1 >&2
mount -t something /dev/mapper/lv1 /somelocation >&2

# extract the key somehow
cat /somelocation/keyfile

# (possibly)
umount /somelocation
cryptsetup close lv1

(But if there's just a single key file on an external device, then
you shouldn't need a keyscript at all with systemd. Could you
describe your setup in a bit more detail? Perhaps I can provide
you with an option that doesn't rely on keyscript=.)

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Fri, 8 Jan 2016 18:37:11 +0100, Christian Seiler
 wrote:
>On 01/08/2016 10:21 AM, Marc Haber wrote:
>> If hundreds of megabytes of software would get moved from /usr to /,
>> this would certainly overflow my root file systems.
>
>That is not what is going to happen. Nobody ever proposed that. I
>don't know where people constantly get this idea...

We have been bitten by editorial changes in the past. The systemd
debate hasn't made things any easier. And I have over the last years
slowly lost part of my faith that Debian's key people (those that
don't get elected or delegated, but those that have control over key
packages) actually care about the _users_ of The Universal Operating
System.

Yes, I know, servers and buildds run without users, and caring about
users is not always more fun than actually doing development and
building sound, clean solutions.

>> making the
>> system completely unuseable if the multi-gigabytes /usr does not mount
>> for some reason.
>
>The system could also be unusable if / doesn't mount, or the kernel
>image is damaged, or...

Kernel Image and small / are less likely to get damaged than a
multi-gigabyte /usr. At least that's how people think who have known a
40 Meg (sic!) disk as "large". I am pretty well aware that my last
corrupted /usr file system was many years ago, but this is a change
one needs to get used to.

[correct reasoning removed]

>Well, but that can go both ways:
>
>1. /usr is too small, then UsrMerge will require repartitioning

I would probably be possible to have the script doing the merge check
whether /usr is large enough and abort if that is not the case. I
would write a wishlist report, but looking at who's in charge I know
that the answer would be "works for me, send a patch if you want this
change" anyway. And I don't like wasting my time, so I have made a
habit of looking into the maintainer field of debian/control and the
changelog of a package before bothering to write a wishlist report. Or
not write one.

[again, correct reasoning removed]

>> [Potential problems with the backup]
>
>I don't get your remarks:
>
>If you back up every file system with --one-file-system separately,
>(as you appear to be doing) other than the relative sizes of the
>backups (the /usr part is going to be larger, the / part smaller by
>the same amount) nothing at all should change.

One will probably need to adjust the anchor points of the file system
backups.

>> And I need
>> to change documentation, which will probably trigger a review process
>> with management attention.
>
>This may be very unfortunate for you, but I don't think a
>situation like yours should be the basis for deciding distribution
>policy.

Well, Debian is (still) used in big enterprises.

>If you want to "stay below the radar" of management, then you
>probably shouldn't dist-upgrade at all - because a lot more things
>can break on a software-level, where you need to adapt configuration.
>Or some software is discontinued and you have to switch to an
>alternative, where you have to redo your configuration completely.

I have been running Debian servers in production for nearly 20 years,
I can handle upgrades just fine. I just hate it when they are harder
than necessary for reasons that I can't follow.

>>>   Sure, you need to test if something breaks (because it always can,
>>>   regardless of whether UsrMerge is done or not), but _surely_ you
>>>   have a test environment before performing a dist-upgrade of your
>>>   entire production system? Right?
>> 
>> Not everywhere. This might look unprofessional, but I am usually
>> running the small little gallic Linux village inside "all Windows"
>> shops, and when I ask organizations for test environments, I might end
>> up with "nah, too much hassle, we'll just use Windows instead for your
>> job".
>
>And you can't even spin up a VM with the same size disk etc. to
>test things?

Not for every single machine.

>> You have a big point here. All I want is documentation and commitments
>> so that no surprises come.
>
>If I look at the Jessie release notes (Niels linked them somewhere
>in this thread), they are _very_ detailed, which is probably a big
>reason why the Jessie transition was far less painful as many
>people her have feared. So I don't think documentation will be an
>issue.

I'd prefer to read the commitment in the package itself.

[again, correct reasoning removed]

>2. The UsrMerge proposed here is optional and will remain so for
>Stretch.

... but not for buster

>Come to an agreement within the Debian project that supporting split
>/usr without an initramfs is not going to work out in the long term,

... but split /usr with initramfs is supported and will continue to be
a supported configuration at least in system upgrades.

>document that with an appropriate wording in the Stretch release notes.
>Suggest alternatives to real issues that people face because of this
>change (tiny-initramfs[1] for example). This way, while those people
>using sp

Re: Death to git://! Long live git://!

[Christian Seiler]

On 01/08/2016 04:43 PM, Paul Tagliamonte wrote:
> We still have `git://` all over the place, for instance, on Vcs-Git on
> control files. That makes me sad. Boo insecure transports.

Ben Hutchings posted this not too long ago on Planet Debian:
http://womble.decadent.org.uk/blog/securing-debcheckout-of-git-repositories.html

Regards,
Christian



signature.asc
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 09:14 -0800, Nikolaus Rath wrote:
> On Jan 08 2016, Svante Signell  wrote:

> > The problem is that with Debian heading down this road, the Debian
> > GNU/Linux distribution will not exist in 5 years from now.
> 
> Debian is developed by its developers, not by its users. Do you have
> any evidence (other than your opinion) that loss of users would cause
> loss of development work?

That would be the biggest mistake ever made in Debian history. What
would you do with a distribution having no users?

Re: support for merged /usr in Debian

[Svante Signell]

On Fri, 2016-01-08 at 19:15 +0100, Marc Haber wrote:

> Quite some developers are getting paid to be Debian users or by
> Debian
> users. We participate in Debian because it makes using Debian easier
> for the people who pay us.On Fri, 08 Jan 2016 09:14:45 -0800,
> Nikolaus Rath 
> 
> 
> If these users stop being Debian users, they have no reason to pay
> developers to make Debian better. This causes significant loss of
> development work.
> 
> Not all Debian contributors are contributing because they're students
> that need to get rid of free time. And, in fact, contributing to
> Debian has significantly lost being fun over the last five years.
> 
> Alas, maybe I'm just too old.

No you are not. Debian following the commercial vendor track will make
them extinguished. Technically there are no real advantages of the new
(in many youngsters mind revolutionary) ideas. The idea of a Debian
Universal Operating System, supporting Free Software (not Open Source
Software), is dead.

Re: support for merged /usr in Debian

[Tobias Frost]

Am Freitag, den 08.01.2016, 09:14 -0800 schrieb Nikolaus Rath:
> 
> Debian is developed by its developers, not by its users. Do you have
> any
> evidence (other than your opinion) that loss of users would cause
> loss
> of development work?


Our priorities are our users and free software

We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. We will not object to non-free works
that are intended to be used on Debian systems, or attempt to charge a
fee to people who create or use such works. We will allow others to
create distributions containing both the Debian system and other works,
without any fee from us. In furtherance of these goals, we will provide
an integrated system of high-quality materials with no legal
restrictions that would prevent such uses of the system.

(Our social contract)

Re: support for merged /usr in Debian

[Robert Edmonds]

Simon McVittie wrote:
> 0m24.5s DEBUG: Starting command: ['adequate', '--root',
> '/srv/piuparts.debian.org/tmp/tmpk5ZNdX', 'iputils-ping']
> 0m24.6s DUMP:
>   iputils-ping: bin-or-sbin-binary-requires-usr-lib-library /bin/ping6
> => /usr/lib/x86_64-linux-gnu/libgnutls-openssl.so.27
> 
> I don't know why a ping implementation wants to do SSL, but let's assume
> that's a useful thing to do for some reason. Are you saying that GNUTLS
> and all its dependencies should move from /usr to /?

Looks like it's not actually SSL that ping6 wants to do, but MD5, due to
the support for "ICMPv6 Node Information Queries (RFC4620)":

https://tools.ietf.org/html/rfc4620#section-5

[...] Compute the MD5 hash [...]

If it really does need to do MD5, maybe it could use the one in libbsd0
instead of dragging in libgnutls-openssl27 and its dependencies.

-- 
Robert Edmonds
edmo...@debian.org

APT 1.2 preview uploaded to experimental -- please test

[Julian Andres Klode]

Good moo,

I just uploaded APT 1.2~exp1 to experimental. This release includes
the following highlights:

* Automatic removal of debs after install for apt(8)
* LZ4 support
* Recompression of indices
* Parallel rred
* Further 15% performance gain in cache generation

It should hit the archive with the next dinstall run.

It will be uploaded to unstable in the coming days, we only want to
get some testing and fix some other bugs from unstable first.

Automatic removal of debs after install
===
After packages are successfully installed by apt(1),
the corresponding .deb package files will be
removed from the /var/cache/apt/archives cache directory.

This can be changed by setting the apt configuration option
"APT::Keep-Downloaded-Packages" to "true". E.g:

# echo 'APT::Keep-Downloaded-Packages "true";' \
  > /etc/apt/apt.conf.d/01keep-debs

Please note that the behavior of apt-get is unchanged. The
downloaded debs will be kept in the cache directory after they
are installed.

LZ4 support

APT now supports LZ4 compression. This allows Contents files
to be compressed much faster with the following change.

Locally Compressed indices
==
If you use Acquire::gzipIndexes, or any other compressed index targets,
those will now be compressed with the fastest supported algorithm,
currently lz4.

This especially applies to apt-file and the Contents files.

Parallel rred
=
APT will now launch upto CPU count * 2 instances of the rred method,
but not more than 10 (there's a hidden Config option to enable more).

This also improves performance of Contents files a lot.

Cache generation improvement

The cache generation now uses string views instead of strings, meaning
that we do not create temporary copies of strings anymores. Depending
on how fast your system can copy memory, this might result in impressive
performance gains. I've seen good gains in ARM.

This work was inspired by the APT patches that are used in the backend
of Cydia, a package manager for jailbroken iOS devices.

We also now use a hash table size of 50503 instead of 15013, and store
length of strings in the cache.

As a summary of performance gains:

Device 1: ThinkPad X230, Core i5-3320M, 8GB Dual-Channel RAM

1.1.8:1.8 seconds
1.1.9:1.5 seconds
1.1.10:   1.4 seconds
1.2~exp1: 1.2 seconds

Device 2: Acer Chromebook 13, Tegra K1, 4GB RAM

1.1.8:3.0 seconds
1.1.10:   2.5 seconds
1.2~exp1: 2.0 seconds

So roughly speaking, we only take 2/3 of the time now compared
to 1.1.8 after which I started optimising the code.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Re: support for merged /usr in Debian

[Russ Allbery]

Svante Signell  writes:

> No you are not. Debian following the commercial vendor track will make
> them extinguished. Technically there are no real advantages of the new
> (in many youngsters mind revolutionary) ideas. The idea of a Debian
> Universal Operating System, supporting Free Software (not Open Source
> Software), is dead.

What will kill Debian faster than anything else is to have every idea for
changing something large, interesting, or possibly revolutionary in Debian
be met with anger, derision, and attacks.  The process of proposing doing
interesting things inside Debian is already so miserable that it surprises
me people are willing to attempt it.  Those ideas are always met with
furious pushback from at least a few people who don't want anything to
ever change in that particular area of the distribution.  That this is
often different people for each change doesn't really help.

If it's not possible to do interesting things and it's not possible to try
to improve Debian, maintaining Debian becomes a job rather than something
one does for fun, which in turn will mean that Debian will become stale
and stagnant and lose contributors.  Then *everyone* loses, since even
those who would be happy to see absolutely nothing about the distribution
change expect incorporation of new software and support for new platforms
and new hardware.

If you want people to do maintenance work without getting to do anything
creative, interesting, or exciting, you had better have some method for
paying them, because that's a job, not something people do for the love of
it.

That doesn't mean we need to break things.  Ideally, we don't.  But if the
entire burden of making everything work exactly the way it always has is
put solely on the people who are trying to do something that excites them,
the stability that we will get will be the stability of death.

I do not believe people working on Debian want to break other people's use
cases for the fun of it.  However, enthusiasm is fragile.  Please, try to
engage with people, find creative solutions, and try to preserve the
things they're excited about in their projects, rather than muffling them
in layers of obstructionism.  We need excited people and enthusiastic
people to make Debian something we can all be proud of.

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

Re: support for merged /usr in Debian

[Nikolaus Rath]

On Jan 08 2016, Tobias Frost  wrote:
> Am Freitag, den 08.01.2016, 09:14 -0800 schrieb Nikolaus Rath:
>>  Debian is developed by its developers, not by its users. Do you have
>> any evidence (other than your opinion) that loss of users would cause
>> loss of development work?
>
>
> Our priorities are our users and free software
>
> We will be guided by the needs of our users and the free software
[...]

I don't see how this answers my question (unless you are agreeing with
me). Almost every Debian developer is a Debian user.

Best,
-Nikolaus

(No Cc on replies please, I'm reading the list)
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: APT 1.2 preview uploaded to experimental -- please test

[Adrien CLERC]

Le 08/01/2016 22:13, Julian Andres Klode a écrit :
> So roughly speaking, we only take 2/3 of the time now compared
> to 1.1.8 after which I started optimising the code.
>
And I wish to say to you that you made a very good job at this. On my
personal self-hosted server, the difference is huge (Intel(R) Atom(TM)
CPU D2550).

Thank you!

Adrien

md5(3bsd) (was: Re: support for merged /usr in Debian)

[Marco d'Itri]

On Jan 08, Robert Edmonds  wrote:

> If it really does need to do MD5, maybe it could use the one in libbsd0
> instead of dragging in libgnutls-openssl27 and its dependencies.
I did not notice this recent addition...
Folks, there is *a lot* of software which embeds copies of md5.c: please 
try to convert it to use libbsd!
And how many of you still have copies of setproctitle.c around? Do you 
know that they probably come from sendmail? Clean up your old code!

If you have some old package with plain makefiles which needs to be 
converted to use libbsd then you can have a look at my openbsd-inetd 
package for inspiration.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Death to git://! Long live git://!

[Christoph Anton Mitterer]

On Fri, 2016-01-08 at 09:35 -0800, Russ Allbery wrote:
> Moving the goalposts from trivial MITM via a rogue AP to obtaining a
> fradulent SSL certificate is probably not "hard" security, whatever
> that
> means to you, but is a substantial increase the level of work
> required for
> the attacker.
Well, I think that's what most people wrongly assume and therefore may
easily fool themselves into a false sense of security.

Sure, such an attack is probably not doable in 5mins for the
neighbouring colleague who wants to play a prank - but so one is
typically not the person who really wants to attack a project like
Debian.

And as I've said, the typical procedure how verification takes place on
most CAs involves so many unsecured paths, mail, whois, how the whois
is set by the (presumed) owner, how the registrar communicates that to
the registry , how the CA retrieves the whois...

It seems foolish, if at the one side many crypto algos (MD5, DSS, etc.)
and keylenghts are considered to be not enough by people, while on the
other side, they put their whole trust into the above weak procedure to
secure their 4096 bit keys ;-)


>   Given that it's a fairly trivial change in most cases,
> since most Git services already expose the repository via HTTPS, I'm
> not
> sure why you're objecting.
I didn't object... I just wanted to express that where possible, ssh
should be used rather than https.
AFAIU, DDs and DMs already have some sort of trust path to Debian (and
I hope it's better than trusting GANDI ;-) ), so they should already
have a secure way to retrieve the public host keys of Debian Servers,
and if not, simply provide them in a package, or somewhere signed by
some Debian Archive key or so.

Of course this applies only to the actual DDs and DMs, and not to
anonymous access - there the best we can get is of course https (as you
pointed out yourself, securing.

Unfortunately, Debian put all its trust-eggs into someone else's basket
- GAND - and thus into the basket of UTN (which belongs to whom right
now?), and thus IIRC under the authority of national security letters
and gag orders.
I've already mentioned previously that this was at best questionable,
because anyone who's more deply into Debian than just visiting the
website (i.e. reading security.debian.org, BTS webinterface, accesing
the mailing list archives - in short, everything that's https secured)
has now no longer the chance to really securely interact with this
systems.

When Debian had its own CA, this was at least in principle possible and
it would have also allowed to really securely use git over https with
Debian's repos.
Again, at least in principle, because IIRC, git didn't directly allow
to set the trusted CA for a repo (or does it? :) ).


> I'm not letting random Internet users ssh into my Git repository
> host,
> thanks.  Securing untrusted ssh is a pain with a lot of fail-open
> pitfalls.  I always tightly firewall ssh to only IP addresses I'm
> actually
> using.
Sorry, I should have made more clear, that I was talking about people
who typically have write-access to these repos, from which one
could/should hope, that they have a proper trust path and are allowed
some form of access anyway.

Oh and I should perhaps mention,... at least when using git with gitolite, I'm 
fairly confident that one actually can secure ssh enough that it shouldn't be a 
problem to give people access even it those are not 100% trusted.
One can restrict things from ssh side quite nicely, and back when I set up my 
own gitservers, I got Sitaram to add a shell mode of gitolite, which I think 
increases security even more.
Even a security paranoid as myself doesn't have too many concerns about it =)


> I'm also entertained that you think that the completely unchecked
> host
> keys that everyone always approves without even looking at are better
> security than X.509 CAs, for all the problems those have.
Well I'm always happy if I can help to entertain people ^^
But seriously,... if someone's so stupid to simply accept the remote
keys without checking... there's nothing one can do (unless perhaps
banning such guy for life if one ever finds out).
The same as such person blindly accepts an unverified key, the same
he/she may simply post his/her trusted DD GPG key on pastebin ;)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#810489: ITP: node-nodeunit -- Easy unit testing for node.js and the browser.

[Jonathan Ulrich Horn]

Package: wnpp
Severity: wishlist
Owner: Jonathan Ulrich Horn 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-nodeunit
  Version : 0.9.1
  Upstream Author : Caolan McMahon
* URL : https://github.com/caolan/nodeunit
* License : Expat
  Programming Lang: JavaScript
  Description : Easy unit testing for Node.js and the browser.

 Nodeunit is an async unit testing tool for Node.js and the browser.
 It is simple to use, has flexible reporters for custom output
 and allows the use of mocks and stubs.
 .
 Node.js is an event-based server-side JavaScript engine.



signature.asc
Description: OpenPGP digital signature

Re: Fwd: git URL wrong on anonscm.debian.org

[Roger Shimizu]

On Sat, Jan 9, 2016 at 3:29 AM, Alexander Wirt  wrote:
> On Sat, 09 Jan 2016, Roger Shimizu wrote:
>> On Sat, Jan 9, 2016 at 12:19 AM, Alexander Wirt  wrote:
>> > On Sat, 09 Jan 2016, Roger Shimizu wrote:
>> In browser, you see an https link, click it then you get an empty
>> page, which I think user deserves better experience.
>>
>> As kernel's upstream page,
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
>> The https link won't get an empty page.
> You are right. I added some more apache magic.
>
> git clone https://anonscm.debian.org/git/kernel/linux.git
> Cloning into 'linux'...
> remote: Counting objects: 141055, done.
> ...
> curl https://anonscm.debian.org/git/kernel/linux.git 2>&1 |grep -i \ kernel/linux - Debian linux repository
>
> I now gives you either git smart http transport or the cgit website of the
> project, depending on what you are asking for.

The empty page goes away. Thanks for the change!

Cheers,
Roger

Re: Fwd: git URL wrong on anonscm.debian.org

[Paul Wise]

On Sat, Jan 9, 2016 at 2:29 AM, Alexander Wirt wrote:

> curl https://anonscm.debian.org/git/kernel/linux.git 2>&1 |grep -i \ kernel/linux - Debian linux repository

I wonder if a redirect would be more appropriate?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: support for merged /usr in Debian

[Lars Wirzenius]

On Fri, Jan 08, 2016 at 01:31:12PM -0800, Russ Allbery wrote:
> What will kill Debian faster than anything else is to have every idea for
> changing something large, interesting, or possibly revolutionary in Debian
> be met with anger, derision, and attacks.

Hear, hear. I snipped out the rest of Russ's mail, but only for
brevity: I fully agree with all of it. Extremely well said, Russ.

I feel that there is fair bit of unresolved conflict sloshing around
the project. This happens when people have a disagreement, and it's
not handled properly on an emotional level: even though the
disagreement is resolved on a technical level, and a decision is made
and implemented, those who didn't agree with it don't get proper
emotional closure, they feel put upon and rejected, that their
concerns do not matter. It's like they are wounded, and the wound
never gets to heal, and if there's any future disagreement, the old
wound gets torn open again. That's not healthy.

In the Battlestar Galactica remake, they have a fleet-wide boxing
match, where anyone can challenge anyone regardless of rank, and they
hit each other and this somehow gives emotional closure. I do not
suggest this, since violence really isn't an answer, and even if it
were, losing a boxing match as well as an argument isn't going to give
closure. Resolving conflicts by having new conflicts isn't the
solution.

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

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: Digital signature