Clearing the conffile status of a file

[Florian Weimer]

I've got a request to remove the conffile status of a file after it is
no longer a conffile.  dpkg-maintscript-helper rm_conffile does not
seem to do this, based on the documentation and the source code.

Is there a clean way to implement this (i.e., by not patching
/var/lib/dpkg/status directly)?  If there is a way, is there a reason
not do it?

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Holger Levsen]

On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
> On Tue, 11 Jul 2017, Bjørn Mork wrote:
> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
> 
> sudo ip link; sudo ip addr;
 
no need for sudo, this is enough: 

ip link ; ip addr

or even shorter:

ip l ; ip a


-- 
cheers,
Holger, who hasn't really noticed this change much, depite maintaining
*lots* of (different) stretch machines… as long as the machines
are not routers but just desktops or laptops because then
network-manager takes care anyway, and if I have a router I
probably don't use Debian anyway and if I have multiple
interfaces on a server I'm very happy about stable names…
so, meh.


signature.asc
Description: Digital signature

Re: Bad interaction between pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master

[Ian Jackson]

James Clarke writes ("Re: Bad interaction between 
pbuilder/debhelper/dpkg-buildinfo/dpkg-genchanges and dak on security-master"):
> Having the _amd64.buildinfo included in a _source.changes created by
> dpkg-genchanges -S in a tree which has done a source+binary build is an
> intended feature.

Wait, what ?  You're telling me that dpkg-genchanges will pick up
random .buildinfo files it happens to find lying around ?  And that
this is deliberate ?

There is no way the tools can tell whether the _amd64.buildinfo it
finds even relates to the same source code, or anything.

Ian.

Re: Naming of network devices - how to improve it in buster

[Ian Jackson]

Nikolaus Rath writes ("Re: Naming of network devices - how to improve it in 
buster"):
> I wonder if anyone actually uses /dev/disk/by-path?

$ grep path /etc/fstab
/dev/disk/by-path/pci-:3b:00.0-platform-rtsx_pci_sdmmc.0-part1/media/sd 
  autorw,user,noauto 0 0
$

^ from my laptop.

Ian.

Re: IMPORTANT: Do live Debian images have a future?

[Fernando Toledo]

El 26/06/17 a las 11:08, Steve McIntyre escribió:
> [ Note the cross-posting... ]
> 
> Hey folks,
> 

Our Use-case:

We develop a derivated distro from Debian called Huayra GNU/Linux, this
is for educational program of government in Argentina. This big program
ship around 5 millons of netbooks to highschool students.

We start using live-builder to customize a live-cd that can be
installable (via live plugin of debian installer due that our distro
have many packages. Chroot install's save us time instead of package by
package)

And found on this tool the solution to make our work (customs packages
list, customize the chroot and binary parts <- this great, the
installer/preseed, isolinux screens, use of our repository and keys
..etc etc etc)
Just this work. Uefi support was bad but workarounds save us.

When live-wrapper annuonce that will be the official tool, we try to
replicate the actual work using the new tool with no great success. Part
of lack of knowledge and not mature status of live-wrapper.

I think that many live-builder users went through the same thing.

I'm not want to re-begin the "tool war" again please!, I can use anyone,
but i need that functionality that means, maybe with better
docummentation for live-wrapper may help.

Debian is great. I hope that these tools gets better every day.
We are grateful for use it.

Saludos!

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#868163: ITP: open-adventure -- colossal cave adventure, the 1995 430-point version

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: "Dr. Tobias Quathamer" 

* Package name: open-adventure
  Version : 1.2
  Upstream Author : Eric S. Raymond 
* URL : https://gitlab.com/esr/open-adventure
* License : BSD 2-clause
  Programming Lang: C, Python
  Description : colossal cave adventure, the 1995 430-point version
 This is the last descendent of the original 1976 Colossal Cave
 Adventure worked on by the original authors -- Crowther & Woods.
 It has sometimes been known as Adventure 2.5. The original PDP-10
 name 'advent' is used for the built program to avoid collision with
 the BSD Games version.


I intend to maintain the package in the pkg-games group on alioth.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: IMPORTANT: Do live Debian images have a future?

[shirish शिरीष]

at bottom :-

On 12/07/2017, Fernando Toledo  wrote:
> El 26/06/17 a las 11:08, Steve McIntyre escribió:
>> [ Note the cross-posting... ]
>>
>> Hey folks,
>>
>
> Our Use-case:
>
> We develop a derivated distro from Debian called Huayra GNU/Linux, this
> is for educational program of government in Argentina. This big program
> ship around 5 millons of netbooks to highschool students.



>
> --
> Fernando Toledo
> Dock Sud BBS
> http://bbs.docksud.com.ar
> telnet://bbs.docksud.com.ar
>

In short, this alone use-case answers Steve's original question which
was primarily are there any users who use or would use this tool or
his time would be better spent somewhere else. I think just the above
use-case and number of users answers the need for a tool like
live-wrapper. As has been pointed out by me and others, it just needs
more testing (documentation and love by devs.) to drive more usage
forwards.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Michael Lustfield]

On Jul 12, 2017 03:39, "Holger Levsen"  wrote:

On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
> On Tue, 11 Jul 2017, Bjørn Mork wrote:
> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
>
> sudo ip link; sudo ip addr;

no need for sudo, this is enough:

ip link ; ip addr

or even shorter:

ip l ; ip a


I don't believe the point had anything to do with ifconfig vs. ip. Rather,
it's no longer possible for people doing remote troubleshooting to make an
educated guess what the name of the interface in question is.

Imagine destining to the lay user how to read and parse the bits from the
ip command output that you're after. Now, instead of knowing it's the
add-on card and asking for bits of "ip addr show eth1", you're now along
them to run "ip addr" and figure out which of the devices might be what
you're looking for.

In another scenario, system automation doesn't often involve management of
network interfaces, but it's also not rare. I had been able to look at DCIM
and know what address ethX would have assigned. At the moment, I'm not
really sure how to handle the new naming scheme. I miss simple and
(globally) predictable.

Re: Naming of network devices - how to improve it in buster

[Marc Haber]

On Tue, 11 Jul 2017 15:20:41 +0200, Michael Biebl 
wrote:
>Am 11.07.2017 um 12:14 schrieb Guus Sliepen:
>> Ok, it should be clear now that the new way of naming interfaces is not
>> ideal, but the older ways weren't either. Let's have a look at what we
>> want:
>> 
>> - A simple name for systems with a single Ethernet and/or Wireless
>>   interface (the simple desktop/laptop scenario).
>
>How would you determine that a system will only ever have a single
>interface?

I'd rather have breakage in this case than having to look for the
interface every fscking time I need to run tcpdump, or having to adapt
to an entirely new name schema like lanc0 and lanw0 to not stomp in
the kernel's name space when using my own naming scheme.

My finger memory will still type tcpdump -i eth0 before the brain can
intervene ten years from now.

Grüße
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: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Marc Haber]

On Wed, 12 Jul 2017 08:38:36 +, Holger Levsen
 wrote:
>On Tue, Jul 11, 2017 at 10:44:47AM -0500, Don Armstrong wrote:
>> On Tue, 11 Jul 2017, Bjørn Mork wrote:
>> > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now?
>> 
>> sudo ip link; sudo ip addr;
> 
>no need for sudo, this is enough: 
>
>ip link ; ip addr
>
>or even shorter:
>
>ip l ; ip a

Still, an elderly family member reading this out to you on the phone
is very very energy-draining.

Grüße
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: Naming of network devices - how to improve it in buster

[Michael Biebl]

Am 12.07.2017 um 17:35 schrieb Marc Haber:
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

thankfully tcpdump (and lots of other tools) have nice shell completion.
tcpdump -i  works great her.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Matt Zagrabelny]

On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  wrote:

> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
>
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.
>
>
Agreed. However, I'd still rather deal with names like /dev/sda and eth0
than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.

It is kind of like using people's first names as opposed to their Social
Security Number (in US) or other form of national identification. I know
when I can use the name Matt and I know who it refers to, even if another
Matt enters the room. I'm comfortable with eth0 being the name, even when
another interface appears.

I completely understand, and largely agree with, the need for persistent
naming - but I think we are selling ourselves and our users short by not
pressing harder for network interface aliases. It seems to be too useful of
a solution for this problem.

-m

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Vincent Bernat]

 ❦ 12 juillet 2017 17:35 +0200, Marc Haber  :

>>> sudo ip link; sudo ip addr;
>> 
>>no need for sudo, this is enough: 
>>
>>ip link ; ip addr
>>
>>or even shorter:
>>
>>ip l ; ip a
>
> Still, an elderly family member reading this out to you on the phone
> is very very energy-draining.

Right click on network manager applet, "Connection Information" (or the
appropriate translation in user language).
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Roger Lynn]

On 10/07/17 19:40, Marvin Renich wrote:



> There is an easy fix to revert the default behavior while still allowing
> knowledgeable sysadmins to get the new behavior.  On the other hand,
> those who need to administer systems but are not sysadmins by trade (and
> thus will have to do significantly more research to even know that the
> older behavior is possible) are the ones who need the older behavior as
> the default.

This caught me out on a recent new installation, which gave me these new
names which are too complicated to be usable. I wasted hours working out
what had happened, how to fix it and how to write a udev rules file from
scratch. And having just read this thread, I've discovered that the rules
I've written are themselves apparently unreliable, for example:
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

Roger

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Wed, Jul 12, 2017 at 08:42:50PM +0200, Vincent Bernat wrote:
>  ❦ 12 juillet 2017 17:35 +0200, Marc Haber  :
> >>> sudo ip link; sudo ip addr;
> >> 
> >>no need for sudo, this is enough: 
> >>
> >>ip link ; ip addr
> >>
> >>or even shorter:
> >>
> >>ip l ; ip a
> >
> > Still, an elderly family member reading this out to you on the phone
> > is very very energy-draining.
> 
> Right click on network manager applet, "Connection Information" (or the
> appropriate translation in user language).

If you rely solely on dynamic configuration via network-manager, you don't
care about interface names so either setup is ok for you.

For the rest of us, though, wlxf81a671bcfae requires copy&paste.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Michael Biebl]

Am 12.07.2017 um 20:40 schrieb Roger Lynn:
> On 10/07/17 19:40, Marvin Renich wrote:
> 
> 
> 
>> There is an easy fix to revert the default behavior while still allowing
>> knowledgeable sysadmins to get the new behavior.  On the other hand,
>> those who need to administer systems but are not sysadmins by trade (and
>> thus will have to do significantly more research to even know that the
>> older behavior is possible) are the ones who need the older behavior as
>> the default.
> 
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

As mentioned elsewhere, such rules are unreliable indeed as they use the
same names as the kernel. You should a different namespace.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Naming of network devices - how to improve it in buster

[Michael Biebl]

Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
> 
> 
> On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  > wrote:
> 
> Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > My finger memory will still type tcpdump -i eth0 before the brain can
> > intervene ten years from now.
> 
> thankfully tcpdump (and lots of other tools) have nice shell completion.
> tcpdump -i  works great her.
> 
> 
> Agreed. However, I'd still rather deal with names like /dev/sda and eth0
> than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.
> 
> It is kind of like using people's first names as opposed to their Social
> Security Number (in US) or other form of national identification. I know
> when I can use the name Matt and I know who it refers to, even if
> another Matt enters the room. I'm comfortable with eth0 being the name,
> even when another interface appears.
> 
> I completely understand, and largely agree with, the need for persistent
> naming - but I think we are selling ourselves and our users short by not
> pressing harder for network interface aliases. It seems to be too useful
> of a solution for this problem.

Indeed, the best solution would be to never rename the interfaces and
simply create aliases / symlinks. Then again, I'm no kernel hacker so I
have no idea if that would be feasible.
I guess Ben is (one of) the most qualified to answer that.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Adam Borowski]

On Wed, Jul 12, 2017 at 07:40:13PM +0100, Roger Lynn wrote:
> On 10/07/17 19:40, Marvin Renich wrote:
> 
> 
> 
> > There is an easy fix to revert the default behavior while still allowing
> > knowledgeable sysadmins to get the new behavior.  On the other hand,
> > those who need to administer systems but are not sysadmins by trade (and
> > thus will have to do significantly more research to even know that the
> > older behavior is possible) are the ones who need the older behavior as
> > the default.
> 
> This caught me out on a recent new installation, which gave me these new
> names which are too complicated to be usable. I wasted hours working out
> what had happened, how to fix it and how to write a udev rules file from
> scratch. And having just read this thread, I've discovered that the rules
> I've written are themselves apparently unreliable, for example:
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:9a", NAME="eth1"

This worked fine on jessie, but on stretch it doesn't anymore.
I've solved the problem by net.ifnames=0; apparently the cause is rules
numbered 73..80 overwriting those set by 70-persistent-net.rules

You also shouldn't use eth0/eth1 because the races aren't fully solved;
using descriptive names like lan0/out0 has the extra benefit of marking
which interface is used for what purpose.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: Clearing the conffile status of a file

[Sven Joachim]

On 2017-07-12 09:56 +0200, Florian Weimer wrote:

> I've got a request to remove the conffile status of a file after it is
> no longer a conffile.  dpkg-maintscript-helper rm_conffile does not
> seem to do this, based on the documentation and the source code.
>
> Is there a clean way to implement this (i.e., by not patching
> /var/lib/dpkg/status directly)?

AFAIK the only method, and not a pretty one, that works from package
maintainer scripts is to rename the file in the preinst and rename it
back in the postinst.  Plus all the error handling required (e.g. if
unpacking fails), where dpkg-maintscript-helper would at least take care
of the gory details[1] for you.

> If there is a way, is there a reason not do it?

There is a time window between the preinst and the postinst where the
file is not available, which might be problematic.

My choice would probably be to leave the conffile alone, at least until
dpkg itself is able to take care of the problem[2].

Cheers,
   Sven


1. https://wiki.debian.org/DpkgConffileHandling
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822462

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Wed, 12 Jul 2017, Michael Biebl wrote:
> Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
> > On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  > > wrote:
> > 
> > Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > > My finger memory will still type tcpdump -i eth0 before the brain can
> > > intervene ten years from now.
> > 
> > thankfully tcpdump (and lots of other tools) have nice shell completion.
> > tcpdump -i  works great her.
> > 
> > 
> > Agreed. However, I'd still rather deal with names like /dev/sda and eth0
> > than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.
> > 
> > It is kind of like using people's first names as opposed to their Social
> > Security Number (in US) or other form of national identification. I know
> > when I can use the name Matt and I know who it refers to, even if
> > another Matt enters the room. I'm comfortable with eth0 being the name,
> > even when another interface appears.
> > 
> > I completely understand, and largely agree with, the need for persistent
> > naming - but I think we are selling ourselves and our users short by not
> > pressing harder for network interface aliases. It seems to be too useful
> > of a solution for this problem.
> 
> Indeed, the best solution would be to never rename the interfaces and
> simply create aliases / symlinks. Then again, I'm no kernel hacker so I
> have no idea if that would be feasible.

ip link set dev eth0 alias foo0

But don't expect everything to work right with this: it is the same
mechanism that was used for adding "extra IP addresses" when using
braindamaged crap from a decade ago (old ifconfig), so I very much bet
there are going to be stuff misbehaving...

The obvious thing would be to just tell the kernel to change namespaces
in the first place (kconfig + command line), and have userspace aware of
the kernel namespace using sysfs.  Just beware the kernel default would
be "unspecified" (and not "eth*", etc) because this is not central
policy in the kernel at all).  I have never understood why this wasn't
done, since it is absolutely trivial to implement, even if it is a lot
of busywork (you have to patch each !@#$ network driver).  But you could
clean up a _LOT_ of crap kernel side while at it, AND create both a
central point for naming this stuff AND better device grouping, so it
would be worth the trouble.  And it would be opt-in, default N, and
detectable from userspace, so that it would not regress anything not
prepared for it.

-- 
  Henrique Holschuh

Re: can't start GUI mode debian 9

[Ben Caradoc-Davies]

On 12/07/17 14:51, Agung Vega wrote:

Then what next? I want to use gui version
(I had sent an email about the same problem, before this one )


This email would be better sent to the debian-user mailing list. The 
debian-devel list is for the development of Debian. This is a user 
support question.


How did you install Debian 9? A minimal installation contains no GUI.

What desktop do you want? Log in as root and use the command-line tools 
to install the desktop you want. For example, to install XFCE and a 
full-featured suite of desktop applications:


apt-get update
apt-get install task-xfce-desktop

You can see the list here:
https://packages.debian.org/stretch/task-xfce-desktop

Restart your computer and you should be presented with a graphical 
login. The instructions are similar for other desktops including gnome, 
mate, cinnamon, lxde, and kde.


If you are on a laptop, you might also consider installing "task-laptop" 
for power management and wifi tools.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Clearing the conffile status of a file

[Florian Weimer]

* Sven Joachim:

> On 2017-07-12 09:56 +0200, Florian Weimer wrote:
>
>> I've got a request to remove the conffile status of a file after it is
>> no longer a conffile.  dpkg-maintscript-helper rm_conffile does not
>> seem to do this, based on the documentation and the source code.
>>
>> Is there a clean way to implement this (i.e., by not patching
>> /var/lib/dpkg/status directly)?
>
> AFAIK the only method, and not a pretty one, that works from package
> maintainer scripts is to rename the file in the preinst and rename it
> back in the postinst.  Plus all the error handling required (e.g. if
> unpacking fails), where dpkg-maintscript-helper would at least take care
> of the gory details[1] for you.

> 1. https://wiki.debian.org/DpkgConffileHandling

Oh, I assumed that this was only about preserving the file, and it
would not affect the state as a conffile as such (except that the file
would be gone).

> My choice would probably be to leave the conffile alone, at least until
> dpkg itself is able to take care of the problem[2].

> 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822462

That makes sense, thanks.

Re: Naming of network devices - how to improve it in buster

[Russell Stuart]

On Wed, 2017-07-12 at 17:35 +0200, Marc Haber wrote:
> I'd rather have breakage in this case than having to look for the
> interface every fscking time I need to run tcpdump, or having to
> adapt to an entirely new name schema like lanc0 and lanw0 to not
> stomp in the kernel's name space when using my own naming scheme.
> 
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

I still don't understand what use case the current scheme is aimed at.

It's not Network Manager users - they don't care about names.  I know
because I used Network Manager on my laptop.

It's not sysadmin's managing fleets of machines.  They need persistent
names, but you rapidly go insane if the lan NIC isn't named "lan0" or
something regardless of the machine your platform is running on.  So
you end up dropping your own customer files in /etc/udev/rules.d
anyway.  At least that's what I do.

It's not cli user who have plugged in a box and want to configure it
with the keyboard.  Anything attached to a PCI bus is usually
"persistent enough" because something hand crafted can also be hand
maintained if it does change.  As Marc says for devices whose names do
change en48e244f61c1b is not a sane solution. Even just having a
template file in /etc/udev/rules.d to jog the memory on how to assign a
persistent name is a better idea.

So who is the person who actually likes typing en48e244f61c1b?

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

Re: IMPORTANT: Do live Debian images have a future?

[Russell Stuart]

On Wed, 2017-07-12 at 21:00 +0530, shirish शिरीष wrote:
> On 12/07/2017, Fernando Toledo  wrote:
> > Our Use-case:
> > 
> > We develop a derivated distro from Debian called Huayra GNU/Linux,
> > this is for educational program of government in Argentina. This
> > big program ship around 5 millons of netbooks to highschool
> > students.
> 
> 
>
> In short, this alone use-case answers Steve's original question which
> was primarily are there any users who use or would use this tool or
> his time would be better spent somewhere else. I think just the above
> use-case and number of users answers the need for a tool like
> live-wrapper. As has been pointed out by me and others, it just needs
> more testing (documentation and love by devs.) to drive more usage
> forwards.

I do a similar thing, although not on quite that scale.

However I thought Steve's question was about maintaining particular
live images, not live-wrapper itself. I too would be very disappointed
to see live-wrapper go.

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