Re: Bug#956612: libpango-1.0-0: broken kerning since 1.44

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2020-06-26 at 00:16 +0200, Cyril Brulebois wrote:
> I thought severity was higher than that. Reasoning for serious is that
> rendering looks ***bad*** plus this breaking d-i's automated testing.
> 
> I'm told desktop users also suffer from that (cc-ing Corsac for a
> possible confirmation).

Yes indeed. If it's not possible to investigate this in Debian, at least
pushing it upstream would be nice.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl71p8IACgkQ3rYcyPpX
RFuB6Af/SYmXSjTqDnU48+e1v5E3Egk//1V+B5M93gn/4dvT1pZZS8klwQxc6obP
jcRYYHfyocyo78XMCdUPy5msTlxBawUrrk4y36JkkJxtPRtQg3QdIQLWvTAnyWyR
DHGGQqrqKbwhHoROom17wem8m5GxABG0BjFgET8YzfydMj+RsYVEgLCku/M7HiHB
d00jC3ReLR/2n019TW3YKVdpPmwmqcmY/EG9iZ/ZeJybD5M44cgonzSqpD3JbfOc
IxWkz3OWKhjeEUroIeCOPTF4ice5dMqI8niFFXuMflNW4XBfESVoJ3SuFKIXt5FV
p8ewCTGoMmgdLKNWMtYs1gabishdkA==
=O2NX
-END PGP SIGNATURE-

Bug#923460: di-netboot-assistant: selecting tftp folder from command line

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2019-02-28 at 21:34 +0300, Andreas B. Mundt wrote:
> I already draft-implemented this, seems to be pretty simple (and
> indeed usefull):
> 
> 
> https://salsa.debian.org/installer-team/netboot-assistant/commit/df7f7d6cb29add2f0f2d05800a19aaa76b95ca95
> 
> It needs some testing and I would like to do a bit general package
> polishing, but maybe we can still get this into buster (I have to
> check the deadlines).  So, if you find time, please test and report
> back as soon as possible.

Hi, that was fast.

It looks good at first sight, I can try it but there actually was other issues
I had with my use case (generating buster d-i for arm64) that I had to
manually download the installer.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlx5JOsACgkQ3rYcyPpX
RFvhVQf/TYU7g1BKtQavQ3xulLw2bgyyUIY9aGDrbNFgJFKx2XokaEs26wYfK0Eo
SfJMBIUY6IcbCaLLG5UbjUoGCE4XlnCmntMWRBxYC1OYwdZ+YEby32iHQcsal97c
NFu+enlRYML3FioOsWuO0OLS1nQ84inztsctLU7TIiUTi08xC3BuYTEHSXziN7Pd
XVk83Hr1dOUCn4A73iJyiUZ4DBWTMx1ZFy8JRqNGt3mR4NdTQcm1pkhGEhHG+nA0
1MBO2SxDVnye6/lDXugZCdS4zfAf+514nfQvVn06D/BckoEAaQSGJlTIsmJekKys
3wg8Mk5owxq1wMD2PjxNsJ8DBQhvpw==
=T7q4
-END PGP SIGNATURE-

Bug#923460: di-netboot-assistant: selecting tftp folder from command line

[Yves-Alexis Perez]

Package: di-netboot-assistant
Version: 0.59
Severity: wishlist

Hi,

I'd like to setup some netboot images for serving over PXE, storing
stuff in /var/lib/tftp is not practical for me. I'd like to be able to
specify the target directory from the command line, but it's apparently
not possible for now so I'm opening a wishlist bug.

Thanks in advance,
-- 
Yves-Alexis

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

Kernel: Linux 4.19.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages di-netboot-assistant depends on:
ii  curl  7.64.0-1
ii  wget  1.20.1-1

Versions of packages di-netboot-assistant recommends:
ii  grub-efi-amd64-bin2.02+dfsg1-11
pn  tftpd-hpa | atftpd | dnsmasq  

Versions of packages di-netboot-assistant suggests:
pn  dnsmasq | isc-dhcp-server | udhcpd  
ii  syslinux3:6.04~git20171011.af7e95c3+dfsg1-6
ii  vim-addon-manager   0.5.10

-- no debconf information

Bug#852646: [Pkg-xfce-devel] Bug#852646: task-xfce-desktop: please recommend atril not evince

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

control: tag -1 patch
On Fri, Jan 27, 2017 at 11:44:02PM +0100, Yves-Alexis Perez wrote:
> Also, atril seems to bring mate-desktop-common package, which is not yet
> present in Xfce installations. I don't really like that (and yes, I don't
> really like having too much gnome packages either)
> 
The dependency is now gone so I've done the change locally and pushed a
MR at https://salsa.debian.org/installer-team/tasksel/merge_requests/1

Regards,
- -- 
Yves-Alexis Perez
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlt2jN4ACgkQ3rYcyPpX
RFts8ggA4oimoElKgZCVQpmBNMVXQ0W92TjepllGR4QCFSE9Nuk58G2rSyNOWwAK
qTu07hM9EKGWT1O/7X2MrOkS6pJuxlOJnLCNxdoPUBzODRlt6dJYRv1ipMWvqXKY
bjItvfLPqcsFekP26nIn+s0eVeG65dyXUsb20NrbRnRozEEM/FevfkZSoP3rpfZv
YzuwT45/4OCiEAosZkOFLq8ivSTVCvngl4MWbQqxGjVjm0EUKdMpmc/Y3cQfYa5L
Crc2NZv7v1gxUUgB4V+UjR6GNVujzP+RZemkdAOuVY7I8Wm3/9DMgsivhQek97RJ
GECvJjNF4YK4EtfyZ9eThcB600gOtA==
=wtds
-END PGP SIGNATURE-

Re: Scheduling 9.5

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-06-05 at 15:44 +0200, Cyril Brulebois wrote:
> > Context: https://salsa.debian.org/kernel-team/linux/merge_requests/30
> 
> Many thanks for the heads-up. I'll be on the lookout for a possible
> late ABI bump then. Feel free to poke me when that gets accepted into
> p-u so that I can adjust our git branch and perform a few build and
> runtime tests.

This is now up to 4.9.106 and there will definitely be an ABI break. I missed
the thread start (I'm not subscribed to -release anymore), but in the quoted
text I can see there were three proposed dates for the 9.5 point release. May
26th and June 2nd are out of the equation now but is June 9th already
targeted?

If so, we really need to move forward on this (and it might be a bit late
already) if we want to make sure it builds everywhere.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlsWuPEACgkQ3rYcyPpX
RFs/qgf/QnAItR/yQtgU9bl7ab4YGSaKgeW98dVeray761S6G0hQVJRF4UvqsUk4
/ZWj2jsZbMFviGD0WbKHncsRzaY0rj9aRk19LPpSpyDLbkFvDaPYmVvHJ7f+3kbJ
IAdN/5O2kq61qoUBdR/LqlSkugzl0Hn8U+ETKzWzkLnNcLYl/A9k2vEBDs+WkSeV
/XQFyKYr21hfYxEA7ZZUT4DvcDVbFbEqdcIkADoH96TiMg1gwKYOHh+l2u1Cc9TC
XY6DS1hpZi9Iakl2hf+VQmNuW4QM9V0D711L8b17mI+4loH4fDW7bmdgKnm+tTYD
52T9NAd/v5Ym0IU5iOJyEoAtKtDuqQ==
=JxL5
-END PGP SIGNATURE-

Re: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Yves-Alexis Perez]

control: tag -1 -patch
On Thu, 2018-02-22 at 09:20 +0100, Geert Stappers wrote:
> Bugreport tagged with 'patch',  hope this helps.

Hi,

There is no patch in that bug report. While copying the whole directory might
be doable, it's not the first solution we would consider, and it would
definitely need a lot more testing.

Regards,
-- 
Yves-Alexis

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

Bug#832485: [Pkg-xfce-devel] Bug#832485: task-xfce-desktop: uninstallable on kfreebsd due to dependency on light-locker

[Yves-Alexis Perez]

On Sun, 2017-02-05 at 14:21 +0100, Christoph Egger wrote:
> Hi all!
> 
> Cyril Brulebois  writes:
> > Adding debian-bsd@ and pkg-xfce-devel@ to the loop:
> > 
> > Adam Borowski  (2016-07-26):
> > > Package: task-xfce-desktop
> > > Version: 3.35
> > > Severity: important
> > > 
> > > Hi!
> > > I'm afraid that the xfce task can't be currently installed on kfreebsd. 
> > > This is especially nasty as xfce is the default DE on that arch.
> > > 
> > > The reason is that it depends on light-locker, which is Linux only.
> > > A possible solution is to change that dependency to:
> > > Depends: light-locker|xscreensaver
> > > which would have the extra benefit of kind of alleviating #827562,
> > > with light-locker as the first alternative per the XFCE's team wishes.
> > > If you think that's a bad idea, the dependency could be arch specific.
> 
> FWIW kfreebsd support in lightlocker seems to really be trivial:

I definitely can add something like that, but did you have a chance to do an
actual test on kFreebSD?

Regards,
-- 
Yves-Alexis

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

Bug#852646: [Pkg-xfce-devel] Bug#852646: task-xfce-desktop: please recommend atril not evince

[Yves-Alexis Perez]

On Fri, 2017-01-27 at 23:42 +0100, Yves-Alexis Perez wrote:
> On Thu, 2017-01-26 at 05:41 +0100, Christian PERRIER wrote:
> > Quoting Adam Borowski (kilob...@angband.pl):
> > > Package: task-xfce-desktop
> > > Version: 3.39
> > > Severity: wishlist
> > > 
> > > Hi!
> > > Currently, the XFCE task pulls in evince, whose interface is really out
> > > of
> > > place outside of Gnome.  It'd be far better to install atril instead
> > > (from
> > > Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from
> > > a
> > > number of weird decisions taken by the Gnome project that make the user
> > > interface really inconsistent with XFCE components.
> > > 
> > > Atril is a fork of Evince, so base functionality is the same.
> > 
> > As usual: what's the stance of Xfce packages maintainers about this?
> 
> I'm not completely against that, we already went back and forth with evince,
> evince-gtk etc. for a long time. But while I do know and use evince, I don't
> know atril yet. I can surely try it, but I won't make a decision soon.

Also, atril seems to bring mate-desktop-common package, which is not yet
present in Xfce installations. I don't really like that (and yes, I don't
really like having too much gnome packages either)

Regards,
-- 
Yves-Alexis

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

Bug#852646: [Pkg-xfce-devel] Bug#852646: task-xfce-desktop: please recommend atril not evince

[Yves-Alexis Perez]

On Thu, 2017-01-26 at 05:41 +0100, Christian PERRIER wrote:
> Quoting Adam Borowski (kilob...@angband.pl):
> > Package: task-xfce-desktop
> > Version: 3.39
> > Severity: wishlist
> > 
> > Hi!
> > Currently, the XFCE task pulls in evince, whose interface is really out of
> > place outside of Gnome.  It'd be far better to install atril instead (from
> > Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from a
> > number of weird decisions taken by the Gnome project that make the user
> > interface really inconsistent with XFCE components.
> > 
> > Atril is a fork of Evince, so base functionality is the same.
> 
> As usual: what's the stance of Xfce packages maintainers about this?

I'm not completely against that, we already went back and forth with evince,
evince-gtk etc. for a long time. But while I do know and use evince, I don't
know atril yet. I can surely try it, but I won't make a decision soon.

Regards,
-- 
Yves-Alexis

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

Bug#849578: [Pkg-xfce-devel] Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Yves-Alexis Perez]

On Thu, 2016-12-29 at 07:58 +0100, Christian PERRIER wrote:
> > The advantages from parole player are, you don't need Qt dependencies from
> > vlc player. The parole player is written in Gtk+, runnig fine and need
> > the gstreamer framework only.
> > 
> > Please do set the parole player as default player in the
> > task-xfce-desktop meta package.

Actually I think the dependency was added when vlc was still GTK+. I'm not
really sure vlc is the only one adding Qt dependency, and I have the feeling
it's still the reference media player out there, so people usually expect it
to be there (although it might be in the common desktop task then).

Regards,
-- 
Yves-Alexis

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

Bug#827562: [Pkg-xfce-devel] Bug#827562: Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Yves-Alexis Perez]

On dim., 2016-06-19 at 09:59 +, Holger Levsen wrote:
>  
> I'm surprised this is news for you.

This is not. And we're not going anywhere.  
> 
> Depends are used when something doesnt work without the depends. XFCE
> definitly works without a screensaver.

So you actuallu missed my point, sorry. There's no such thing as “XFCE” (btw
it's Xfce). What we are talking about here is task-xfce-desktop which is
tasksel task representing “the default Debian Xfce desktop, as installed by d-
i”.

One stuff which might represent “Xfce” here is the 'xfce4' metapackage, which
doesn't have any relationship to light-locker but Depends on xfce4-session.
xfce4-session itself has a Recommends: on light-locker, and you can safely
remove it without removing xfce4-session (and xfce4 metapackage).
> 
> As I see it, your point is that you dont seem to understand recommends.

I think we can end the conversation here.
-- 

Yves-Alexis

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

Bug#827562: [Pkg-xfce-devel] Bug#827562: Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Yves-Alexis Perez]

On dim., 2016-06-19 at 09:19 +, Holger Levsen wrote:
> On Sun, Jun 19, 2016 at 11:08:56AM +0200, Yves-Alexis Perez wrote:
> > Because we *want* light-locker as part of the default Xfce install.
> 
> Well, having it in recommends is enough for that.

Then I don't see the point in having Depends: at all, let's replace every
Depends: by Recommends…

Anyway, I don't know what you want me to reply. I think I already made my
point.

Regards,
-- 

Yves-Alexis

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

Bug#827562: [Pkg-xfce-devel] Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Yves-Alexis Perez]

On dim., 2016-06-19 at 02:01 -0700, Leo L. Schwab wrote:
> On Sat, Jun 18, 2016 at 10:46:55AM +0200, Yves-Alexis Perez wrote:
> > task-xfce-desktop is for installation time, so here Depends is correct. We
> > want light-locker by default, but people are free to remove it afterwards
> > if
> > they know what they do.
> > 
>   Uh, no, because when you go to delete light-locker, aptitude stops
> you because deleting that hard dependency will break task-xfce-desktop.

Except that (unless that's actually wrong, but then noone told me in years)
task-xfce-desktop is here for install time. It's what we (the Xfce task
maintainers, which are also the pkg-xfce maintainers, which is actually just
me, but eh…) define as the Debian Xfce desktop.

So yes, we *want* light-locker in the default Debian Xfce desktop. But that
doesn't mean you can't use something else with the Xfce desktop environment
under debian: just remove light-locker. Yes, it'll remove task-xfce-desktop
(except that I've never seen it installed after a standard installer run, but
I don't do that very often either), but task-xfce-desktop is just a
metapackage anyway.

I hope the position is clearer now?

Regards,
-- 
Yves-Alexis

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

Bug#827562: [Pkg-xfce-devel] Bug#827562: Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Yves-Alexis Perez]

On dim., 2016-06-19 at 08:03 +, Holger Levsen wrote:
> On Sun, Jun 19, 2016 at 08:57:44AM +0200, Christian PERRIER wrote:
> > > task-xfce-desktop is for installation time, so here Depends is correct.
> > > We
> > > want light-locker by default, but people are free to remove it
> > > afterwards if
> > > they know what they do.
> 
> I still don't see why this cannot be achieved by recommends, which are
> installed by default…

Because we *want* light-locker as part of the default Xfce install.
-- 

Yves-Alexis

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

Bug#827562: [Pkg-xfce-devel] Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Yves-Alexis Perez]

On sam., 2016-06-18 at 07:25 +0200, Christian PERRIER wrote:
> Xfce people, could you please bring some input on that issue?

Sure.
> 
> TIA
> 
> Quoting Leo L. Schwab (ew...@ewhac.org):
> > Package: task-xfce-desktop
> > Version: 3.35
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > task-xfce-desktop has grown a dependency on the package
> > light-locker, which is billed as a lightweight alternative to
> > xscreensaver.
> > I suspect this is to track a similar change in xfce4-session, which
> > recently
> > also added a dependency for light-locker.

Indeed, we replaced xscreensaver by light-locker.
> > 
> > However, xfce4-session only Recommends light-locker; it does not
> > Depends on it.  light-locker at the moment doesn't seem to play well with
> > xscreensaver,

Well, obviously, they have the same role, they can't run both at one.

> >  and is something of a nuisance.  For those of us who prefer
> > xscreensaver, light-locker gets in the way.

Then you can just remove light-locker (that's why it's only a Recommends in
xfce4-session, and not a Depends).
> > 
> > I suggest that task-xfce-desktop reduce the dependency on
> > light-locker from Depends to Recommends.

task-xfce-desktop is for installation time, so here Depends is correct. We
want light-locker by default, but people are free to remove it afterwards if
they know what they do.

Regards,
-- 

Yves-Alexis

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

tasksel upload

[Yves-Alexis Perez]

Hi,

I've made some changes to tasksel recently, which I've pushed to the
repository. As there were some errors when pushing, I guess no mail was sent
to the list (not sure if it's usually the case anyway), so I'm sending a mail
to notify you. There's no urgency to the upload.

Here is the dpkg-parsechangelog output:

Source: tasksel
Version: 3.35
Distribution: UNRELEASED
Urgency: medium
Maintainer: Yves-Alexis Perez <cor...@debian.org>
Date: Fri, 18 Mar 2016 16:29:04 +0100
Changes:
 tasksel (3.35) UNRELEASED; urgency=medium
 .
   * debian/control:
 - replace iceweasel by firefox-esr now that it has entered the archive.
 - drop firefox language packages not present in the archive.
 - add light-locker to xfce dependencies
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mer., 2016-02-03 at 14:37 +0100, Cyril Brulebois wrote:
> [Context: packages shipping /bin with “funny” permissions, seen in stable.]
> 
> Yves-Alexis Perez <cor...@debian.org> (2016-02-03):
> > 
> > On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> > > 
> > > I didn't check the whole archive, but doing so might be interesting.
> > I did a quick check on a local mirror (which might be incomplete), and
> > found
> > three packages with errors:
> > 
> > dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
> > drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
> > dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
> > drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
> > dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep
> > bin/$
> > drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/
> > 
> > Note that lintian complains a lot about them:
> > 
> > lintian sed_4.2.2-4+b1_amd64.deb
> > W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key
> > Binary-only - copying to XS-Binary-only"
> > W: sed: latest-debian-changelog-entry-without-new-date
> > E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
> > W: sed: description-synopsis-starts-with-article
> > W: sed: non-standard-dir-perm bin/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip
> > usr/share/doc/sed/changelog.Debian.gz
> > W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
> > W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
> > W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
> > W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all
> > (or pipe to a file/program)
> > W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz
> > 
> > It looks like an umask problem at package build time. Right now it doesn't
> > seem to have obvious security issues (like world writable /bin) but I'm
> > not
> > too sure there are not other stuff hidden.
> > 
> > I guess it'd make sense to do an archive-wide lintian run to look for that
> > kind of mistakes, and then ask for stable binNMUs of the relevant
> > packages.
> It seems to me that lintian looks at testing/unstable (at least looking
> at https://lintian.debian.org/full/cl...@debian.org.html#sed_4.2.2-6),
> so I'm not sure this would help for stable.
> > 
> > 
> > What do you think?
> I think debian-release@ needs to be in the loop, doing so.
> 
Hey,

so as far as I can tell there was no reaction from -release (although I can
understand noone's really sure what to do here). Is it at least possible to
schedule binNMUs in stable for those affected packages so future installs
don't end up with bad permissions like these?

Regards,
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> I didn't check the whole archive, but doing so might be interesting.

I did a quick check on a local mirror (which might be incomplete), and found
three packages with errors:

dpkg -c debian/pool/main/s/sed/sed_4.2.2-4+b1_amd64.deb |grep bin/$
drwxrwxr-x root/root 0 2014-11-08 19:28 ./bin/
dpkg -c debian/pool/main/l/lpe/lpe_1.2.7-2_amd64.deb|grep bin/$ 
drwxrwxr-x root/root 0 2014-12-24 23:14 ./usr/bin/
dpkg -c debian/pool/main/u/ucspi-proxy/ucspi-proxy_0.99-1_amd64.deb|grep bin/$
drwxrwxr-x root/root 0 2014-08-10 18:08 ./usr/bin/

Note that lintian complains a lot about them:

lintian sed_4.2.2-4+b1_amd64.deb
W: sed: syntax-error-in-debian-changelog line 1 "unknown key-value key 
Binary-only - copying to XS-Binary-only"
W: sed: latest-debian-changelog-entry-without-new-date
E: sed: control-file-has-bad-permissions md5sums 0664 != 0644
W: sed: description-synopsis-starts-with-article
W: sed: non-standard-dir-perm bin/ 0775 != 0755
W: sed: package-contains-timestamped-gzip usr/share/doc/sed/changelog.Debian.gz
W: sed: non-standard-dir-perm usr/share/info/ 0775 != 0755
W: sed: package-contains-timestamped-gzip usr/share/info/sed.info.gz
W: sed: non-standard-dir-perm usr/share/locale/ 0775 != 0755
W: sed: non-standard-dir-perm ... use --no-tag-display-limit to see all (or 
pipe to a file/program)
W: sed: package-contains-timestamped-gzip usr/share/man/man1/sed.1.gz

It looks like an umask problem at package build time. Right now it doesn't
seem to have obvious security issues (like world writable /bin) but I'm not
too sure there are not other stuff hidden.

I guess it'd make sense to do an archive-wide lintian run to look for that
kind of mistakes, and then ask for stable binNMUs of the relevant packages.

What do you think?
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mar., 2016-02-02 at 16:23 +0100, HacKurx wrote:
> Hi,

Hey,

> I just saw that the /bin directory does not have the correct
> permissions (775 instead of 755).

Interesting, I saw that on few boxes but we didn't push the investigation too
far.

For other people: it matters because on a grsec enabled system with trusted
path execution, users are not able to execute binaries from folders with group
group writable bit. In this case the group is root so might not not matter
that much, but it's still a bit surprising (afaict /bin and /usr/bin have
always been 755). And not beeing able to execute stuff from /bin is a bit
surprising.

> This error is made during installation in the "target" directory.
> View capture.

It doesn't actually say much…
> 
> Tested by debian-8.3.0-amd64-netinst.iso

Good to know. I'm actually unsure if the problem lies in debootstrap or
somewhere else. debian-boot, any idea?

Regards,
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mar., 2016-02-02 at 16:48 +0100, Yves-Alexis Perez wrote:
> Good to know. I'm actually unsure if the problem lies in debootstrap or
> somewhere else. debian-boot, any idea?

Running:
debootstrap jessie jessie
ls -dl jessie/bin
drwxr-xr-x 2 root root 2240 Feb  2 17:02 jessie/bin

so it looks like it's not debootstrap itself (I've tried using jessie
debootstrap)

Regards,
-- 
Yves-Alexis



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

Re: Debian Jessie - Incorrect permissions on /bin directory

[Yves-Alexis Perez]

On mar., 2016-02-02 at 17:16 +0100, Cyril Brulebois wrote:
> Notice sed's being different.
> 
> I didn't check the whole archive, but doing so might be interesting.

Thanks for the investigation. That also means any package can change the
permissions on any folder (outside of /etc, I guess)? Or maybe it depends on
the installation order?

Regards,
-- 
Yves-Alexis



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

Bug#806936: /usr/share/debootstrap/functions: use tar -h in extract_dpkg_deb_data

[Yves-Alexis Perez]

On jeu., 2015-12-03 at 13:26 +0100, Cyril Brulebois wrote:
> 
> so BSD tar wouldn't get the fix for your usecase?

I guess not.
> 
> (Inspecting its code, ./tar/write.c is where symlink_mode is used, and
> only when writing an archive.)
> 
> 
> Looking at GNU tar I read:
> |  -h, --dereference
> |    follow symlinks; archive and dump the files they point to
> 
> I wasn't exactly sure about “dump” but src/extract.c's check on
> dereference_option seems to suggest that means tar -hxf would work;
> out of curiosity, did you test the proposed change?

Yes, on GNU tar 1.26 (latter version have a --keep-directory-symlink option
option which is even less portable).

Regards,
-- 
Yves-Alexis



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

Bug#806936: /usr/share/debootstrap/functions: use tar -h in extract_dpkg_deb_data

[Yves-Alexis Perez]

Package: debootstrap
Version: 1.0.75
Severity: normal
File: /usr/share/debootstrap/functions

Hi,

dpkg behavior is to preserve as hard as it can the current layout of the
filesystem wrt. symlink to directories: it will try not to replace a
symlink by a folder or even the opposite.

In debootstrap early stages, dpkg is not used (because not yet installed
in the target), but a custom implementatin using dpkg-deb|tar or ar is
used. Unfortunately, this implementation doesn't follow dpkg behavior,
and will happily replace a symlink by a dir.

I'm using debootstrap in a custom way where I need to create some
symlinks beforehand (for example some multiarches dirs like lib -> lib64
in / and /usr), it works fine with dpkg, but not with debootstrap early
extract.

Would it be possible to replace the tar call in extract_dpkg_deb_data
with tar -hxf so it will follow symlinks instead of replacing them?

Regards,
-- 
Yves-Alexis


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

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

Versions of packages debootstrap depends on:
ii  wget  1.17-1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.19-6

debootstrap suggests no packages.

-- no debconf information

Bug#792283: [Pkg-xfce-devel] Bug#792283: task-xfce-desktop: should only recommend (not depend on) xfce4

[Yves-Alexis Perez]

On lun., 2015-07-13 at 16:46 +0200, Cyril Brulebois wrote:
 Hi,
 
 Jonas Smedegaard d...@jones.dk (2015-07-13):
  Package: task-xfce-desktop
  Version: 3.32
  Severity: important
  
  task-xfce-desktop depends on xfce4.  While that may seem the very
  purpose of this package, it causes problem when e.g. wanting the 
  XFCE
  desktop environment but not GStreamer0.10.
  
  See bug#774282 for the concrete issue caused by this IMO too strict
  relationship.
  
  Similarly, the relationship with lightdm should probably be 
  relaxed.
 
 Let's ask pkg-xfce-devel@…

Well, at first sight, i'd say “no”. The whole point of the task-xfce
-desktop task is to install the Xfce desktop environment. So yes, we do
want xfce4.
Right now that means pulling gstreamer0.10, yeah, but since it's going
away anyway, that point will be moot soon.

So, again, no, that doesn't look like the right thing to do.

Regards,
-- 
Yves-Alexis


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

Bug#651650: #651650 tasksel-xfce-desktop: Dependency problem in netinst tasksel-xfce

[Yves-Alexis Perez]

On sam., 2015-05-09 at 00:13 +0200, Cyril Brulebois wrote:
 Joey Hess jo...@debian.org (2011-12-13):
  Yves-Alexis Perez wrote:
   It seems that this is something hurting a few people already, so maybe.
   I'm not too sure why pulseaudio is installed by default, but if
   xfce4-mixer doesn't work with the pulseaudio audiosink, then it might
   just be wise to just depend on the -alsa variant.
  
  When installing task-xfce4-desktop, gstreamer0.10-plugins-good etc are
  installed as dependencies of quodlibet, and provide gstreamer0.10-audiosync.
  
  (Pulseaudio does get pulled in, as a recommends of a vlc plugin, but
  gstreamer0.10-pluseaudio is not installed.)
  
  Another way this can happen is if a user has gnome previously installed
  and just installs xfce4 with apt. Perhaps gstreamer0.10-audiosync is
  really too broad a virtual package for xfce4-mixer to depend on?
 
 What shall we do with this bug report for stretch?

Considering gstreamer0.10 is on the way out and gstreamer1.0 doesn't
have mixer support, xfce4-mixer will unfortunately have to go to. I'm
unsure what will be able to replace it though.

Regards,
-- 
Yves-Alexis


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

Bug#777526: [Pkg-xfce-devel] Bug#777526: debian-installer: when installing xfce system only, quodlibet installed and gstreamer pulse module not

[Yves-Alexis Perez]

On lun., 2015-02-09 at 14:30 +0100, Cyril Brulebois wrote:
 Hello Xfce people,
 
 What's your take on this? Is an addition through the xfce task the
 best way?

I just saw that email, sorry for the delay. We're not responsible for
the pulseaudio part (I actually don't recommend it, and prefer using
plain alsa). So either pulseaudio came from another task (and one needs
to add the gstreamer plugin to it), or someone else added it to the Xfce
task (and you need to ask them because I sure don't know anything about
pulseaudio)

Regards,
-- 
Yves-Alexis


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

Bug#760778: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca

[Yves-Alexis Perez]

On dim., 2014-09-07 at 16:28 -0400, Joey Hess wrote:
 So, I see no problem with adding gnome-orca to task-xfce-desktop, given
 those installation size numbers.

I do.
 
 I sympathize with Yves in wanting to keep the xfce4-* packages
 containing only actual upstream XFCE stuff;

(OT: Yves-Alexis and Xfce)

  that's part of why we have
 the task packages to add currently missing (and in some ways suboptimal)
 bits -- including network-manager-gnome already.

No, that wasn't my point. I'm not against adding useful stuff to the
Xfce desktop environment. As I already stated, there's a somehow a goal
in Xfce to have a modular desktop, where you can use bits from here and
there and it works fine.

What I'm against is forcing stuff onto users which have exactly no need
for it. With that kind of reasoning we would install the complete set of
packages in every installed system “just in case”.

And again, I fail to see why this is about Xfce desktop. One can use GTK
stuff in a KDE desktop where I guess GTK+ a11y would work. One could be
blind and don't use a full DE but just a window manager.

I fail to see why a11y would be important enough to force it to Xfce
installations while not beeing important enough to force it to default
installations.

 
 Bear in mind that accessability is one of the most important criteria
 for picking the default desktop -- for the reasons Samuel has given.
 It could easily be *the* determining factor between xfce and gnome for
 jessie.

I already stated my position wrt. Xfce beeing the default desktop, I
think.
-- 
Yves-Alexis


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

Re: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca

[Yves-Alexis Perez]

On dim., 2014-09-07 at 21:13 +0200, Samuel Thibault wrote:
 Well, for a blind user, it *is*!...

Sure, but not everyone's blind. I sympathise with a11y, but forcing
gnome-orca on everyone won't happen.
 
 Anyhow, what do you propose to fix the accessibility of XFCE? Adding
 the
 dependency to task-xfce-desktop? (Cc-ed)

That's exactly the same thing. Just create an a11y subtask or whatever,
bringing everything needed?
-- 
Yves-Alexis


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

Re: [Pkg-xfce-devel] Bug#760778: xfce4-session: Please depend on gnome-orca

[Yves-Alexis Perez]

Control: tag -1 wontfix

On dim., 2014-09-07 at 21:53 +0200, Samuel Thibault wrote:
 Yves-Alexis Perez, le Sun 07 Sep 2014 21:15:19 +0200, a écrit :
  On dim., 2014-09-07 at 21:13 +0200, Samuel Thibault wrote:
   Well, for a blind user, it *is*!...
  
  Sure, but not everyone's blind.
 
 And not everyone speaks all languages on earth, yet we install all
 language files by default, which really eats a lot of disk by default,
 just because we can't know when one will need it because a random user
 happens to need it.  That is the same with accessibility.

Last time I did an install, a debconf question was actually asking about
the locale.
 
  I sympathise with a11y, but forcing gnome-orca on everyone won't
  happen.
 
 Well, that is actually precisely our goal: to have gnome-orca installed
 on all systems, ready to be started in case one needs it.

Then it's unrelated to Xfce, and you want to include that in the base
system. I would still disagree, but that wouldn't be my call anyway.
 
 There is this very simple scenario: you welcome a blind guest at home,
 and he'd like to use the home computer. Currently, with XFCE, you'd
 click on Enable assistive technologies, and unlog/relog. But nothing
 happens, no speech. You then have to connect to the Internet (who knows
 whether it works that day), look for why this is not working, eventually
 understand that you need to install the gnome-orca package, install it,
 etc. and at last it works.
 
 Another typical scenario is a public library with computers: there is
 very little hope that the user will manage to find out how to contact
 the sysadmin to get gnome-orca installed (and there is very little hope
 that the sysadmin will have already thought about installing it), so he
 will just not be able to use the computer at all.
 
 Yes, real accessibility means being available, ready to be enabled. Any
 barrier is really a killing pain for disabled people.

I'm sure you can find a lot of slightly convoluted scenarios. I'm sure
we can find a lot of them for a lot of packages, actually.
 
   Anyhow, what do you propose to fix the accessibility of XFCE? Adding
   the
   dependency to task-xfce-desktop? (Cc-ed)
  
  That's exactly the same thing. Just create an a11y subtask or whatever,
  bringing everything needed?
 
 That won't change the fact that we'll want to always install it by
 default (thus at least via a Recommends)

Again, I'd disagree with that, but still.
 
 Just to bring the figure in the discussion: from a base system,
 installing task-xfce-desktop without Orca uses 1596MiB. Adding Orca
 brings 1658MiB, so that's just a 3% increase.

That's not just a question of installed size. A lot of people want to
keep a somehow minimal system in term of disk, memory, CPU time, and
which doesn't get in their way. And some actually chose Xfce *for* that.

Even though it's quite hard to achieve these days, Xfce is designed to
be modular, and will (apparently) happily support gnome-orca if
installed. Fine.

In any case, the original bug was about adding dependency to
xfce4-session, and the answer is no (and the same applies to the xfce
task). If you want to add gnome-orca to the base system, I don't think
it's the right place.

Regards,
-- 
Yves-Alexis


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

Re: ***SPAM*** [Pkg-xfce-devel] systemd/logind integration of desktop environments

[Yves-Alexis Perez]

On ven., 2014-09-05 at 16:46 -0400, Joey Hess wrote:
 As part of the process described on this wiki page --
 https://wiki.debian.org/DebianDesktop/Requalification/Jessie
 We're requesting some information from each desktop team, as well
 as the systemd maintainers:

Hi,

what kind of reply do you expect? Direct reply, group reply, or direct
edit of the wiki page?

Regards,
-- 
Yves-Alexis


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

Re: Artwork for jessie?

[Yves-Alexis Perez]

On mar., 2014-08-12 at 21:18 +0200, Cyril Brulebois wrote:
 Hello desktop people,
 
 Jessie is approaching, it would be nice to know what's going to happen
 for this release. If there's no new artwork I suppose it's OK to stick
 to the current one, but stating that in advance of the freeze would be
 nice. :)
 
And in any case the extlinux themes need to be reworked since apparently
the 6.x package broke support for the previous themes.

Regards,
-- 
Yves-Alexis


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

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Yves-Alexis Perez]

On ven., 2014-08-08 at 18:38 -0700, Paul C. Bryan wrote:
 With all due respect to XFCE, I'd hate the interpretation to be along
 the lines of, Oh, Debian state of the art desktop environment feels
 something like Windows, circa 2000. But, XFCE's lightweight. It's
 meant
 to lack such fancy features.

I'm unsure what you mean by that. We don't do specific efforts to tune
Xfce appearance (that's not really our priority indeed), but you might
want to take a look at Xubuntu customization if eye candy is what
interest you.

Regards,
-- 
Yves-Alexis


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

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Yves-Alexis Perez]

On jeu., 2014-08-07 at 23:57 +0200, Jordi Mallach wrote:
 Hi Debian,

About the decision itself, as Debian Xfce main maintainer, I honestly
don't really care. I don't think the default desktop matters that much
on Debian (while I guess it means a lot for Ubuntu, for example). I
actually think having no default desktop would be just fine, instead
having the current 3-4 desktop installation media. Then anyone can pick
the DE she likes.

Now, about specific items:

 Downstream health: The number of active members in the team taking care of
 GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of Xfce.
 Being the default desktop draws a lot of attention (and bug reports) that only
 a bigger team might have the resources to handle.

Indeed. I somehow hoped that the attention brought on the initial switch
would bring more developpers to the pkg-xfce team, but that failed. But
I'm unsure how much people actually saw the switch, since it's only for
the current beta installers for Jessie…
 
 Upstream health: While GNOME is still committed to its time-based release
 schedule and ships new versions every 6 months, Xfce upstream is,
 unfortunately, struggling a bit more to keep up with new plumbing technology.
 Only very recently it has regained support to suspend/hibernate via logind, or
 support for Bluez 5.x, for example.

Same as above.

 Hardware: GNOME 3.12 will be one of the few desktop environments to support
 HiDPI displays, now very common on some laptop models. Lack of support for
 HiDPI means non-technical users will get an unreadable desktop by default, and
 no hints on how to fix that.

Well, considering Xorg harcodes DPI to 96, what's the problem anyway?
Also, with DPI correctly set to 140 on my Thinkpad (not really HiDPI but
still more than 96), the only problems I've seen is chromium since it
dropped GTK (#749239 where the URL bar font is oversized and the menu
fonts are unreadable).
 
 Security: GNOME is more secure. There are no processes launched with root
 permissions on the user’s session. All everyday operations (package 
 management,
 disk partitioning and formatting, date/time configuration…) are accomplished
 through PolicyKit wrappers.

That doesn't make much sense to me. It seems you're considering GNOME as
a distribution more than a desktop environment. That's not how Xfce sees
it. It relies on stuff like PolicyKit for interactions with hardware,
for example, but it doesn't really ship anything which should be run as
root. The user is free to do anything she wants, though.
 
 Privacy: One of the latest focuses of GNOME development is improving privacy,
 and work is being done to make it easy to run GNOME applications in isolated
 containers, integrate Tor seamlessly in the desktop experience, better disk
 encryption support and other features that should make GNOME a more secure
 desktop environment for end users.

Again, for me that's somehow unrelated to the DE, but my vision is less
about having a DE which does everything and more about having it only
handle things like session, window management, file management (each
component appart). It's perfectly possible to use GNOME components in
Xfce, and actually a lot of people do that.

 systemd embracing: One of the reasons to switch to Xfce was that it didn’t
 depend on systemd. But now that systemd is the default, that shouldn’t be a
 problem. Also given ConsoleKit is deprecated and dead upstream, KDE and Xfce
 are switching or are planning to switch to systemd/logind.

Not really. We relie on PolicyKit and used to use ConsoleKit because
that was somehow enforced on about everyone. Now ConsoleKit has been
deprecated, and the same people now enforce libpam-systemd and logind.
I'm fine with that, but the goal would be to support both systemd and
sysvrc/systemd-shim systems.

 Many members of the Debian GNOME team feel shipping Xfce by default would
 mean regressing in a few key areas like, as mentioned before, accessibility,
 localisation and documentation of the default set of applications. We are wary
 about the state of some features of the current default with respect
 to power management and bluetooth, for example. These features are driven by,
 and working since day 1, by GNOME 3.12.

Put it another way, Xfce (and other DEs) have been hurt by the various
enforced transitions (ConsoleKit,
hal/devicekit-power/upower/upower-0.99), yes. Combined with the lack of
resources, that means it lays behind the people who decided those
transitions.

Regards,
-- 
Yves-Alexis


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

Bug#738945: [Pkg-xfce-devel] Bug#738945: task-xfce-desktop: Hibernate doesn't work out of the box

[Yves-Alexis Perez]

Control: reassign -1 src:linux
Control: tag -1 wheezy

Kernel maintainers: it seems that Max has an issue with suspend to disk
in Wheezy. He initially reported against tasksel because he thought it
was related to the default install, but in the end it looks like it's
more a kernel issue.

On Tue, Mar 11, 2014 at 12:51:38PM +0100, Max Kubierschky wrote:
 Hi everybody,
 
 Ok, I was't informed, that hibernating should work without uswsusp.
 So I removed uswsusp again, for bug-hunting. I did try as suggested:
 
 - logout button, then hibernate
 - pm-hibernate (as root)
 - echo disk  /sys/power/state (as root)
 
 All of the above have the same effect: The screen goes black,
 after some seconds, the computer switches off. When switching
 it on again, It boots normally instead of returning to the hibernated
 state.
 
 So this bug is indeed not related to Xfce.

Thanks, I'm reassigning to the Linux kernel then. It might help to try
to reproduce with a vanilla 3.2 kernel, but I'll let the Linux
maintainers ask the information they need.
 
 For me personally, the problem is solved, as I am fine with uswsusp.
 But if it may benefit other users, I'm willing to cooperate in hunting it
 down further.
 
 As to my hardware: Its a Dell inspiron 1525 Notebook.
 To provide more information, below is the output from lspci.
 I have the non-free module iwl3945 installed for wifi, but
 
   rmmod iwl3945 iwl_legacy mac80211 cfg80211
 
 before hibernating doesn't change anything.
 
 Yours, Max
 
  lspci
 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory
 Controller Hub (rev 0c)
 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
 Integrated Graphics Controller (primary) (rev 0c)
 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated
 Graphics Controller (secondary) (rev 0c)
 00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
 Controller #4 (rev 02)
 00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
 Controller #5 (rev 02)
 00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
 Controller #2 (rev 02)
 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
 Controller (rev 02)
 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port
 1 (rev 02)
 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port
 2 (rev 02)
 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port
 5 (rev 02)
 00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
 Controller #1 (rev 02)
 00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
 Controller #2 (rev 02)
 00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI
 Controller #3 (rev 02)
 00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI
 Controller #1 (rev 02)
 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2)
 00:1f.0 ISA bridge: Intel Corporation 82801HM (ICH8M) LPC Interface
 Controller (rev 02)
 00:1f.1 IDE interface: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) IDE
 Controller (rev 02)
 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA
 Controller [AHCI mode] (rev 02)
 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev
 02)
 02:09.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev
 05)
 02:09.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host
 Adapter (rev 22)
 02:09.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter
 (rev 12)
 02:09.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12)
 09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E
 Fast Ethernet Controller (rev 12)
 0b:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan]
 Network Connection (rev 02)
 
 Am 11.03.2014 11:16, schrieb Yves-Alexis Perez:
 On Tue, Mar 11, 2014 at 01:13:59AM +0100, Cyril Brulebois wrote:
 Hi Xfce maintainers,
 
 please find below an installation report regarding Xfce. Feedback welcome.
 Thanks for the report, answers inline.
 
 Max Kubierschkym...@knirz.de  (2014-02-14):
 Package: task-xfce-desktop
 Version: 3.14.1
 Severity: normal
 
 Dear Maintainer,
 
 I installed debian wheezy with xfce desktop.
 hibernate was available in the energy settings, but did not work.
 Or more exactly, hibernate did work, but after switching on the
 computer again, it booted normally, instead of thawing.
 
 After some debugging and research, Installing uswsusp solved the
 problem.
 What kind of debug did you do? Do the following ways work:
 
 - logout button, then hibernate
 - pm-hibernate (as root)
 - echo disk  /sys/power/state (as root)
 
 Also, it'd help to know the kind of hardware you have (and especially
 stuff like wireless and graphic cards).
 Suggestion: add dependency on uswsusp to package task-xfce-desktop
 No way. uswsusp is (imho) just plain useless. Hibernation

Bug#738945: [Pkg-xfce-devel] Bug#738945: task-xfce-desktop: Hibernate doesn't work out of the box

[Yves-Alexis Perez]

On Tue, Mar 11, 2014 at 01:13:59AM +0100, Cyril Brulebois wrote:
 Hi Xfce maintainers,
 
 please find below an installation report regarding Xfce. Feedback welcome.

Thanks for the report, answers inline.

 Max Kubierschky m...@knirz.de (2014-02-14):
  Package: task-xfce-desktop
  Version: 3.14.1
  Severity: normal
  
  Dear Maintainer,
  
  I installed debian wheezy with xfce desktop.
  hibernate was available in the energy settings, but did not work.
  Or more exactly, hibernate did work, but after switching on the
  computer again, it booted normally, instead of thawing.
  
  After some debugging and research, Installing uswsusp solved the
  problem.

What kind of debug did you do? Do the following ways work:

- logout button, then hibernate
- pm-hibernate (as root)
- echo disk  /sys/power/state (as root)

Also, it'd help to know the kind of hardware you have (and especially
stuff like wireless and graphic cards).
  
  Suggestion: add dependency on uswsusp to package task-xfce-desktop

No way. uswsusp is (imho) just plain useless. Hibernation belongs in the
kernel. If it's broken, it should be fixed there.

In any case, it looks at first sight unrelated to Xfce, but the
questions above will help narrow the problem.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain

[Yves-Alexis Perez]

On Thu, 2013-10-10 at 11:32 -0400, Joey Hess wrote:
 Yves-Alexis Perez wrote:
  Or tasksel could stop installing recommends, like it was done before,
  and people involved in the various tasks can handle the list explicitly.
 
 This thread seems to have gone off on a tangent after the correct fix
 has already been indentified and committed by Emilio.
 
Well, maybe that's because people concerned by this disagree with the
“correct” fix. Unless I'm mistaken, that still brings
gnome-control-center on both first Xfce/LXDE discs and installations. 

That's not really acceptable, especially if the only other solution is
for us to drop network-manager-gnome from the task.

Regards,
-- 
Yves-Alexis


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

Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain

[Yves-Alexis Perez]

On mer., 2013-10-09 at 15:16 +0900, Charles Plessy wrote:
 It looks like that the problem is that when two desktop systems are installed,
 the one that pops up by default is not necessarly the one that the user 
 wanted.

That's a point, althought alternatives can be used here.
 
 If we can assume that the user is not bothered that GNOME packages are
 installed on the system despite they are not used,

That's wrong actually. Packages can modify system behavior when they're
installed without the user knowing, and they sure can be bothered.
Especially here, the major point is that no GNOME packages should be
implicitly installed, only explicit dependencies should be added, imho.

Regards,
-- 
Yves-Alexis


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

Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain

[Yves-Alexis Perez]

On mer., 2013-10-09 at 10:50 +0200, Emilio Pozuelo Monfort wrote:
 On 09/10/13 10:29, Per Olofsson wrote:
  Hi,
  
  On Tue, Oct 08, 2013 at 23:54 +0200, Michael Biebl wrote:
  Both recommends are there for a reason. gnome-bluetooth relies heavily
  on gnome-control-center when you try to pair / manage devices and
  network-manager-applet relies on gnome-bluetooth for DUN and PAN
  connections. So no, I don't see those recommends go away.
  
  According to policy, The Recommends field should list packages that
  would be found together with this one in all but unusual
  installations.
  
  Is it really unusual to use Network Manager without bluetooth? Doesn't
  most people use Network Manager to connect to wifi and ethernet?
 
 So what? This is just a recommends, you can install NM without gnome-bluetooth
 if you so desire. But in the general case, we want users to also get PAN/DUN
 support, so recommends is very appropriate.

This is not the general case. This is the installation, where the tasks
maintainers have selected a package set which fits a specific intent. In
Xfce case, we're ok to have network-manager, we then accept
network-manager-gnome because there's no other GTK+ NM client than
nm-applet, but that's all. We don't really need gnome-bluetooth
(although I think we'd be fine with it) and we definitely don't need
gnome-control-center. Also, I have no idea how well behaved
gnome-bluetooth is when not running under GNOME.
 
 I have dropped the gnome-session recommends from gnome-control-center, isn't
 that enough to stop all of gnome from being installed when xfce is selected in
 tasksel?

No, see above.

Regards,
-- 
Yves-Alexis


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

Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain

[Yves-Alexis Perez]

On lun., 2013-10-07 at 20:30 +0200, Emilio Pozuelo Monfort wrote:
 On 07/10/13 19:38, Joey Hess wrote:
  network-manager-gnome recommnds gnome-bluetooth recommends
  gnome-control-center recommends gnome-session
  
  Not sure what to do about this. gnome-bluetooth seems to have
  that recommends because its control panel was moved into
  gnome-control-center and is presumably used by its UI.
  
  Perhaps gnome-control-center does not need to recommend gnome-session?
 
 We talked about exactly this issue on irc this weekend and we didn't see a
 reason for g-c-c to recommend gnome-session, so that can be dropped. I've gone
 ahead and applied that in svn for the next upload.

I still don' think having gnome-control-center installed on Debian Xfce
(or any !gnome) installations is a good idea, to be honest. I personally
use network-manager-gnome nm-applet under Xfce because it doesn't
actually needs GNOME bits, so imho either the gnome-bluetooth recommends
should be dropped from network-manager-gnome, or the
gnome-control-center one dropped from gnome-bluetooth.

Or tasksel could stop installing recommends, like it was done before,
and people involved in the various tasks can handle the list explicitly.

Regards,
-- 
Yves-Alexis


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

Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain

[Yves-Alexis Perez]

On mar., 2013-10-08 at 23:54 +0200, Michael Biebl wrote:
 Am 08.10.2013 15:02, schrieb Yves-Alexis Perez:
  I still don' think having gnome-control-center installed on Debian Xfce
  (or any !gnome) installations is a good idea, to be honest. I personally
  use network-manager-gnome nm-applet under Xfce because it doesn't
  actually needs GNOME bits, so imho either the gnome-bluetooth recommends
  should be dropped from network-manager-gnome, or the
  gnome-control-center one dropped from gnome-bluetooth.
 
 Both recommends are there for a reason. gnome-bluetooth relies heavily
 on gnome-control-center when you try to pair / manage devices and
 network-manager-applet relies on gnome-bluetooth for DUN and PAN
 connections. So no, I don't see those recommends go away.
 
Then we should make tasksel stop installing recommends. Or maybe I
should add a conflict in task-xfce-desktop (although I'm not so sure it
works fine).

Regards,
-- 
Yves-Alexis


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

Bug#712482: [Pkg-xfce-devel] Bug#712482: task-xfce-desktop recommends unavailable package xfprint4

[Yves-Alexis Perez]

On dim., 2013-06-16 at 13:05 +0200, Cyril Brulebois wrote:
 Hi Andreas,
 
 Andreas Schneider schneider.a...@gmail.com (16/06/2013):
  Package: task-xfce-desktop
  Version: 3.16
  Severity: normal
  
  The task xfce-desktop recommends xfprint4. This package is not available
  anymore (except for m68k) since it has been removed from unstable. Quote:
  Bug#710041: Removed package(s) from unstable. Therefore please drop the
  recommendation.
 
 given a few xfce components are being updated those days, I guess it
 makes sense to ask xfce maintainers what they want to see in the xfce
 task. Adding them to the loop so that they can comment.
 

Actually it already has been dropped from git
(http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a=commitdiff;h=b057b6e59b3b20aa124cd08c5ca0a657e40c810a)
 but it's just missing an upload.

Regards,
-- 
Yves-Alexis


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

Bug#673200: Splitting Xfce/LXDE

[Yves-Alexis Perez]

I'm unsure about that, but it might make sense to split Xfce and LXDE
cds. I don't really know about LXDE in Debian (although I'm unsure of
its real utility and upstream maintenance in general), but it definitely
make sense to have an Xfce CD.

I'll also try to check what's installed besides Xfce and see if there's
a way to reduce the total.

Regards,
-- 
Yves-Alexis


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

Bug#651650: #651650 tasksel-xfce-desktop: Dependency problem in netinst tasksel-xfce

[Yves-Alexis Perez]

On 13/12/2011 18:02, Joey Hess wrote:
 Hello, i just installed wheezy with a desktop=xfce option at grub in netinst 
 cd.
 Works fine, but xfce-mixer don't.
 Probably a dependency problem in tasksel program.
 I install gstreamer-alsa and i fixed this manually
 
 My guess from this limited and unclear information is that, since
 xfce-mixer depends on gstreamer0.10-alsa | gstreamer0.10-audiosink,
 installation of various other packages that provide the latter,
 such as gstreamer0.10-pulseaudio, could unintentionally satisfy the
 dependency without the former being installed. 
 
 When I remove gstreamer0.10-alsa here, xfce4-mixer seems
 to use OSS instead, which works here but is not really desirable.
 
 Should the xfce4 task explicitly pull in gstreamer0.10-alsa to avoid this
 problem?
 
It seems that this is something hurting a few people already, so maybe.
I'm not too sure why pulseaudio is installed by default, but if
xfce4-mixer doesn't work with the pulseaudio audiosink, then it might
just be wise to just depend on the -alsa variant.

Regards,
-- 
Yves-Alexis



-- 
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/4ee78d37.8070...@debian.org

Re: [Pkg-xfce-devel] not able to install xfce parallely to GNOME desktop

[Yves-Alexis Perez]

On mar., 2011-09-06 at 11:07 +0530, shirish शिरीष wrote:
 $ sudo aptitude install quodlibet
 The following NEW packages will be installed:
   gstreamer0.10-gnomevfs{a} python-gpod{ab} quodlibet
 0 packages upgraded, 3 newly installed, 0 to remove and 33 not
 upgraded.
 Need to get 854 kB of archives. After unpacking 2,081 kB will be used.
 The following packages have unmet dependencies:
   gnome-desktop-environment: Conflicts: gstreamer0.10-gnomevfs but
 0.10.35-1 is to be installed.
   python-gpod: Depends: python-mutagen-gobject which is a virtual
 package.
 The following actions will resolve these dependencies:
 
  Keep the following packages at their current version:
 1) gstreamer0.10-gnomevfs [Not Installed]
 2) python-gpod [Not Installed]
 
  Leave the following dependencies unresolved:
 3) quodlibet recommends gstreamer0.10-gnomevfs
 4) quodlibet recommends python-gpod
 
 
 Accept this solution? [Y/n/q/?] q
 Abandoning all efforts to resolve these dependencies.
 Abort.
 
 Am I missing something ? 

I don't think is related to either debian-boot or pkg-xfce.
-- 
Yves-Alexis


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

Bug#621769: debian-installer: fails to load preseed file from local media

[Yves-Alexis Perez]

reopen 621769
severity 621769 wishlist
retitle 621769 please include file-reseed udeb on netboot images
thanks
On ven., 2011-04-08 at 13:27 -0400, Joey Hess wrote:
 Yves-Alexis Perez wrote:
  I'm using the netboot files (so linux kernel and initrd.gz). I've tried
  various setups:
  
  preseed/file=/hd-media/foo.cfg
  preseed/file=file:///hd-media/foo.cfg
  
  Looking at the content of the initrd it seems that there is nothing
  mounting the media nor anything done to handle preseed/file. I've found
  stuff for handling preseed/url but nothing for the file scheme.
 
 /hd-media is mounted by iso-scan. That will work fine if you're
 installing from a hdF11-media image. Otherwise it won't, and you'll
 have to put the file somewhere else.
 
 d-i does not have one initrd, it has initrds customized for different
 media types. The file-preseed udeb that handles preseed/file is only
 present on the hd-media, cdrom, and monolithic initrds.

Ok, the more I think about it, the more I'd find it useful to be able to
just drop a preseed file in a usb key along with kernel/initrd and be
able to use it. 

hd-media doesn't fit because that means having a complete mirror of what
you want on the key (since it won't be able to install from a http
mirror) and you need to have the usb key plugged in for the whole
install (it's alway more practical to be able to just remove the key
once it has booted, and in cases like you have a lot of install running
in parallel it means you can just have once key for all of them). 

Adding the preseed files to the initramfs means you have to rebuild it
each time the installed is updated or you change the preseed file, which
is a bit painful.

file-preseed udeb is just 24kb installed (3.8kb for the package, meaning
it compresses just fine in the initramfs) so I guess it's not too much
of a space problem.

All in all it's not a huge problem, there are workarounds, but it'd be
really convenient, imho.

Thanks for your work and consideration.

Regards,
-- 
Yves-Alexis


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

Bug#621769: debian-installer: fails to load preseed file from local media

[Yves-Alexis Perez]

On dim., 2011-04-10 at 15:29 -0300, Otavio Salvador wrote:
 On Sat, Apr 9, 2011 at 02:32, Christian PERRIER bubu...@debian.org
 wrote:
  So, this is not a bug, then?
 
 IMO we could close this bug report in this case. Others? 

I've already closed it (though I still think it'd be nice to have a way
to give a preseed/file in netboot image since that means one can just
boot with the key and doesn't have to keep it plugged for the whole
install).

Regards,
-- 
Yves-Alexis


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

Bug#621769: debian-installer: fails to load preseed file from local media

[Yves-Alexis Perez]

Package: debian-installer
Severity: normal
Tags: d-i

Hey,

it seems that preseed/file doesn't work at all.

I'm using the netboot files (so linux kernel and initrd.gz). I've tried
various setups:

preseed/file=/hd-media/foo.cfg
preseed/file=file:///hd-media/foo.cfg

Looking at the content of the initrd it seems that there is nothing
mounting the media nor anything done to handle preseed/file. I've found
stuff for handling preseed/url but nothing for the file scheme.

Regards,
-- 
Yves-Alexis
-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)

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



-- 
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/20110408170306.13004.95417.reportbug@hidalgo

Bug#621769: debian-installer: fails to load preseed file from local media

[Yves-Alexis Perez]

On ven., 2011-04-08 at 13:27 -0400, Joey Hess wrote:
 Yves-Alexis Perez wrote:
  I'm using the netboot files (so linux kernel and initrd.gz). I've tried
  various setups:
  
  preseed/file=/hd-media/foo.cfg
  preseed/file=file:///hd-media/foo.cfg
  
  Looking at the content of the initrd it seems that there is nothing
  mounting the media nor anything done to handle preseed/file. I've found
  stuff for handling preseed/url but nothing for the file scheme.
 
 /hd-media is mounted by iso-scan. That will work fine if you're
 installing from a hdF11-media image. Otherwise it won't, and you'll
 have to put the file somewhere else.
 
 d-i does not have one initrd, it has initrds customized for different
 media types. The file-preseed udeb that handles preseed/file is only
 present on the hd-media, cdrom, and monolithic initrds.
 

Damn. So I guess I'll have to fall back to the network preseed or
rebuild the initrd (the whole point was to embed the preseed file on the
usb drive but keep a generic initrd.gz so I could chose the kind of
install (standard, preseed1/2/..) depending on the boot options.
hd-media won't work since, afair, it can't use a network mirror but will
only rely on local mirror.

Regards,
-- 
Yves-Alexis


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

Bug#621769: debian-installer: fails to load preseed file from local media

[Yves-Alexis Perez]

On ven., 2011-04-08 at 13:27 -0400, Joey Hess wrote:
 /hd-media is mounted by iso-scan. That will work fine if you're
 installing from a hdF11-media image. Otherwise it won't, and you'll
 have to put the file somewhere else.
 
 d-i does not have one initrd, it has initrds customized for different
 media types. The file-preseed udeb that handles preseed/file is only
 present on the hd-media, cdrom, and monolithic initrds. 

For people looking for that, just in case, the info above was indeed
available from the documentation at
http://www.debian.org/releases/stable/i386/apbs01.html.en#preseed-methods


-- 
Yves-Alexis


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

Re: Bug#612074: debian-cd: provide iso image aligned on usb thumb drive size

[Yves-Alexis Perez]

On Wed, 2011-02-23 at 14:43 +, Steve McIntyre wrote:

 For now, I've added code to debian-cd to allow for configuration to
 specify use of a specified disk type (i.e. size), but then to
 over-ride the size for *all* the images (as I did for the KDE CDs for
 squeeze), and/or a single specific image number.

Does this mean a random user (maybe not so random but...) can easily use
debian-cd to cook his own unofficial disk saying “I have an usb thumb
drive which is 3.141G and would like to put as much packages as I can on
it”?
 
 Then I'm going to make DVD#1 limit to 4GB for amd64, i386 and the
 amd64/i386 m-a DVD. Then it'll fit on a 4GB stick too, and I think
 that's useful. The rest of the set will still fill up to the normal
 4.7GB DVD size, as there's no point to keeping to that limit on later
 discs. Other arches and source DVDs will also not be affected -
 there's also no point messing with them AFAICS. Please correct me if
 you think I'm wrong here!

Yeah, no use for the rest of the set. 4G is nice, will the removed 700M
contain useful stuff which will miss to our users? (Agreed that it might
not make sense for other arches than amd64 and i386).
 
 For a 1GB or 2GB (or even 8GB/16GB) image, we *can* add more builds
 targetted to fit those sizes, but I would rather make those be totally
 separate builds; they're not close enough to any of the current
 standard sizes that we generate IMHO.

Yup, agreed.
 
 Thoughts?
 

Thanks for your work :)

Regards,
-- 
Yves-Alexis


-- 
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/1298473021.3118.3.camel@oban

Bug#603554: Bug#603552: Update theme SpaceFun and wiki page

[Yves-Alexis Perez]

On dim., 2011-01-16 at 08:49 +0100, Daniel Baumann wrote:
 On 01/13/2011 10:52 PM, Adam D. Barratt wrote:
  Is there anything that still needs to happen on the syslinux side
 
 yes.
 
  if so, could it either happen soon or for 6.0.1, please? :)
 
 like i said[0], after my vac[1].
 
 [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604783#27
 [1] 4d025597.1090...@debian.org on debian-private
 
Assuming your back from [VAC], is there any news from this?

Regards,
-- 
Yves-Alexis




-- 
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/1295616773.11245.18.camel@oban

reassign 599392 to grub-installer, forcibly merging 598130 599392

[Yves-Alexis Perez]

# Automatically generated email from bts, devscripts version 2.10.35lenny7
reassign 599392 grub-installer 
forcemerge 598130 599392


-- 
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/1286446718-4197-bts-cor...@debian.org

Bug#579363: partman-lvm: don't allocate all space in guided LVM configuration

[Yves-Alexis Perez]

Package: partman-lvm
Version: 65
Severity: wishlist

Hi,

this is not exactly a feature request, it's more like a start of a
discussion and a maybe-wishlist depending on what people think about that.

I use LVM from the debian-installer since quite some time now, and I find
it really useful. I definitely love the “guided lvm” and “guided encrypted
LVM”, but sometime, after using the box a bit, I find out that the layout
wasn't exactly like I needed and I'm short on space on one partition.

 Fine, LVM is good at that, I can reallocate some space.

But, shrinking some VG to reallocate space is not that easy. One
needs to shrink one filesystem, then the LV, then grow the needed LV,
and then the filesystem. It's not that easy, and I'm not sure this is
really the way LVM was intended to be used.

It might been easier to not allocate all the space on the hard drive chosen
for guided LVM. Only allocate, say 10 or 20G (only if the hard drive is big
enough, that said), do a guided layout on that, and keep free extents in
the volume group.

Then, when one partition starts to fill up, the admin only needs to grow it
a little, with the free PE in the VG.

What do you think?

Cheers,
--
Yves-Alexis

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



--
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/20100427112610.15302.30914.report...@molly.corsac.net

Bug#545431: tasksel: update xfce4-desktop task for squeeze

[Yves-Alexis Perez]

On mar, 2009-09-08 at 22:10 +0200, Christian Perrier wrote:
 tags 545431 peding
 thanks
 
 Quoting Yves-Alexis Perez (cor...@debian.org):
  Package: tasksel
  Version: 2.80
  Severity: wishlist
  
  Hey,
  
  here's an updated xfce-desktop task definition for squeeze, matching the
  changes in Xfce 4.6.
  
  Could you import it in next tasksel upload?
 
 Commited to git.

Thanks. Could you add the attached patch too?

Thanks,

-- 
Yves-Alexis
diff --git a/tasks/xfce-desktop b/tasks/xfce-desktop
index 3bea71e..644794d 100644
--- a/tasks/xfce-desktop
+++ b/tasks/xfce-desktop
@@ -38,3 +38,5 @@ Packages-list:
 # icon theme
   tango-icon-theme
   xfce4-power-manager
+# network management
+  wicd


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

Bug#545431: tasksel: update xfce4-desktop task for squeeze

[Yves-Alexis Perez]

On mar, 2009-09-29 at 06:31 +0200, Christian Perrier wrote:
 Quoting Yves-Alexis Perez (cor...@debian.org):
 
   Commited to git.
  
  Thanks. Could you add the attached patch too?
 
 
 Done.

Thanks!
 
 Would that help if you have commit access to tasksel's git?

Sure, though I'm not that often modifying xfce task. But yes, it'd could
be helpful.

-- 
Yves-Alexis


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

Bug#545431: tasksel: update xfce4-desktop task for squeeze

[Yves-Alexis Perez]

Package: tasksel
Version: 2.80
Severity: wishlist

Hey,

here's an updated xfce-desktop task definition for squeeze, matching the
changes in Xfce 4.6.

Could you import it in next tasksel upload?

Thanks,
--
Yves-Alexis


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

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

Versions of packages tasksel depends on:
ii  aptitude  0.4.11.11-1+b2 terminal-based package manager
ii  debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii  liblocale-gettext-perl1.05-4 Using libc functions for internati
ii  tasksel-data  2.80   Official tasks used for installati

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information:
  tasksel/title:
  tasksel/desktop: gnome
  tasksel/first:
  tasksel/tasks:
diff --git a/tasks/xfce-desktop b/tasks/xfce-desktop
index 0778217..3bea71e 100644
--- a/tasks/xfce-desktop
+++ b/tasks/xfce-desktop
@@ -18,8 +18,6 @@ Packages-list:
   xfce4-goodies
 # xfce text editor  
   mousepad
-# xfce media player (uses xine)  
-  xfmedia
 # calendar application  
   orage
   xfce4-mixer
@@ -32,3 +30,11 @@ Packages-list:
   xsane
 # gui for configuration of the print server
   foomatic-gui
+# media players
+  vlc
+  quodlibet
+# pdf viewer
+  epdfview
+# icon theme
+  tango-icon-theme
+  xfce4-power-manager

Bug#421837: [Pkg-xfce-devel] Sudo for xfce

[Yves-Alexis Perez]

On lun, 2009-04-27 at 07:47 +0200, Yves-Alexis Perez wrote:
 On dim, 2009-04-26 at 21:36 +0100, Simon Huggins wrote:
  I got forwarded this today.  Do we need anything more from a fresh
  install?  It's been a while since I've done one...
 
 We have ktsuss for Xfce but I'm not sure it fills the gap. xfce4-session
 now uses hal for everything (shutdown/suspend/hibernate), so basically
 we just need hal (installed by X anyway), consolekit and policykit.

Confirmed, ktsuss is just a wrapper around su, meaning it won't work
with sudo.

Cheers,
-- 
Yves-Alexis


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

Re: Suggestions for improving the (Xfce) Desktop install

[Yves-Alexis Perez]

On mar, 2009-03-17 at 19:49 +0200, Andrei Popescu wrote:
 [please CC me, I'm not subscribed]
 
 Hello,

Hey,

I'm (one of) the Xfce maintainer in Debian. I'll comment on this, but
I'm not subscribed either.
 
 I recently installed sid with desktop=xfce and some things I consider 
 should definitely be there were *completely missing*. Since we are 
 talking about Xfce all my suggestions will be about lightweight gtk 
 apps:

I'm planning to update the xfce task, but I'm waiting for 4.6 to enter
unstable before.
 
 - infrastructure: hal (without hal no icon will show up for plugged in 
   removable media)

Yeah, we didn't want to depend on hal and dbus for Lenny, but this will
be dropped in Squeeze, so one way or another we'll bring hal.

 - GUI package manager: synaptic

Yeah, good idea. 

 - image viewer: gpicview

The Xfce image viewer is ristretto, will be added.

 - pdf viewer: epdfview or maybe even evince-gtk

Yes, epdfview.

 - IM client: pidgin

Hmhm, I don't really want to add another package depending on gconf. Not
sure if there are some viable alternatives.
 
 Some other apps are pulled in via the generic Desktop task (AFAICT from 
 aptitude), but a bit too heavy for a lightweight desktop:
 
 - openoffice.org - for most uses Abiword + Gnumeric are enough

Too gnomish. And OpenOffice is OpenOffice, I guess it's supposed to be
there on a desktop install, though the user is free to remove it if
needed.

 - gimp - gpaint

Same applies here, gimp is gimp :)
One stuff I'll have to think about, too, is the browser. I'd be glad to
drop iceweasel for midori once webkit is stabilized (especially since
midori is now officially some kind of an xfce project) but maybe the
user expects iceweasel to be there on a desktop task. That or we could
drop it from the desktop task and let every *-task define the preferred
brother (epiphany/konqueror/midori/…)


On mer, 2009-03-18 at 07:02 +0100, Christian Perrier wrote:
 Quoting Andrei Popescu (andreimpope...@gmail.com):
  [please CC me, I'm not subscribed]
  
  Hello,
  
  I recently installed sid with desktop=xfce and some things I consider 
  should definitely be there were *completely missing*. Since we are 
  talking about Xfce all my suggestions will be about lightweight gtk 
  apps:
 
 
 Shouldn't this be discussed with Debian Xfce maintainers mor ethan
 tasksel maintainers (aka the D-I team)?
 
 In our POV, the content of the desktop tasks themselves is more up to
 the respective maintenance teams...
 
Good point, but the change need to be made in tasksel, so it's not
irrelevant to discuss that in tasksel lists. But maybe it'd be even
better to discuss that on a bug reported against tasksel? What do you
think Andrei?

Cheers,
-- 
Yves-Alexis


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

Re: Suggestions for improving the (Xfce) Desktop install

[Yves-Alexis Perez]

On mer, 2009-03-18 at 18:59 -0300, Otavio Salvador wrote:
 Yves-Alexis Perez cor...@debian.org writes:
 
 
 [...]
 
  Good point, but the change need to be made in tasksel, so it's not
  irrelevant to discuss that in tasksel lists. But maybe it'd be even
  better to discuss that on a bug reported against tasksel? What do you
  think Andrei?
 
 I belive the right place to discuss it is in xfce mailing list and after
 a conclusion has been made, report a bug against tasksel (with a patch
 if possible) for us to update it.
 
 Obviously if we think something is wrong we'll ask and discuss it in the
 bug report but a lot of noise could be avoided if doing this way. And it
 will also speedup things for you all.

Ok, if it's fine with you :)

Andrei, could you please post a summary to pkg-xfce mailing list, with
what you think would be nice to have or nice to not have on the xfce
task? I'll provide my input (maybe in beginning of april because I'm
going to not be around until end of march) and then we'll provide
tasksel a patch with the all the data, when 4.6 have ended in unstable
etc.

Cheers,
-- 
Yves-Alexis


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

Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On jeu, 2009-01-08 at 00:21 -0500, Daniel Dickinson wrote:
 Ah!  Aptitude also has the ability to select tasks.  One of the
 categories in the defaults displays is 'Tasks' and under that there
 are
 things like 'End User' and 'Localisation'.  For XFCE you open 'End
 User' and the highlight 'Xfce Desktop Environment' then press '+',
 which select the packages in the task for installation.

Yesh I know. But afaik tasks are only displayed by aptitude, it doesn't
have the choice on what they represent. I guess when one runs “aptitude
install task it doesn't calls tasksel install which would then call
aptitude install task which would loop :)

But the point is, the source for tasks is tasksel.

Cheers,
-- 
Yves-Alexis


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

Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On mar, 2009-01-06 at 16:06 -0500, Daniel Dickinson wrote:
 Perhaps it's only when one tries to install xfce after doing a
 standard
 install and not when using an xfce cd  (that's when it showed up for
 me).  So probably tasksel is fine, the problem is that if you apt-get
 or aptitude|select task, then it pulls in the stuff.  Nautilus and
 that
 are only probably only pulled in because of recommends when installing
 after-the-fact and gnome-session is a bug in aptitude and apt.  

Wait. It's been days that we look for a bug at install time.

If you want to install xfce *after* that, just use apt-get install xfce4
xfce4-goodies. 
If you want the task, then yes use aptitude install xfce-desktop

You can manually tweak the command line to say that you don't want
gnome-session or whatever. And I don't think apt-get can install tasks
directly so the bug only triggers when you do that with aptitude.

Anyway, I'm *really* lost about where we are, what the problem really
is, and what exactly we are wanting to do to solve it.

Frans: basically, you were not really involved in the loop, sorry,
that's not d-i related in any way. We don't need to change anything in
tasks for Lenny, so we stay with gdm and it'll be fine.

Cheers and thanks,
-- 
Yves-Alexis


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

Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On mar, 2009-01-06 at 20:01 -0500, Daniel Dickinson wrote:
 
 It occurs to me the reason you are confused is that when I 'Standard
 System' you are thinking I mean 'typical system' when in fact I mean
 that I select the option 'Standard System' on the tasksel menu. 

No I'm confused because you select tasks in aptitude. And tasks are
tasksel job.

Cheers,
-- 
Yves-Alexis


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

Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On lun, 2009-01-05 at 13:31 +0100, Frans Pop wrote:
 On Monday 05 January 2009, Yves-Alexis Perez wrote:
   Reason is that tasksel makes use of the Task: fields in the Packages
   file, not the task files included in tasksel itself (which,
   simplified, are only used to update the Packages file).
 
  Ha, crap. And I guess the Task: order isn't reliable?
 
 The order of packages in the Packages file is reliable (alphabetical), but 
 I'm not sure how exactly that translates to the order in which tasksel 
 will list packages when it calls aptitude.
 
   Would replacing gdm by xdm solve the problem (see #510422)?
 
  Well, I guess so.
 
 Could you (or someone else from the desktop teams) test this?

Well, testing the desktop task not really, especially if it uses
Packages files. But we can test installing xdm on top of xfce4. It'll
work (but as there's no way to chose session from xdm, it may be more
painful for end users then using gdm, as the correct way to start Xfce
is to run startxfce4 and not “just“ running the registered session
manager (which is the case by default on *dm). 

 
  I'd like some comments from other pkg-xfce team 
  members, but if it's not too late, that would be ok.
 
 There is a slight risk of incompatibility with tasksel.

What do you mean?
 
  I didn't use xdm since quite some time, but does it uses a desktop-base
  theme by default, these days?
 
 No idea. You are supposed to be the desktop people here...
 
Uh, oh, well, yeah, sorry :)
Installed xdm, it just look awful. I don't know about xdm themes, but
I'm not sure cooking an xdm desktop-base theme would be done easily.

Simon Huggins told me on IRC that you talked about this issue and that
in tasksel tasks (tasksel/tasks/xfce-desktop for example) Keys: and
Packages: stuff were treated differently, and that we might have a
chance there. Could you elaborate on this?

Cheers,
-- 
Yves-Alexis




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

Bug#506406: [Pkg-xfce-devel] Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On Mon, Jan 05, 2009 at 07:58:28PM +0100, Frans Pop wrote:
 severity 506406 minor
 thanks
 
 On Monday 05 January 2009, Yves-Alexis Perez wrote:
  Well, testing the desktop task not really, especially if it uses
  Packages files. But we can test installing xdm on top of xfce4.
 
 That's not sufficient. What would need to be tested is installing xdm and 
 xfce at the same time, just like tasksel would do.
 I've just tried this, but it hardly has any effect.

Yes that's what I meant. Using a commandline aptitude with all the
packages in xfce-desktop task and xdm instead of gdm.

 
 Hmm. It looks like this is only an issue when the task is installed *from 
 aptitude itself*, and *not* when it is installed using tasksel or during 
 a new installation from D-I.
 That means it's almost impossible to test without actually uploading 
 tasksel, that it's unlikely that it can be fixed through some creative 
 change in tasksel, that IMO it is not even remotely an important issue 
 and that it is almost certainly not an issue in tasksel, but in aptitude.

Well, for Simon and me it looks really like magic. We don't really know
what is done when installing from d-i an Xfce desktop.

It should at one point run:
  tasksel install xfce-desktop

But according to tasksel --test install xfce-desktop, in fact it should run:

  aptitude -q --without-recommends -o APT::Install-Recommends=no -y \
   install desktop gnome-desktop xfce-desktop

Which looks quite weird. Wouldn't be that gnome-desktop the problem?

 AFAICT it can be worked around by first selecting the xfce meta packages 
 in aptitude and only then selecting other packages, such as gdm.
 If I do that, aptitude only wants to install 720MB instead of 1027 MB 
 worth of packages.
 
  It'll work (but as there's no way to chose session from xdm, it may be
  more painful for end users then using gdm, as the correct way to start
  Xfce is to run startxfce4 and not “just“ running the registered session
  manager (which is the case by default on *dm).
 
 I don't get this. I just gave it a try and Xfce started fine with xdm as 
 display manager. I don't see any difference.

Yeah, that's not your problem. Default session stuff in gdm/xdm only
runs whatever session manager is configured, which, on an Xfce install
is xfce4-session. So it runs xfce4-session, which is not the perfect way
to run Xfce. The better way is to run startxfce4, and we have a config
file to run that correctly, it's selectable in gdm but not really in
xdm.

  Uh, oh, well, yeah, sorry :)
  Installed xdm, it just look awful. I don't know about xdm themes, but
  I'm not sure cooking an xdm desktop-base theme would be done easily.
 
 I would think it's almost certainly to late for that for Lenny.
 
 xdm looks more basic then gdm and is less themed, but TBH that's exactly 
 what I'd expect with a lightweight DE. And it does have the Debian logo.

Yeah but it could at least have the Lenny wallpaper which is in
desktop-base :)

 
  Simon Huggins told me on IRC that you talked about this issue and that
  in tasksel tasks (tasksel/tasks/xfce-desktop for example) Keys: and
  Packages: stuff were treated differently, and that we might have a
  chance there. Could you elaborate on this?
 
 I did talk to Simon, but we did not talk about that. He asked how the 
 definition of a task could be changed or overruled, which is a different 
 question.
 
 So, switching from gdm to xdm may work, but there is no real way to test 
 that. My advise is to just leave things as they are for Lenny and just 
 live with the issue.

Yeah but having to install that many gnome stuff on Xfce install is
quite painful. I'll try to see if I can do anything on that.

Cheers,
-- 
Yves-Alexis



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

Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On lun, 2009-01-05 at 12:50 +0100, Frans Pop wrote:
  Ok it seems that adding xfce4-session before gdm in the list enables
  apt-get and aptitude to satisfy the dependency on x-session-manager.
 
 Unfortunately this cannot be fixed in tasksel this way. The order in which 
 packages are actually installed is not determined by the order in which 
 they are listed in tasksel.
 
 Reason is that tasksel makes use of the Task: fields in the Packages file, 
 not the task files included in tasksel itself (which, simplified, are 
 only used to update the Packages file).

Ha, crap. And I guess the Task: order isn't reliable?
 
 Would replacing gdm by xdm solve the problem (see #510422)?

Well, I guess so. I'd like some comments from other pkg-xfce team
members, but if it's not too late, that would be ok. I tend to prefer
slim over xdm but it doesn't seem really maintained upstream and has
some drawbacks which make it not suitable for a default install.

I didn't use xdm since quite some time, but does it uses a desktop-base
theme by default, these days?

Cheers,
-- 
Yves-Alexis




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

Bug#506406: xfce4: apt bug causes gdm to pull in unneeded/unwanted gnome dependencies

[Yves-Alexis Perez]

On lun, 2009-01-05 at 22:55 -0500, Daniel Dickinson wrote:
 On Mon, 5 Jan 2009 13:31:59 +0100
 Frans Pop elen...@planet.nl wrote:
 
  
Would replacing gdm by xdm solve the problem (see #510422)?
  
   Well, I guess so.
  
  Could you (or someone else from the desktop teams) test this?
 
 I'm just the user who reported the bug (though I hope at some point to
 become a DD), and I have tested with a custom task (below).  I did a
 standard install, modified the task file and did
 
 tasksel -t install xfce-desktop

Frans said this wasn't a correct way to test. I'm not sure you followed
all the mails ont the BR as I dropped you from CC:.

 On another note, I'd like to suggest using system-config-printer
 instead of foomatic-gui ; I'm not sure foomatic-gui is maintained
 anymore and system-config-printer is the recommended replacement in any
 event.

system-config-printer is nice but depends on python-gnome2 which pulls
way too much GNOME and gksu which aswell. But as foomatic-gui does that
too anyway…

Anyway, I just tried an install in kvm. What I did:

kvm -k en-us -hda xfce-desktop.img -kernel linux -initrd initrd.gz
-append desktop=xfce

Iirc linux and initrd are from d-i RC1 or more recent. It seems to be
“the recommended way” to install Xfce Desktop Environment when using the
netinstall. And dpkg -l | grep gnome gives:

ii  gnome-keyring2.22.3-2
GNOME keyring services (daemon and tools)
ii  gnome-mime-data  2.18.0-1   base
MIME and Application database for GNOME.
ii  libgnome-keyring02.22.3-2
GNOME keyring services library
ii  libgnome2-0  2.20.1.1-1 The
GNOME 2 library - runtime files
ii  libgnome2-common 2.20.1.1-1 The
GNOME 2 library - common files
ii  libgnomecanvas2-02.20.1.1-1 A
powerful object-oriented display - runtime files
ii  libgnomecanvas2-common   2.20.1.1-1 A
powerful object-oriented display - common files
ii  libgnomeui-0 2.20.1.1-2 The
GNOME 2 libraries (User Interface) - runtime files
ii  libgnomeui-common2.20.1.1-2 The
GNOME 2 libraries (User Interface) - common files
ii  libgnomevfs2-0   1:2.22.0-5
GNOME Virtual File System (runtime libraries)
ii  libgnomevfs2-common  1:2.22.0-5
GNOME Virtual File System (common files)
ii  python-gnome22.22.0-1
Python bindings for the GNOME desktop environment

So it's not that hard. Manually replacing foomatic-gui by
system-config-printer gives:

xfce:~# apt-get --no-install-recommends remove --purge foomatic-gui
system-config-printer+
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer
required:
  python-gtkhtml2
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  python-cups python-cupsutils python-notify system-config-printer
Recommended packages:
  hal-cups-utils synaptic
The following packages will be REMOVED:
  foomatic-gui*
The following NEW packages will be installed:
  python-cups python-cupsutils python-notify system-config-printer
0 upgraded, 4 newly installed, 1 to remove and 0 not upgraded.
Need to get 823kB of archives.
After this operation, 3009kB of additional disk space will be used.
Do you want to continue [Y/n]? 


I'll try an install with the Xfce cd to see if that matches. But
basically I don't see gnome-session or stuff like that coming in.

Daniel: it seems I can't reproduce the bug where gnome-session is
installed. I'll try again (in case it's a random bug), but basically I'd
be fine keeping everything that way, and take care of Xfce task early in
squeeze process.

Cheers,
-- 
Yves-Alexis


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

reassign 506406 to tasksel

[Yves-Alexis Perez]

reassign 506406 tasksel 


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

Bug#510300: Patch

[Yves-Alexis Perez]

tag 510300 +patch
thanks

Attached trivial patch should do the trick. I'll test on a lenny
standard install what install dbus-x11 on top of xfce-desktop adds.

Cheers,
-- 
Yves-Alexis
diff --git a/tasks/xfce-desktop b/tasks/xfce-desktop
index 53895bf..4628228 100644
--- a/tasks/xfce-desktop
+++ b/tasks/xfce-desktop
@@ -23,3 +23,5 @@ Packages-list:
   xfprint4
   xfce4-terminal
   openoffice.org-gtk
+# Xfce Desktop is really improved by using dbus
+  dbus-x11


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

Bug#510300: installation-report: Missing installation of dbus-x11 package in xfce based install

[Yves-Alexis Perez]

On mer, 2008-12-31 at 10:15 +0100, Frans Pop wrote:
 reassign 510300 tasksel 2.77
 thanks
 
 On Wednesday 31 December 2008, Pietro Pizzo wrote:
  Comments/Problems:
  I chose to install the xfce desktop environment and the installation
  process worked like a sharm. The only problem I had after logging into
  the system, was the lack of the trash can.
 
  I would suggest to include dbus-x11 in the installation package list
  for xfce, otherwise people won't be able to see the trash can unless
  they install that package manually.
 
 Seems reasonable, but maybe the maintainers of the Xfce desktop task 
 should comment.

Hmhm yes, dbus-x11 is Recommended: by various Xfce packages, but tasksel
doesn't install Recommends: (which is normal). So yes, adding it to the
xfce task would be a good idea.

Cheers,
-- 
Yves-Alexis


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

Bug#510300: installation-report: Missing installation of dbus-x11 package in xfce based install

[Yves-Alexis Perez]

On jeu, 2009-01-01 at 00:19 +0800, Andrew Lee wrote:
 Frans Pop wrote:
  reassign 510300 tasksel 2.77
  thanks
  Is the same maybe needed for the LXDE desktop?
 
 LXDE in lenny hasn't support trash can yet. So no need for LXDE desktop
 for now.

This is not about trash support but about dbus one.

Cheers,
-- 
Yves-Alexis


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

Problems with netboot files for etch'n half

[Yves-Alexis Perez]

Hi,

I think there is some problems with installation files (kernel and
initrd) for netboot.

I pick the files from:

http://ftp.nl.debian.org/debian/dists/etch/main/installer-amd64/current/images/netboot/debian-installer/amd64/

linux is kernel 2.6.24, so it's correctly etch'n half
but initrd.gz only contains modules for 2.6.18 (in /lib/modules) so no
way one can install something from that.

Is the script used to generate those files broken? (and is debian-boot
the correct place to ask?)

Please keep me CC:ed has I'm not subscribed to the list yet.

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Problems with netboot files for etch'n half

[Yves-Alexis Perez]

On mer, 2008-08-06 at 19:14 +0200, Frans Pop wrote:
 This does not make any sense to me. 'strings' tells me the kernel in that 
 dir is 2.6.18. And that is exactly as it is supposed to be as _none_ of 
 the images under dists/etch/main/installer-* has anything at all to do 
 with etchnhalf. They are etch 4.0r4 images, not etchnhalf images, and 
 thus use and install 2.6.18.
 
 See [1] for installation instructions and images that will install 
 etchnhalf.
 
 [1] http://www.debian.org/releases/etch/debian-installer/etchnhalf

Hmhm, yeah. I guess I picked up correctly initrd.gz from the link on the
page above, but picked the kernel from the standard etch netboot image,
thus getting the 2.6.18.

Sorry for the mess,
-- 
Yves-Alexis


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

Bug#407834: tasksel: add librsvg2-common to xfce-desktop task

[Yves-Alexis Perez]

Package: tasksel
Version: 2.66
Severity: wishlist

To display svg background, xfdesktop needs librsvg2-common installed. As
desktop-base use by default an svg background, it'd be nice that this
lib should be installed with xfce-desktop task.

Patch is attached.

Regards,
--
Yves-Alexis Perez

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Versions of packages tasksel depends on:
ii  aptitude  0.4.4-1terminal-based apt frontend
ii  debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii  liblocale-gettext-perl1.05-1 Using libc functions for internati
ii  tasksel-data  2.66   Official tasks used for installati

tasksel recommends no packages.

-- debconf information:
  tasksel/title:
  tasksel/first:
  tasksel/tasks:
--- tasksel-2.66/tasks/xfce-desktop-2.662007-01-17 20:29:04.0 
+0100
+++ tasksel-2.66/tasks/xfce-desktop 2007-01-21 19:21:57.0 +0100
@@ -28,3 +28,4 @@
   openoffice.org-gtk
 # Support for scanners
   xsane
+  librsvg2-common

Bug#407834: tasksel: add librsvg2-common to xfce-desktop task

[Yves-Alexis Perez]

On dim, 2007-01-21 at 20:35 +0100, Per Olofsson wrote:
 Yves-Alexis Perez:
  Package: tasksel
  Version: 2.66
  Severity: wishlist
  
  To display svg background, xfdesktop needs librsvg2-common installed. As
  desktop-base use by default an svg background, it'd be nice that this
  lib should be installed with xfce-desktop task.
 
 Isn't this a bug in xfdesktop4 then, that it doesn't depend on
 librsvg2-common?

Well, xfdesktop (will) recommends librsvg2-common. But user may don't
want to use svg background, and thus doesn't need it. And tasksel won't
look at Recommends: so it needs to be manually added to the task. 

Regards,
 
-- 
Yves-Alexis



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: powerpc daily sid_d-i CD builds working again

[Yves-Alexis Perez]

On Tue, 2006-05-16 at 08:23 +0200, Sven Luther wrote:
 On Tue, May 16, 2006 at 12:17:10AM +0200, Yves-Alexis Perez wrote:
  0 OFfb ATY,264LTP
  1 OFfb ATY,264LTP
 
 Ok, this is atyfb, and you probably have a rage something chip in there. I
 wonder about the two fbdevs, but i suppose this is one for the external port,
 and one for the LCD panel. Do you per chance have an external monitor
 connected ?

No, but I can connect one if needed.
 

  dmesg says nothing about framebuffer. The .config is the one used when
  generating powerpc gtk installer, don't know where to find it.
 
 Ok.

But syslog does. See http://heracles.corsac.net/~corsac/hydra/syslog

Jan  1 00:02:32 kernel: atyfb: using auxiliary register aperture
Jan  1 00:02:32 kernel: atyfb: 3D RAGE LT PRO (Mach64 LI, PCI) [0x4c49 rev 0xdc]
Jan  1 00:02:32 kernel: atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 
100 Mhz MCLK, 100 MHz XCLK
Jan  1 00:02:32 kernel: atyfb: monitor sense=62b, mode 6
Jan  1 00:02:32 kernel: Console: switching to colour frame buffer device 128x48
Jan  1 00:02:32 kernel: atyfb: fb0: ATY Mach64 frame buffer device on PCI
 
   Or alternatively give us the lspci output corresponding to your graphic 
   card,
   and the kernel version used, and i will investigate for you.
  
  Linux 2.6.16-1-powerpc
  lspci isn't very verbose at the moment because there are only unknown
  devices.
 
 Try lspci -n.

http://heracles.corsac.net/~corsac/hydra/lspci

-- 
Yves-Alexis Perez


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: powerpc daily sid_d-i CD builds working again

[Yves-Alexis Perez]

On Tue, 2006-05-16 at 09:58 +0200, Sven Luther wrote:
 My diagnostic here, is that g-i makes some assumptions that are wrong
 on
 powerpc. Most probably it tries to load the vesafb module, but since
 the above
 is builtin in the powerpc kernel, that test fails, obviously.
 Furthermore,
 vesafb is a x86-only thingy. 

Ok, I tried with some options
(http://people.debian.org/~terpstra/message/20051202.093632.1589458f.en.html ) 
that people indicate me in #debian-boot.

Still nothing.

I managed to install strace in the busybox and ran debian-installer
trough it.

The logs are here:

http://heracles.corsac.net/~corsac/hydra/di3.log
http://heracles.corsac.net/~corsac/hydra/strace.log

Don't really know what's happening...

To make myself clear, I don't really *need* to use gtk-installer on this
box, it's only my test box, and I wanted to try g-i on this (old)
hardware, only to test if it worked.

Regards,
-- 
Yves-Alexis Perez


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: powerpc daily sid_d-i CD builds working again

[Yves-Alexis Perez]

On Tue, 2006-05-16 at 17:52 +0200, Sven Luther wrote:
 On Tue, May 16, 2006 at 05:33:24PM +0200, Sven Luther wrote:
  On Tue, May 16, 2006 at 12:16:38PM +0200, Michael Schmitz wrote:
 $ more /proc/fb
 0 ATI Radeon Lf
   
0 OFfb ATY,264LTP
1 OFfb ATY,264LTP
   
   Might be the LCD is actually on the second one?
  
  This might be the reason it fails, if it is so. But i am not sure, since the
  dmesg output mentioned fb0.
 
 17:37  Corsac but forcing DEBIAN_FRONTEND to gtk seems to run correctly,
 until it crash with signal 11
 
 So, the DEBIAN_FRONTEND is not correctly set to gtk, for whatever reason,
 probably because of the image used, and the build setup not being adapted for
 powerpc after the merge or something.

I don't really know. Maybe the framebuffer.. error message is also due
to framebuffer crashing.

 
 Still, it crashed with signal 11. 
 
 Could you tell us more about this signal 11, and tell us when it happened.

You can see logs of running debian-installer:

http://heracles.corsac.net/~corsac/hydra/di3.log

When I strace this, this is what I get:
http://heracles.corsac.net/~corsac/hydra/strace.log

 
 It is possible that we did disable some stuff in the directfb code for radeon,
 which needs disabling also for atyfb, or in general for powerpc.
 
 Some directfb accel i think it was.


On advices got on #debian-boot I added on my /etc/directfbrc:

debug
no-hardware

Regards,
-- 
Yves-Alexis Perez


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: powerpc daily sid_d-i CD builds working again

[Yves-Alexis Perez]

On Mon, 2006-05-15 at 23:53 +0200, Sven Luther wrote:
 On Mon, May 15, 2006 at 04:01:17PM +0200, Yves-Alexis Perez wrote:
  On Mon, 2006-05-15 at 15:28 +0200, Sven Luther wrote:
   What framebuffer is used ? atyfb probably ? 
  
  I don't really know. I used video=ofonly but it doesnt help.
  I can login on terminal 4, and it seems that there are no fb module (at
  least find /lib/module/2.6.16-powerpc-1 -name '*fb*' outputs nothing.
  
  I have a /dev/fb0
 
 What does dmesg say, and also what is the content of /proc/fb. My powerbook
 says :
 
 $ more /proc/fb
 0 ATI Radeon Lf

0 OFfb ATY,264LTP
1 OFfb ATY,264LTP
 
   I believe that this one is builtin in the kernel, it used to be at
   least. Can
   you check that ?
   
   Basically, there is two possibilities of it failing :
   
 1) the framebuffer device is not builtin, and cannot be found as
   module.
  
  how can I check I check if framebuffer is builtin ?
 
 Read the dmesg output, and see what it says. Check /proc/fb too. Check the
 .config file.

dmesg says nothing about framebuffer. The .config is the one used when
generating powerpc gtk installer, don't know where to find it.
 
 Or alternatively give us the lspci output corresponding to your graphic card,
 and the kernel version used, and i will investigate for you.

Linux 2.6.16-1-powerpc
lspci isn't very verbose at the moment because there are only unknown
devices.

I'll reinstall a debian on it without the gtk installer to have those
informations.

 
 2) the graphical frontend doesn't know how to deal with builtin
   framebuffer
 devices.
   
   What strikes me at odd though, is that if you are having output, then
   you
   already have a framebuffer device, and thus there is a problem around
   2).
   MAybe it tries to loade vesafb, or something such.
  
  dmesg | grep fb outputs nothing useful
 
 Ah, this is suspisious. At least offb and radeonfb are builtin, and either
 should report a fb-greppable string. Maybe dmesg did overflow ? 


Possible yes, I'll try a restart before reinstalling

-- 
Yves-Alexis Perez


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]