[DNG] hostname set to (none)

[aitor_czr]

Hi,

I built the minimal chroot jailgenerated by live-build in devuan, and
the hostname is set to none:

$ hostname
(none)

There aren't underscores in the /etc/hostname file, and the /etc/hosts
is also correct.It happened to me the same some other time starting with
sysvinit, but not with systemd.

Any idea? Thankyou in advance.

Aitor.

Note: I installed live-config-sysvinit, etc... and removed systemd.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Didier Kryn]

Le 15/08/2015 02:26, Steve Litt a écrit :

On Fri, 14 Aug 2015 14:49:17 -0700
Go Linux  wrote:


On Fri, 8/14/15, T.J. Duchene  wrote:

  Subject: Re: [DNG] Systemd Shims
  To: dng@lists.dyne.org
  Date: Friday, August 14, 2015, 2:47 PM
  

I know not everyone here agrees with me, especially Steve, and
that's perfectly okay.  I have no problem with that at all. I just
don't see "System 5 pure"  as realistic when planning ahead looking
at a maintenance standpoint when Debuan upstream is more and more
likely to stick with Systemd in designing their packaging.


Maybe we should just put Steve in charge of decontaminating all
packages with systemd deps!

Oh, you wouldn't want to do that. Contrary to what I wrote in another
thread about "the perfect is the enemy of the good", if *I* were in
charge of decontamination, I'd throw out whole subsystems. Gnome gone.
KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
systemd on us.

In the massive time I save as not being the bomb squad defusing Red
Hat's terrorism, I'd write small replacements for a lot of things that
use only Linux and a very rudimentary and optional GUI interface.

Then I'd write documentation explaining how to use a sharp thinking
computer, to the proud ignorants of the world, especially those who
believe their ignorance is a badge of honor proving their age or
gender.

And the people who prioritize pretty over functional and robust: I'd
tell them to get a Mac.

You don't want me in that capacity.

And yes, I *am* a hypocrit who takes one position in one thread, and
then says he'd do the opposite in another. :-)

SteveT




Please, Steve, provide us with all you mentionned, as an 
alternative to mainstream bloated/infected stuff. Since Devuan is all 
about freedom, this is the place where to deliver to the world. As soon 
as I can install Devuan on metal, I'll be one of your testers.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[aitor_czr]

Hi again,

Grub-install failed in gnuinos server (Alpha2). Apparently libfuse2 and
os-prober are not included in it. I will solve this issue during the day.


Thanks,

Aitor.

On Fri, 14 Aug 2015 23:52:56 +0200 aitor_czr wrote:

> Hi all,
>
> I'm uploading a live image of gnuinos in amd64 architecture (and shortly
> in i386) without desktop environment, taking Devuan Alpha2 as a base
> (~390 MB). Network connection and quick installation. Download zone:
>
> http://mirrors.gnuinos.org/?dir=DEVUAN-BASED%20IMAGES
>
> The web site is not updated, but this distribution will be definitely
> based on Devuan.
>
> Regards,
>
> Aitor.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[T.J. Duchene]

On Fri, 14 Aug 2015 22:38:35 -0700
Isaac Dunham  wrote:


> 
> To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11
> support.
> Packages using C++11 need to be rebuilt with the new library;
> libreoffice has already been rebuilt, but not KDE.

That's a very good point, Isaac.  C++11 is a very interesting revision,
although C++14 is technically the highest available standard. I'm never
a fan of rapidly changing standards, because they tend to be a mess,
poorly considered. I understand they plan another revision for 2017,
and I think they are nuts.


T.J.
 


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Isaac Dunham]

On Fri, Aug 14, 2015 at 02:42:14PM +0200, Adam Borowski wrote:
> On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote:
> > Seems to me there's something weird, both, in libreoffice depending on
> > just one single version of libstdc++, and in libklabxml being broken by this
> > version of libstdc++, be it the fault of kde or libstdc++ developpers.
> 
> That's the GCC-5 transition, unstable is broken as it's supposed to.  You
> can use testing if you're bothered by uninstallable packages (or any other
> form of the sky falling).

To elaborate on this, GCC 5.1 (I think) has changed the ABI for C++11
support.
Packages using C++11 need to be rebuilt with the new library; libreoffice
has already been rebuilt, but not KDE.

HTH,
Isaac
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[Isaac Dunham]

On Fri, Aug 14, 2015 at 07:01:11AM -0400, Haines Brown wrote:
> The aim is to boot to a console prompt, log in as root, install xorg and
> fluxbox. That gives me X and a window manager but no desktop
> environment. At present I get a log in prompt and can log in as user in
> console, but for some reason root log in not working. I suppose that
> when I provided a password I mistyped. 

At the grub menu, edit the kernel commandline to change
"root=... ro ..." to "root=... rw ... init=/bin/bash"

Then run "passwd", sync a couple times, and reboot.

HTH,
Isaac Dunham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[T.J. Duchene]

On Fri, 14 Aug 2015 20:26:58 -0400
Steve Litt  wrote:


> 
> Oh, you wouldn't want to do that. Contrary to what I wrote in another
> thread about "the perfect is the enemy of the good", if *I* were in
> charge of decontamination, I'd throw out whole subsystems. 


LOL! =) 

One thing I say with the utmost respect, Steve, is that you do
not dance around. I appreciate knowing exactly where you stand on
something.


> 
> And the people who prioritize pretty over functional and robust: I'd
> tell them to get a Mac.

I don't get where that fits in, but then to be perfectly honest, I do
not understand a great deal.  I do not see any reason for the present
day dichotomy in the software world.  Good software design embodies all
of those qualities.  Anything less is shoddy work, and I despise not
taking pride in the craft by making a real effort.

If I had to effort some kind of idea what happened, I would have to
blame the programmer, because they were disconnected from the process of
providing what the user needs.

> 
> And yes, I *am* a hypocrit who takes one position in one thread, and
> then says he'd do the opposite in another. :-)
> 
That's fine! =)  Blunt honesty goes a long way with someone like
myself. The only thing I ever ask from anyone is that even
disagreements remain civil.  DNG has had its moments, but I think
we have been handling that pretty well lately.  That is just my opinion,
of course.


Have a good night!
T.J.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Sat, Aug 15, 2015 at 03:21:47PM +1200, Daniel Reurich wrote:
> On 15/08/15 14:47, Hendrik Boom wrote:
> 
> >>
> >>Don't forget to do `update-initramfs -u -k all` and `update-grub` to
> >>rebuild the
> >
> >Ouch. update-initramfs crapped out:
> >
> >oot@notlookedfor:~# update-initramfs -u -k all
> >update-initramfs: Generating /boot/initrd.img-3.16.0-4-686-pae
> >mkinitramfs: failed to determine device for /usr
> >mkinitramfs: workaround is MODULES=most, check:
> >grep -r MODULES /etc/initramfs-tools/
> 
> so it failed to determine the path for /usr.
> 
> Double check your fstab uses either the new path and that the new
> path exists (if it's using UUID= for /usr it shouldn't need to be
> changed.
> 
> You may need to do a `mount -o remount /usr` so that your cat
> /proc/mounts matches /etc/fstab

mount -o remount /usr

doesn't help.  It seems to have figured out all by itself that / is now 
on 
/dev/mapper/jessie-devuan--root
but it still thinks /usr is on 
/dev/mapper/VG1-devuan--usr which no longer exists, even after the 
remount.

It's late at night here, and I'm tired.  (I suppose it's daytime in New 
Zealand) If no ideas show up overnight I'm going to try rebooting 
on the off chance that the message is merely precautionary, and if that 
doesn't work, I can simply reinstall.  It will be easier this time 
because now that I've already done it.

Still wondering why initramfs needs to know where /usr is.

> 
> >Another anomaly:
> >
> >I grepped for my new volume group in /boot/grub/grub.cfg, and the third
> >"linux" line it produced was:
> >
> >linux/vmlinuz-3.16.0-4-686-pae root=/dev/mapper/jessie-devuan--root
> >ro  quiet init=/lib/systemd/systemd
> >
> >The others did not mention systemd.
> >
> >THen I noticed that /lib/systemd/ is a fully populated  directory, with
> >lots of systemd stuff in it.  Surprise!  To be investigated another day.
> 
> That looks like you've got systemd-sysv installed - what do you have
> for PID1?

4 S 0 1 0  0  80   0 -   810 poll_s ?00:00:01 init

Some program called init.  There is an /sbin/init, but I have no proof 
that it is indeed that one.

There's also a process running systemd-logind but the name may have been 
trunctated.  Could it have come in with xfce?  or whatever display 
manager Devuan uses?

I thought, in my innocence, that devuan might have avoided systemd.  I 
guess we're not all the way there yet.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Fri, Aug 14, 2015 at 10:21:33PM -0400, fsmithred wrote:
> If you just need to transfer the data to the new installation, attach the
> external drive to a different machine and rsync it. Boot with live media
> if you have the same problem on the other machine.
> 
> fsr

I thonk I might have been able to do that from an Ubuntu machine I have 
lying around.   Except that I already started changing the volume group 
name and now have to see it through or reinstall.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[fsmithred]

If you just need to transfer the data to the new installation, attach the
external drive to a different machine and rsync it. Boot with live media
if you have the same problem on the other machine.

fsr


On 08/14/2015 09:13 PM, Hendrik Boom wrote:
> On Sat, Aug 15, 2015 at 12:41:06PM +1200, Daniel Reurich wrote:
>> On 15/08/15 12:24, Hendrik Boom wrote:
>>> I tried plugging a external hard drive into my newly installed Devuan
>>> system, and  immediately ran into a problem:  It seems the volume group
>>> name used on that drive is the same as the one on my devuan system.
>>> Not that surprising; thee external drive contains the Debian system I'm
>>> migrating away from.
>>>
>>> lvdisplay tells me:
>>>
>>> root@notlookedfor:~# lvdisplay
>>>   WARNING: Duplicate VG name VG1: Existing
>>> zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
>>> over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
>>>   WARNING: Duplicate VG name VG1: Existing
>>> P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH (created here) takes precedence
>>> over zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV
>>>   WARNING: Duplicate VG name VG1: Existing
>>> zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
>>> over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
>>>
>>>
>>> How do I go about mounting its LVM partitions without screing everything
>>> up?  Can I just ignore the name conflict and mount by UUID?  And are the
>>> UUIDs in the error message the ones I need for this?
>>
>>>
>>> Or is there some way to rename VG1 to something else?  Some way that
>>> will take care of all the corner cases?  There's a command vgimportclone
>>> that seems to be for this, but ... it says it also changes the UUID's,
>>> which are *not* duplicates, and it just might be that another use of
>>> this external disk might rely on those particulat UUIDs.
>>
>> vgrename supports identifying the volumegroup by UUID - so try:
>> vgrename  
> 
> I'll have to be careful with that -- the lvdisplay message suggests that 
> it has assigned new UUID's for that VG1 at least three times.  Does 
> that mean the disk has been rewritten?  Or does LVM lie to itself as a 
> kludge to prevent catastrophe?
> 
>>
>> If your changing the old vg and not booting it again, then fine, but
>> if you want to change either the running systems VG name (or keep
>> the old system bootable) you'll need to fix the relevant fstab and
>> grub(2) configuration to match the changes.
> 
> Yes.  I hope that's all.
> 
> It may ne simples to rename the VG1 in the devuan system -- if something 
> goes wrong, I don't yet have enough effort invested to make a fresh 
> install problematic.
> 
>>>
>>> It's just possible that the LVM partition names will also have a
>>> conflict.
>>
>> shouldn't be a problem once you fix the volume group name conflict.
> 
> Yes, their full names do end up containing the VG name, don't they?
> 
>>
>> Cheers,
>>  Daniel.
> 
> Thank you.  You've been very helpful.
> 
>>
>> -- 
>> Daniel Reurich
>> Centurion Computer Technology (2005) Ltd.
>> 021 797 722
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Sat, Aug 15, 2015 at 02:15:35PM +1200, Daniel Reurich wrote:
> On 15/08/15 14:11, Hendrik Boom wrote:
> >Easy enough to edit /boot/grub/grub.cfg.
> >Or do I really have to edit other files that this is made from?  I
> >remember there was some complication there with Debian's grub2.
> >
> /etc/default/grub is the file you need to edit followed by running
> 'update-grub'

It doesn't mention VG1 either, so I suppose it's clean.
I don't plan on changing any UUIDs.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Fri, Aug 14, 2015 at 10:11:46PM -0400, Hendrik Boom wrote:
> On Sat, Aug 15, 2015 at 01:22:42PM +1200, Daniel Reurich wrote:
> > On 15/08/15 13:13, Hendrik Boom wrote:
> > >On Sat, Aug 15, 2015 at 12:41:06PM +1200, Daniel Reurich wrote:
> > >>On 15/08/15 12:24, Hendrik Boom wrote:
> > >>>I tried plugging a external hard drive into my newly installed Devuan
> > >>>system, and  immediately ran into a problem:  It seems the volume group
> > >>>name used on that drive is the same as the one on my devuan system.
> > >>>Not that surprising; thee external drive contains the Debian system I'm
> > >>>migrating away from.
> > >>>
> > >>>lvdisplay tells me:
> > >>>
> > >>>root@notlookedfor:~# lvdisplay
> > >>>   WARNING: Duplicate VG name VG1: Existing
> > >>>zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> > >>>over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> > >>>   WARNING: Duplicate VG name VG1: Existing
> > >>>P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH (created here) takes precedence
> > >>>over zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV
> > >>>   WARNING: Duplicate VG name VG1: Existing
> > >>>zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> > >>>over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> > >>>
> > >>>
> > >>>How do I go about mounting its LVM partitions without screing everything
> > >>>up?  Can I just ignore the name conflict and mount by UUID?  And are the
> > >>>UUIDs in the error message the ones I need for this?
> > >>
> > >>>
> > >>>Or is there some way to rename VG1 to something else?  Some way that
> > >>>will take care of all the corner cases?  There's a command vgimportclone
> > >>>that seems to be for this, but ... it says it also changes the UUID's,
> > >>>which are *not* duplicates, and it just might be that another use of
> > >>>this external disk might rely on those particulat UUIDs.
> > >>
> > >>vgrename supports identifying the volumegroup by UUID - so try:
> > >>vgrename  
> > >
> > >I'll have to be careful with that -- the lvdisplay message suggests that
> > >it has assigned new UUID's for that VG1 at least three times.  Does
> > >that mean the disk has been rewritten?  Or does LVM lie to itself as a
> > >kludge to prevent catastrophe?
> > 
> > Use vgdisplay and pvdisplay to determine which UUID belongs to which
> > system/disk
> > >
> > >>
> > >>If your changing the old vg and not booting it again, then fine, but
> > >>if you want to change either the running systems VG name (or keep
> > >>the old system bootable) you'll need to fix the relevant fstab and
> > >>grub(2) configuration to match the changes.
> 
> Easy enough to edit /boot/grub/grub.cfg.
> Or do I really have to edit other files that this is made from?  I 
> remember there was some complication there with Debian's grub2.

That would presumably be the files in /etc/grub.d

They happen not to contain any VG1's, so the VG1 must come fro somewhere else.

> 
> > >
> > >Yes.  I hope that's all.
> > 
> > Don't forget to do `update-initramfs -u -k all` and `update-grub` to
> > rebuild the
> > >
> > >It may ne simples to rename the VG1 in the devuan system -- if something
> > >goes wrong, I don't yet have enough effort invested to make a fresh
> > >install problematic.
> > >
> > If you do that you shouldn't have too much trouble as Devuan should
> > be using the UUID's of the logical volumes anyway.
> > >>>
> > >>>It's just possible that the LVM partition names will also have a
> > >>>conflict.
> > >>
> > >>shouldn't be a problem once you fix the volume group name conflict.
> > >
> > >Yes, their full names do end up containing the VG name, don't they?
> > 
> > Yup
> > >>
> > >>Cheers,
> > >>  Daniel.
> > >
> > >Thank you.  You've been very helpful.
> > >
> > Your welcome - all part of the service.
> > 
> > Cheers, 
> > Daniel
> > -- 
> > Daniel Reurich
> > Centurion Computer Technology (2005) Ltd.
> > 021 797 722
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Daniel Reurich]

On 15/08/15 14:11, Hendrik Boom wrote:

Easy enough to edit /boot/grub/grub.cfg.
Or do I really have to edit other files that this is made from?  I
remember there was some complication there with Debian's grub2.

/etc/default/grub is the file you need to edit followed by running 
'update-grub'


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Sat, Aug 15, 2015 at 01:22:42PM +1200, Daniel Reurich wrote:
> On 15/08/15 13:13, Hendrik Boom wrote:
> >On Sat, Aug 15, 2015 at 12:41:06PM +1200, Daniel Reurich wrote:
> >>On 15/08/15 12:24, Hendrik Boom wrote:
> >>>I tried plugging a external hard drive into my newly installed Devuan
> >>>system, and  immediately ran into a problem:  It seems the volume group
> >>>name used on that drive is the same as the one on my devuan system.
> >>>Not that surprising; thee external drive contains the Debian system I'm
> >>>migrating away from.
> >>>
> >>>lvdisplay tells me:
> >>>
> >>>root@notlookedfor:~# lvdisplay
> >>>   WARNING: Duplicate VG name VG1: Existing
> >>>zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> >>>over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> >>>   WARNING: Duplicate VG name VG1: Existing
> >>>P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH (created here) takes precedence
> >>>over zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV
> >>>   WARNING: Duplicate VG name VG1: Existing
> >>>zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> >>>over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> >>>
> >>>
> >>>How do I go about mounting its LVM partitions without screing everything
> >>>up?  Can I just ignore the name conflict and mount by UUID?  And are the
> >>>UUIDs in the error message the ones I need for this?
> >>
> >>>
> >>>Or is there some way to rename VG1 to something else?  Some way that
> >>>will take care of all the corner cases?  There's a command vgimportclone
> >>>that seems to be for this, but ... it says it also changes the UUID's,
> >>>which are *not* duplicates, and it just might be that another use of
> >>>this external disk might rely on those particulat UUIDs.
> >>
> >>vgrename supports identifying the volumegroup by UUID - so try:
> >>vgrename  
> >
> >I'll have to be careful with that -- the lvdisplay message suggests that
> >it has assigned new UUID's for that VG1 at least three times.  Does
> >that mean the disk has been rewritten?  Or does LVM lie to itself as a
> >kludge to prevent catastrophe?
> 
> Use vgdisplay and pvdisplay to determine which UUID belongs to which
> system/disk
> >
> >>
> >>If your changing the old vg and not booting it again, then fine, but
> >>if you want to change either the running systems VG name (or keep
> >>the old system bootable) you'll need to fix the relevant fstab and
> >>grub(2) configuration to match the changes.

Easy enough to edit /boot/grub/grub.cfg.
Or do I really have to edit other files that this is made from?  I 
remember there was some complication there with Debian's grub2.

> >
> >Yes.  I hope that's all.
> 
> Don't forget to do `update-initramfs -u -k all` and `update-grub` to
> rebuild the
> >
> >It may ne simples to rename the VG1 in the devuan system -- if something
> >goes wrong, I don't yet have enough effort invested to make a fresh
> >install problematic.
> >
> If you do that you shouldn't have too much trouble as Devuan should
> be using the UUID's of the logical volumes anyway.
> >>>
> >>>It's just possible that the LVM partition names will also have a
> >>>conflict.
> >>
> >>shouldn't be a problem once you fix the volume group name conflict.
> >
> >Yes, their full names do end up containing the VG name, don't they?
> 
> Yup
> >>
> >>Cheers,
> >>Daniel.
> >
> >Thank you.  You've been very helpful.
> >
> Your welcome - all part of the service.
> 
> Cheers,   
>   Daniel
> -- 
> Daniel Reurich
> Centurion Computer Technology (2005) Ltd.
> 021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Stupid LVM conflict

[Hendrik Boom]

On Sat, Aug 15, 2015 at 12:41:06PM +1200, Daniel Reurich wrote:
> On 15/08/15 12:24, Hendrik Boom wrote:
> >I tried plugging a external hard drive into my newly installed Devuan
> >system, and  immediately ran into a problem:  It seems the volume group
> >name used on that drive is the same as the one on my devuan system.
> >Not that surprising; thee external drive contains the Debian system I'm
> >migrating away from.
> >
> >lvdisplay tells me:
> >
> >root@notlookedfor:~# lvdisplay
> >   WARNING: Duplicate VG name VG1: Existing
> >zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> >over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> >   WARNING: Duplicate VG name VG1: Existing
> >P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH (created here) takes precedence
> >over zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV
> >   WARNING: Duplicate VG name VG1: Existing
> >zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence
> >over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
> >
> >
> >How do I go about mounting its LVM partitions without screing everything
> >up?  Can I just ignore the name conflict and mount by UUID?  And are the
> >UUIDs in the error message the ones I need for this?
> 
> >
> >Or is there some way to rename VG1 to something else?  Some way that
> >will take care of all the corner cases?  There's a command vgimportclone
> >that seems to be for this, but ... it says it also changes the UUID's,
> >which are *not* duplicates, and it just might be that another use of
> >this external disk might rely on those particulat UUIDs.
> 
> vgrename supports identifying the volumegroup by UUID - so try:
> vgrename  

I'll have to be careful with that -- the lvdisplay message suggests that 
it has assigned new UUID's for that VG1 at least three times.  Does 
that mean the disk has been rewritten?  Or does LVM lie to itself as a 
kludge to prevent catastrophe?

> 
> If your changing the old vg and not booting it again, then fine, but
> if you want to change either the running systems VG name (or keep
> the old system bootable) you'll need to fix the relevant fstab and
> grub(2) configuration to match the changes.

Yes.  I hope that's all.

It may ne simples to rename the VG1 in the devuan system -- if something 
goes wrong, I don't yet have enough effort invested to make a fresh 
install problematic.

> >
> >It's just possible that the LVM partition names will also have a
> >conflict.
> 
> shouldn't be a problem once you fix the volume group name conflict.

Yes, their full names do end up containing the VG name, don't they?

> 
> Cheers,
>   Daniel.

Thank you.  You've been very helpful.

> 
> -- 
> Daniel Reurich
> Centurion Computer Technology (2005) Ltd.
> 021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Unstalled from alpha2 installer on bare machine

[Hendrik Boom]

On Sat, Aug 15, 2015 at 12:28:39PM +1200, Daniel Reurich wrote:
> On 15/08/15 12:05, Hendrik Boom wrote:
> >I installed from alpha2, and it mostly worked.
> >Devuan boots up properly, and runs.  I'm currently ssh-ed in to another
> >machine where I have my email, accessible via mutt.
> 
> Thanks for the report.  Was it a standard install or expert-mode and
> was it Jessie, Ascii or Ceres?

An expert-install.  I am somewhat particular about the partitioning, and 
didn't know whether a standard install would give me the options I 
wanted.

And Jessie.  I love that Jessie and Ascii are planetoid names!

> >
> >There were a few glitches:
> >
> >(1) it still offered to install the system on my installer USB stick.
> >I wasn't stupid enough to fall for this ruse, and specified my hard
> >drive.
> 
> That's odd.  I hadn't noticed that... could be a hardware specific issue.

I do remember that if was discussed on either this or the Debian boot 
mailing list some time ago.  I thought it had been fixed long ago.

> >
> >(2) Going through the steps one by one, I got to setting up MD devices.
> >I made the mistake of asking it to do this.  I had no MD devices on this
> >machine, so I expected it just to moce on to the next step, after
> >possibly dong some internal overhead to tell it this had been done.
> >
> >Instead, the screen went blank and stayed that way for a long time (at
> >least ten minutes).  For a while the disk light on my laptop blinked,
> >then even taht stopped.  I eventually used ctl-alt-F2 to get a console,
> >but a few commands there (such as ps) left me no wiser.  I went back to
> >ctl-alt-F1, and after a long hesitation, did control-C.
> >
> >I recovered control, and once again was aat the set up MD devices
> >step.  I bypassed it and went on to the next step.
> 
> That's really weird behaviour.

Yes.  if I ever install this system again, I'll make sure to sskip this 
step.

> >
> >(3) The 'configure the package manager' step worked, but the text on
> >that page refers to Debian, not Devuan.
> 
> Known issue

Not serious for now, anyway.

> >
> >(4) popcon:  The text says it sends popularity stats to
> >http://popcon.debian.org.  Now perhaps devuan does not have a popcon
> >server set up yet.  In any case, I bypassed this step, lest I
> >contaminate Debian's statistics.  Was that the righht thing to do?
> >
> I like contaminating Debians popcon stats... I occasionally check
> their popcon for the devuan-keyring package as a guage for how many
> Devuan installs have been done :-)

Ah!  Fun.

How would Debian feel about this, I wonder.  popcon seems to handle 
packages that aren't in Debian!

> 
> >(5) The select and install software step told me it would take about an
> >hour.  I went away and did other things, such as laundry.  When I came
> >back to the laptop I was faces with the message that this step had
> >failed, and that I could either skip this step or retry it.
> >
> >I retried it and this time it succeeded.
> >
> >What might th eprooble have been?  Network congestion?  Weird package
> >dependencies?  I have no idea.
> 
> Most likely a dependency loop that was solved in the second pass.

There's probably no way to track it sown at this stage.  Or is there a 
installation log somewhere?

> >
> >(6) When it came time to install grub, it told me that my machine 
does
> >an EFI boot.  That was a surprise to me.  It is an ancient XP laptop,
> >and I just replaced its hard disk with a new, empty one before the
> >install (this no WIndows).  I did let it install an EFI bootloader on a
> >USB stick (my installlation USB stick, as it happened) and it did
> >something.
> >
> It should only do that if the machine booted the installer from EFI
> in the first place.

Strange.  I've never changed the boot method, and it always booted XP 
fine, with an MBR-style partition table.  I could partition the old 
system with Linux's fdisk, and fdisk suffices to show me the partition 
table, without complaint.

fdisk even tells me that:

Partition 2 does not start on physical sector boundary.

That's the extended partition that cotains everything Linux.  There's a 
40G partition in frint if it that may some day contain a coopy of my old 
WIndows XP, in case I discover I still need it.
> 
> >But the machine booted properly without using the stick.
> OK.  That's good.
> >
> >The machine is an Asus EEEPC 1000He, the first of the EEEPC's that did
> >not need any proprietary Linux drivers, and the first that came with
> >Windows installed instead of Linux.
> >
> Nice.  How does it perform.

Well enough for everyday non-game use.  It doesn't have a really fast 
video chip, and flash videos have aleays been the pits.  But the new 
HTML5 video is OK, and s=things like VLC perform adequately for video.
They didn't when the machine was new, but things have beenn getting 
faster and faster as the years passed.

> 
> >I installed from the devuan-jessie-netboot-i386-alpha2.iso
> >
> >-- hendrik
> 
> Thanks for the report H

Re: [DNG] Devuan and upstream

[James Powell]

I respectfully disagree.

A single package would require a new build script, but equally it will pay for 
itself in the long run by reducing the overall workload to maintain each 
package.

The short term, yes its work. It will be. But why not have one single 
SDL2-2.0.0-x86_64-1.deb package that is sustainable in the long term?

I don't want to debate long term versus short term, but at the current rate, 
Devuan will be sustainable, but for how long with such a small team?

From: Hendrik Boom
Sent: ‎8/‎14/‎2015 5:33 PM
To: dng@lists.dyne.org
Subject: Re: [DNG] Devuan and upstream

On Fri, Aug 14, 2015 at 05:19:25PM -0700, James Powell wrote:
> Slackware is maintained by 3 core people with extra help as needed. The rest 
> of the packages are pushed by the community at large contributing. Devuan 
> doesn't have to maintain every package possible. That's ludicrous to think so.
>
> Debian got in over its head by allowing this. Thousands upon thousands of 
> packages that required a committee to oversee.
>
> Honestly, what is needed by a distribution? Look at Slackware or BLFS that's 
> a lot of packages, but it's manageable by a small team. Why can't Devuan 
> follow suit? There doesn't need to be a bagillion packages maintained by the 
> main devs. If the rest need to be passed back to the community at large, then 
> do it. This also hits the point of why do we need 5 different for things 
> like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? 
> One package is easier to maintain than five individual ones. It lightens the 
> load significantly, especially for the poor soul having to make 5 or more 
> different scripts for 5 packages from the same source tarball. Yes, it's nice 
> to have small packages for embedded stuff and small disks, but do you really 
> want to raise the workload of the maintainer that much?

It would also be folly to increase the maintainers load by naing him
reunite those multiple binary packages that are prooduced from one
source package.  We don't have the manpower for that economy!

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Hendrik Boom]

On Fri, Aug 14, 2015 at 05:19:25PM -0700, James Powell wrote:
> Slackware is maintained by 3 core people with extra help as needed. The rest 
> of the packages are pushed by the community at large contributing. Devuan 
> doesn't have to maintain every package possible. That's ludicrous to think so.
> 
> Debian got in over its head by allowing this. Thousands upon thousands of 
> packages that required a committee to oversee.
> 
> Honestly, what is needed by a distribution? Look at Slackware or BLFS that's 
> a lot of packages, but it's manageable by a small team. Why can't Devuan 
> follow suit? There doesn't need to be a bagillion packages maintained by the 
> main devs. If the rest need to be passed back to the community at large, then 
> do it. This also hits the point of why do we need 5 different for things 
> like, for example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? 
> One package is easier to maintain than five individual ones. It lightens the 
> load significantly, especially for the poor soul having to make 5 or more 
> different scripts for 5 packages from the same source tarball. Yes, it's nice 
> to have small packages for embedded stuff and small disks, but do you really 
> want to raise the workload of the maintainer that much?

It would also be folly to increase the maintainers load by naing him 
reunite those multiple binary packages that are prooduced from one 
source package.  We don't have the manpower for that economy!

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Unstalled from alpha2 installer on bare machine

[Daniel Reurich]

On 15/08/15 12:05, Hendrik Boom wrote:

I installed from alpha2, and it mostly worked.
Devuan boots up properly, and runs.  I'm currently ssh-ed in to another
machine where I have my email, accessible via mutt.


Thanks for the report.  Was it a standard install or expert-mode and was 
it Jessie, Ascii or Ceres?


There were a few glitches:

(1) it still offered to install the system on my installer USB stick.
I wasn't stupid enough to fall for this ruse, and specified my hard
drive.


That's odd.  I hadn't noticed that... could be a hardware specific issue.


(2) Going through the steps one by one, I got to setting up MD devices.
I made the mistake of asking it to do this.  I had no MD devices on this
machine, so I expected it just to moce on to the next step, after
possibly dong some internal overhead to tell it this had been done.

Instead, the screen went blank and stayed that way for a long time (at
least ten minutes).  For a while the disk light on my laptop blinked,
then even taht stopped.  I eventually used ctl-alt-F2 to get a console,
but a few commands there (such as ps) left me no wiser.  I went back to
ctl-alt-F1, and after a long hesitation, did control-C.

I recovered control, and once again was aat the set up MD devices
step.  I bypassed it and went on to the next step.


That's really weird behaviour.


(3) The 'configure the package manager' step worked, but the text on
that page refers to Debian, not Devuan.


Known issue


(4) popcon:  The text says it sends popularity stats to
http://popcon.debian.org.  Now perhaps devuan does not have a popcon
server set up yet.  In any case, I bypassed this step, lest I
contaminate Debian's statistics.  Was that the righht thing to do?

I like contaminating Debians popcon stats... I occasionally check their 
popcon for the devuan-keyring package as a guage for how many Devuan 
installs have been done :-)




(5) The select and install software step told me it would take about an
hour.  I went away and did other things, such as laundry.  When I came
back to the laptop I was faces with the message that this step had
failed, and that I could either skip this step or retry it.

I retried it and this time it succeeded.

What might th eprooble have been?  Network congestion?  Weird package
dependencies?  I have no idea.


Most likely a dependency loop that was solved in the second pass.


(6) When it came time to install grup, it told me that my machine does
an EFI boot.  That was a surprise to me.  It is an ancient XP laptop,
and I just replaced its hard disk with a new, empty one before the
install (this no WIndows).  I did let it install an EFI bootloader on a
USB stick (my installlation USB stick, as it happened) and it did
something.

It should only do that if the machine booted the installer from EFI in 
the first place.



But the machine booted properly without using the stick.

OK.  That's good.


The machine is an Asus EEEPC 1000He, the first of the EEEPC's that did
not need any proprietary Linux drivers, and the first that came with
Windows installed instead of Linux.


Nice.  How does it perform.


I installed from the devuan-jessie-netboot-i386-alpha2.iso

-- hendrik


Thanks for the report Hendrik

--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Steve Litt]

On Fri, 14 Aug 2015 14:49:17 -0700
Go Linux  wrote:

> On Fri, 8/14/15, T.J. Duchene  wrote:
> 
>  Subject: Re: [DNG] Systemd Shims
>  To: dng@lists.dyne.org
>  Date: Friday, August 14, 2015, 2:47 PM
>  
> > I know not everyone here agrees with me, especially Steve, and
> > that's perfectly okay.  I have no problem with that at all. I just
> > don't see "System 5 pure"  as realistic when planning ahead looking
> > at a maintenance standpoint when Debuan upstream is more and more
> > likely to stick with Systemd in designing their packaging.
> > 
> 
> Maybe we should just put Steve in charge of decontaminating all
> packages with systemd deps!

Oh, you wouldn't want to do that. Contrary to what I wrote in another
thread about "the perfect is the enemy of the good", if *I* were in
charge of decontamination, I'd throw out whole subsystems. Gnome gone.
KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all
systemd on us.

In the massive time I save as not being the bomb squad defusing Red
Hat's terrorism, I'd write small replacements for a lot of things that
use only Linux and a very rudimentary and optional GUI interface.

Then I'd write documentation explaining how to use a sharp thinking
computer, to the proud ignorants of the world, especially those who
believe their ignorance is a badge of honor proving their age or
gender.

And the people who prioritize pretty over functional and robust: I'd
tell them to get a Mac.

You don't want me in that capacity.

And yes, I *am* a hypocrit who takes one position in one thread, and
then says he'd do the opposite in another. :-)

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Stupid LVM conflict

[Hendrik Boom]

I tried plugging a external hard drive into my newly installed Devuan 
system, and  immediately ran into a problem:  It seems the volume group 
name used on that drive is the same as the one on my devuan system.
Not that surprising; thee external drive contains the Debian system I'm  
migrating away from.

lvdisplay tells me:

root@notlookedfor:~# lvdisplay
  WARNING: Duplicate VG name VG1: Existing 
zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence 
over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH
  WARNING: Duplicate VG name VG1: Existing 
P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH (created here) takes precedence 
over zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV
  WARNING: Duplicate VG name VG1: Existing 
zXs7iy-ukO4-ecrC-B1ag-wQkA-6L4K-YKyKRV (created here) takes precedence 
over P4Ggic-hQS6-b82V-zUj6-a0eu-dA3z-5mIkOH


How do I go about mounting its LVM partitions without screing everything 
up?  Can I just ignore the name conflict and mount by UUID?  And are the 
UUIDs in the error message the ones I need for this?

Or is there some way to rename VG1 to something else?  Some way that 
will take care of all the corner cases?  There's a command vgimportclone  
that seems to be for this, but ... it says it also changes the UUID's, 
which are *not* duplicates, and it just might be that another use of 
this external disk might rely on those particulat UUIDs.

It's just possible that the LVM partition names will also have a 
conflict.

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[James Powell]

Slackware is maintained by 3 core people with extra help as needed. The rest of 
the packages are pushed by the community at large contributing. Devuan doesn't 
have to maintain every package possible. That's ludicrous to think so.

Debian got in over its head by allowing this. Thousands upon thousands of 
packages that required a committee to oversee.

Honestly, what is needed by a distribution? Look at Slackware or BLFS that's a 
lot of packages, but it's manageable by a small team. Why can't Devuan follow 
suit? There doesn't need to be a bagillion packages maintained by the main 
devs. If the rest need to be passed back to the community at large, then do it. 
This also hits the point of why do we need 5 different for things like, for 
example, SDL packages for -bin, -lib, -doc, -dev, -src, and such? One package 
is easier to maintain than five individual ones. It lightens the load 
significantly, especially for the poor soul having to make 5 or more different 
scripts for 5 packages from the same source tarball. Yes, it's nice to have 
small packages for embedded stuff and small disks, but do you really want to 
raise the workload of the maintainer that much?

-Jim

From: Stephanie Daugherty
Sent: ‎8/‎14/‎2015 6:21 AM
To: T.J. Duchene; 
dng@lists.dyne.org
Subject: Re: [DNG] Devuan and upstream

On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene  wrote:

>
> 1.  You can't mark a package as "Do not install."  APT simply does not give
> you the option.
>
> Heaven knows, there are a lot of people who dislike things like network-
> manager, and do not them to install for any reason.
>
> Someone might say - wait you can put a hold on packages.  That's true, but
> that does not stop packages from being installed. It only says which
> version
> is preferred.  There is no option for "none".
>
> You can block packages with APT pinning, but using pinning is very
> esoteric.
>
> There's a less obvious, but more reliable solution that holding or
pinning., and that is the dummy package. equivs makes this pretty easy to
create - you simply need a package marked that conflicts with the undesired
software, or if you prefer, one which tells the system that package is
already installed, so that you can ignore the dependency at your own risk
and without any pestering from apt. .



> 2. Whenever an update has bug, you cannot rollback to the previous version
> of
> the package.  It is always assumed that the latest version is correct.  In
> the
> real world, we know that is not always true.
>

Sure you can, just not with apt. dpkg is still the actual package manager,
and will happily install older versions for you, so long as you take care
of the dependencies on your own. In many cases the previous packages are
still sitting around in apt's download directory, but if not, they can
usually still be found in the archives.

Besides, unless you follow unstable, this doesn't happen often enough to be
a serious concern, because of Debian's rigid "no functionality changes in
stable, only fixes" policy.

The situation in both of these cases should be better, but arguably, if
it's a direction Devuan decides to go in, it would be best to do so as
extensions to apt rather than reinventing the wheel, so as to keep as much
compatibility with Debian as possible and continue to use Debian as
upstream whenever possible.

Without Debian as an upstream, the task of maintaining Devuan even at
parity with Debian would be all but impossible for the small team of
maintainers and developers currently part of Devuan. Unless a very large
portion of the Debian community jumps ship, and Devuan becomes the base of
Debian rather than the other way around, I think this will have to continue
for the foreseeable future.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Steve Litt]

On Fri, 14 Aug 2015 20:03:49 +0200
Teodoro Santoni  wrote:


> It's true, that's a waste, although very small, to add an if
> structure. Remains a weak argument: not being clamav a Go project, it
> has for sure a badly optimized, on the buiding side, codebase, so a
> config macro and an #ifdef SYSTEMD_EXISTS around the call surely
> doesn't waste anything valuable.

:s/EXISTS/INFESTS/

/* Litt ducks and runs */
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Unstalled from alpha2 installer on bare machine

[Hendrik Boom]

I installed from alpha2, and it mostly worked.
Devuan boots up properly, and runs.  I'm currently ssh-ed in to another 
machine where I have my email, accessible via mutt.

There were a few glitches:

(1) it still offered to install the system on my installer USB stick.
I wasn't stupid enough to fall for this ruse, and specified my hard 
drive.

(2) Going through the steps one by one, I got to setting up MD devices.
I made the mistake of asking it to do this.  I had no MD devices on this 
machine, so I expected it just to moce on to the next step, after 
possibly dong some internal overhead to tell it this had been done.

Instead, the screen went blank and stayed that way for a long time (at 
least ten minutes).  For a while the disk light on my laptop blinked, 
then even taht stopped.  I eventually used ctl-alt-F2 to get a console, 
but a few commands there (such as ps) left me no wiser.  I went back to 
ctl-alt-F1, and after a long hesitation, did control-C.

I recovered control, and once again was aat the set up MD devices 
step.  I bypassed it and went on to the next step.

(3) The 'configure the package manager' step worked, but the text on 
that page refers to Debian, not Devuan.

(4) popcon:  The text says it sends popularity stats to 
http://popcon.debian.org.  Now perhaps devuan does not have a popcon 
server set up yet.  In any case, I bypassed this step, lest I 
contaminate Debian's statistics.  Was that the righht thing to do?

(5) The select and install software step told me it would take about an 
hour.  I went away and did other things, such as laundry.  When I came 
back to the laptop I was faces with the message that this step had 
failed, and that I could either skip this step or retry it.

I retried it and this time it succeeded.

What might th eprooble have been?  Network congestion?  Weird package 
dependencies?  I have no idea.

(6) When it came time to install grup, it told me that my machine does 
an EFI boot.  That was a surprise to me.  It is an ancient XP laptop, 
and I just replaced its hard disk with a new, empty one before the 
install (this no WIndows).  I did let it install an EFI bootloader on a 
USB stick (my installlation USB stick, as it happened) and it did 
something.

But the machine booted properly without using the stick.

The machine is an Asus EEEPC 1000He, the first of the EEEPC's that did 
not need any proprietary Linux drivers, and the first that came with 
Windows installed instead of Linux.

I installed from the devuan-jessie-netboot-i386-alpha2.iso

-- hendrik


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Dng Digest, Vol 11, Issue 46

[aitor_czr]

Hi all,

I'm uploading a live image of gnuinos in amd64 architecture (and shortly
in i386) without desktop environment, taking Devuan Alpha2 as a base
(~390 MB). Network connection and quick installation. Download zone:

http://mirrors.gnuinos.org/?dir=DEVUAN-BASED%20IMAGES

The web site is not updated, but this distribution will be definitely
based on Devuan.

Regards,

Aitor.

El 14/08/15 a las 22:16, dng-requ...@lists.dyne.org escribió:
> Message: 1
> Date: Fri, 14 Aug 2015 13:27:49 -0400
> From: Steve Litt 
> To: dng@lists.dyne.org
> Subject: Re: [DNG] Alpha2 without desktop environment
> Message-ID: <20150814132749.5da7a...@mydesq2.domain.cxm>
> Content-Type: text/plain; charset=US-ASCII
>
> On Fri, 14 Aug 2015 07:01:11 -0400
> Haines Brown  wrote:
>
>
>>> > > Rereading your original post: Do you want to not have a Display
>>> > > Manager such as lightdm, kdm, gdm etc, or do you want your computer
>>> > > not to have X at all? If the latter, just deinstall X. If the
>>> > > former, you need to find your display manager, based on ps axjf.
>> > 
>> > The aim is to boot to a console prompt, log in as root, install xorg
>> > and fluxbox. That gives me X and a window manager but no desktop
>> > environment. 
> What you describe above is *precisely* how I want things to go. Your
> box and my desktop are the same except I use Openbox instead of
> fluxbox. I love startx so much my wife is getting jealous.
>
>> > At present I get a log in prompt and can log in as user
>> > in console, but for some reason root log in not working. I suppose
>> > that when I provided a password I mistyped. 
> :-) If this were Ubuntu, I'd tell you to do sudo su -
>
>> > 
>>> > > Anyway, luckily for you, you're on Devuan with sysvinit, so I'm
>>> > > pretty sure almost any way that you could disable plymouth and
>>> > > lightdm would bring you to CLI, from which you could run startx
>>> > > which would work with a properly configured ~/.xinitrc.
>> > 
>> > You describe a complicated scenario. I've never had to go through all
>> > that because I've always simply done expert install, avoided
>> > installing a desktop environment, and then in console install xorg and
>> > fluxbox. Over the years never had a problem.
> Yes, you're right, it's too complicated. I was thinking in Ubuntu-eze,
> where the entire distro is designed to never let you boot to command
> prompt. At least up to Wheezy (I haven't used Jessie), Debian was
> designed to allow booting to CLI via installation, in the manner you
> voiced earlier: Install base, install X, install fluxbox, done. In
> Debian (and therefore I assume Devuan), what I described should only be
> used for troubleshooting purposes.
>
> SteveT

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Go Linux]

On Fri, 8/14/15, T.J. Duchene  wrote:

 Subject: Re: [DNG] Systemd Shims
 To: dng@lists.dyne.org
 Date: Friday, August 14, 2015, 2:47 PM
 
> I know not everyone here agrees with me, especially Steve, and that's
> perfectly okay.  I have no problem with that at all. I just don't see
> "System 5 pure"  as realistic when planning ahead looking at a
> maintenance standpoint when Debuan upstream is more and more likely to
> stick with Systemd in designing their packaging.
> 

Maybe we should just put Steve in charge of decontaminating all packages with 
systemd deps!

> 
> If it is of any interest, the last time I tested Debian Sid a few days
> ago, it had the option on the Grub menu to choose to boot via System
> 5 or Systemd.
> 

Does that mean you can now install another init system without having to 
install systemd first?

golinux

 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Simon Hobson]

Rainer Weikusat  wrote:

> ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS,
> Slackware and Windows, all of which certainly don't have systemd. I've
> just cloned the current development repository and build it on Wheezy
> using a plain
> 
> ./configure
> make
> 
> which worked without issues and this system is certainly systemd-free,
> too.

Which makes it even more non-sensical to make it have systemd dependencies.

> Could perhaps provide some kind of link illustrating what you were
> referring to?

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

And from http://lists.clamav.net/pipermail/clamav-users/2015-June/001604.html
> BTW, since I'm the primary clamav maintainer in Debian, guess how much action 
> your report is going to get.


As you've pointed out, this is a package widely used across various OSs, and is 
still officially supported in Wheezy through security updates. But the Debian 
Jessie package hard depends on libsystemd0.

Now I know some will call me paranoid, but if you're going to allow various 
libraries, then you are allowing part of the code that people are complaining 
about. I'm not able to go and examine the code, but I've seen enough of what 
systemd does and how it's coded to know I don't want it on servers I'm 
responsible for keeping running.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Teodoro Santoni]

On Fri, Aug 14, 2015 at 09:06:08PM +0100, Rainer Weikusat wrote:
> Simon Hobson  writes:
> 
> [...]
> 
> > As an example, I tried to upgrade one of my Wheezy systems to Jessie
> > with *systemd* pinned as not installable. It took a bit of messing
> > around figuring out what the broken dependencies were, and in the end
> > I only had ONE single package that I needed and which wouldn't install
> > - clamav-daemon (the other clamav* packages were fine, just not that
> > individual one). In response to my messages on the clamav mailing list
> > and bug report, it turns out that they only make ONE call to
> > libsystemd during startup and then never use it again,
> 
> ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS,
> Slackware and Windows, all of which certainly don't have systemd. I've
> just cloned the current development repository and build it on Wheezy
> using a plain
> 
> ./configure
> make
> 
> which worked without issues and this system is certainly systemd-free,
> too.
> 
> Could perhaps provide some kind of link illustrating what you were
> referring to?

The package clamav-daemon.
Putting it as you did, then, one should just repackag the software after a 
build in a systemd-clean environment.

--
Teodoro Santoni

Something is wrong. I don't wanna compile 20 KB of Go code to list files.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Rainer Weikusat]

Steve Litt  writes:
> On Fri, 14 Aug 2015 13:59:32 +0100
> Simon Hobson  wrote:

[...]

> Bottom line: The perfect is the enemy of the good. To the extent that
> shims can defuse silly, reasonless dependencies, in situations where a
> revised makefile and maybe tiny changes to the C can't do it, shims
> help Devuan continue to promote life without systemd, and hasten the
> day when *everybody* will realize King Lennart has no clothes.

If 'a revised Makefile and tiny changes to the C' can't do it, a systemd
emulator without real functionality almost certainly also can't do
it. And as soon as you start to reimplement systemd, you are using it
and can save yourself the trouble by using the standard implementation
unless you're convinced that your systemd will be a better systemd than
the systemd systemd but since it will still be systemd, you've obviously
accepted its general architecture as sensible.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Rainer Weikusat]

Simon Hobson  writes:

[...]

> As an example, I tried to upgrade one of my Wheezy systems to Jessie
> with *systemd* pinned as not installable. It took a bit of messing
> around figuring out what the broken dependencies were, and in the end
> I only had ONE single package that I needed and which wouldn't install
> - clamav-daemon (the other clamav* packages were fine, just not that
> individual one). In response to my messages on the clamav mailing list
> and bug report, it turns out that they only make ONE call to
> libsystemd during startup and then never use it again,

ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS,
Slackware and Windows, all of which certainly don't have systemd. I've
just cloned the current development repository and build it on Wheezy
using a plain

./configure
make

which worked without issues and this system is certainly systemd-free,
too.

Could perhaps provide some kind of link illustrating what you were
referring to?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[T.J. Duchene]

Hi Stephanie! =)

On Fri, 14 Aug 2015 13:44:42 +
Stephanie Daugherty  wrote:



> 
> I fear however that we're going to see packages with deeper and deeper
> entanglement with systemd, where it won't be a simple matter to patch
> the software to work correctly. Gnome already seems to be moving full
> speed ahead in this direction, and unfortunately, it's a matter of
> time before others follow suit. 

It's already a done deal.  KDE announced that they are going to
soft-depend on systemd.  =P

I really so not see what the big deal about a shim is, and why we
even debating the idea. 


It is just a compatibility wrapper, no more or less evil than any other.
BSD already does that for some software because Linux has basically
taken over.  Yes, systemd is Linux specific and I prefer POSIX, but
there is no official spec in POSIX for init, so I can't fault anyone
for using systemd. Systemd is not particularly good for servers and so
I agree with Devuan that it needs to remain optional, but neither is it
a pressing problem that is going to end the world. 

I prefer to stick with the engineering facts, and not hyperbole. There
are three and only three ways to end the "systemd/Linux only" problem.
One is to force the Linux community to stop using Linux only system
calls. That is *NOT* going to happen.  The other is to provide a layer
to mitigate those calls. That is exactly what a shim does. The third is
to fork every software that depends on systemd or drop support for it
entirely. What Devuan does on that is up to them, but I would suggest
that a Devuan without software is less useful than one that uses a
shim.  I do not think they are going to have the resources to maintain
an ever-increasing number of forks.


> I think collaboration with
> them on a common implementation that provides a workable, portable,
> and non-invasive comparability layer would be mutually beneficial,
> and needn't be exclusive of efforts to disentangle packages from the
> systemd beast altogether.

Personally, I agree with you. 

I see the shim as the only reasonable option going forward at present,
unless things change within the community radically.  It's the only one
that makes engineering sense.  FreeBSD also thinks the same way,  They
are presently working on a shim to mitigate the issue of systemd.

I know not everyone here agrees with me, especially Steve, and that's
perfectly okay.  I have no problem with that at all. I just don't see
 "System 5 pure"  as realistic when planning ahead looking at a
maintenance standpoint when Debuan upstream is more and more likely to
stick with Systemd in designing their packaging.

If it is of any interest, the last time I tested Debian Sid a few days
ago, it had the option on the Grub menu to choose to boot via System
5 or Systemd.

Have a fabulous day!
T.J.  
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Teodoro Santoni]

On Fri, Aug 14, 2015 at 01:59:32PM +0100, Simon Hobson wrote:
> As an example, I tried to upgrade one of my Wheezy systems to Jessie with 
> *systemd* pinned as not installable. It took a bit of messing around figuring 
> out what the broken dependencies were, and in the end I only had ONE single 
> package that I needed and which wouldn't install - clamav-daemon (the other 
> clamav* packages were fine, just not that individual one). In response to my 
> messages on the clamav mailing list and bug report, it turns out that they 
> only make ONE call to libsystemd during startup and then never use it again, 
> and it's not even an essential call - but no, it would be a "waste of CPU 
> cycles" to do a "if exists libsystemd0 then call ..." I assume it's not 
> considered a waste of cycles to maintain a separate package for Wheezy 
> security updates !

Good evening,

It's true, that's a waste, although very small, to add an if structure.
Remains a weak argument: not being clamav a Go project, it has for sure a 
badly optimized, on the buiding side, codebase, so a config macro and an 
#ifdef SYSTEMD_EXISTS around the call surely doesn't waste anything valuable.

--
Teodoro Santoni

Something is wrong. I don't wanna compile 20 KB of Go code to list files.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Steve Litt]

On Fri, 14 Aug 2015 13:59:32 +0100
Simon Hobson  wrote:

 
> > If Devuan developers write 50 simple shims to fulfill those 
> > dependencies, then Devuan users can run those 10,000 apps 
> > as they are, directly from the Debian repos. And when the 
> > apps are updated, they will still run.
> 
> As pointed out already, unless the systemd calls are not actually
> doing anything useful to the operation of the program then replacing
> each call with a "null operation" will break the program.
> 
> But, IMO there is a more important philosophical reason not to do it.
> 
> If it were technically possible to create all these shims that would
> "do nothing but magically still let programs work", by doing it that
> way you have "legitimised" the use of those systemd calls. As in,
> "use as many as you like, it doesn't actually matter". If Devuan can
> get to the point where the devs that are "blindly going down the
> systemd alley"* want to get on board, without these shims there is a
> clear message - fix your code or it can't be installed.

Laurent Bercot earlier brought up this exact philosophical reason not
to do it. You two make a good point, but I disagree with the point.

This point would be spot on if Devuan had any marketplace clout. The
trouble is, with Devuan currently having such a tiny "market share",
and Devuan having almost zero funding (compared to Red Hat, Cannonical,
SuSE), threaten an upstream with "your software won't go on Devuan" and
their response will be "so what, I'll lose 0.1% of my users". In fact,
compared to that tiny loss, Devuan will lose many more because many
user's favorite program won't run on Devuan, for philosophical reasons.

Which makes it yet harder for users to avoid systemd, creating more
systemd usership, shrinking our "market share" even more.

Bottom line: The perfect is the enemy of the good. To the extent that
shims can defuse silly, reasonless dependencies, in situations where a
revised makefile and maybe tiny changes to the C can't do it, shims
help Devuan continue to promote life without systemd, and hasten the
day when *everybody* will realize King Lennart has no clothes.


SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[Steve Litt]

On Fri, 14 Aug 2015 07:01:11 -0400
Haines Brown  wrote:


> > Rereading your original post: Do you want to not have a Display
> > Manager such as lightdm, kdm, gdm etc, or do you want your computer
> > not to have X at all? If the latter, just deinstall X. If the
> > former, you need to find your display manager, based on ps axjf.
> 
> The aim is to boot to a console prompt, log in as root, install xorg
> and fluxbox. That gives me X and a window manager but no desktop
> environment. 

What you describe above is *precisely* how I want things to go. Your
box and my desktop are the same except I use Openbox instead of
fluxbox. I love startx so much my wife is getting jealous.

> At present I get a log in prompt and can log in as user
> in console, but for some reason root log in not working. I suppose
> that when I provided a password I mistyped. 

:-) If this were Ubuntu, I'd tell you to do sudo su -

> 
> > Anyway, luckily for you, you're on Devuan with sysvinit, so I'm
> > pretty sure almost any way that you could disable plymouth and
> > lightdm would bring you to CLI, from which you could run startx
> > which would work with a properly configured ~/.xinitrc.
> 
> You describe a complicated scenario. I've never had to go through all
> that because I've always simply done expert install, avoided
> installing a desktop environment, and then in console install xorg and
> fluxbox. Over the years never had a problem.

Yes, you're right, it's too complicated. I was thinking in Ubuntu-eze,
where the entire distro is designed to never let you boot to command
prompt. At least up to Wheezy (I haven't used Jessie), Debian was
designed to allow booting to CLI via installation, in the manner you
voiced earlier: Install base, install X, install fluxbox, done. In
Debian (and therefore I assume Devuan), what I described should only be
used for troubleshooting purposes.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Stephanie Daugherty]

If anything, shims for systemd should be something that relies on
LD_PRELOAD to provide the wrappers, rather than making them broadly
available - so that it's possible to use it as a workaround, but without
deliberately doing so, the affected packages WILL break.

I fear however that we're going to see packages with deeper and deeper
entanglement with systemd, where it won't be a simple matter to patch the
software to work correctly. Gnome already seems to be moving full speed
ahead in this direction, and unfortunately, it's a matter of time before
others follow suit. Since systemd is firmly committed to being Linux only,
other *nix operating systems, including the *BSD world are having to build
workarounds. I think collaboration with them on a common implementation
that provides a workable, portable, and non-invasive comparability layer
would be mutually beneficial, and needn't be exclusive of efforts to
disentangle packages from the systemd beast altogether.


On Fri, Aug 14, 2015 at 8:59 AM Simon Hobson  wrote:

> > It seems to me that it's good to have shim programs that satisfy
> > dependencies of apps on systemd, each shim performing some systemd
> > function. Here's why:
> >
> > Suppose there are 10,000 application programs (apps) for Linux,
> > and their developers foolishly insert dependencies on systemd.
> >
> > If Devuan developers write 50 simple shims to fulfill those
> > dependencies, then Devuan users can run those 10,000 apps
> > as they are, directly from the Debian repos. And when the
> > apps are updated, they will still run.
>
> As pointed out already, unless the systemd calls are not actually doing
> anything useful to the operation of the program then replacing each call
> with a "null operation" will break the program.
>
> But, IMO there is a more important philosophical reason not to do it.
>
> If it were technically possible to create all these shims that would "do
> nothing but magically still let programs work", by doing it that way you
> have "legitimised" the use of those systemd calls. As in, "use as many as
> you like, it doesn't actually matter".
> If Devuan can get to the point where the devs that are "blindly going down
> the systemd alley"* want to get on board, without these shims there is a
> clear message - fix your code or it can't be installed.
>
> * I'm sure some feel they are using systemd calls for a good reason. In
> many cases there may well be merit in using them when available.
>
>
> As an example, I tried to upgrade one of my Wheezy systems to Jessie with
> *systemd* pinned as not installable. It took a bit of messing around
> figuring out what the broken dependencies were, and in the end I only had
> ONE single package that I needed and which wouldn't install - clamav-daemon
> (the other clamav* packages were fine, just not that individual one). In
> response to my messages on the clamav mailing list and bug report, it turns
> out that they only make ONE call to libsystemd during startup and then
> never use it again, and it's not even an essential call - but no, it would
> be a "waste of CPU cycles" to do a "if exists libsystemd0 then call ..." I
> assume it's not considered a waste of cycles to maintain a separate package
> for Wheezy security updates !
> If you provide a shim, then you legitimise this sort of behaviour. Which
> would you prefer : a clamav-daemon package with a dependency on a "fake"
> libsystemd0, or a clamav-daemon package without any systemd dependency ? If
> you legitimise using shims, then the same people that see no reason to not
> hard-depend on libsystemd0 will bring you a package with a hard-depends on
> fake-libsystemd0.
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Stephanie Daugherty]

On Thu, Aug 13, 2015 at 4:06 PM T.J. Duchene  wrote:

>
> 1.  You can't mark a package as "Do not install."  APT simply does not give
> you the option.
>
> Heaven knows, there are a lot of people who dislike things like network-
> manager, and do not them to install for any reason.
>
> Someone might say - wait you can put a hold on packages.  That's true, but
> that does not stop packages from being installed. It only says which
> version
> is preferred.  There is no option for "none".
>
> You can block packages with APT pinning, but using pinning is very
> esoteric.
>
> There's a less obvious, but more reliable solution that holding or
pinning., and that is the dummy package. equivs makes this pretty easy to
create - you simply need a package marked that conflicts with the undesired
software, or if you prefer, one which tells the system that package is
already installed, so that you can ignore the dependency at your own risk
and without any pestering from apt. .



> 2. Whenever an update has bug, you cannot rollback to the previous version
> of
> the package.  It is always assumed that the latest version is correct.  In
> the
> real world, we know that is not always true.
>

Sure you can, just not with apt. dpkg is still the actual package manager,
and will happily install older versions for you, so long as you take care
of the dependencies on your own. In many cases the previous packages are
still sitting around in apt's download directory, but if not, they can
usually still be found in the archives.

Besides, unless you follow unstable, this doesn't happen often enough to be
a serious concern, because of Debian's rigid "no functionality changes in
stable, only fixes" policy.

The situation in both of these cases should be better, but arguably, if
it's a direction Devuan decides to go in, it would be best to do so as
extensions to apt rather than reinventing the wheel, so as to keep as much
compatibility with Debian as possible and continue to use Debian as
upstream whenever possible.

Without Debian as an upstream, the task of maintaining Devuan even at
parity with Debian would be all but impossible for the small team of
maintainers and developers currently part of Devuan. Unless a very large
portion of the Debian community jumps ship, and Devuan becomes the base of
Debian rather than the other way around, I think this will have to continue
for the foreseeable future.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Systemd Shims

[Simon Hobson]

> It seems to me that it's good to have shim programs that satisfy 
> dependencies of apps on systemd, each shim performing some systemd 
> function. Here's why: 
> 
> Suppose there are 10,000 application programs (apps) for Linux, 
> and their developers foolishly insert dependencies on systemd. 
> 
> If Devuan developers write 50 simple shims to fulfill those 
> dependencies, then Devuan users can run those 10,000 apps 
> as they are, directly from the Debian repos. And when the 
> apps are updated, they will still run.

As pointed out already, unless the systemd calls are not actually doing 
anything useful to the operation of the program then replacing each call with a 
"null operation" will break the program.

But, IMO there is a more important philosophical reason not to do it.

If it were technically possible to create all these shims that would "do 
nothing but magically still let programs work", by doing it that way you have 
"legitimised" the use of those systemd calls. As in, "use as many as you like, 
it doesn't actually matter".
If Devuan can get to the point where the devs that are "blindly going down the 
systemd alley"* want to get on board, without these shims there is a clear 
message - fix your code or it can't be installed.

* I'm sure some feel they are using systemd calls for a good reason. In many 
cases there may well be merit in using them when available.


As an example, I tried to upgrade one of my Wheezy systems to Jessie with 
*systemd* pinned as not installable. It took a bit of messing around figuring 
out what the broken dependencies were, and in the end I only had ONE single 
package that I needed and which wouldn't install - clamav-daemon (the other 
clamav* packages were fine, just not that individual one). In response to my 
messages on the clamav mailing list and bug report, it turns out that they only 
make ONE call to libsystemd during startup and then never use it again, and 
it's not even an essential call - but no, it would be a "waste of CPU cycles" 
to do a "if exists libsystemd0 then call ..." I assume it's not considered a 
waste of cycles to maintain a separate package for Wheezy security updates !
If you provide a shim, then you legitimise this sort of behaviour. Which would 
you prefer : a clamav-daemon package with a dependency on a "fake" libsystemd0, 
or a clamav-daemon package without any systemd dependency ? If you legitimise 
using shims, then the same people that see no reason to not hard-depend on 
libsystemd0 will bring you a package with a hard-depends on fake-libsystemd0.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Adam Borowski]

On Fri, Aug 14, 2015 at 02:02:22PM +0200, Didier Kryn wrote:
> Seems to me there's something weird, both, in libreoffice depending on
> just one single version of libstdc++, and in libklabxml being broken by this
> version of libstdc++, be it the fault of kde or libstdc++ developpers.

That's the GCC-5 transition, unstable is broken as it's supposed to.  You
can use testing if you're bothered by uninstallable packages (or any other
form of the sky falling).

> The dependency chains might be shortened by linking at least part of the
> libraries statically. All this dependency buysiness mostly comes from the
> abuse of dynamic linking. The only real advantage of dynamic linking is
> faster upgrade in a distribution, but it often turns out to make it just
> impossible.

Static linking has no place in a distribution.  Among numerous other
downsides, any update of a dependency requires a "rebuild world".  There's
no way to make a security or bugfix update without such a mass recompile.

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Didier Kryn]

Le 14/08/2015 10:16, Noel Torres a écrit :


Everyone that has anytime been trapped in the Dependency Hell knows 
about the complicated chains of dependencies in Debian. As a simple 
example, today it is impossible to install LibreOffice 5 and KDE 
together, since libreoffice 1:5.0.1~rc1-2 ends depending on libstdc++6 
5.2.1-15 while kde-full 5:81 end depending on libkolabxml1 1.1.0-3 
(the highest version available), but libstdc++6 Breaks libkolabxml1 <= 
1.1.0-3


Seems to me there's something weird, both, in libreoffice depending 
on just one single version of libstdc++, and in libklabxml being broken 
by this version of libstdc++, be it the fault of kde or libstdc++ 
developpers.


The dependency chains might be shortened by linking at least part 
of the libraries statically. All this dependency buysiness mostly comes 
from the abuse of dynamic linking. The only real advantage of dynamic 
linking is faster upgrade in a distribution, but it often turns out to 
make it just impossible.


As a simple rule, I don't understand why Debian accepts a package 
which depends on just one version of libstdc++, therefore de facto 
preventing any upgrade. To be accepted, this package should be linked 
against a static version of libstdc++6, hence dropping the dependency. 
But, Ok, it's Debian's buziness for now.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Install Devuan without network/WIFI access

[Edward Bartolo]

Please, ignore this email. I successfully used the netboot iso to
install Devuan 64 bit.

My sincere thanks go to all those are giving their time for the project.

Thanks to all involved.

On 13/08/2015, Edward Bartolo  wrote:
> I am trying to figure out how I should go to install Devuan without
> having network access. I remember I had serious problems installing
> Debian as none of the network interfaces was recognized. This also
> includes WIFI. The reason for prefering to use debootstrap is lack of
> network recognition during the installation.
>
> Which file should I download for Intel hardware 64 bit?
>
>
> Thanks
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[Haines Brown]

On Thu, Aug 13, 2015 at 11:54:48PM +0200, Riccardo Boninsegna wrote:
> Il 13/ago/2015 10:21 PM, "Haines Brown"  ha scritto:
> > I guess I'll just try to reinstall. I initially tried to install
> > testing/ascii, but couldn't complete install software. So I retreated to
> > jessie, and had the same problem, but after choosing not to install CUPS
> > (and no desktop manager), I finally succeeded but for the problem under
> > discussion. When I redo, I'll repartition and not use the default
> > partitioning scheme. I'll report on my success.
> 
> Now I understand: you went through "Install the base system" (if not more, 
> most
> likely given the issue is with Xfce), then went back to "choose a mirror" to
> switch releases, then back again to base system/package manager/install
> software without going back to partitioning to reformat root?
> 
> That's where it went wrong, then: "install the base system" blindly overwrites
> dpkg's status file with one matching the debootstrap that happens for the most
> of that step (before it says to select a kernel package)!
> 
> There is a warning if you "install the base system" on a non-empty partition
> but it's easy to miss if you went through partitioning again without
> reformatting, as it immediately follows "warnings" such as saving the 
> partition
> table and complaining about not using a swap partition!

Yes, you spotted the problem. Perhaps only when I did chroot (cross)
installations, but it seems I used to partition and format a hard disk
before installing, and then skip the partitioning step in the
installation. But Devuan installation routine insisted that I partition
the drive because it seems to have removed mount points and
filesystem. I defined them and wrote to disk but I suspect without
re-formatting. That was my mistake. 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Alpha2 without desktop environment

[Haines Brown]

On Thu, Aug 13, 2015 at 05:13:46PM -0400, Steve Litt wrote:
> On Thu, 13 Aug 2015 15:16:21 -0400
> Haines Brown  wrote:
> 
> > On Thu, Aug 13, 2015 at 01:57:58PM -0400, Steve Litt wrote:
> > > On Thu, 13 Aug 2015 13:01:14 -0400
> > > Haines Brown , "To:dng"@lists.dyne.org,
> > > "Cc:Bcc:"@tupac2.dyne.org wrote:

> > Aptitude tells me that xfce4 and these specific utilities are not
> > installed.
> 
> I suspect that aptitude is wrong, or you are interpreting it wrong. But
> anyway...

No I'm interpreting it correctly. The mystery won't be solved because I
reinstalled. 

> Rereading your original post: Do you want to not have a Display Manager
> such as lightdm, kdm, gdm etc, or do you want your computer not to have
> X at all? If the latter, just deinstall X. If the former, you need to
> find your display manager, based on ps axjf.

The aim is to boot to a console prompt, log in as root, install xorg and
fluxbox. That gives me X and a window manager but no desktop
environment. At present I get a log in prompt and can log in as user in
console, but for some reason root log in not working. I suppose that
when I provided a password I mistyped. 

> Anyway, luckily for you, you're on Devuan with sysvinit, so I'm pretty
> sure almost any way that you could disable plymouth and lightdm would
> bring you to CLI, from which you could run startx which would work with
> a properly configured ~/.xinitrc.

You describe a complicated scenario. I've never had to go through all
that because I've always simply done expert install, avoided installing
a desktop environment, and then in console install xorg and
fluxbox. Over the years never had a problem.

Thanks,

Haines
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Congratulations to the Devuan team

[shraptor]

I would help you mate but my install is a package
to be overlaid using aufs.

I have never used debian so would be a poor choice
in making a package for it.

I don't know how to turn off udev in debian.
I know Jude did some magic with that.

If you try to go at it manually I am willing
to offer help.

/Scooby



On 20lite 15-08-13 04:30, Robert Storey wrote:

About vdev...

It looks like it's almost ready for prime time, but that further
testing is needed to work out any bugs. So I'd like to throw out a
little suggestion to expedite that.

Could someone come up with a package so that we can install vdev on
Debian? In my case, I'm currently using antiX as my stable operating
system. I would be willing to install vdev on it and put it through
its paces, reporting back any suspected bugs I encounter.

Barring a specific package, then maybe some published instructions and
a download for installing it on Debian.

It sounds to me like vdev could be a game changer, so I'm enthused
about installing it and doing what I can to make it a new standard.

As I've mentioned before, I do occasionally write for DistroWatch, so
if I can get a positive experience with vdev, I'd do an article on
that. Hopefully, this would encourage others to download and install
vdev, helping to move along its widespread adoption.

Kudos to all the Devuan developers.

 - Robert


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Evince, gimp and okular in devuan

[aitor_czr]

Riccardo,

Yes, i have enabled debian security updates. I downloaded the sources of
cups and changed:

  libcups2 (= ${binary:Version})

by:

  libcups2 (= ${source:Version})

in debian/control.

Thanks,

Aitor.


El 13/08/15 a las 19:38, Riccardo Boninsegna escribió:
>
> Il 13/ago/2015 07:04 PM, "aitor_czr"  > ha scritto:
> >
> > I don't know, i'm in devuan jessie :)
>
> Looks like you don't have the Debian Security repos enabled (deb
> http://security.debian.org/ jessie-updates main #contrib non-free),
> which at the moment don't have a Devuan equivalent for all I know
>
> Yes, this means an update could install systemd, but it's one of the
> cases where always pays to not blindly agree to update confirmations...
>

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan and upstream

[Noel Torres]

James Powell  escribió:
[...]
Devuan should follow the Debian methodology, but equally it should  
forge it's own path away from Debian. It doesn't need to draw from  
any other distribution like Funtoo, CRUX, Slackware, or anything  
other distributions, other than seeing what people are using and in  
need of. The wants will be many, but what users need will matter  
most of all.

[...]

I have thought extensively (in some sort of silence, I suppose, since  
you have not heard of^H read from me for a long time) in this issue of  
packages and dependencies, and I have come across an idea, that of  
boxes.


Everyone that has anytime been trapped in the Dependency Hell knows  
about the complicated chains of dependencies in Debian. As a simple  
example, today it is impossible to install LibreOffice 5 and KDE  
together, since libreoffice 1:5.0.1~rc1-2 ends depending on libstdc++6  
5.2.1-15 while kde-full 5:81 end depending on libkolabxml1 1.1.0-3  
(the highest version available), but libstdc++6 Breaks libkolabxml1 <=  
1.1.0-3


These chains of dependencies can be shortened if we use "boxes" of  
packages. They are not metapackages, but a new idea, albeit somewhat  
similar.


Why is LibreOffice worth a dozen packages? If I want LibreOffice, I  
want it all (Thanks, Queen). So I install the LibreOffice box. The box  
on its own will install the needed packages and care for the internal  
dependencies, and provide a shiny dependencies inteface to the other  
boxes. And of course, boxes can be inside boxes.


This way, boxes are managed as simple units, migrate from ceres to  
testing as complete units, etc. They also allow for efficient  
teamworking.


e.g. The LAMP box contains (and iterfaces with) the Apache box and the  
MySQL box. The LAMP box controls the migration of all of Apache, PHP  
and MySQL packages, to ensure they all work properly and are  
coinstallable.


Just two (or maybe three) euro cents.

regards

Noel
er Envite


binnlCoFEfKn8.bin
Description: Clave PGP pública


pgpXdOlK6cgzH.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng