Bug#766914: Patch dropping hardware access groups

2018-05-30 Thread Felipe Sateler 
On Tue, Jan 30, 2018 at 3:32 PM Felipe Sateler  wrote:

> Control: tags 766914 patch
> Control: tags 821424 patch
>
> Hi,
>
> Please find attached an (untested) patch dropping the hardware access
> groups.
>
>
I have reposted the patch as merge request:
https://salsa.debian.org/installer-team/user-setup/merge_requests/1

-- 

Saludos,
Felipe Sateler

Bug#766914: Patch dropping hardware access groups

2018-01-30 Thread Felipe Sateler 
Control: tags 766914 patch
Control: tags 821424 patch

Hi,

Please find attached an (untested) patch dropping the hardware access groups.


Saludos


0001-Drop-several-groups-from-the-default-user-groups.patch
Description: Binary data

Re: Bug#872598: udev-udeb: no input in graphical installer

2017-08-19 Thread Felipe Sateler 
On Sat, Aug 19, 2017 at 9:38 AM, Cyril Brulebois <k...@debian.org> wrote:
> Control: tag -1 patch
>
> Hi,
>
> (Again, please keep debian-boot@ in copy.)
>
> Raphael Hertzog <hert...@debian.org> (2017-08-19):
>> > I've only quickly glanced at the contents of both packages, and
>> > debdiff mentions no obvious issues (file lists are the same).
>>
>> I believe this is precisely the problem. The new udev-udeb should
>> include a new file:
>> diff --git a/debian/udev-udeb.install b/debian/udev-udeb.install
>> index 6a8e2108f..6758fef06 100644
>> --- a/debian/udev-udeb.install
>> +++ b/debian/udev-udeb.install
>> @@ -5,6 +5,7 @@ lib/udev/ata_id
>>  lib/udev/scsi_id
>>  lib/udev/cdrom_id
>>  lib/udev/rules.d/50-udev-default.rules
>> +lib/udev/rules.d/60-input-id.rules
>>  lib/udev/rules.d/60-cdrom_id.rules
>>  lib/udev/rules.d/60-persistent-input.rules
>>  lib/udev/rules.d/60-persistent-storage.rules
>>
>> I won't have the time to test this now but I believe it's the problem.
>
> That's absolutely correct. I've started by copying the file manually into
> the netboot-gtk mini.iso, and confirmed the fix. To be extra sure, I've
> rebuilt a systemd package with your change, and used the new udev udebs
> for a clean build, and that works as well.
>
> A timely fix would be appreciated, the breakage(s) in the graphical
> installer prevented us from releasing debian-installer over the past few
> weeks, and it would be great not to wait too long before we're able to do
> so, esp. with linux 4.12.6-1 having reached testing lately.
>
> Thinking about this, I'll check with debian-release@ and I might just
> freeze all udeb-producing packages right away. Winter has come.
>
>
>> It would be nice to have a fixed udev soon. Thank you Cyril for the
>> investigation!
>>
>> I wonder if it would be possible to have autopkgtest tests covering
>> udev-udeb...
>
> I'm still new to the whole autopkgtest thing, but from where I stand, the
> fact d-i is broken has been known for quite a while; the core issue is
> that nobody investigated this before I found some time. An easy way to be
> more proactive on the systemd side would be to make sure that new (and/or
> deleted) files in the udev and libudev1 binaries are detected by
> maintainers (esp. since udev.install uses wildcards for rules files, while
> udev-udeb.rules uses a static list), so that the update can be propagated
> to the udebs if relevant.

--fail-missing is broken on the udeb builds at the moment, so it is
not enabled. I'll try to fix this and enable it. This should help
catch these sort of issues in the future.

-- 

Saludos,
Felipe Sateler

Bug#866614: console-setup-linux: drop dependency on initscripts

2017-06-30 Thread Felipe Sateler 
On Fri, Jun 30, 2017 at 10:10 AM, Felipe Sateler <fsate...@debian.org>
wrote:

> Package: console-setup-linux
> Version: 1.165
> Severity: minor
> Tags: patch
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: initscripts-dep
>
> The package console-setup-linux Depends on:
>
> init-system-helpers (>= 1.29~) | initscripts
>
> Since i-s-h is already at the required version in stable, and i-s-h is
> Essential, the alternative is fully superfluous for debian. It would be
> nice to
> have this dependency dropped for buster. Patch against git is attached
>

I just noticed the same applies to console-setup-freebsd. The same change
should be applied there.

-- 

Saludos,
Felipe Sateler

Bug#866614: console-setup-linux: drop dependency on initscripts

2017-06-30 Thread Felipe Sateler 
Package: console-setup-linux
Version: 1.165
Severity: minor
Tags: patch
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: initscripts-dep

The package console-setup-linux Depends on:

init-system-helpers (>= 1.29~) | initscripts

Since i-s-h is already at the required version in stable, and i-s-h is
Essential, the alternative is fully superfluous for debian. It would be nice to
have this dependency dropped for buster. Patch against git is attached.

Saludos

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.48
ii  kbd 2.0.3-2+b1
pn  keyboard-configuration  

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
pn  console-setup  
diff --git a/debian/control b/debian/control
index 5857d6c..002a313 100644
--- a/debian/control
+++ b/debian/control
@@ -71,7 +71,7 @@ Section: utils
 Priority: optional
 Architecture: all
 Multi-Arch: foreign
-Depends: kbd (>= 0.99-12) | console-tools (>= 1:0.2.3-16), 
keyboard-configuration (= ${source:Version}), ${misc:Depends}, 
init-system-helpers (>= 1.29~) | initscripts
+Depends: kbd (>= 0.99-12) | console-tools (>= 1:0.2.3-16), 
keyboard-configuration (= ${source:Version}), ${misc:Depends}
 Suggests: console-setup
 Conflicts: console-setup-freebsd
 Breaks: console-terminus, console-cyrillic (<= 0.9-11), console-setup (<< 1.71)

Bug#857132: console-setup: additional info needed ?

2017-03-23 Thread Felipe Sateler 
On Thu, Mar 23, 2017 at 10:58 AM, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote:
>>
>> In Debian, we don't enable the systemd-vconsole component [1].
>
> This is good, but...
>
>> So there should be no console configuration happening from systemd's
>> side.
>
> ...suppose udev creates a new console.

As mentioned by Michael, this is not done by udev or systemd.

> Then it has to be initialized
> with some font, hasn't it?

When it is created, the udev rule should be fired. So
cached_setup_font.sh should be invoked again.

>  From my tests it seems that the font used
> for this initialization is the same as the font used on the current
> console.  Isn't it possible that sometimes this font is set only _after_
> udev has started the script cached_setup_font.sh by the following rule
>
> ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", 
> RUN+="/etc/console-setup/cached_setup_font.sh"
>
> however the font of the current console is read _before_ the script
> cached_setup_font.sh has had a chance to configure the font?

I don't know of any component that does that. Systemd-vconsole, as
mentioned by Michael, is not enabled in the debian packages.

However, I see the following in cached_setup_font:

setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz'

if ls /dev/fb* >/dev/null 2>/dev/null; then
for i in /dev/vcs[0-9]*; do
{ :
setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
    done
fi

Might it be that /dev/fb* do not exist during boot, and thus the font
is not loaded in all ttys?

-- 

Saludos,
Felipe Sateler

Bug#768062: Does not take already-selected alternate dependencies into account

2016-09-28 Thread Felipe Sateler 
On Tue, 04 Nov 2014 07:58:59 -0800 Josh Triplett  wrote:
> Package: debootstrap
> Version: 1.0.64
> Severity: normal
>
> Please see the analysis in bug 746578.
>
> The essential package "init" has:
> Depends: systemd-sysv | sysvinit-core | upstart
>
> The test in bug 746578 involved a modified libpam-systemd that had:
> Depends: systemd-shim (>= 8-2) | systemd-sysv
>
> The test invoked debootstrap like this:
> debootstrap --print-debs --no-check-gpg --include=libpam-systemd jessie $DIR 
> $MIRROR
>
> Given that set of constraints, debootstrap *should* install init,
> systemd-sysv, libpam-systemd, and *not* systemd-shim, since systemd-sysv
> already satisfies libpam-systemd's dependency.
>
> In addition to figuring that out automatically, debootstrap should at
> least have produced that result if given --exclude=systemd-shim, since
> no dependency requires debootstrap to add that back in.

Doing a full dependency resolver in debootstrap may be too difficut,
but excluding packages after resolution should be possible.

Maybe this is enough?

diff --git a/debootstrap b/debootstrap
index 084a541..a0a6000 100755
--- a/debootstrap
+++ b/debootstrap
@@ -584,8 +584,6 @@ if am_doing_phase finddebs; then

work_out_debs

-   base=$(without "$base $ADDITIONAL" "$EXCLUDE")
-
if [ "$RESOLVE_DEPS" = true ]; then
requiredX=$(echo $(echo $required | tr ' ' '\n' | sort | uniq))
baseX=$(echo $(echo $base | tr ' ' '\n' | sort | uniq))
@@ -613,6 +611,8 @@ if am_doing_phase finddebs; then
fi
fi

+   base=$(without "$base $ADDITIONAL" "$EXCLUDE")
+
all_debs="$required $base"
 fi


This currently prevents debootstrapping a system with dracut and a
linux image installed, as dracut conflicts with initramfs-tools (which
in turn is the first alternative on the linux image).

Saludos,

Re: Support for merged-/usr now in debootstrap; default for stretch?

2016-09-14 Thread Felipe Sateler 
On Wed, 14 Sep 2016 16:50:13 +0200, Pierre Chifflier wrote:

> On Wed, Sep 14, 2016 at 02:38:09PM +0000, Felipe Sateler wrote:
>> On Tue, 13 Sep 2016 22:36:58 +0200, Ansgar Burchardt wrote:
>> 
>> > Hi,
>> > 
>> > debootstrap in unstable can now install with merged-/usr, that is
>> > with /bin, /sbin, /lib* being symlinks to their counterpart in /usr. 
>> > Run
>> > 
>> >   debootstrap --merged-usr testing .../testing
>> >   http://deb.debian.org/debian
>> > 
>> > to give it a try.
>> > 
>> > It has been previously suggested to make this the default for (at
>> > least)
>> > new installations.  I think Russ' earlier mail[1] explains quite well
>> > why the "split" between / and /usr doesn't really work out for Debian
>> > these days and that trying to maintain it for some configurations
>> > (which are not documented) is mostly busy-work.  There is also a nice
>> > article on LWN[2] summarizing earlier discussions.
>> > 
>> > I found these arguments convincing enough and would like to see the
>> > default switched to merged-/usr for Stretch and later.  Possibly also
>> > switching systems on upgrade to the new scheme (not necessarily
>> > already in the Stretch release cycle).
>> 
>> I agree that merging /usr is a good thing to do. We should default to
>> that, and at some point force the merge somehow (via the usrmerge
>> package?
>> ). Ideally, stretch systems that are fresh-installed should have the
>> same configuration as stretch-upgraded systems, otherwise confusion
>> will ensue.
>> 
>> 
> Hi,
> 
> Except that breaks having different mount points, which is useful to
> enforce different mount options (my /usr is nodev,ro).

You seem to misunderstand. The proposal is to move everything from /bin, /
sbin, /lib{,64,32,...} into /usr/$dir. It does not prevent having /usr in 
a separate partition.

Please see the references in Ansgar's original mail.

> Does this mean this cannot be supported anymore ? It would be a step
> backward, security-speaking, if split /usr does not work at all.

Split /usr is still supported, but it has to be mounted by the initramfs. 
All initramfs providers in debian do so for stretch. Even more, having a 
split /usr that is not mounted by the initramfs is not supported:

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

-- 
Saludos,
Felipe Sateler

Re: Support for merged-/usr now in debootstrap; default for stretch?

2016-09-14 Thread Felipe Sateler 
On Tue, 13 Sep 2016 22:36:58 +0200, Ansgar Burchardt wrote:

> Hi,
> 
> debootstrap in unstable can now install with merged-/usr, that is with
> /bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run
> 
>   debootstrap --merged-usr testing .../testing
>   http://deb.debian.org/debian
> 
> to give it a try.
> 
> It has been previously suggested to make this the default for (at least)
> new installations.  I think Russ' earlier mail[1] explains quite well
> why the "split" between / and /usr doesn't really work out for Debian
> these days and that trying to maintain it for some configurations (which
> are not documented) is mostly busy-work.  There is also a nice article
> on LWN[2] summarizing earlier discussions.
> 
> I found these arguments convincing enough and would like to see the
> default switched to merged-/usr for Stretch and later.  Possibly also
> switching systems on upgrade to the new scheme (not necessarily already
> in the Stretch release cycle).

I agree that merging /usr is a good thing to do. We should default to 
that, and at some point force the merge somehow (via the usrmerge package?
). Ideally, stretch systems that are fresh-installed should have the same 
configuration as stretch-upgraded systems, otherwise confusion will ensue.

-- 
Saludos,
Felipe Sateler

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

2016-05-19 Thread Felipe Sateler 
On 18 May 2016 at 17:42, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote:
>>
>> Ok. I see that the rules file appears to invoke the scripts in /etc
>> directly. Is this intended
>
> Yes.  The keyboard is configured by /lib/console-setup/keyboard-setup.sh
> and the font by the scripts in /etc.
>
> Notice that /lib/console-setup/console-setup.sh does not run the scripts
> in /etc at all.  If necessary it runs setupcon.

Oh, right.

>
>> (IOW, shouldn't they invoke the wrappers at /lib/console-setup)?
>
> Although setupcon is an universal and reliable tool, this cames at a
> price --- it is slow.  Many people have complained that console-setup
> slows down the boot and thats the only reason I decided to use scripts
> in /etc instead of setupcon.
>
> By the way, the only thing /lib/console-setup/console-setup.sh does in
> addition to the scripts in /etc is to rebuild the scripts in /etc if
> necessary.  And it is necessary to rebuild these scripts only if the
> sysadmin modifies the console configuration by hand and doesn't run
> `setupcon --save-only` afterwards.  In this case the wrapper will
> rebuild the scripts in /etc during the first reboot.

OK, this clarifies things. Thanks.

>
>> But upstream systemd and udev have pushed for mounting /usr in the
>> initramfs for a long time,
>
> Is there a place where one can learn about such things?

AFAIK, there is no document I can point at for this particular thing
(which is a shame though). There is a page making the case for the
merged /usr (ie, drop the distinction between / and /usr), and this
necessitates that /usr is mounted before executing init (because init
will live in /usr)[1]. Russ Allbery did a short summary during a
recent thread discussing the same /usr merge in debian[2]

[1] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[2] http://article.gmane.org/gmane.linux.debian.devel.general/206431


>
>> Note that because it has no WantedBy line, this service will not be
>> actually executed during boot. If the service should run as part of
>> normal system boot, it should have either WantedBy=sysinit.target or
>> WantedBy=multi-user.target.
>> Services WantedBy=sysinit.target will be pulled in both single user
>> and multi user boots. Services in multi-user.target will only be
>> pulled in multi user boots.
>
> OK, then it has to be WantedBy=multi-user.target.  Rebuilding the
> scripts in /etc is not something we want in single user mode.

Right, writing to /etc is probably not something that should be done there.

-- 

Saludos,
Felipe Sateler

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

2016-05-18 Thread Felipe Sateler 
On 18 May 2016 at 07:59, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Wed, May 11, 2016 at 01:27:52PM -0300, Felipe Sateler wrote:
>>
>> Sure. Also, feel free to point me to what you have, and I can comment
>> on that as well.
>
> I've pushed the changes I made in git. The new version of
> keyboard-setup.service is more or less unchanged:
>
> [Unit]
> Description=Set the console keyboard layout
> DefaultDependencies=no
> Before=local-fs-pre.target
> Wants=local-fs-pre.target
> ConditionPathExists=/bin/setupcon
>
> [Service]
> Type=oneshot
> ExecStart=/lib/console-setup/keyboard-setup.sh
> RemainAfterExit=yes
>
> [Install]
> WantedBy=sysinit.target

This looks good to me.

> As for console-setup.service, this script doesn't actually configure the
> console (that is on Linux; on FreeBSD it does).  Therefore, I removed
> the instructions Before=system-getty.slice and WantedBy=sysinit.target.
> The actual configuration of the console is accomplished by udev (see
> /lib/udev/rules.d/90-console-setup.rules).

Ok. I see that the rules file appears to invoke the scripts in /etc
directly. Is this intended (IOW, shouldn't they invoke the wrappers at
/lib/console-setup)?

>
>> > What about the following additional instruction: RequiresMountsFor=/usr
>>
>> It would be redundant, as /usr is guaranteed to be mounted by the
>> initramfs (for stretch, both dracut and initramfs-tools do so). It
>> would cause no harm, though.
>>
>> Split-/usr without an initramfs that mounts /usr is not supported and
>> is likely to break.
>
> I suppose this is so only on Debian?  In order to support other
> nonstandard/future distributions I added this instruction.

It does no harm, so it is OK to leave there. But upstream systemd and
udev have pushed for mounting /usr in the initramfs for a long time,
so it is unlikely a systemd-based system will not have /usr mounted,
except as a misconfiguration.

>  So, now
> console-setup.service looks in this way:
>
> [Unit]
> Description=Set console font and keymap
> DefaultDependencies=no
> After=console-screen.service kbd.service local-fs.target
> RequiresMountsFor=/usr
> ConditionPathExists=/bin/setupcon
>
> [Service]
> Type=oneshot
> ExecStart=/lib/console-setup/console-setup.sh
> RemainAfterExit=yes


Note that because it has no WantedBy line, this service will not be
actually executed during boot. If the service should run as part of
normal system boot, it should have either WantedBy=sysinit.target or
WantedBy=multi-user.target.
Services WantedBy=sysinit.target will be pulled in both single user
and multi user boots. Services in multi-user.target will only be
pulled in multi user boots.

-- 

Saludos,
Felipe Sateler

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

2016-05-11 Thread Felipe Sateler 
On 11 May 2016 at 11:18, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote:
>>
>> > On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote:
>> >>
>> >> I meant the logic to determine if setupcon or the cached scripts
>> >> should be run. If in the future that part is changed (eg, the names
>> >> are changed, or more scripts are generated), there is no guarantee
>> >> the change will reach users, since they may have modified the init
>> >> script.
>
> Right now I am preparing some changes in console-setup and one of them
> is to implement your suggestion to move the logic out of the init
> scripts.

Excellent.

>
>> Would you be OK, until further development comes along, to use a
>> wrapper unit like this:
>
> And while I am reviewing your changes, I find (as expected) that there
> are things I don't understand.  So before I make changes and introduce
> bugs, I decided to ask.

Sure. Also, feel free to point me to what you have, and I can comment
on that as well.

>
>> [Install]
>> WantedBy=sysinit.target
>
> What is the purpose of this instruction?  Wouldn't it be possible to
> remove it at least for console-setup.service?

WantedBy is the equivalent of the LSB Default-Start directive. This
means that when the unit is enabled, it will be pulled in whenever
sysinit.target is started.

sysinit.target roughly corresponds to runlevel S. In particular, it is
both pulled in by multi user and single user boots, which AFAICT is
what we want for console-setup.

Note that Wants relationships do not mean anything for ordering: this
instruction does not specify that console-setup must finish for
sysinit.target to be considered active.

>
> Also, inside console-setup.service I find these:
>
>> After=console-screen.service kbd.service local-fs.target
>
> What about the following additional instruction: RequiresMountsFor=/usr

It would be redundant, as /usr is guaranteed to be mounted by the
initramfs (for stretch, both dracut and initramfs-tools do so). It
would cause no harm, though.

Split-/usr without an initramfs that mounts /usr is not supported and
is likely to break.

>
>> Before=system-getty.slice
>
> Nothing really serious is going to happen if this script is executed
> after getty.  Wouldn't it be better to remove this instruction?

The idea behind it was to guarantee console-setup had run before the
user could login to a console. Maybe it is not strictly necessary, but
I think it provides good user experience.

-- 

Saludos,
Felipe Sateler

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-04-25 Thread Felipe Sateler 
On 24 April 2016 at 16:32, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Fri, Apr 01, 2016 at 08:55:31PM -0300, Felipe Sateler wrote:
>>
>> I have uploaded a new version. I have not yet, however, secured commit
>> rights to d-i git repository. If you want to pull the changes before I
>> get the access, you can pull the signed tag from my fork:
>
> I noticed that you put the files *.service in the package
> console-setup-freebsd and (as far as I can tell) this doesn't seem an
> oversight but rather done by intention.  Why?

Yes, it was done on purpose.

>
> I think that the non-Linux ports of Debian do not use systemd or am I missing
> something?

No, they do not. But because the -freebsd package is Arch: all, it is
still installable on linux archs. So, if by some chance a -freebsd
package ends up installed in a linux arch, the cycle would not be
reintroduced. The cost would be a few KB extra space wasted on some
otherwise useless files. I think the tradeoff is acceptable.

I hope that makes sense.

-- 

Saludos,
Felipe Sateler

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-04-24 Thread Felipe Sateler 
On 24 April 2016 at 04:33, Christian PERRIER <bubu...@debian.org> wrote:
>
> Quoting Felipe Sateler (fsate...@debian.org):
> > I have uploaded a new version. I have not yet, however, secured commit
> > rights to d-i git repository. If you want to pull the changes before I
> > get the access, you can pull the signed tag from my fork:
> >
> > git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
> > debian/1.141
>
>
> I just added you to committers : I didn't notice this discussion when
> it happened and went on a problem when trying to upload a new version
> of the package --> my new version was 1.141 as it was built from git,
> and of course it was REJECTed as it conclicted with your upload.
>
> Would you mind pushing your changes to the D-I git? I'm more confident
> in you doing so than me merging from your git repo as my git skills
> are.let's say incomplete..:-)

Done. I did not reapply the changelog commit though.

-- 

Saludos,
Felipe Sateler

Re: Bug#821424: pulseaudio: Do not put normal users on group audio

2016-04-18 Thread Felipe Sateler 
On 18 April 2016 at 14:59, asu <a...@marian1000.go.ro> wrote:
>
>
> On 04/18/2016 07:36 PM, Felipe Sateler wrote:
>>
>> Control: reassign -1 debian-installer
>>
>> On 18 April 2016 at 13:06, Corcodel Marian <a...@marian1000.go.ro> wrote:
>>
>>> Any way pulseaudio is default sound server on debian and suggest to do
>>> not put
>>> users on audio group because cross interference with alsa programs, now
>>> alsa is
>>> for power users and pulseaudio is on default.
>>
>> Pulseaudio does not add the user to the audio group. I'm guessing the
>> installer does, so I reassign there.
>>
>>
> Pulseaudio  does not add users but can do erase all users from audio group.

We most certainly should not do that.

-- 

Saludos,
Felipe Sateler

Re: Bug#821424: pulseaudio: Do not put normal users on group audio

2016-04-18 Thread Felipe Sateler 
Control: reassign -1 debian-installer

On 18 April 2016 at 13:06, Corcodel Marian <a...@marian1000.go.ro> wrote:

> Any way pulseaudio is default sound server on debian and suggest to do not put
> users on audio group because cross interference with alsa programs, now alsa 
> is
> for power users and pulseaudio is on default.

Pulseaudio does not add the user to the audio group. I'm guessing the
installer does, so I reassign there.


-- 

Saludos,
Felipe Sateler

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-04-01 Thread Felipe Sateler 
On 19 March 2016 at 06:55, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote:
>>
>> Yet another one would be to have setupcon itself detect the existence
>> of the cached scripts.
>
> The only reason there are cached scripts is that people are complaining
> that console-setup is slow at boot.  The cached scripts contain the
> mininum configuration sufficient to configure the console.  If we run
> setupcon, we don't need cached scripts.
>
>> Would you be OK, until further development comes along, to use a
>> wrapper unit like this:
>
> Yes and thank you!
>
>> I plan to do a NMU fixing this bug via a unit like the above, please
>> tell me if you want to address this in some other way.
>
> However, I don't think it is appropriate to do a NMU with such changes.
> Instead you should make a regular upload of the package.  I don't know
> whether you have commit rights in the repository of Debian installer
> (where the sources of console-setup are), or not, but in any case I
> think you can obtain such rights in no time.

I have uploaded a new version. I have not yet, however, secured commit
rights to d-i git repository. If you want to pull the changes before I
get the access, you can pull the signed tag from my fork:

git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
debian/1.141

-- 

Saludos,
Felipe Sateler

Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot

2016-03-27 Thread Felipe Sateler 
On 26 March 2016 at 06:21, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Sat, Mar 26, 2016 at 12:53:45AM -0300, Felipe Sateler wrote:
>>
>> The cached scripts rely on the compiled keyboard maps to be present in
>> /tmp (presumably by having being saved by setupcon -k).
>
> Hm, this is totaly unexpected.  Normally the cached scripts rely on
> compiled keyboard maps in /etc.
>
> The only reason I can see the cached scripts rely on maps in /tmp is
> that /etc/ was read-only when `setupcon --save-only` was executed by
> /etc/init.d/console-setup.sh or `dpkg-reconfigure`.
>
> The cached scripts should never rely on files in /tmp and this is a bug
> I will have to fix somehow.  However, an important question we have to
> investigate here is this: why in your system the cached scripts rely on
> files in /tmp.

Interesting. Indeed, re-running console-setup.sh (after boot)
generates a new cached_setup_keyboard script that uses a file in /etc.
Even more, I cannot reproduce the original problem, and cannot find in
the code how did this happen in the first place (after all, the script
should not have been written to /etc either!)

But, maybe setupcon should force remove the cached script if it
contains references to /tmp (or better yet, the script does not match
/etc/console-setup/cached_*.map.gz)

-- 

Saludos,
Felipe Sateler

Bug#819288: console-setup-linux: keyboard-setup.sh init script (actually, the cached scripts) rely on /tmp, which may not be mounted at early boot

2016-03-25 Thread Felipe Sateler 
Package: console-setup-linux
Version: 1.141
Severity: normal

Hi,

The cached scripts rely on the compiled keyboard maps to be present in
/tmp (presumably by having being saved by setupcon -k). However, when
/tmp is a separate filesystem, this will never work, as the init script
is run to soon, and for memory-backed /tmp it can only work during the
same boot.

The cached stuff needs to be stored elsewhere.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.29
ii  initscripts 2.88dsf-59.3
ii  kbd 2.0.3-2
ii  keyboard-configuration  1.141

console-setup-linux recommends no packages.

Versions of packages console-setup-linux suggests:
ii  console-setup  1.141

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.59
ii  liblocale-gettext-perl  1.07-1+b1

Versions of packages console-setup depends on:
ii  debconf 1.5.59
ii  keyboard-configuration  1.141
ii  xkb-data2.17-1

Versions of packages console-setup suggests:
ii  locales2.22-4
ii  locales-all [locales]  2.22-4
ii  lsb-base   9.20160110

Versions of packages console-setup-linux is related to:
pn  console-common
ii  console-data  2:1.12-5
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.3-2
ii  systemd   229-3

-- debconf information:
* keyboard-configuration/model: Generic 105-key (Intl) PC
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/xkb-keymap: us
* keyboard-configuration/layout:
  console-setup/guess_font:
  keyboard-configuration/ctrl_alt_bksp: false
  console-setup/charmap47: UTF-8
  console-setup/fontsize-fb47: 8x16
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/modelcode: pc105
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/optionscode:
* keyboard-configuration/compose: No compose key
* keyboard-configuration/layoutcode: us
* keyboard-configuration/toggle: No toggling
  keyboard-configuration/unsupported_config_options: true
  console-setup/use_system_font:
  console-setup/fontsize-text47: 8x16
  console-setup/fontface47: Fixed
* keyboard-configuration/variantcode:
* keyboard-configuration/other:
  keyboard-configuration/unsupported_config_layout: true
  console-setup/codesetcode: Lat15
  keyboard-configuration/unsupported_options: true
  console-setup/fontsize: 8x16
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/altgr: The default for the keyboard layout
* keyboard-configuration/variant: English (US)
* keyboard-configuration/switch: No temporary switch
  console-setup/framebuffer_only:
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-03-19 Thread Felipe Sateler 
On 6 March 2016 at 19:29, Anton Zinoviev <an...@lml.bas.bg> wrote:
> Thank you for the useful explanations in your message!

Glad they are useful :)

>
> On Sun, Mar 06, 2016 at 02:51:34PM -0300, Felipe Sateler wrote:
>>
>> I meant the logic to determine if setupcon or the cached scripts should be
>> run. If in the future that part is changed (eg, the names are changed, or
>> more scripts are generated), there is no guarantee the change will reach
>> users, since they may have modified the init script.
>
> I see...  Yes, you are correct about this.
>
>> However, this is not exactly the same: if the cached script fails, then
>> setupcon would not be run.
>
> I was just pondering on the different options I had.  One of them was
> to change the cached script so that it runs setupcon when necessary.

Yet another one would be to have setupcon itself detect the existence
of the cached scripts.


>> Also, I would advise against having different logic in the systemd services
>> than in the init scripts: the maintenance burden is higher, and requires a
>> higher initial understanding from people not already familiar with the
>> package.
>
> I agree in 100% with this.

Would you be OK, until further development comes along, to use a
wrapper unit like this:

[Unit]
Description=Set the console keyboard layout
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
ExecStart=/etc/init.d/keyboard-setup.sh start
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target



And mutatis mutandis for console-setup.sh? While not being the optimal
setup, it works, and avoids reliance on the debian-specific runlevel S
support.

I plan to do a NMU fixing this bug via a unit like the above, please
tell me if you want to address this in some other way.

-- 

Saludos,
Felipe Sateler

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-03-06 Thread Felipe Sateler 
On 5 Mar 2016 17:01, "Anton Zinoviev" <an...@lml.bas.bg> wrote:
>
> On Fri, Mar 04, 2016 at 03:08:39PM -0300, Felipe Sateler wrote:
> >
> > > Unfortunately, I will not be able to maintain this file or to update
it
> > > in accordance with future changes in systemd.  So I suppose that
unless
> > > you or somebody else volunteers to maintain it, it will be better to
> > > continue without it.
> >
> > As long as the initscript does simple things, it should require very
> > little maintainance. While I can't commit to maintain it (I am no
> > expert in console matters), feel free to CC pkg-systemd-maintainers or
> > myself if you ever receive a bug about this.
>
> The reason I hesitate is that I am not a "normal" maintainer of
> console-setup.  While I have enough time for development related to
> console-setup, my limitations force me to allocate this time in batches
> with relatively large periods between them.  In fact, it won't be
> incorrect to say that most of the time other people take care of this
> package (one can easily observe this in the changelog).

As long as the systemd service keeps relatively close to what the init
script is doing, keeping the service file up to date is easy. The only
problematic parts would be if the dependencies are changing; but then there
are people that can answer questions.

It would be a bit harder if the systemd units and init scripts start
diverging.

>
> > >> Before=local-fs-pre.target
> > >> Wants=local-fs-pre.target
> > >
> > > What is the meaning of these two?
> >
> > This ensures it is run before systemd attempts to fsck and mount any
> > local filesystems. It is therefore a relatively appropriate
> > replacement for the checkroot dependency.
>
> What does 'Wants' do?  Is this some kind of optimization?

Wants means that whenever the service is started, the listed dependencies
should be started as well.

In systemd, ordering and functional dependencies are orthogonal, so there
are separate keywords to specify both. Ordering dependencies do not mean
that all the listed services will be activated, it only means: if these
units are part of the same transaction, then start them before (or after)
the declaring unit. The functional dependency means that if the service is
to be started, the listed units will be added to the transaction.

In this case, there is a small optimization: mounts and fsck services are
ordered after local-fs-pre, but do not depend on it. Thus on simple
scenarios the target is never incorporated into the boot transaction.
Services that should run before need to cause the target to be pulled in
explicitly, which is why keyboard-setup.sh would need to Want it.

There are more details about the target in the systemd.special manpage, and
about dependencies in systemd.unit.

>
> > There does not appear to be a keymap init script:
> >
> > These are created by the kernel when devtmpfs is mounted, and systemd
> > mounts /dev before starting any units, so they should be available,
> > yes.
>
> This is good.  It seems we don't need 'After'.

Right, it can be started as early as possible (and keymap removed from the
init script).

>
> > > One novelty in version 1.138 is that it is unnecessary to run setupcon
> > > in order to configure the console.  It is OK to configure the keyboard
> > > in this way, but this usually will be slower than what the script
> > > keyboard-setup.sh does -- instead of setupcon it runs
> > > /etc/console-setup/cached_setup_keyboard.sh and reverts to using
> > > setupcon only when this script doesn't exist of fails.
> >
> > IMO, the init script should be as dumb as possible, as it is a
> > conffile. Therefore all program logic should move outside the script
> > and into a helper script that lives in /lib. This way, improvements
> > are guaranteed to be shipped to users.
>
> The script /etc/console-setup/cached_setup_keyboard.sh is not a
> configuration file and the user is not supposed to edit it.  Since it is
> autogenerated, there is no problem to ship improvements to the users.
> (Under FHS this script would have to go in /var rather than in /etc,
> however, we need it while /var is not yet mounted.  Years ago, nobody at
> debian-devel could find a solution to this problem, so now console-setup
> violates this aspect of FHS.)

I meant the logic to determine if setupcon or the cached scripts should be
run. If in the future that part is changed (eg, the names are changed, or
more scripts are generated), there is no guarantee the change will reach
users, since they may have modified the init script.

>
> > The resulting unit would be:
> >
> > Conditi

Bug#804988: keyboard-configuration: Please drop dependency on initscripts package

2016-03-05 Thread Felipe Sateler 
On 5 Mar 2016 17:02, "Anton Zinoviev" <an...@lml.bas.bg> wrote:
>
> On Fri, Mar 04, 2016 at 11:23:52AM -0300, Felipe Sateler wrote:
> >
> > AFAICT, initscripts itself is only needed to ensure the Required-Start
> > dependency of keyboard-setup.sh. This problem is solved by replacing
> > the dependency with init-system-helpers (>= 1.29~), which will do the
> > right thing when initscripts is not installed (ie, not abort the
> > installation).
>
> Another problem is the $remote_fs dependency of console-setup.sh. See
> #621077.

The problem is fixed when init-system-helpers (>= 1.29~) is installed.
Update-rc.d has been modified so that when it detects that initscripts is
not installed, insserv is invoked in a way that doesn't fail if
dependencies are missing. Therefore, the dependency can be changed from
initscripts to init-system-helpers (>= 1.29~).

Saludos

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-03-04 Thread Felipe Sateler 
Control: reopen -1
Control: found -1 1.138

On 3 March 2016 at 08:24, Debian Bug Tracking System
<ow...@bugs.debian.org> wrote:
> Source: console-setup
> Source-Version: 1.138
>
> We believe that the bug you reported is fixed in the latest version of
> console-setup, which is due to be installed in the Debian FTP archive.

>* On Linux: move init.d/console-setup.sh out of singe user mode.
>  Closes: #796603, #816090.

There is still keyboard-configuration.sh in runlevel S. So this
problem is still present. I suggest including a service file like
this:

[Unit]
Description=Set preliminary keymap
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
After=udev.service keymap.service
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
EnvironmentFile=-/etc/default/locale
ExecStart=/bin/setupcon --keyboard-only
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target



-- 

Saludos,
Felipe Sateler

Bug#804988: keyboard-configuration: Please drop dependency on initscripts package

2016-03-04 Thread Felipe Sateler 
Control: reopen -1
Control: found -1 1.138

On Thu, 03 Mar 2016 11:21:32 + Anton Zinoviev <zinov...@debian.org> wrote:
> Source: console-setup
> Source-Version: 1.138
>
> We believe that the bug you reported is fixed in the latest version of
> console-setup, which is due to be installed in the Debian FTP archive.

> * Move the init scripts from keyboard-configuration to
>   console-setup-linux and console-setup-freebsd.  Closes: #805928.
>   Give them a .sh extension to make them sourcable.  Move the
>   dependency on initscripts to these two packages.  Closes: #804988.

Moving the dependency to another package does not remove the
dependency ;), so this bug is not fixed.

AFAICT, initscripts itself is only needed to ensure the Required-Start
dependency of keyboard-setup.sh. This problem is solved by replacing
the dependency with init-system-helpers (>= 1.29~), which will do the
right thing when initscripts is not installed (ie, not abort the
installation).

-- 

Saludos,
Felipe Sateler

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

2016-03-04 Thread Felipe Sateler 
On 4 March 2016 at 14:40, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Fri, Mar 04, 2016 at 11:23:54AM -0300, Felipe Sateler wrote:
>>
>> There is still keyboard-configuration.sh in runlevel S. So this
>> problem is still present.
>
> Yes.  The problem however is much smaller because this script does not
> require $remote_fs.

Right. The real problem however, is that rcS support is a
debian-specific patch, and the systemd maintainers would like to drop
it to decrease maintainance workload.

>> I suggest including a service file like this:
>
> OK.
>
> Unfortunately, I will not be able to maintain this file or to update it
> in accordance with future changes in systemd.  So I suppose that unless
> you or somebody else volunteers to maintain it, it will be better to
> continue without it.

As long as the initscript does simple things, it should require very
little maintainance. While I can't commit to maintain it (I am no
expert in console matters), feel free to CC pkg-systemd-maintainers or
myself if you ever receive a bug about this.

>
>> Description=Set preliminary keymap
>
> 'Set the console keyboard layout' is a better description.  The new
> console-setup is better optimized for speed and configures the keyboard
> only once.
>
>> Before=local-fs-pre.target
>> Wants=local-fs-pre.target
>
> What is the meaning of these two?

This ensures it is run before systemd attempts to fsck and mount any
local filesystems. It is therefore a relatively appropriate
replacement for the checkroot dependency.

>
>> After=udev.service keymap.service

These two were copied as-is from the LSB headers

>
> The reason for keymap.service is that the keymap of console-setup can
> take precedence to the keymap provided by the package kbd (I am not sure
> this package still configures the keyboard, in the past it did).

There does not appear to be a keymap init script:

% apt-file search etc/init.d/key
console-setup-freebsd: /etc/init.d/keyboard-setup.sh
console-setup-linux: /etc/init.d/keyboard-setup.sh
keystone: /etc/init.d/keystone

This can be dropped then.

>
> The keyboard configuration depends on the existence of /dev/null and
> /dev/tty[1-6].  I have no idea whether this small dependency requires
> udeb.service.

These are created by the kernel when devtmpfs is mounted, and systemd
mounts /dev before starting any units, so they should be available,
yes.

>
>> EnvironmentFile=-/etc/default/locale
>
> What does this do?  This file is used (optionally) only in abnormal
> situations.

It reads the key-value pairs from the file (if it exists), and exports
them as environment variables. Shell commands are not supported, only
assignments.

>
>> ExecStart=/bin/setupcon --keyboard-only
>
> One novelty in version 1.138 is that it is unnecessary to run setupcon
> in order to configure the console.  It is OK to configure the keyboard
> in this way, but this usually will be slower than what the script
> keyboard-setup.sh does -- instead of setupcon it runs
> /etc/console-setup/cached_setup_keyboard.sh and reverts to using
> setupcon only when this script doesn't exist of fails.

IMO, the init script should be as dumb as possible, as it is a
conffile. Therefore all program logic should move outside the script
and into a helper script that lives in /lib. This way, improvements
are guaranteed to be shipped to users.

I don't think it is reasonable to try to replicate the logic in
keyboard-configuration.sh via systemd dependencies. I would instead
split out a script as mentioned, and invoke that (instead of setupcon)
in the ExecStart line. If you do not want to extract the logic to a
separate script, then the course of action should be to drop the
EnvironmentFile, and have

ExecStart=/etc/init.d/keyboard-setup.sh start

to delegate all the logic to the init script.

Note that the important part for us is not the amount of work a given
runlevel S script does, but rather that the dependencies are defined
by the systemd unit, and not autoguessed from the LSB headers.


The resulting unit would be:


[Unit]
Description=Set the console keyboard layout
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
ExecStart=/etc/init.d/keyboard-setup.sh start
# Alternatively, if the setup logic is split to a separate script:
#ExecStart=/lib/console-setup/keyboard-setup.sh
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target

-- 

Saludos,
Felipe Sateler

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2016-02-29 Thread Felipe Sateler 
On 29 February 2016 at 15:22, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Mon, Feb 29, 2016 at 09:54:23AM -0300, Felipe Sateler wrote:
>>
>> On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev <an...@lml.bas.bg> wrote:
>> > tags 796603 + help patch
>>
>> I see you tagged this bug help. What can I do to help move this forward?
>
> Thank you.  In the new version I am preparing now (should be ready in a
> couple of days), this script will move out of runlevel S on Linux and on
> FreeBSD there is no systemd.

Interesting. Why is it no longer required during early boot?

> So it seems there will be no need for a
> systemd service unit.

Well, that depends on the value of "need" ;).  A systemd unit would
still be useful, as it allows better tracking by systemd of the
process. I can submit a systemd unit, after I see the end result of
this rework you are doing now.


-- 

Saludos,
Felipe Sateler

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2016-02-29 Thread Felipe Sateler 
Hi Anton,

On Mon, 22 Feb 2016 19:33:28 +0300 Anton Zinoviev <an...@lml.bas.bg> wrote:
> tags 796603 + help patch

I see you tagged this bug help. What can I do to help move this forward?


-- 
Saludos,
Felipe Sateler

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2015-11-03 Thread Felipe Sateler 
On 10 October 2015 at 09:54, Felipe Sateler <fsate...@debian.org> wrote:
> Control: tags -1 patch
>
> Missed the bug cc, sorry for the duplicate.
>
> On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote:
>> Am 01.09.2015 um 19:38 schrieb Felipe Sateler:
>>> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote:
>>>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote:
>>>>>
>>>>> Does console-setup actually need to be run before user services are
>>>>> started? My guess is that it only needs to run before getty, but it
>>>>> should not block other services that want to start.
>>>>
>>>> It should run before fsck.
>>>
>>> That is definitely not what the init script says[1]:
>>>
>>> # Provides:  console-setup
>>> # Required-Start:$remote_fs
>>
>> Right, the $remote_fs dependency means it's actually started pretty late.
>> I guess what Anton meant was keyboard-setup.
>
> OK, so I added 2 service files, and preserved the early startup. However:
>
> 1. keyboard-setup is setup very early at boot, before
> local-fs-pre.target so that it occurs before fsck (at least the ones
> that don't happen in the initrd).
> 2. The ordering on console-setup is relaxed so that it starts early,
> but after /usr and /usr/local are mounted and the root fs is remounted
> (so that it can be saved in /etc). At the same time, this will not
> delay any further services except the gettys by being
> Before=system-getty.slice (BTW, maybe we need a getty-pre.target?).

I have attached a new version. Changes:

1. Add ConditionPathExists (because the service is shipped in another package).
2. Add RemainAfterExit=yes. I was getting the service started multiple
times during boot.


-- 

Saludos,
Felipe Sateler
From 7bf25445c6c72e532235448e9342572a138cbccf Mon Sep 17 00:00:00 2001
From: Felipe Sateler <fsate...@debian.org>
Date: Sat, 10 Oct 2015 08:40:50 -0300
Subject: [PATCH] Add systemd units

---
 debian/changelog |  7 +++
 debian/keyboard-configuration.console-setup.service  | 16 
 debian/keyboard-configuration.keyboard-setup.service | 16 
 debian/rules |  8 
 4 files changed, 47 insertions(+)
 create mode 100644 debian/keyboard-configuration.console-setup.service
 create mode 100644 debian/keyboard-configuration.keyboard-setup.service

diff --git a/debian/changelog b/debian/changelog
index 8c7915f..0a63688 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+console-setup (1.134+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add systemd units
+
+ -- Felipe Sateler <fsate...@debian.org>  Thu, 08 Oct 2015 20:18:37 -0300
+
 console-setup (1.134) unstable; urgency=medium
 
   [ Colin Watson ]
diff --git a/debian/keyboard-configuration.console-setup.service b/debian/keyboard-configuration.console-setup.service
new file mode 100644
index 000..d75c3dd
--- /dev/null
+++ b/debian/keyboard-configuration.console-setup.service
@@ -0,0 +1,16 @@
+[Unit]
+Description=Set console font and keymap
+DefaultDependencies=no
+After=console-screen.service kbd.service local-fs.target
+Before=system-getty.slice
+RequiresMountsFor=/usr /usr/local
+ConditionPathExists=/bin/setupcon
+
+[Service]
+Type=oneshot
+EnvironmentFile=-/etc/default/locale
+ExecStart=/bin/setupcon --save
+RemainAfterExit=yes
+
+[Install]
+WantedBy=sysinit.target
diff --git a/debian/keyboard-configuration.keyboard-setup.service b/debian/keyboard-configuration.keyboard-setup.service
new file mode 100644
index 000..946b91f
--- /dev/null
+++ b/debian/keyboard-configuration.keyboard-setup.service
@@ -0,0 +1,16 @@
+[Unit]
+Description=Set preliminary keymap
+DefaultDependencies=no
+Before=local-fs-pre.target
+Wants=local-fs-pre.target
+After=udev.service keymap.service
+ConditionPathExists=/bin/setupcon
+
+[Service]
+Type=oneshot
+EnvironmentFile=-/etc/default/locale
+ExecStart=/bin/setupcon --keyboard-only
+RemainAfterExit=yes
+
+[Install]
+WantedBy=sysinit.target
diff --git a/debian/rules b/debian/rules
index d709312..1982d0d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -145,10 +145,18 @@ install-main: build
 		usr/share/console-setup/
 	dh_link -pkeyboard-configuration usr/share/X11/xkb/rules/xorg.lst \
 		usr/share/doc/keyboard-configuration/xorg.lst
+	dh_systemd_enable -pkeyboard-configuration \
+		--name keyboard-setup
+	dh_systemd_enable -pkeyboard-configuration \
+		--name console-setup
 	dh_installinit -pkeyboard-configuration \
 		--no-start --name keyboard-setup -- start 06 S .
 	dh_installinit -pkeyboard-configuration \
 		--no-start --name console-setup -- start 49 S .
+	dh_systemd_start -pkeyboard-configuration \
+		--no-start --name keyboard-setup
+	dh_systemd_start -pkeyboard-configuration \
+		--no-start --name console-setup
 
 .PHONY : install-bdf2psf
 install-bdf2psf: build
-- 
2.6.2

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2015-10-10 Thread Felipe Sateler 
On 10 October 2015 at 09:54, Felipe Sateler <fsate...@debian.org> wrote:
> On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote:
>> Am 01.09.2015 um 19:38 schrieb Felipe Sateler:
>>> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote:
>>>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote:
>>>>>
>>>>> Does console-setup actually need to be run before user services are
>>>>> started? My guess is that it only needs to run before getty, but it
>>>>> should not block other services that want to start.
>>>>
>>>> It should run before fsck.
>>>
>>> That is definitely not what the init script says[1]:
>>>
>>> # Provides:  console-setup
>>> # Required-Start:$remote_fs
>>
>> Right, the $remote_fs dependency means it's actually started pretty late.
>> I guess what Anton meant was keyboard-setup.
>
> OK, so I added 2 service files, and preserved the early startup.

On IRC it was pointed out that --save is not necessary under systemd:
/usr must always be mounted. However I decided to preserve it because:

1. I am not 100% sure that /usr is guaranteed to be mounted (the
initrd AFAIK does not handle all cases).
2. On reboot to sysv it would be good to preserve the files in /etc.

If /usr is actually guaranteed to be available, then we should drop
--save from both the init script and service file.

-- 

Saludos,
Felipe Sateler

Bug#796603: Fwd: Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2015-10-10 Thread Felipe Sateler 
Control: tags -1 patch

Missed the bug cc, sorry for the duplicate.

On 1 September 2015 at 17:54, Michael Biebl <bi...@debian.org> wrote:
> Am 01.09.2015 um 19:38 schrieb Felipe Sateler:
>> On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote:
>>> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote:
>>>>
>>>> Does console-setup actually need to be run before user services are
>>>> started? My guess is that it only needs to run before getty, but it
>>>> should not block other services that want to start.
>>>
>>> It should run before fsck.
>>
>> That is definitely not what the init script says[1]:
>>
>> # Provides:  console-setup
>> # Required-Start:$remote_fs
>
> Right, the $remote_fs dependency means it's actually started pretty late.
> I guess what Anton meant was keyboard-setup.

OK, so I added 2 service files, and preserved the early startup. However:

1. keyboard-setup is setup very early at boot, before
local-fs-pre.target so that it occurs before fsck (at least the ones
that don't happen in the initrd).
2. The ordering on console-setup is relaxed so that it starts early,
but after /usr and /usr/local are mounted and the root fs is remounted
(so that it can be saved in /etc). At the same time, this will not
delay any further services except the gettys by being
Before=system-getty.slice (BTW, maybe we need a getty-pre.target?).

Review welcome.

-- 

Saludos,
Felipe Sateler
From 7ed5dcd10e76b25304ca2584cd828be4aa61e61c Mon Sep 17 00:00:00 2001
From: Felipe Sateler <fsate...@debian.org>
Date: Sat, 10 Oct 2015 08:40:50 -0300
Subject: [PATCH] Add systemd units

---
 debian/changelog |  7 +++
 debian/keyboard-configuration.console-setup.service  | 14 ++
 debian/keyboard-configuration.keyboard-setup.service | 14 ++
 debian/rules |  8 
 4 files changed, 43 insertions(+)
 create mode 100644 debian/keyboard-configuration.console-setup.service
 create mode 100644 debian/keyboard-configuration.keyboard-setup.service

diff --git a/debian/changelog b/debian/changelog
index 73796fb..6b8dae1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+console-setup (1.133+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add systemd units
+
+ -- Felipe Sateler <fsate...@debian.org>  Thu, 08 Oct 2015 20:18:37 -0300
+
 console-setup (1.133) unstable; urgency=medium
 
   [ Updated translations ]
diff --git a/debian/keyboard-configuration.console-setup.service b/debian/keyboard-configuration.console-setup.service
new file mode 100644
index 000..67af770
--- /dev/null
+++ b/debian/keyboard-configuration.console-setup.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=Set console font and keymap
+DefaultDependencies=no
+After=console-screen.service kbd.service local-fs.target
+Before=system-getty.slice
+RequiresMountsFor=/usr /usr/local
+
+[Service]
+Type=oneshot
+EnvironmentFile=-/etc/default/locale
+ExecStart=/bin/setupcon --save
+
+[Install]
+WantedBy=sysinit.target
diff --git a/debian/keyboard-configuration.keyboard-setup.service b/debian/keyboard-configuration.keyboard-setup.service
new file mode 100644
index 000..d50247b
--- /dev/null
+++ b/debian/keyboard-configuration.keyboard-setup.service
@@ -0,0 +1,14 @@
+[Unit]
+Description=Set preliminary keymap
+DefaultDependencies=no
+Before=local-fs-pre.target
+Wants=local-fs-pre.target
+After=udev.service keymap.service
+
+[Service]
+Type=oneshot
+EnvironmentFile=-/etc/default/locale
+ExecStart=/bin/setupcon -k
+
+[Install]
+WantedBy=sysinit.target
diff --git a/debian/rules b/debian/rules
index d709312..1982d0d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -145,10 +145,18 @@ install-main: build
 		usr/share/console-setup/
 	dh_link -pkeyboard-configuration usr/share/X11/xkb/rules/xorg.lst \
 		usr/share/doc/keyboard-configuration/xorg.lst
+	dh_systemd_enable -pkeyboard-configuration \
+		--name keyboard-setup
+	dh_systemd_enable -pkeyboard-configuration \
+		--name console-setup
 	dh_installinit -pkeyboard-configuration \
 		--no-start --name keyboard-setup -- start 06 S .
 	dh_installinit -pkeyboard-configuration \
 		--no-start --name console-setup -- start 49 S .
+	dh_systemd_start -pkeyboard-configuration \
+		--no-start --name keyboard-setup
+	dh_systemd_start -pkeyboard-configuration \
+		--no-start --name console-setup
 
 .PHONY : install-bdf2psf
 install-bdf2psf: build
-- 
2.6.0

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2015-09-01 Thread Felipe Sateler 
On 1 September 2015 at 14:05, Anton Zinoviev <an...@lml.bas.bg> wrote:
> On Thu, Aug 27, 2015 at 03:18:17PM -0300, Felipe Sateler wrote:
>>
>> Does console-setup actually need to be run before user services are
>> started? My guess is that it only needs to run before getty, but it
>> should not block other services that want to start.
>
> It should run before fsck.

That is definitely not what the init script says[1]:

# Provides:  console-setup
# Required-Start:$remote_fs
# Required-Stop:
# Should-Start:  console-screen kbd
# Default-Start: S

The keyboard-setup script does, though[2]:

# X-Start-Before: checkroot


[1] 
http://sources.debian.net/src/console-setup/1.132/debian/keyboard-configuration.console-setup.init/
[2] 
http://sources.debian.net/src/console-setup/1.132/debian/keyboard-configuration.keyboard-setup.init/
-- 

Saludos,
Felipe Sateler

Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

2015-08-27 Thread Felipe Sateler 
On 23 August 2015 at 09:56, Cyril Brulebois k...@debian.org wrote:
 Hi,

 fsate...@debian.org fsate...@debian.org (2015-08-22):
 Package: keyboard-configuration
 Severity: important
 User: pkg-systemd-maintain...@lists.alioth.debian.org
 Usertags: init-rcs-service

 (maintonly considered slightly annoying.)

 Hi,

 Your package keyboard-configuration has an initscript that is enabled
 in runlevel S, but it does not provide a corresponding systemd
 service unit.

 Systemd generates units for all sysv init scripts that do not have a
 corresponding systemd unit. By default, it sets
 DefaultDependencies=yes, which means they get ordered after early
 boot has finished.

 The problem is that to preserve the runlevel S semantics, systemd in
 debian is currently[1] ordering all S services Before=sysinit.target.
 This target is particularly early in the boot sequence, which means
 that it is most of the time too strict. In turn, this means it is
 fairly easy to end up with dependency cycles. For an example, see bug
 [763315]. Do note that the cycle still exists with sysvinit, it is
 just that systemd complains more loudly.

 Please add a systemd unit for the given service with the appropriate
 dependencies, which most of the time will be less strict than
 Before=sysinit.target. In other cases, the script is simply not
 applicable in systemd, in which case the package should ship a
 symlink to /dev/null as /lib/systemd/system/initscript.service.

 We have prepared a transition wiki page[2] explaining the issue in
 more detail, and outlining some general guidance. Please refer to it
 as it will have useful information.

 If you have any other doubts, feel free to ask in
 pkg-systemd-maintain...@lists.alioth.debian.org

 (Talking more as d-i RM than possible comaintainer, which I'm not.)

 src:console-setup could probably do with more hands on it, especially
 given (very friendly) bug reports like #763695. If you guys had any time
 to spend on making sure boot time dependencies are correct, and possibly
 that boot time performances improve over time, that would be much
 appreciated.

Does console-setup actually need to be run before user services are
started? My guess is that it only needs to run before getty, but it
should not block other services that want to start.

If someone could answer that question it should be very simple to
provide a patch for this.

-- 

Saludos,
Felipe Sateler

Bug#763695: console-setup is slowest part of boot, not fast as setupcon manpage tells us

2015-04-22 Thread Felipe Sateler 
On Wed, 8 Oct 2014 18:27:04 +0300 Anton Zinoviev an...@lml.bas.bg wrote:
 On Wed, Oct 01, 2014 at 11:31:18PM +0200, Julian Andres Klode wrote:
 
  console-setup requires 800ms during a boot. The complete boot finishes
  in 4.1 seconds. This really should not be a shell script in the long
  term, but short term at least removing fast from the manual page
  would be a good idea...
 
  Here's a boot graph:
  https://people.debian.org/~jak/boot.svg

 One possible explanation is what Samuel Thibault proposed (for some
 reason setupcon doesn't use cached keymap).  The following is (may be)
 another explanation.

 I don't know how exactly recent Debian systems boot so the following is
 only a guess.  Considering that keyboard-setup.service uses only 190 ms
 compared to 823 ms for console-setup.service, I suppose that these 823 ms
 are caused by forked printf commands (by setupcon) waiting for the
 virtual consoles to become active.  So during most of these 823ms the
 scripts were waiting and didn't consume cpu resources.

 If my hypothesis is true, the proper fix is to improve the description
 console-setup.service in order to run it only after the virtual consoles
 become active.  This, however, is not something I can do (with my
 current knowledge).

I am experiencing the same problem. I edited setupcon to add set -x
at the beginning to help tracing where the slowness is. It doesn't
look like printf is at fault.

I also tried changing the amount of ACTIVE_CONSOLES in
/etc/default/console-setup but it did not make much of a difference (I
tried setting it to just tty1 and to the empty string).

Logs, plots and systemd-blame at
https://people.debian.org/~fsateler/console-setup/

Saludos


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caafdzj-mpu7mexwftcixqaec-1fjgegfp7z2jxldxzutp4b...@mail.gmail.com

Bug#758116: Please be verbose whether you would like to get your Blend promoted by tasksel

2014-09-03 Thread Felipe Sateler 
Hi,

On Wed, Sep 3, 2014 at 2:40 AM, Andreas Tille andr...@an3as.eu wrote:
 Hi,

 On Wed, Sep 03, 2014 at 07:45:12AM +0200, Per Andersson wrote:

 I don't think this is a particularly good measure since the blends are
 relatively unknown.

 I think it is not a measure for a sequence but rather a measure whether
 a Blend should be included or not.  For instance I missed
 multimedia-tasks in my list (for the simple reason that I have not seen
 any relevant commit since nearly one year).  But for sure multimedia is
 quite important for our users and perhaps the fact that there is a
 chance to prominently be shown in the installer might be a motivation
 for multimedia maintainers to review the tasks (both team members who
 previously commited to Git in CC).

Sorry for not commenting on the bug but we did start a discussion
within the multimedia team on wether we want to pursue this or not.
Unfortunately, there seems to not be enough manpower to actually
prepare a reasonable set of tasks. We did discuss what would be
desirable, but nobody actually stepped up and offered to do the job.

I would very much like to have the multimedia tasks included, but
unfortunately I think they are not high quality enough at the moment,
and I can't commit to improving them in the short term (ie, before the
freeze).

-- 

Saludos,
Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caafdzj8rzx2it7t+ko_jfd1ppqmsphzvn+zkm2e2+aneesw...@mail.gmail.com

Bug#583993: discover-pkginstall: Recommends ipw3954-source, which no longer exists

2010-06-01 Thread Felipe Sateler 
On Tue, Jun 1, 2010 at 02:29, Petter Reinholdtsen p...@hungry.com wrote:
 [Felipe Sateler]
 % discover-pkginstall -l
 ipw3945-source

 ipw3945 has been superseeded by the iwl drivers.

 Thank you for reviewing the discover-pkginstall behaviour. :)

 When did it become superseeded?  What does that mean for discover?
 Should some other package be proposed, or the ipw3945-source package
 not be proposed for newer versions of Debian?

Yes, ipw* should not be proposed anymore. Instead, firmware-iwlwifi
should be. But that's another bug (#464968).

-- 

Saludos,
Felipe Sateler



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

Bug#583993: discover-pkginstall: Recommends ipw3954-source, which no longer exists

2010-05-31 Thread Felipe Sateler 
Package: discover-data
Version: 2.2010.04.07
Severity: normal

% discover-pkginstall -l
ipw3945-source

ipw3945 has been superseeded by the iwl drivers.

-- Package-specific info:
lspci:
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory 
Controller Hub [8086:2a00] (rev 0c)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller [8086:2a02] (rev 0c)
00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller [8086:2a03] (rev 0c)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #4 [8086:2834] (rev 02)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #5 [8086:2835] (rev 02)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI 
Controller #2 [8086:283a] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio 
Controller [8086:284b] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express 
Port 1 [8086:283f] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express 
Port 2 [8086:2841] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express 
Port 4 [8086:2845] (rev 02)
00:1c.5 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express 
Port 6 [8086:2849] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #1 [8086:2830] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #2 [8086:2831] (rev 02)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI 
Controller #3 [8086:2832] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI 
Controller #1 [8086:2836] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge 
[8086:2448] (rev f2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HEM (ICH8M) LPC Interface 
Controller [8086:2815] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) 
IDE Controller [8086:2850] (rev 02)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) 
SATA AHCI Controller [8086:2829] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller 
[8086:283e] (rev 02)
03:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller 
[1180:0832] (rev 05)
03:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro 
Host Adapter [1180:0822] (rev 22)
03:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller 
[1180:0843] (rev 12)
03:01.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host 
Adapter [1180:0592] (rev 12)
03:01.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller 
[1180:0852] (rev ff)
09:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5906M Fast 
Ethernet PCI Express [14e4:1713] (rev 02)
0c:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG 
[Golan] Network Connection [8086:4222] (rev 02)

lsusb:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 038: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of 
BCM2046 Bluetooth)
Bus 003 Device 039: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth
Bus 003 Device 040: ID 0a5c:4502 Broadcom Corp. Keyboard (Boot Interface 
Subclass)
Bus 003 Device 041: ID 0a5c:4503 Broadcom Corp. 
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

loaded modules:
8086:2a02 drm
8086:2834 uhci_hcd
8086:2835 uhci_hcd
8086:283a ehci_hcd
8086:284b snd_hda_intel
8086:2830 uhci_hcd
8086:2831 uhci_hcd
8086:2832 uhci_hcd
8086:2836 ehci_hcd
8086:2850 ata_piix
8086:2829 ahci
8086:283e i2c_i801
1180:0832 firewire_ohci
1180:0822 sdhci_pci
1180:0843 ricoh_mmc
14e4:1713 tg3
8086:4222 iwl3945


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

discover-data depends on no packages.

Versions of packages discover-data recommends:
ii  pciutils  1:3.1.7-3  Linux PCI Utilities

discover-data suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:

Bug#345999: installation-report: Fails to detect CD

2006-02-20 Thread Felipe Sateler 
On Wednesday 11 January 2006 01:34, Felipe Sateler wrote:
 On Wednesday 11 January 2006 01:23, Frans Pop wrote:
  Felipe, could you send us the output of 'lsmod' for both the old
  installer (that worked) and the new one?

 That might be a problem, because the laptop is not currently here (it
 should back be in a couple of days). 

Unfortunately, I could never get a hold of that laptop for enough time to 
actually do that, and now the laptop is completely out of my reach, so I 
won't be able to check lsmod's output. Sorry.

-- 


 Felipe Sateler


pgpNtkae82vD0.pgp
Description: PGP signature