Re: How to build-depend on a C++11-capable compiler?

[Thibaut Paumard]

Le 21/07/2014 23:19, Gert Wollny a écrit :
>> Last time I asked:
>>
>> https://lists.debian.org/debian-devel/2013/09/msg00335.html
>>
>> It was prefered to provide a C++98 ABI compatible library for the time
>> being. If you start providing a C++11 ABI library people will not be
>> able to mix symbols from your lib and other part of debian system. As
>> far as I understand the whole debian should transition to C++11 ABI at
>> the same time.
> 
> Well, since g++-4.9 now c++11 feature complete (with one exception
> afair)  the situation is probably a lot better now. 

Hi,

Debian is the primary development platform of Gyoto, so Gyoto is known
to work in this context. There is also no reverse dependency as of now,
and I don't expect any to emerge any time soon (at least not before the
freeze!). I have checked the ABI compatibility page at
 https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
and I don't see anything relevant to Gyoto either.

[...]
> The only problem I came across in all this time was with BOOST,

Gyoto actually uses Boost (just odeint and multiprecision). Do you know
whether there are incompatibilities in these?

Anyway, I think I'll just go ahead and don't build-depend on a specific
compiler, because Gyoto can be built already with Wheezy's default
compiler in C++11 mode. Thanks all for your tips.

Kind regards, Thibaut.


-- 
* Dr Thibaut Paumard   | LESIA/CNRS - Table équatoriale (bât. 5)   *
* Tel: +33 1 45 07 78 60   | Observatoire de Paris - Section de Meudon *
* Fax: +33 1 45 07 79 17   | 5, Place Jules Janssen*
* thibaut.paum...@obspm.fr | 92195 MEUDON CEDEX (France)   *



smime.p7s
Description: Signature cryptographique S/MIME

Bug#755676: general: Intermittent failure to mount partition [after hibernate?] with message "Transport endpoint is not connected"

[Paul G Taylor]

Package: general
Severity: important

Dear Maintainer,

I have set up my sister's PC, which was running Windows XP, with RoboLinux, a
derivative of Debian Wheezy
**@robolinux:~$ cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

The  /dev/sda2, NTSF formatted partition, is shared between RoboLinux, Windows
XP and Windows XP virtualised in VirtualBox.
/etc/fstab shows : --
**@robolinux:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#   
  
# / was on /dev/sda5 during installation
UUID=16b91710-2e23-422e-b09a-aaf8d1ab75cb /   ext4errors
=remount-ro 0   1
# /home was on /dev/sda7 during installation
UUID=d994a183-c3d9-4779-83a3-c058dcbc3d03 /home   ext4defaults
0   2
# /var was on /dev/sda8 during installation
UUID=6796e893-de2c-4878-93a4-343f2e643ea7 /varext4defaults
0   2
# swap was on /dev/sda6 during installation
UUID=86f89ed8-9c45-4837-957d-d358621dc55a noneswapsw
0   0
## Data partition as mounted after booting the system
# /dev/sda2 on /media/Data type fuseblk
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,defaults,allow_other,blksize=4096)
# /dev/sda2: LABEL="Data" UUID="161C2A371C2A11F3" TYPE="ntfs" as listed by
blkid
UUID=161C2A371C2A11F3   /media/Data ntfs-3g
auto,user,rw,relatime,uid=1000,gid=1000,defaults,allow_other  0   2
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/fd0/media/floppy0  autorw,user,noauto  0   0
none /proc/bus/usb usbfs devgid=117,devmode=664 0 0
**@robolinux:~$

While working in RoboLinux, intermittently, there is no access to this
partition where all data is stored including the profiles for Thunderbird. So
far this has only been able to recover from by a full reboot.

So far I have found information about this using Google search but only in
relation to other distributions and of very uncertain usefulness. If the
problem has been reported previously to Debian then please add this to the bug
report, else I would appreciate this being listed as a bug.

Regards,

Paul




-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140722095853.7238.50800.reportbug@robolinux.unassigned-domain

Re: Bug#755676: general: Intermittent failure to mount partition [after hibernate?] with message "Transport endpoint is not connected"

[Simon McVittie]

On 22/07/14 10:58, Paul G Taylor wrote:
> The  /dev/sda2, NTSF formatted partition, is shared between RoboLinux, Windows
> XP and Windows XP virtualised in VirtualBox.

Not necessarily related to the error you reported (which I have no idea
about) but you should never allow VirtualBox to have raw filesystem
access to this filesystem (access via /dev/sda2 device node) at the same
time that it is mounted on /media/Data. If VirtualBox is accessing it
via /media/Data that's OK.

In an attempt to be clearer, this is OK (view in a monospace font):

Emulated XP
|
v
VirtualBox   other apps
 \/
  v  v
 /media/Data
   |
   v
/dev/sda2

but this is not:

Emulated XP  other apps
||
vv
VirtualBox   /media/Data
 \/
  v  v
 /dev/sda2

If that's what you're doing, stop doing that; it can't work reliably.

Otherwise, this bug report does not have enough information to be useful
to a developer trying to find and fix this bug. The system log
(/var/log/syslog) around the time of failure might provide more hints as
to which component is failing to do something and why. Please contact a
support channel such as the debian-user mailing list
 or  if
you are unsure how to find more information.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ce3c9f.90...@debian.org

Bug#755676: marked as done (general: Intermittent failure to mount partition [after hibernate?] with message "Transport endpoint is not connected")

[Debian Bug Tracking System]

Your message dated Tue, 22 Jul 2014 12:49:07 +0200
with message-id <201407221249.08846.hol...@layer-acht.org>
and subject line Re: Bug#755676: general: Intermittent failure to mount 
partition [after hibernate?] with message "Transport endpoint is not connected"
has caused the Debian Bug report #755676,
regarding general: Intermittent failure to mount partition [after hibernate?] 
with message "Transport endpoint is not connected"
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
755676: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755676
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important

Dear Maintainer,

I have set up my sister's PC, which was running Windows XP, with RoboLinux, a
derivative of Debian Wheezy
**@robolinux:~$ cat /etc/*release
PRETTY_NAME="Debian GNU/Linux 7 (wheezy)"
NAME="Debian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

The  /dev/sda2, NTSF formatted partition, is shared between RoboLinux, Windows
XP and Windows XP virtualised in VirtualBox.
/etc/fstab shows : --
**@robolinux:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#   
  
# / was on /dev/sda5 during installation
UUID=16b91710-2e23-422e-b09a-aaf8d1ab75cb /   ext4errors
=remount-ro 0   1
# /home was on /dev/sda7 during installation
UUID=d994a183-c3d9-4779-83a3-c058dcbc3d03 /home   ext4defaults
0   2
# /var was on /dev/sda8 during installation
UUID=6796e893-de2c-4878-93a4-343f2e643ea7 /varext4defaults
0   2
# swap was on /dev/sda6 during installation
UUID=86f89ed8-9c45-4837-957d-d358621dc55a noneswapsw
0   0
## Data partition as mounted after booting the system
# /dev/sda2 on /media/Data type fuseblk
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,defaults,allow_other,blksize=4096)
# /dev/sda2: LABEL="Data" UUID="161C2A371C2A11F3" TYPE="ntfs" as listed by
blkid
UUID=161C2A371C2A11F3   /media/Data ntfs-3g
auto,user,rw,relatime,uid=1000,gid=1000,defaults,allow_other  0   2
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/fd0/media/floppy0  autorw,user,noauto  0   0
none /proc/bus/usb usbfs devgid=117,devmode=664 0 0
**@robolinux:~$

While working in RoboLinux, intermittently, there is no access to this
partition where all data is stored including the profiles for Thunderbird. So
far this has only been able to recover from by a full reboot.

So far I have found information about this using Google search but only in
relation to other distributions and of very uncertain usefulness. If the
problem has been reported previously to Debian then please add this to the bug
report, else I would appreciate this being listed as a bug.

Regards,

Paul




-- System Information:
Debian Release: 7.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Hi,

I'm sorry but I'm closing this bug as you are using Robolinux, not Debian.


cheers,
Holger


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

Re: How Debian should handle users requests?

[Reinhard Tartler]

On Mon, Jul 21, 2014 at 7:30 AM, Holger Levsen  wrote:

>> The main goal of all this is to make Debian more user friendly.
>
> You dont make Debian more user friendly by creating a support forum which will
> not be used... there is d-u@l.d.o and there is "ask debian" (forgot the url)
> too.

http://ask.debian.net

> Are you active on those, helping users?


-- 
regards,
Reinhard


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caj0cceafunu8flbh6ocecshztss+xbxi5wremvbmjftp_2d...@mail.gmail.com

Re: Debconf - how to run a packaging workshop

[Matthew Vernon]

Dominic Hargreaves  writes:

> I've agreed to give a one day Debian packaging workshop at $dayjob aimed at
> sysadmins and developers, and I'd be interested in hearing from those who
> have already run similar sessions to get advice/tips for how to approach
> such a thing. Would there be any interest at attending/contributing to
> such a session at Debconf?

I'd attend it.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5btx69pncq@chiark.greenend.org.uk

Re: How Debian should handle users requests?

[Holger Levsen]

Hi Abou,

On Montag, 21. Juli 2014, Abou Al Montacir wrote:
> > oh, wow, how do you want to deal with those? What do you do if these
> > users don't follow up?
> There is always a risk that a user make a mistake, but these questions
> can only reduce the noise and increase the SNR on this comm channel.

You didnt answer my question at all: what do you do, when there is no 
feedback? This is very very often the case.

Past experiences show that these bugs accumulate and suddenly there are 50 
useless bugs against base|general and then someome has to spend hours to clean 
those up. Which mostly means closing them, but this could have been (and 
usually now is) done immediatly.

Also please not that I *do* reassign bugs with a little bit of substance to 
the relevant packages. (Where they might rot again...)

> > Really there are quite many many of these bugs already, against
> > base+general, but also against d-i (installation-reports) and many other
> > packages, where users file "bug reports" which are *not* bug reports
> > (because they lack vital information) but just "bug notices" which are
> > often quite useless.

I forgot src:linux in that list. That package also desperately needs help.

> I know this very well, just taking my personal case, but my point is not
> about lack of support but rather about abrupt reaction to some bugs. It
> is more about nice reaction when someone reports a bad bug and teaching
> him how to improve his reporting. This can help him for next bugs he
> will report.
[..]
> I trust you here, but my rule is try to clean my packages as much as
> possible and try to explain to users the real issues. Some of my bugs I
> know I'll never be able to fix, but I don't close them, I just keep them
> maybe someone someday will be able to do what I can't do.

Well, you maintain 4 packages with 6 bugs in total (that's totally great), but 
this tells me that you cannot imagine how it is, to receive one bug per day or 
week. (one (or three more) per day is more the src:linux case, while base 
probably gets a bug per week, or less.)
 
> > A useless bug is a useless bug. If a submitter cannot come up with any
> > useful information in the report, it is very unlikey they will be able
> > to come up with that later.
> Here I really disagree. User my be ignorant but never assume he is
> stupid. Sometimes small hints could help.

I never said I assume users are stupid. I said what I said (and what is quoted 
above) ;-p
 
> I should admit I'm not active on those due to lack of time, and I really
> appreciate the energy and devotion of all active persons (not only DDs
> but also users) who helped me many times on these lists.
> But still, I'm not trying to replace this help channel, I'm just trying
> to extend it.

No, you are not trying to extend it. You are voicing your opinion, that's all. 
I totally agree that Debian should be more user friendly and developers should 
spend more time helping users, but I also believe in world peace and I think a 
48h day would be very helpful. IOW: I think your suggestions are (partly) 
good/justified, but without someone actually *living up* to these suggestions, 
they are just hot air. Sorry.

I hope I don't sound to frustrated/harsh here, but the reality is very very 
few people (thank you!) have regularily triaged those bugs (some help 
occasionally and I'm very thankful for that too), and it's mostly me caring 
about keeping bugs.debian.org/base|general sane. So surely everybody is 
welcome to make suggestions, but don't expect me to listen much, unless you 
are also planning to get involved in the work.

That said, there will be an event at DebConf14, called "Some Debian QA bits" 
where I'll be happy to discuss this (and probably change my mind and/or 
actions) and where I will (at least) listen to people not willing to do the 
work, but merely giving suggestions.

And, please trust me, I hate to frustrate users too and I try to avoid this. 
And (but?) I actually don't think closing a bug as "invalidate" has to be 
frustrating, as this helps developers to focus and thus help the users in the 
long run. This can be conveyed and I usually try to too.


cheers,
Holger, mostly "maintaining" these bugs alone since 2009. There once 
was a team...


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

linux-image-3.14-2-armmp description out of date

[David Goodenough]

In the above package the description reads:-

The Linux kernel 3.14 and modules for use on ARMv7 multiplatform kernel for 
Marvell Armada 370/xp, Freescale iMX5x/iMX6.

Reading the list of DTB files it includes, this list is rather out of date.
Now (hopefully) this list will grow with most new kernel versions, so 
continuously updating the description in the list might be a bit of a load on 
whoever did it, so perhaps it should mention the main families, but it 
should also point people at the file list for the DTBs for the complete 
detailed list.

David




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3220983.k35cvBBgWx@stargate

Re: How to build-depend on a C++11-capable compiler?

[Matthias Klose]

Am 21.07.2014 14:31, schrieb Mathieu Malaterre:
> On Mon, Jul 21, 2014 at 12:48 PM, Thibaut Paumard  wrote:
>> Hi,
>>
>> The new release of my package Gyoto should be built preferably with a
>> C++11-capable compiler. It can be built with a reduced feature-set
>> without, though.
>>
>> Is there a clever way to ensure that the default compiler is
>> C++11-capable, if available in the archive, or should I simply
>> Build-Depend on g++ (>=4:4.7)? (The goal behind this question is to make
>> life easier for backporters and persons trying alternate toolchains).
> 
> Last time I asked:
> 
> https://lists.debian.org/debian-devel/2013/09/msg00335.html
> 
> It was prefered to provide a C++98 ABI compatible library for the time
> being. If you start providing a C++11 ABI library people will not be
> able to mix symbols from your lib and other part of debian system.

this is still the way to go. C++11 support in libstdc++ is still marked as
experimental in GCC 4.9, and if other toolchains are using libstdc++ this is
valid for other toolchains too.

C+11 support currently is incompatible across GCC versions (see ). This may
affect you or not, but if you build a C++ application in c++11 mode you should
make sure to build it with the same compiler version.

> As far as I understand the whole debian should transition to C++11 ABI at
> the same time.

I don't think this is needed. You just have to make sure that you are using a
compiler with a stable C++11 ABI *and* a stable libstdc++ ABI. GCC 5.0 promises
to be such a compiler.

  Matthias


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53cebdfe.5000...@debian.org

Re: linux-image-3.14-2-armmp description out of date

[Neil Williams]

On Tue, 22 Jul 2014 20:18:29 +0100
David Goodenough  wrote:

> In the above package the description reads:-
> 
> The Linux kernel 3.14 and modules for use on ARMv7 multiplatform
> kernel for Marvell Armada 370/xp, Freescale iMX5x/iMX6.
> 
> Reading the list of DTB files it includes, this list is rather out of
> date. Now (hopefully) this list will grow with most new kernel
> versions, so continuously updating the description in the list might
> be a bit of a load on whoever did it, so perhaps it should mention
> the main families, but it should also point people at the file list
> for the DTBs for the complete detailed list.

0: this is probably best discussed in a bug report

1: the mere fact that a dtb exists in the source tree and is built does
not mean it works on the expected hardware

I'm not part of the kernel team, but I am working on ways to regularly
validate as many dtbs as I can, using LAVA. More testers are always
wanted.

Yes, I do need to blog about what I've done so far with this ... keep
getting distracted 

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: linux-image-3.14-2-armmp description out of date

[Ben Hutchings]

On Tue, 2014-07-22 at 20:18 +0100, David Goodenough wrote:
> In the above package the description reads:-
> 
> The Linux kernel 3.14 and modules for use on ARMv7 multiplatform kernel for 
> Marvell Armada 370/xp, Freescale iMX5x/iMX6.
> 
> Reading the list of DTB files it includes, this list is rather out of date.

It's not really grammatical either!

> Now (hopefully) this list will grow with most new kernel versions, so 
> continuously updating the description in the list might be a bit of a load on 
> whoever did it, so perhaps it should mention the main families, but it 
> should also point people at the file list for the DTBs for the complete 
> detailed list.

I don't think we know exactly which machines it currently works on.
Just because a DTB is included, doesn't mean all the drivers are
included and working.  But the intent is that all ARMv7 machines we can
support, will be supported by this package, and the description should
be updated to reflect that.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Re: Solutions for the Apache upgrade hell

[Arno Töll]

On 21.07.2014 20:58, Vincent Lefevre wrote:

>
> Yes, and a consequence of this loss is that dpkg fails.
> 

dpkg does not at all fail. If anything dpkg errors out because Apache's
maintainer script failed, because "invoke.rc-d apache2 restart" failed,
because ... you guess it, somebody removed the .load symlinks we expect
to be there.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

[James Cloos]

> "PW" == Paul Wise  writes:

>> * Package name: fonts-adobe-sourcehansans-cn

PW> Due to the need for Adobe's ADFKO, this will have to go to contrib.
PW> IIRC ADFKO will become open source at some point and the font could
PW> move to main then.

AFAICT, fontforge has enough capability to convert the format of the
files in the git repo into OTF files, at least.  Pehaps also combining
those into the OTC files.

The outlines are in the repo as type0 (collection of type1) format, but
again fontforge can edit and save that format just as well as its own
sfd format, so onecan argue that it is close enough to preferred src
format.

So it seems they are already dfsg-free, even without a dfsg-free release
of adfko, yes?

Or did I miss something which fontforge and/or fonttools cannot yet
accomplish?

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m3siltdp0j@carbon.jhcloos.org

systemd now appears to be only possible init system in testing

[Julian Gilbey]

I just tried updating testing on my system.  I currently use
sysvinit-core (reasons below), but aptitude is telling me that I
should remove this in favour of systemd-sysv.  Hmm, why is that?
Well, because the new version of libpam-systemd, 208-6, now depends on
systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
much depends on it, so that's not an option: gdm3, gnome-bluetooth,
network-manager, policykit-1, udisks2.

So I would presume that for many or most Debian systems, systemd is
now required, and no other /sbin/init providers will work.  I'm
unclear whether this was a deliberate policy decision or an unintended
consequence of various package requirements.

For me, this is a killer, as I still do not know how to solve the
problem I asked a while back on debian-user
(https://lists.debian.org/debian-user/2014/04/msg01286.html): in
summary, I need to unlock an encrypted filesystem during boot time by
asking for a password to feed into encfs.  But I cannot figure out how
to do this under systemd.

Answers to this question would also be much appreciated!

   Julian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722215455.ga28...@d-and-j.net

Re: systemd now appears to be only possible init system in testing

[Svante Signell]

Forward this to the debian CTTE, please!

On Tue, 2014-07-22 at 22:54 +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.
> 
> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.
> 
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!
> 
>Julian
> 
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1406069476.2350.0.camel@PackardBell-PC

Re: systemd now appears to be only possible init system in testing

[Norbert Preining]

Hi Julian,

long time no see!

[ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
This email is the personal opinion of its author.
As we are not allowed to criticize due to the newly installed 
Code of Conduct, you are required to pre- or postfix *every* sentence
in the following email with one of the following fragments:
. I thing it might be an option to say that 
. I could reach the opinion that under certain circumstances ...
. In my all too humble opinion, which is not important, ...
Failure to do the above will result in wrong interpretation of the
following email, so stop reading here if you are not ready to do that.
[ COC DISCLAIMER ENDS HERE ]

[ JOKE DISCLAIMER START ]
If you are without humour - stop reading here!
[ JOKE DISCLAIMER END ]

On Tue, 22 Jul 2014, Julian Gilbey wrote:
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.

Yes, if you use *anything* slightly gnome related, you are hosed
and need to install systemd.

You need to get rid of gdm3, gnome-bluetooth, and network-manager,
then it should be possible to get a system without systemd.
If you want one of these ... well, then the systemd mafia got you!

That is Debian, as long nobody steps forward and stops this.

> unclear whether this was a deliberate policy decision or an unintended

Deliberate. Since systemd* 208, systemd-shim is "said to be not compatible"
anymore. Well, here we go with freedom.

> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.

Everything can be done in systemd, since it is Turing complete.
The only problem is that nobody knows how to, it is not predicatable
what will actually happen (formatted hard disk, crashed kernel, etc).

In your case I *strongly* recommend to remove nm, gdm3 and by this
get rid of systemd, too.

> Answers to this question would also be much appreciated!

There are thousands of emails here, all with the same effect:

We have commit rights, so go away and shut up!

or alternatively

We are systemd, and we are now the only init system in Debian,
so go away and shut up.

or again alternatively

One init to rule them all, to bind them, and throw them into
darkness!

Fortunately, I don't use encrypted disks or anything fancy, so I am 
stupid dummy user that has no special requirements. So I am free to
use systemd, because this is the target audience!

If you would fall into the same category, you could be happy, too, but
alas, ... you are a power user and thus hosed.

Norbert

[ END OF DISCLAIMER GOVERNED TEXT ]


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014075305.gb6...@auth.logic.tuwien.ac.at

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-22 22:10:07 +0200, Arno Töll wrote:
> On 21.07.2014 20:58, Vincent Lefevre wrote:
> > Yes, and a consequence of this loss is that dpkg fails.
> 
> dpkg does not at all fail. If anything dpkg errors out because Apache's
> maintainer script failed, because "invoke.rc-d apache2 restart" failed,
> because ... you guess it, somebody removed the .load symlinks we expect
> to be there.

I didn't say that this was dpkg's fault. Then, "errors out" and "fails"
are synonymous here. The error is fatal and the system is left in
an inconsistent state. The user must fix things manually then run
"apt-get install -f", hoping things are really fixed...

BTW, I'm wondering whether the fact that "invoke.rc-d apache2 restart"
fails should make the postinst script fail and affect the whole upgrade.
If the goal is to make the user notice that Apache doesn't run, this is
rather unnecessary: In any case, the user should test his web server
after an Apache upgrade (or other major upgrade in the system), even
when everything seems fine during the upgrade. This should be regarded
more as a "run-time" failure than an "install-time" failure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722231930.ga3...@xvii.vinc17.org

Re: Solutions for the Apache upgrade hell

[Christian Hofstaedtler]

* Arno Töll  [140722 22:10]:
> On 21.07.2014 20:58, Vincent Lefevre wrote:
> 
> >
> > Yes, and a consequence of this loss is that dpkg fails.
> > 
> 
> dpkg does not at all fail. If anything dpkg errors out because Apache's
> maintainer script failed, because "invoke.rc-d apache2 restart" failed,
> because ... you guess it, somebody removed the .load symlinks we expect
> to be there.

As a mere bystander I still don't really understand the underlying
issue. You're basically saying that /some/ conffiles are kept, and
others are purged and reinstalled?

Possible radical solution: abandon old apache binary package names
[of those that ship conffiles], introduce a new set of names,
Conflict/Break (but not Replace?) the old ones and have all modules
depend on the new packages.
3rdparty module packages will then prevent upgrades or get
deinstalled, and users get a fresh config that works, but may not do
anything useful.

  C.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722231901.gb96...@sx.home.zeha.at

Re: systemd now appears to be only possible init system in testing

[Julian Gilbey]

On Wed, Jul 23, 2014 at 12:51:16AM +0200, Svante Signell wrote:
> Forward this to the debian CTTE, please!

Thanks for the suggestion, Svante!  I've just reread
https://www.debian.org/devel/tech-ctte and it does not yet seem
appropriate for the CTTE; there has not yet been any discussion with
the relevant package maintainers.

A bit more searching (reading the relevant changelogs) has shown that
bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
more information about this issue.

It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
new version of systemd-shim will be able to be uploaded, which will
allow libpam-systemd to coexist with sysvinit once again.

It's just a shame that various migrations to testing were allowed
before this had been resolved :-(

Anyway, I would still love to know how to write a systemd script which
pauses to accept input from the keyboard before continuing.

   Julian

> On Tue, 2014-07-22 at 22:54 +0100, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?
> > Well, because the new version of libpam-systemd, 208-6, now depends on
> > systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> > remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> > much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> > network-manager, policykit-1, udisks2.
> > 
> > So I would presume that for many or most Debian systems, systemd is
> > now required, and no other /sbin/init providers will work.  I'm
> > unclear whether this was a deliberate policy decision or an unintended
> > consequence of various package requirements.
> > 
> > For me, this is a killer, as I still do not know how to solve the
> > problem I asked a while back on debian-user
> > (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> > summary, I need to unlock an encrypted filesystem during boot time by
> > asking for a password to feed into encfs.  But I cannot figure out how
> > to do this under systemd.
> > 
> > Answers to this question would also be much appreciated!
> > 
> >Julian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722230804.ga30...@d-and-j.net

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-23 01:19:01 +0200, Christian Hofstaedtler wrote:
> * Arno Töll  [140722 22:10]:
> > On 21.07.2014 20:58, Vincent Lefevre wrote:
> > > Yes, and a consequence of this loss is that dpkg fails.
> > 
> > dpkg does not at all fail. If anything dpkg errors out because Apache's
> > maintainer script failed, because "invoke.rc-d apache2 restart" failed,
> > because ... you guess it, somebody removed the .load symlinks we expect
> > to be there.
> 
> As a mere bystander I still don't really understand the underlying
> issue. You're basically saying that /some/ conffiles are kept, and
> others are purged and reinstalled?

The issue is that they are purged, but *not* reinstalled.

> Possible radical solution: abandon old apache binary package names
> [of those that ship conffiles], introduce a new set of names,
> Conflict/Break (but not Replace?) the old ones and have all modules
> depend on the new packages.
> 3rdparty module packages will then prevent upgrades or get
> deinstalled, and users get a fresh config that works, but may not do
> anything useful.

The issue is not with 3rd-party module packages (specifically),
but with the standard modules. And without these standard modules,
Apache cannot be started.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232912.gc3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Christian Hofstaedtler]

* Julian Gilbey  [140723 00:36]:
> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.

Can't directly help you with this, but the manual page text for
`--no-tty` reads as if it would do the opposite of what you actually
want to do.

  C.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722231233.ga96...@sx.home.zeha.at

Re: systemd now appears to be only possible init system in testing

[Steve Langasek]

On Tue, Jul 22, 2014 at 10:54:55PM +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.  OK, so I'll
> remove libpam-systemd.  Ooops - that looks pretty disastrous, as so
> much depends on it, so that's not an option: gdm3, gnome-bluetooth,
> network-manager, policykit-1, udisks2.

> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.

See bug #752939, which is currently blocked on cgmanager, which was in the
NEW queue but for some reason seems to have been rejected rather than
accepted.

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


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Marco d'Itri]

On Jul 22, Julian Gilbey  wrote:

> So I would presume that for many or most Debian systems, systemd is
> now required, and no other /sbin/init providers will work.  I'm
> unclear whether this was a deliberate policy decision or an unintended
> consequence of various package requirements.
It is a consequence of systemd-shim not being ready at the time systemd 
was last updated in unstable. I understand that now it is, but it still 
waiting for NEW processing of one of its dependencies.
If you care so much then maybe you could help the maintainers.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?
> Well, because the new version of libpam-systemd, 208-6, now depends on
> systemd-sysv rather than systemd-sysv | systemd-shim.

As you can see with this dependency, you just need to install
systemd-shim. No need to install systemd-sysv!

The default (systemd-sysv) was just a poor choice from aptitude.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232452.gb3...@xvii.vinc17.org

Disclaimers (was: Re: systemd now appears to be only possible init system in testing)

[Christian Hofstaedtler]

* Norbert Preining  [140723 01:09]:
> [ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE CONTINUING ]
> This email is the personal opinion of its author.
> As we are not allowed to criticize due to the newly installed 
> Code of Conduct, you are required to pre- or postfix *every* sentence
> in the following email with one of the following fragments:
>   . I thing it might be an option to say that 
>   . I could reach the opinion that under certain circumstances ...
>   . In my all too humble opinion, which is not important, ...
> Failure to do the above will result in wrong interpretation of the
> following email, so stop reading here if you are not ready to do that.
> [ COC DISCLAIMER ENDS HERE ]

How does "write a disclaimer in the hope of justifying possible
violations of rules instead of doing something productive" fit into
anybody's applied business logic?

  C.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722232628.ga96...@sx.home.zeha.at

all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Holger Levsen]

Hi,

(as this thread has already attracted two "interesting replies", I'll try 
again to convey the message which has not been heard yet... I don't have high 
hopes this thread won't become a flamefest, but I want to at least try to kill 
the flames before they explode...)

(And if you know systemd, please scroll down and help Julian with his actual 
question...)

On Dienstag, 22. Juli 2014, Julian Gilbey wrote:
> I just tried updating testing on my system.  I currently use
> sysvinit-core (reasons below), but aptitude is telling me that I
> should remove this in favour of systemd-sysv.  Hmm, why is that?

Because all modern desktops now need systemd so all features work. blame 
upstream^w^wsend patches to upstream and Debian will have those...

Really, get over it or do something. Ranting on -devel will not change 
anything. 

And this is actually pretty old news too: see 
http://layer-acht.org/thinking/blog/2014-06-03-systemd-mostly-harmless/

Thank you.

> So I would presume that for many or most Debian systems, systemd is
> now required

s#most Debian systems#most Debian desktop systems#

> For me, this is a killer, as I still do not know how to solve the
> problem I asked a while back on debian-user
> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
> summary, I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
> Answers to this question would also be much appreciated!

I hope someone will be able to help Julian with this question...


cheers,
Holger




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

Re: systemd now appears to be only possible init system in testing

[Charles Plessy]

Le Wed, Jul 23, 2014 at 12:08:04AM +0100, Julian Gilbey a écrit :
> 
> Anyway, I would still love to know how to write a systemd script which
> pauses to accept input from the keyboard before continuing.

Hi Julian,

I suggest to ask this question on 
pkg-systemd-maintain...@lists.alioth.debian.org
or even on systemd-de...@lists.freedesktop.org.  Pepole there are supportive and
may be able to help you to find the way to boot your encrypted filesystem while
using systemd.

On debian-devel unfortunately, there are too many people who will actively
repel any attempt of solving your problem (a few pepole are enough to destroy
the productivity of a mailing list).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722233445.gc17...@falafel.plessy.net

Re: Solutions for the Apache upgrade hell

[Arno Töll]

On 23.07.2014 01:19, Christian Hofstaedtler wrote:
> Possible radical solution: abandon old apache binary package names
> [of those that ship conffiles], introduce a new set of names,
> Conflict/Break (but not Replace?) the old ones and have all modules
> depend on the new packages.
> 3rdparty module packages will then prevent upgrades or get
> deinstalled, and users get a fresh config that works, but may not do
> anything useful.

That's exactly what we do. The Apache2 (Wheezy) packaging is a bit
simplified:

- apache2: empty meta package
- apache2.2-common: conffiles, MPM management, executables, init
scripts, maintainer scripts
- apache2.2-bin: modules and executables outside $PATH

Third party packages depend on apache2.2-common as they interact with
a2enmod, .load files etc.

Apache 2.4 packaging (Jessie) is

- apache2: maintainer scripts, conffiles
- apache2-bin: binaries, modules
- apache2-data shared arch:all data

In Wheezy, modules depend on apache2.2-common for historical reasons (I
guess, this predates my involvement into the package). For the upgrade
we need to get rid of those modules, as their ABI is not compatible to
Apache 2.4. At runtime this will fail to run, with Apache erroring out
because of incompatible shared module libraries being loaded into the
binary.

Therefore, we must get rid of the apache2.2-common package so that dpkg
forces removal of those module depending on that. If we Provide:
apache2.2-common in apache2, dpkg would consider the dependency
satisfied and we run into the same problem again. Likewise, if we add a
transitional package depending on apache2 [1].

Now, the usual upgrade process is this (consider related transitional
packages are in place to make this happen):

- install apache2{-bin,-data}
- preinst apache2 checks the apache2.2-common conffiles and transitions
them to apache2 by taking them over
- force removal of old modules as there is no apache2.2-common anymore
- postinst apache2 refreshes our stuff, does lots of upgrade handling etc


However, if you call aptitude --purge-unused:

- apt purges apache2.2-common. This calls apache2.2-common's postrm
purge, wiping all our configuration
- install apache2{-bin,-data}
- preinst apache2 detects an upgrade, but has no clue about the previous
state, because apt purged everything before we could look at it
- force removal of old modules as there is no apache2.2-common anymore
- postinst apache2 is a bit helpless and works through, but does not
treat the installation as new and does therefore not set system defaults
as it thinks "we're upgrading"


As soon as we add in addition to all this cruft an apache2.2-common
transitional package, apt does not purge the package anymore, and we can
properly upgrade. However, this comes at the side effect, that all old
and ABI breaking modules aren't forcibly removed causing havoc at
runtime later unless we add lots of versioned breaks [2].


[1] which is in NEW as of today by the way
[2]
http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/control?id=596d18e0bc7e23b2a897f4e1bfb4f1864c8d373e#n127

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: systemd now appears to be only possible init system in testing

[Vincent Lefevre]

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:
> On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?
> > Well, because the new version of libpam-systemd, 208-6, now depends on
> > systemd-sysv rather than systemd-sysv | systemd-shim.
> 
> As you can see with this dependency, you just need to install
> systemd-shim. No need to install systemd-sysv!
> 
> The default (systemd-sysv) was just a poor choice from aptitude.

Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722233957.gd3...@xvii.vinc17.org

Re: systemd now appears to be only possible init system in testing

[Matthias Urlichs]

Hi,

Julian Gilbey:
> I need to unlock an encrypted filesystem during boot time by
> asking for a password to feed into encfs.  But I cannot figure out how
> to do this under systemd.
> 
"encfs --extpass=systemd-ask-password" ?

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140722234438.ge15...@smurf.noris.de

Re: systemd now appears to be only possible init system in testing

[Ben Finney]

Norbert Preining  writes:

> [ IMPORTANT - COC DISCLAIMER - IMPORTANT - PLEASE READ BEFORE
> CONTINUING ]

Writing a disclaimer doesn't exempt you from the Code of conduct in
Debian forums. Please don't violate it again.

-- 
 \  “It's up to the masses to distribute [music] however they want |
  `\… The laws don't matter at that point. People sharing music in |
_o__)their bedrooms is the new radio.” —Neil Young, 2008-05-06 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85d2cxot2z@benfinney.id.au

Re: Solutions for the Apache upgrade hell

[Arno Töll]

On 23.07.2014 01:19, Vincent Lefevre wrote:
> BTW, I'm wondering whether the fact that "invoke.rc-d apache2 restart"
> fails should make the postinst script fail and affect the whole upgrade.

It does actually as we fixed #716921 a while back.

> If the goal is to make the user notice that Apache doesn't run, this is
> rather unnecessary: In any case, the user should test his web server
> after an Apache upgrade (or other major upgrade in the system), even
> when everything seems fine during the upgrade. This should be regarded
> more as a "run-time" failure than an "install-time" failure.
> 

... which we do. Yet people, including you, blame us for that data loss
as you start the (re-)server at runtime afterwards even though the
installation completes.  :-)

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Holger Levsen  writes:
> On Dienstag, 22. Juli 2014, Julian Gilbey wrote:

>> For me, this is a killer, as I still do not know how to solve the
>> problem I asked a while back on debian-user
>> (https://lists.debian.org/debian-user/2014/04/msg01286.html): in
>> summary, I need to unlock an encrypted filesystem during boot time by
>> asking for a password to feed into encfs.  But I cannot figure out how
>> to do this under systemd.
>> 
>> Answers to this question would also be much appreciated!

> I hope someone will be able to help Julian with this question...

This is just speculation, and I've not tried this, but my first thought in
reading this message is that the --no-tty part is a mistake.  The
documentation of that option says:

When run with no TTY or with --no-tty it will query the password
system-wide and allow active users to respond via several agents. The
latter is only available to privileged processes.

However, you're doing this during boot, so there *are* no active users,
since the system hasn't come up far enough to let anyone log in yet.  So
it makes sense that you don't get a prompt.

I suspect you instead need to run systemd-ask-password with a tty.  Take a
look at systemd.exec(5) at the TTY* options for the systemd unit file.  I
suspect you need to write a unit file corresponding to your init script
that runs systemd-ask-password and uses TTYPath=/dev/tty1.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ha29ndyf@windlord.stanford.edu

Re: systemd now appears to be only possible init system in testing

[Ben Hutchings]

On Wed, 2014-07-23 at 00:08 +0100, Julian Gilbey wrote:
> On Wed, Jul 23, 2014 at 12:51:16AM +0200, Svante Signell wrote:
> > Forward this to the debian CTTE, please!
> 
> Thanks for the suggestion, Svante!  I've just reread
> https://www.debian.org/devel/tech-ctte and it does not yet seem
> appropriate for the CTTE; there has not yet been any discussion with
> the relevant package maintainers.
> 
> A bit more searching (reading the relevant changelogs) has shown that
> bugs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754984 contain a lot
> more information about this issue.
> 
> It seems that once cgmanager 0.27 is allowed into unstable from NEW, a
> new version of systemd-shim will be able to be uploaded, which will
> allow libpam-systemd to coexist with sysvinit once again.
> 
> It's just a shame that various migrations to testing were allowed
> before this had been resolved :-(
> 
> Anyway, I would still love to know how to write a systemd script which
> pauses to accept input from the keyboard before continuing.

I believe you're supposed to do that through plymouth (which does not
imply a graphical boot splash; it has a text mode as well).

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Steve Langasek]

On Wed, Jul 23, 2014 at 01:26:47AM +0200, Holger Levsen wrote:
> On Dienstag, 22. Juli 2014, Julian Gilbey wrote:
> > I just tried updating testing on my system.  I currently use
> > sysvinit-core (reasons below), but aptitude is telling me that I
> > should remove this in favour of systemd-sysv.  Hmm, why is that?

> Because all modern desktops now need systemd so all features work. blame 
> upstream^w^wsend patches to upstream and Debian will have those...

What they need is logind.  Saying "needs systemd" for things that need
logind is as hopelessly confusing as if you were to say it for things that
need udev.

logind itself currently needs systemd as PID 1, because systemd 208 was
uploaded to unstable (and has migrated to testing) before systemd-shim has
been updated for compatibility.

I have already opined that I think this was a bad idea and will not belabor
the point.

> Really, get over it or do something. Ranting on -devel will not change 
> anything. 

There was nothing in Julian's message which was a rant, so I don't think
this response is called for.  He *was* doing something about a systemd
integration problem that was a blocker for him - he was asking for help.

If we have to go through this same sequence of messages every time someone
asks on debian-devel for help with a systemd issue, it's going to be a long
release cycle.

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


signature.asc
Description: Digital signature

Re: Solutions for the Apache upgrade hell

[Vincent Lefevre]

On 2014-07-23 02:05:26 +0200, Arno Töll wrote:
> On 23.07.2014 01:19, Vincent Lefevre wrote:
> > BTW, I'm wondering whether the fact that "invoke.rc-d apache2 restart"
> > fails should make the postinst script fail and affect the whole upgrade.
> 
> It does actually as we fixed #716921 a while back.

OK, I forgot that (I solved the problem before this was fixed IIRC).

> > If the goal is to make the user notice that Apache doesn't run, this is
> > rather unnecessary: In any case, the user should test his web server
> > after an Apache upgrade (or other major upgrade in the system), even
> > when everything seems fine during the upgrade. This should be regarded
> > more as a "run-time" failure than an "install-time" failure.
> 
> ... which we do. Yet people, including you, blame us for that data loss
> as you start the (re-)server at runtime afterwards even though the
> installation completes.  :-)

Well, with the fix above, this is now a separate problem.
Unfortunately it seems that there are no really good solutions.
One can at least suppose that the user keeps backups, at least
before such a major upgrade. Now, thinking again about your
first mail:

> * Ignore the problem, and refer to the manpage of aptitude without
> proper fix etc. which clearly says "THIS OPTION CAN CAUSE DATA LOSS! DO
> NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING". The bad news is, we
> can't tell this before it's too late, such as in a NEWS file - and we
> know, everybody reads release notes too, right?

I don't understand that: Why is it too late? The NEWS.Debian file is
displayed by apt-listchanges *before* the user accepts the upgrade.
So, the user should be aware of the problem. If the user doesn't
read the NEWS.Debian file (which is there to present important
differences, regressions..., i.e. something that the user must
really know in general), then this is his fault.

Note: the NEWS.Debian part for apache2 2.4.1-1 is rather lengthy
(which is normal here). So, information related to data loss must
be put first, with a big WARNING, so that the user doesn't miss it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723013341.ge3...@xvii.vinc17.org

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Holger Levsen]

Hi Steve,

thanks for the technical details, much appreciated. 

On Mittwoch, 23. Juli 2014, Steve Langasek wrote:
> There was nothing in Julian's message which was a rant, so I don't think
> this response is called for.

Well, the subject (and also the body) conveyed the wrong message, that systemd 
is mandatory in Debian now. Which - as you also said - is wrong, at least for 
two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

And, even though the rest of Julians message was as you described, it 
attracted two quite flamatory replies at first...

> He *was* doing something about a systemd
> integration problem that was a blocker for him - he was asking for help.
> 
> If we have to go through this same sequence of messages every time someone
> asks on debian-devel for help with a systemd issue, it's going to be a long
> release cycle.

I totally agree with these parts - and while I do think this thread startly 
badly I also think it has become a much nicer one by now. Hopefully this is 
more like how systemd threads will be in future too ;)


cheers,
Holger



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

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Adam Borowski]

On Wed, Jul 23, 2014 at 03:58:32AM +0200, Holger Levsen wrote:
> Well, the subject (and also the body) conveyed the wrong message, that 
> systemd 
> is mandatory in Debian now. Which - as you also said - is wrong, at least for 
> two reasons: a.) it's logind, not systemd and b.) only desktops are affected.

apt-get install logind
E: Unable to locate package logind

If logind was detachable from systemd, it would be in a separate package.


For now, just use the last working version of policykit (0.105-4).

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140723023548.ga23...@angband.pl

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Tue, 22 de Jul 2014 a las 4:39 PM, Vincent Lefevre 
 escribió:

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:

 On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
 > I just tried updating testing on my system.  I currently use
 > sysvinit-core (reasons below), but aptitude is telling me that I
 > should remove this in favour of systemd-sysv.  Hmm, why is that?
 > Well, because the new version of libpam-systemd, 208-6, now 
depends on

 > systemd-sysv rather than systemd-sysv | systemd-shim.
 
 As you can see with this dependency, you just need to install

 systemd-shim. No need to install systemd-sysv!
 
 The default (systemd-sysv) was just a poor choice from aptitude.


Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.


I used this apt preferences part to keep systemd back to version 204 
until systemd-shim is updated:


   Package: systemd libsystemd-* libpam-systemd
   Pin: version 204*
   Pin-Priority: 1001

I noticed that not doing the libraries cause apt to try to upgrade them 
on dist-upgrade and do some weird operations like try to remove my 
current init system and install systemd-sysv or remove all of systemd, 
as well as NM and udisks and a lot of other packages.


Best wishes,
--
Cameron Norman

Re: all modern desktops need systemd, either send patches or life with it (Re: systemd now appears to be only possible init system in testing)

[Russ Allbery]

Adam Borowski  writes:
> On Wed, Jul 23, 2014 at 03:58:32AM +0200, Holger Levsen wrote:

>> Well, the subject (and also the body) conveyed the wrong message, that
>> systemd is mandatory in Debian now. Which - as you also said - is
>> wrong, at least for two reasons: a.) it's logind, not systemd and b.)
>> only desktops are affected.

> apt-get install logind
> E: Unable to locate package logind

> If logind was detachable from systemd, it would be in a separate package.

logind is also not mandatory in Debian now.  It's just required, upstream,
by all the major desktop environments.

I think one point Holger was making is that *desktop environments* are not
mandatory in Debian.  I have lots of Debian systems, including my desktop,
that don't run any desktop environment at all.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbqohjjh@windlord.stanford.edu

Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

[Paul Wise]

On Wed, Jul 23, 2014 at 6:09 AM, James Cloos  wrote:
>> "PW" == Paul Wise  writes:
>
>>> * Package name: fonts-adobe-sourcehansans-cn
>
> PW> Due to the need for Adobe's ADFKO, this will have to go to contrib.
> PW> IIRC ADFKO will become open source at some point and the font could
> PW> move to main then.
>
> AFAICT, fontforge has enough capability to convert the format of the
> files in the git repo into OTF files, at least.  Pehaps also combining
> those into the OTC files.
>
> The outlines are in the repo as type0 (collection of type1) format, but
> again fontforge can edit and save that format just as well as its own
> sfd format, so onecan argue that it is close enough to preferred src
> format.
>
> So it seems they are already dfsg-free, even without a dfsg-free release
> of adfko, yes?
>
> Or did I miss something which fontforge and/or fonttools cannot yet
> accomplish?

I would be happy to be proven wrong on this; feel free to package it
for main if fontforge can take the place of all the commands mentioned
in the upstream build system. The way to prove that would be to only
ship the non-OTF files in the source package and build the OTF files
at build time using fontforge. Adobe might be unhappy at us for
finding out we are using a non-standard build though, so it might be a
good idea to ping them about AFDKO becoming FLOSS and let them know we
will use fontforge until that happens. Might be a good idea to send
them a Makefile that uses fontforge too.

https://github.com/adobe-fonts/source-han-sans/blob/master/COMMANDS.txt
Ken Lunde 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gqjl7hjwuxd_-zzklj18-tk1krjn2ddc4fmt6xhfv...@mail.gmail.com

Re: Bug#755382: ITP: fonts-adobe-sourcehansans-cn -- “Source Han Sans CN” A sans-serif Pan-CJK font family (CN subset) that is offered in seven weights

[Paul Wise]

On Wed, Jul 23, 2014 at 11:24 AM, Paul Wise wrote:

> I would be happy to be proven wrong on this; feel free to package it
> for main if fontforge can take the place of all the commands mentioned
> in the upstream build system. The way to prove that would be to only
> ship the non-OTF files in the source package and build the OTF files
> at build time using fontforge. Adobe might be unhappy at us for
> finding out we are using a non-standard build though, so it might be a
> good idea to ping them about AFDKO becoming FLOSS and let them know we
> will use fontforge until that happens. Might be a good idea to send
> them a Makefile that uses fontforge too.
>
> https://github.com/adobe-fonts/source-han-sans/blob/master/COMMANDS.txt
> Ken Lunde 

FYI, I just contacted Ken about this. Apparently Read Roberts is in
the final stages of preparing to open-source AFDKO. Also Ken suggests
not using FontForge because in his experience, it often produces
malformed fonts.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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