Re: [External] Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-11-04 at 13:45 -0500, Mark Pearson wrote:
> I've started chasing this directly myself, but last week was crazy busy.
> I have the owner of a number of S and Central America countries looking 
> into it - I need to go chase some others.
> Sorry - really slow going :(

Hi Mark, I hope a monthly ping is ok for you. Did you have a chance to talk to
EU geos people?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl/HQ7AACgkQ3rYcyPpX
RFvvFAgA0TUoJRfJ7v+KlhCSOtXB0Kzp0b1Yr+dmEngejNjBR2wOF9ttEbAeAVpI
5nEYDKSs6KgoqABUNG8+CIxkSnH3o1O9lwApLJ5xTqUakso9JAQpW9Z3eMSeB9Hf
K3kSSui+SJM3SAxEzFQS7vHPNKpa1ckbgi9u+xDO3C3ObOOiXFkapsYJdUtI4f6i
wrBikX9GzMOskG/E5OSdI3fcUFih5/E5km74/lA8pLYtIJDXWVqsDqKFyHh8VCI3
DHPsFWfmbiELbqasFyhLdWA7F/g56tmdM/tqzWHDgOFQHkj+NVeQ/N1iFIf/Xgsr
xXAdwRoPZjQ8cqqBHJJfVxlYms7VRw==
=eT6s
-END PGP SIGNATURE-

Re: [Artwork] Survey for the default artwork for Bullseye (Debian 11)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2020-10-26 at 16:18 +0200, Jonathan Carter (highvoltage) wrote:
> To vote for your favourite theme, visit the following website and click
> on the "Bullseye Artwork Survey" button. From there, you can rank your
> choices from the available options to the My Choices section from most
> preferred to least preferred.
> 
> https://surveys.debian.net/
> 
> The survey is now open and closes on 2020-11-10 23:59 UTC.

Hi Jonathan,

I somehow missed the call (and even the deadline). The survey doesn't seem
available anymore (because we're after the closing date, I assume), do we have
a winner yet?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+sNpUACgkQ3rYcyPpX
RFsQ/ggAtDFOw/p4rBtsRhPaonbLgyWbFH1mYM+9OJqnGUxEIV/+48nvNl28CGX4
+mOI/0sv6ofc36O3K1E/8ufsB8wddfDgLBMAMVcYjeqPCypYvXHlyyfSyvfpuJ3d
0v/T2KIjNeZTfYLFS3S8zDxNunF/KwzlFlMEwByVlZ++pOMUtjTsg/v4JqkeZP9l
ST/SKrxDnhIiL6N2mcCq/ANCqtqvPNBKG+zJ1AHKvw6hzvCZEegrJr+h5gcSJrIV
BkT8q1eahnNoYnJmONSq34M42UPERHAIlYTX88LLZzUYgN39PbkofJRsK+t/+9PP
9r4Ay66SfB7TWvwJbRG5TfiMAIvCPQ==
=9njd
-END PGP SIGNATURE-

Re: [External] Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-11-04 at 13:45 -0500, Mark Pearson wrote:
> I've started chasing this directly myself, but last week was crazy busy.
> I have the owner of a number of S and Central America countries looking 
> into it - I need to go chase some others.
> Sorry - really slow going :(

Thanks! I'm personnaly more interested in EU/FR geo, but thanks anyway :)

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+i+JQACgkQ3rYcyPpX
RFtGYAf/ZN2b6nZcM+Sb11Vm0VbdPtmbK9hdW2wBI7a1aFagDJyejCDNhUe0TGol
Uoxdmu4jD8EAbpyULJerKr0Mwhayr1ekJB9suP9ZMIak2HuNkmkp6klvjPU255pz
AEnbxBA4QGTT/FYWbgkTQaEzQcNBW7kRzGwoVQJzRtDr95yG6eun4MndES5tfcJ9
PK48Ha9vi2CEXUPwAgZNf1nyWzeYMJap3fdsWf/uSkvaEB0HN31MtgSeityqL7rf
zEYgcNqyJoqr5i0OXArOEKCQqVIFLgVAshzKGK7SUjrAyuSDA26bN7yQ0LM5oKmS
pnEhEd3qCv2s+Lt2TBu4708Mi9Oplw==
=kcm/
-END PGP SIGNATURE-

Re: [External] Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2020-09-17 at 11:12 +0200, Yves-Alexis Perez wrote:
> did you have an update from your colleague on the other geos?

Hi Mark, I might have missed it, but did your daily poking of your collegues
gave results on the others geos? Thanks!
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+i7C8ACgkQ3rYcyPpX
RFtgZAgAoEEfTPawnMK7u16I8h7SXODl/496tmCtjeUSgtMZdON0c5YNYNPsbV0O
JX5oFuEM6CFu6BX5mTRIXm6cXzqlu9my5Mu338aGbMi8lRpEnDeO9d0a6CPjiE6P
12DXqhkHU/x3EZdmn+McXmVNUR6R10bplqU9s+SkeRLiowlN4pauOWOe4IT5who7
jaXc2Ugty9EVPopsHTcu6tA4ZllNFqlAFc3YIf1BTZm/AT/DZ8BbYBIiBc/ddC3e
Uuf78WpiekToE5kpvGUtaAuuudjabOovUflYIdTvCQ9RiEr41Snx7VrcgbRVYMJD
LIUpZbTktyUsvJ/622CvdyzPFnJsJA==
=ls85
-END PGP SIGNATURE-

Re: [External] Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-09-02 at 15:30 -0400, Mark Pearson wrote:
> On 9/2/2020 2:19 PM, Yves-Alexis Perez wrote:
> > > We're still working on getting other geographies up and running - not
> > > available yet I'm afraid.
> > 
> > Any idea of the timeframe? Weeks, months, more?
> Afraid I don't know but I hope it's not months...it will depend on the 
> geo teams to some extent.
> The US site took us a few weeks to get up but that was the first 
> oneso fingers crossed the others are easier. My colleague is chasing 
> the others down so I'll check with him what the status is.

Hi Mark,

did you have an update from your colleague on the other geos?

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl9jKHMACgkQ3rYcyPpX
RFtopAf+KUt38VYwcbNjZ2dY3QB0r8emGSjxFqMwkxmf3f7YwQajrzxGB7wRvhOd
C69WQAdppNhiyovlBSU950p1XFQRUjfyg68zRo6X1BSUnjvNKQmAVd8ZaKnmZNp/
ZEV8Vc1+bV6tvVowArdv24E19CMwbIa2Wtabgg9btu/pwNLal4dahNNIZEWo7SgS
qSHNlIZaykgaHtXs8tyBUfQbTY3pBjH4NW4P49feXbHOoFS179igDkFXbo7ot9eB
1clOtkJOMlgEUztleJS5u7rFt9AASFbhhfc42BSkPVY2iBKxGpXl0iu83Qy/r6t7
58Y+wWo0RtzNXeDGkZYrnys6rxXfTQ==
=au9y
-END PGP SIGNATURE-

Re: [External] Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-09-02 at 15:30 -0400, Mark Pearson wrote:
> Hi
> 
> On 9/2/2020 2:19 PM, Yves-Alexis Perez wrote:
> > > US: http://www.lenovo.com/us/en/Linux
> > > Canada: http://www.lenovo.com/ca/en/linuxca
> > 
> > I've tried registering on the US website and it seems to work fine here.
> > I'm
> > not completely sure how explicit the “rebate” is (and with the LABORDAY
> > coupon
> > currently on the “standard” website it's not easy to compare). Anyway I
> > didn't
> > investigate further because I'm from Europe so I'll wait a bit.
> > 
> I'm just curious - it doesn't let you double up on the discounts? (I 
> have no idea if it would or notbut worth a go :P)

To be fair, I did try to add that, but the /Linux website told me the coupon
was expired :)
> 
> > > We're still working on getting other geographies up and running - not
> > > available yet I'm afraid.
> > 
> > Any idea of the timeframe? Weeks, months, more?
> Afraid I don't know but I hope it's not months...it will depend on the 
> geo teams to some extent.
> The US site took us a few weeks to get up but that was the first 
> oneso fingers crossed the others are easier. My colleague is chasing 
> the others down so I'll check with him what the status is.

Ack, thanks!

> > On the X1C configuration I tried, the “Absolute” stuff is there but one
> > can't
> > change it. For the HAP the snippet is not there at all (although I think I
> > remember seeing it once)
> > 
> I've not played with that but I can find out about it. I've got a T14 
> AMD in front of me right now and it I could configure the Absolute 
> Persistence Module (enable/disable/permanently disable).

Yeah I know the end-user / administrator can disable it in the BIOS settings,
but there's apparently a way to do it on the website and I was curious about
it.

> For the ME HAP...I don't see that either. I'll see if I can find out 
> about it.

Obviously that's only on Intel platforms (AMD has the PSP processor but I'm
unsure if there's an equivalent HAP stuff). This one actually *needs* to be
set by the OEM before end of manufacturing (flashing would work on older Intel
platforms but not the more recent ones). Some details can be found here: 
https://en.wikipedia.org/wiki/Intel_Management_Engine#%22High_Assurance_Platform%22_mode

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl9P9HsACgkQ3rYcyPpX
RFtQdggAqqLcNKfzR8wWePE3tKc9i8jd3m/ey53GCOY/SvcF9j88ajDBqJlgkFm8
tcr6tlNPWsqqBDEYceslXrzEE94c2I9Ddrh0g1nn4/bpVMLgKWUgqq2fculhfhMt
et3gDr+M8ERCWHBHTHNK0adVxGfidC8JlXamgNFaMOpg9YJ8rMcZhwKAA1aS1Jgq
Oj9Bf2Ec7T2lj4PZNG1RrOoOzV16xx6DAkGv1ZUAXXd2+mLpbnRWWfnhPfD0GEKH
iz3Ehrdn1Kxkt2qNNirQA8SkdTbJA+hXb89RxDFrSWuQGDWiuxZJiey5zjDbPHMm
eUZHn5mBsIpyF70a4dMSY5u4Mdr/7A==
=U/iR
-END PGP SIGNATURE-

Re: Lenovo discount portal update (and a few other things)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2020-09-02 at 09:08 -0400, Mark Pearson wrote:
> Hi Debian developers,
> 
> Following on from DebConf 2020 (which I thoroughly enjoyed - thank you!) 
> the Lenovo portal that was announced is now available:

Hi Mark, and many thanks!
> 
> US: http://www.lenovo.com/us/en/Linux
> Canada: http://www.lenovo.com/ca/en/linuxca

I've tried registering on the US website and it seems to work fine here. I'm
not completely sure how explicit the “rebate” is (and with the LABORDAY coupon
currently on the “standard” website it's not easy to compare). Anyway I didn't
investigate further because I'm from Europe so I'll wait a bit.

> We're still working on getting other geographies up and running - not 
> available yet I'm afraid.

Any idea of the timeframe? Weeks, months, more?

> You should just be able to register with your debian.org email address 
> to get the discount on any Lenovo equipment. Do let me know if any 
> problems.

Worked just fine for me at least.
> 
> We also have our first Linux platform up (X1 Carbon Gen 8 with Fedora). 
> There should be a number of other platforms coming soon - we're working 
> on those and I expect them to be out in the next few weeks. If you have 
> any questions on our Linux platforms please let me know.

Actually I do, although it's not entirely linked to Linux. When configuring an
Intel platform there are two choices which are not always there but would be
interesting I think:

- - Disabling of Absolute bios agent
- - Activation of the High Assurance Platform bit (HAP) in the Intel ME
configuration

On the X1C configuration I tried, the “Absolute” stuff is there but one can't
change it. For the HAP the snippet is not there at all (although I think I
remember seeing it once)

Again thanks for the work enabling the portal.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl9P4hUACgkQ3rYcyPpX
RFvHLAf/dDnQwGKqdgV+7Pv621sn8ykpwvjIrA6jiKBOIodl3NXfnR+J4eeov2Do
zHtx+p15gphk4rmC7cZG7SiCWpqSLmRyOAyouutqgreXwUROmJt/TNA37dVvjT2R
O8dIvGyJlUO7lWYwBwMvpdZCPki5Q1eC4j+ZwhUXTq4iptYFyliePJkKbTOcUETP
rOwVjCtN7Wrdj20v0xopREi2ZabbQuvnMng+pL+KyOVebE4Md6wKHXuwWgKNx8FR
STqQsHmDQHOogGp8BkvZ0lQUZRgQgHAR7rvjl2LLHiWzanuqDomlSIGsXsyZUZcW
lIaKUvr5xoceEtyVHTfJuI3sH61xKQ==
=kHpq
-END PGP SIGNATURE-

Bug#963091: ITP: idevicerestore -- command-line application to restore firmware files to iOS devices

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: pkg-gtkpod-de...@alioth-lists.debian.net

* Package name: idevicerestore
  Version : 1.0.0
  Upstream Author : libimobiledevice project
* URL : http://www.libimobiledevice.org/
* License : LGPL
  Programming Lang: C
  Description : command-line application to restore firmware files to iOS 
devices

 The idevicerestore application is a full reimplementation of all granular
 steps which are performed during the restore of a firmware to a device.
 .
 In general, upgrades and downgrades are possible, however subject to
 availability of SHSH blobs from Apple for signing the firmare files.
 .
 Some key features are:
  - Restore: Update firmware on iOS devices
  - Firmware: Use official IPSW firmware archive file or a directory as source
  - Update: Allows updating the device by default or erasing all data
  - Download: On demand download of latest available firmware for a device
  - Cache: Downloaded firmware files are cached locally
  - Custom Firmware: Restore custom firmware files (requires bootrom exploit)
  - Baseband: Allows one to skip NOR/Baseband upgrade
  - SHSH: Fetch TSS records and save them as ".shsh" files
  - DFU: Put devices in pwned DFU mode (limera1n devices only)
  - AP Ticket: Use custom AP ticket from a file

Bug#963042: ITP: libirecovery -- Library allowing communication with iBoot/iBSS of iOS devices via USB

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: gtkpod Maintainers 

* Package name: libirecovery
  Version : 1.0.0
  Upstream Author : libimobiledevice project
* URL : http://www.libimobiledevice.org/
* License : GPL/LGPL
  Programming Lang: C
  Description : Library allowing communication with iBoot/iBSS of iOS 
devices via USB

libirecovery is a library which implements communication to iBoot/iBSS
recovery mode found on Apple's iOS devices via USB.

It can be used with the idevicerestore utility to flash firmwares to
iOS devices.

Re: Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-06-03 at 12:59 -0700, Russ Allbery wrote:
> Ah, good call.  I was also seeing other problems with the Intel driver in
> combination with light-locker where the monitor resolution would be set to
> some incorrect value after restore from lock.  This would come with kernel
> errors like:
> 
> [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo 
> underrun on pipe B
> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
> underrun
> 
> and then lots and lots of:
> 
> [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle 
> patterns

My gut feeling is that light-locker just uses codepaths not really used
otherwise, like vt-switch at the same time as suspend/resume or screen off/on.
Unfortunately debugging i915 is completely out of my league (and I already
tried multiple time on other issues).

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1fv0ACgkQ3rYcyPpX
RFuTTQf+ITXxUm6DnBRNuGwsKbKCFoeXUAiP+v5GdIJDDifEWG91inoF1tf6GswS
l1RRJHYczv9WtjL+6e1522vzAp0h6jw5WuAcQfXcAZZR4n/GU25VVa6gsIqbGIv9
XvsoN+Y/MGdJueg0xYfBTuiInoySchJ4cv2oh56MkcndjgDiPtiH8bAXCcxwBflj
OXkCEUj8LLoOACdTYBWA02vA66daEMRk7Y6gkO+BwbvS/ZeVL1T2xQV0W47obtF5
AaBhx/AwM59Bzk5RUD8EBi5cOWuXB7KIYcuXLzaFjNzk6yXXTAx26740dR8q3CoD
JHld4HjQRllFUxsDiZvz5+1q5+nShw==
=ho8d
-END PGP SIGNATURE-

Re: Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2019-06-03 at 21:55 +0200, Yves-Alexis Perez wrote:
> I noted Andreas raised the severity, but I hope someone has an idea how to fix
> that because I don't.

Also, since it was posted on -devel, I guess there's a bit of exposure: if
some people care about Xfce, by all mean please join the team and give a help,
because right now it's basically on my shoulders, with bits of help here and
there from other (mostly on the packaging side, not really on bug triaging). 

It's been like that since years, and it's not really working fine, especially
when I'm not around. And at that point I'm not comfortable anymore with that
because it more likely that I might be “not around” now than before.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1e+oACgkQ3rYcyPpX
RFtp6gf/SeqjvtvV/3TZg5DX327r4oJcLku0EggZJWfiyFYM73Erq81YZMNbOTsL
/9xcg6wri9gHZO4+tkzjhdrv0Meuh9+cXHDeBgdg0I9b6HKl1T4Xo6CE7fFvrexn
KgQGqy5Tc1yttQVrPFTI9s+WEhxrByEB70rYHuOQW0TvgKIYaAdpfG1gRV14gw23
vvgeBwNpYSlfiD1Od/lVjkYuyPRcmwi2FNC6sbhSIui3Ll2UppOeFoqA4Y962vnM
XP1cMux8BOEwfHZnjL9bzV7x+tWGFz7l2mbV/Xyew5hHBIstYkFk6VDIJHLxeMd1
nMXCY+neAYb7gzfXQlCNVAg+w63a/w==
=E2SN
-END PGP SIGNATURE-

Re: Bug#929834: Buster/XFCE unlock screen is blank

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2019-05-31 at 18:32 -0700, Russ Allbery wrote:
> This appears to be a bug in light-locker specifically, which is the
> default screen lock program with XFCE with lightdm.  See, for instance:
> 
> https://github.com/the-cavalry/light-locker/issues/114

Actually it seems to me that the bug is a bad interaction with light-
locker/lightdm locking system (which relies on vt switch) and the Intel
driver. It only seems to happens on this driver, and I think it's also been
reproduced just by doing vt-switches (but can't remember where it was
reported).
> 
> Switching to another greeter from the default gtk-greeter appears to help
> according to that bug, which may mean that the bug is actually in
> lightdm-gtk-greeter.  There doesn't appear to be a Debian bug for this; it
> might be a good idea to open one against light-locker (or, if you confirm
> switching to slick-greeter per that bug, lightdm-gtk-greeter).

There are at least a gazillion bugs against light-locker and lightdm, or xfce.
I tried to at least merge some of them (like #846278) but clearly failed to
identify all of them.

And people are still reporting new ones (or posting to -devel) so clearly they
are hard to spot.

Maybe locking through vt-switch is a bad idea,

I noted Andreas raised the severity, but I hope someone has an idea how to fix
that because I don't.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlz1eyAACgkQ3rYcyPpX
RFvkhQf8Dqj0s6569PTiyxfczeA2PV83LWFdBOaCU3FDHv3I3Gdk2E+CR8UpunwI
n+YsAEIU/bixAGVhH8yiPKSJiZg4Zjv7pCLVKNHSeg9vigAIWzjag+dArFQciZkP
4JdqtmJRxPwKyK4v7Fp2u3/DK8kjHvUKr0AafkhVGxo0qSuvTUxqBhiy5CeBX4NP
2lnZ5JE+zUsuweEFomy/FAXMMC8E34eWCWtQ/w4iJlwlUghPLR0YbRANN1sbqz73
MHT/fCF+xCKoSRDQT+UZWNGs9hCEDOpoAydXIuwiMzXxsKG83SFGuCFku4ZGZ0vK
d4nzUUNx7UhpwcGWSKAXOq1TbtfnJA==
=lmZk
-END PGP SIGNATURE-

Re: Bug#919226: ITP: hardening-runtime -- Runtime hardening configuration files

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Just a side note on this. The package currently supports sysctl (by dropping a
file in /etc/sysctl.d, which should be common enough) and Linux commandline
when using grub (by dropping a file in /etc/default/grub.d).

I was asked to open a discussion about the general matter of a package tuning
the Linux kernel command line options.

I don't think it's a problem since it's in a package whose purpose is exactly 
that and it's easy to tune/disable if needed since it's in a configuration
file, but in case people disagree feel free to reply (please keep me on CC,
I'm not subscribed to -devel@).

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlw8UR8ACgkQ3rYcyPpX
RFtMuggA2H/+/cLT71cLzQVrkBy/yRsdpZ/2TRPn9akTP2BUUjlB3Ze/B5kBXFFT
LnpfDap6/0RapExdPAmfGDEJnw0liV4jWfQy+g78VvKdoNUdqu5kqIB3tiY6pBnP
yxLQZW/NMZTi+oM3sYK20PnyKWeN8eMfpNi5JAyUDELSXCPBMre9TrkAG9trnK+Y
ilRWPV2p9BZQ7VlA8Psb9magXc9/O3r5dj9u9XdEjiyM5rtFl57gz+BFMfNOBRCI
B4B4BWTyno/4y6+VK/tOl6ZmpVa5wuxk4VDHWZlRdCkPmWhrzezOIiNIZ58tPwAz
KA2q1Z/+PbX4vSymzfdlW4BWUVa7Ag==
=stla
-END PGP SIGNATURE-

Bug#919226: ITP: hardening-runtime -- Runtime hardening configuration files

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Yves-Alexis Perez 

* Package name: hardening-runtime
  Version : 1
  Upstream Author : Yves-Alexis Perez https://salsa.debian.org/corsac/hardening-runtime
* License : GPL-2+
  Programming Lang: configuration file
  Description : Runtime hardening configuration files

The package contains configuration files (Linux command line and sysctl
for now) with settings recommended by the Linux Kernel Self-Protection
project
(https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings)

The package can be used to quickly harden a default Debian installation.

Re: Bits from the DPL (May 2018)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-05-31 at 21:40 +0100, Chris Lamb wrote:
> You did not miss anything; it was not discussed in public.

Ok.
> 
> I can let you know the details privately if you wish, but I'd rather
> not shout the parties involved from the rooftops just in case it could
> still happen, but mostly because it could prevent other firms from
> suggesting partnerships with Debian in future.

No need, thanks. It was merely just to know if the reason was technical or
not, and if it was something we could do something about.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlsRJgAACgkQ3rYcyPpX
RFvBhQgA5nM96b51E5kjnwmPBnBd8pdjdU+TC67UN0A1yWu7j9P4gVlEgy/wW/+N
vn0m1SeMn43jlc/pDD2O775+rhKcrtN/0yjVgpSigcuZjHChVXtThF54VQ7BzjIy
5tKtVnLqTdRFuGkVyVBo6ZkubKi6ccu1gILTu5aTeJoEV2+NC3oaEaifg1cO2nG2
h592YlkHLYA33GxRGfd02WUSMKpPm/cGBHtXTRE50lj3IAT9M4N2/cba5781BuyK
Jo/lYgFnRHCCohY14EvwvMpLoKvrQ0pogkOaAJ/OT6upXJq8j4erGKkY6J7tS8Ee
6Q4V6xiKTzI5k13QByNXaimDUHbIYQ==
=YBa/
-END PGP SIGNATURE-

Re: Bits from the DPL (May 2018)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2018-05-31 at 17:33 +0100, Chris Lamb wrote:
>  * Discussing a potential scenario where we could provide hardware
>encryption keys for all Developers, partly as another benefit of being a
>DD [25] but moreoever to raise the general level of security in the
>Project. Unfortunately, this now appears like it will not happen.

Hi Chris,

would it be possible to get more details on this? If it was already discussed
publicly I have missed it, that's entirely possible, so feel free to point me
to that discussion.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlsQWycACgkQ3rYcyPpX
RFsfuAf/T7YfRypgSOO7W2+PJQSZodO4bcECAJztsy7wvdv1KMgdkqDrxIIQ30cL
zXhBdSTFWVmRd6L/MjVN9sEq2eFD3W1V3mER05pYWo4BTEl8sXSqm54tkCbNxGQS
51hXERwrX+fxNj9H/4QmbHazLTCydiuNQU+c2Uhl4QjmasHLRsp0VN5dl79fskMY
cc0r8lgdU0aPTiDL064xHhnSQD/4Jz45rO/JEcpHzKs8QNJKjznK0gjj6xc3Gzc6
1xvw6tl2UbypHKHVTS4oci/HB19nbHQziVDchWRYz9CRQhOJ3T6ooowlr3j12eUe
HDOaYUdyevOHTIp8FjFpRVHZ/z3rDg==
=vx50
-END PGP SIGNATURE-

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

[Yves-Alexis Perez]

On Sun, 2017-07-09 at 15:41 +0100, James Clarke wrote:
>  You've done the build, so by uploading the _amd64.buildinfo
> you are announcing that you were able to produce those build results in the
> specified environment, and in theory it allows anyone to compare the buildd's
> results to what you claim to have been able to build, without you ever having
> to upload the binaries (yes, throwing away binary uploads would allow you to 
> do
> this, but *you would still want to upload and keep the _amd64.buildinfo
> otherwise you have nothing to compare against and you might as well have just
> done a source-only upload*).

Actually, I've done the build just to be sure what I'm uploading does build.
But I'm doing a source-only upload, I'm uploading only the _sources.changes
that pbuilder requests generating (with SOURCE_ONLY_CHANGES=yes in
.pbuilderrc), but the build does produce and _amd64.changes too (which I don't
touch).

Regards,
-- 
Yves-Alexis

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

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

[Yves-Alexis Perez]

On Mon, 2017-07-03 at 20:49 +0200, Yves-Alexis Perez wrote:
> On Mon, 2017-07-03 at 19:06 +0200, Mattia Rizzolo wrote:
> > On Mon, Jul 03, 2017 at 07:00:20PM +0200, Philipp Kern wrote:
> > > [ Correcting ftp-master's email address, but keeping the large list of
> > > recipients for some reason. ]
> > 
> > really…  that's just a ftp-master issue IMHO, definitely not due to
> > debhelper much less by pbuilder…
> 
> I fine with that answer. My point was just that, should ftpmasters say that it
> was unsupported to have an _.buildinfo file inside a _source.changes,
> then something was wrong in the build toolchain.

I hope that ftpmasters will reply here, but just in case:

[08:06:05] (ansgar): Corsac: I fixed it by changing the filename and resigning
the buildd's changes.  But please don't upload _amd64.buildinfo unless you 
include amd64 binaries.

I didn't manually generate this _sources.changes and I didn't ask to include
_amd64.buildinfo. So something does need fixing in the build chain, whether
it's pbuilder, debhelper or dpkg-dev or a combination thereof.

Regards,
-- 
Yves-Alexis

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

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

[Yves-Alexis Perez]

On Mon, 2017-07-03 at 19:06 +0200, Mattia Rizzolo wrote:
> On Mon, Jul 03, 2017 at 07:00:20PM +0200, Philipp Kern wrote:
> > [ Correcting ftp-master's email address, but keeping the large list of
> > recipients for some reason. ]
> 
> really…  that's just a ftp-master issue IMHO, definitely not due to
> debhelper much less by pbuilder…

I fine with that answer. My point was just that, should ftpmasters say that it
was unsupported to have an _.buildinfo file inside a _source.changes,
then something was wrong in the build toolchain.

Regards,
-- 
Yves-Alexis

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

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

[Yves-Alexis Perez]

Sorry for the fail on FTP-masters email address (which also got the mail
bounced from alioth). Replying to keep threading consistent but quoting the
whole mail below).

On Mon, 2017-07-03 at 14:49 +0200, Yves-Alexis Perez wrote:
> Hi,
> 
> I recently had a problem with an upload to the archive, likely due to bad
> interaction between the tooling I use to build packages and the archive
> manager.
> 
> I usually build my packages using pbuilder, with SOURCE_ONLY_CHANGES=yes in
> .pbuilderrc, so pbuilder will ask to generate a _source.changes along with
> the
> _.changes files.
> 
> When uploading to the archive, I do a complete (meaning arch-any + arch-all)
> build to be sure, then upload only the _source.changes so everything gets
> rebuilt by the autobuilders. It worked just fine for every upload I did to
> sid
> and experimental.
> 
> However, I recently did that for an upload targeted at stretch-security, and
> unfortunately this caused a problem on security-master, where dak couldn't
> process the build by the amd64 autobuilder because an _amd64.buildinfo file
> was already present. It was part of my upload because it was included in the
> _source.changes file generated during the pbuilder run.
> 
> I'm not completely sure what needs fixing here, but:
> 
> - when doing a complete build, something will generate a _.buildinfo
> file (using dpkg-genbuildinfo), maybe its part of debhelper, I'm not sure
> what
> control I, dpkg or pbuilder have on this;
> - nothing generates a _source.buildinfo file;
> - when pbuilder generates the source changes file, it calls dpkg-genchanges
> -S
> after the build, which apparently includes any buildinfo file
> unconditionnaly
> (http://sources.debian.net/src/dpkg/1.18.24/scripts/dpkg-genchanges.pl/#L310
> )
> 
> So few questions:
> 
> - would it make sense to have a _source.buildinfo when building a package?
> - would it make sense to not include _.buildinfo when generating a
> _source.changes?
> - should the archive accept a _source.changes file with arch specific stuff
> inside (it's does currently, although the security archive failed later)?
> 
> I yet didn't file any bug (to pbuidler, debhelper or dpkg-dev) because I'm
> really unsure where the problem(s) lies.
> 
> Any help appreciated here. Please keep on CC, I'm not subscribed to debian-
> devel anymore.
> 
> Regards,
-- 
Yves-Alexis

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

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

[Yves-Alexis Perez]

Hi,

I recently had a problem with an upload to the archive, likely due to bad
interaction between the tooling I use to build packages and the archive
manager.

I usually build my packages using pbuilder, with SOURCE_ONLY_CHANGES=yes in
.pbuilderrc, so pbuilder will ask to generate a _source.changes along with the
_.changes files.

When uploading to the archive, I do a complete (meaning arch-any + arch-all)
build to be sure, then upload only the _source.changes so everything gets
rebuilt by the autobuilders. It worked just fine for every upload I did to sid
and experimental.

However, I recently did that for an upload targeted at stretch-security, and
unfortunately this caused a problem on security-master, where dak couldn't
process the build by the amd64 autobuilder because an _amd64.buildinfo file
was already present. It was part of my upload because it was included in the
_source.changes file generated during the pbuilder run.

I'm not completely sure what needs fixing here, but:

- when doing a complete build, something will generate a _.buildinfo
file (using dpkg-genbuildinfo), maybe its part of debhelper, I'm not sure what
control I, dpkg or pbuilder have on this;
- nothing generates a _source.buildinfo file;
- when pbuilder generates the source changes file, it calls dpkg-genchanges -S
after the build, which apparently includes any buildinfo file unconditionnaly
(http://sources.debian.net/src/dpkg/1.18.24/scripts/dpkg-genchanges.pl/#L310)

So few questions:

- would it make sense to have a _source.buildinfo when building a package?
- would it make sense to not include _.buildinfo when generating a
_source.changes?
- should the archive accept a _source.changes file with arch specific stuff
inside (it's does currently, although the security archive failed later)?

I yet didn't file any bug (to pbuidler, debhelper or dpkg-dev) because I'm
really unsure where the problem(s) lies.

Any help appreciated here. Please keep on CC, I'm not subscribed to debian-
devel anymore.

Regards,
-- 
Yves-Alexis

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

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Yves-Alexis Perez]

On Sun, 2017-01-29 at 17:54 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 853084 xfce4-pulseaudio-plugin
> 
> Bug #853084 [general] general: Not connected to PulseAudio server
> Bug reassigned from package 'general' to 'xfce4-pulseaudio-plugin'.
> Ignoring request to alter found versions of bug #853084 to the same values
> previously set
> Ignoring request to alter fixed versions of bug #853084 to the same values
> previously set
> > thanks
> 
Michael, it's always appreciated when you add a bit of context when
reassigning bug.

Fredrik, the plugin already recommends pavucontrol (which recommends
pulseaudio) so it should already have been installed unless you manually asked
 not. But right, it might be a good idea to have a direct pulseaudio
recommends .

Regards,
-- 
Yves-Alexis

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

Re: [Pkg-xfce-devel] Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Yves-Alexis Perez]

On Sun, 2016-07-10 at 08:39 +0200, Emilio Pozuelo Monfort wrote:
> Maybe the XFCE / Cinnamon / Mate maintainers can confirm if that is indeed
> the plan.

Talking for pkg-xfce: I have no idea what this is about.

Regards,
-- 

Yves-Alexis

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

Re: interested in (co-)maintaining midori

[Yves-Alexis Perez]

On ven., 2015-08-14 at 02:39 -0400, Sergio Durigan Junior wrote:
> Did you guys have time to look at my repository?

I'm not right sure who you're asking exactly, but just to re-state this
again: I don't want to be involved with Midori packaging anymore *at
all*. You can safely drop me from those mails, and do whatever you
want, I won't bother at all.

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

Re: [Pkg-swan-devel] say goodbye to network-manager-strongswan?

[Yves-Alexis Perez]

On mer., 2014-07-16 at 15:08 +0200, Romain Francoise wrote:
> On Wed, Jul 16, 2014 at 03:40:13PM +0300, Riku Voipio wrote:
> > Since you seem to know the software well, and it is important for you,
> > perhaps you can take over maintainence of the package? The current
> > maintainer doesn't seem to be active (no upload since 2012..).
> > Alternatively the package could be maintained by the strongswan team?
> 
> The strongswan team appears to have only two active members at the
> moment, Yves-Alexis and I, and I have no interest in maintaining
> network-manager-strongswan as I don't use network-manager myself.
> 

I don't currently use the network-manager strongSwan plugin but that's
mostly because it doesn't work. Should it work, I'm unsure I would use
it, but I do use network-manager on one laptop so I should be able to at
least test it, so I'm ok to put it under pkg-swan umbrella. But I would
also welcome anyone interested to join the team :)

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 05:02:03PM +0100, Ben Hutchings wrote:
> No, I meant that you might build a single binary package that would
> contain the grsec-patched source.  That would encourage building custom
> kernels with build-time randomisation.  I understand that's not the way
> you want to go.

Indeed. There's already a (quite outdated) linux-patch-grsecurity2
package which contains the patch for people wanting to patch the kernel
themselves. But that's not really useful imho.
> 
> Presumably your current package builds a linux-source-3.13 which
> includes an upstream source tarball plus a grsec patch?

In my case, it's actually the src:linux orig.tar.xz with the (adapted)
grsec patch added to debian/patches (like other featuresets).

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Wed, Apr 23, 2014 at 12:45:10PM +0100, Ben Hutchings wrote:
> On Tue, 2014-04-22 at 22:41 +0200, Yves-Alexis Perez wrote:
> [...]
> > NOTE: I don't want to dismiss Mempo attempts, especially the
> > reproducible build part, and I also think it's valuable to provide our
> > users a grsec kernel as part of the distribution, just that I prefered
> > to go the featureset way.
> 
> I do want to see the Mempo reproducible build work go upstream and/or
> into src:linux, as appropriate.  Unfortunately it's currently siloed
> just like grsec itself.

Well, I guess the non-grsec related stuff can go upstream/src:linux, but
as I'm not involved in the project, I can't really say.
> 
> > I had the impression that adding a new copy of the linux sources was not
> > really something appreciated by the project, and re-using linux-source
> > (binary) package means the patch porting needs to be done anyway.
> 
> That was what I thought, too.  Specifically, the security team is
> generally opposed to such duplication.

Well, speaking with my security team hat, I can't say I really like it,
but that's not really like having multiple copies of a library either.

Sharing an orig.tar.xz between multiple source packages would be nice
here (although it wouldn't help in case we have different versions).

In any case, that's something I'd accept, but I don't think I can have
the final word on this :)

> > But if I'm wrong or if things have changed since them, and there's
> > indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
> > easy way to provide grsec kernels in the Debian archive, then I'm all
> > for it.
> 
> Well 'make deb-pkg' doesn't work with a source package so you can't use
> it as a basis for official Debian packages.

Yeah, sorry my words were a bit confusing. I really mean “using a
vanilla linux.tar.xz, adding the grsecurity patch and the Debian .config
and building a Debian package with that”.
> 
> The options I see are:
> - Provide a source package based on src:linux that includes only the
> grsec featureset 

Which is more or less what I do with my current patchset (except that I
keep the src:linux name, but that could be changed pretty easily I
think).

> on top of an appropriate base version

I'm not sure I understand what you mean here. You mean staying at
3.2/3.13 for example?

> - Provide a source package that builds only a 'source' binary package
> (like linux-source-3.13)

I'm not sure what's the point here? Is it about having a source package
providing a binary package containing the unpatched vanilla linux sources,
which a src:linux-grsec package could build-depend on, then I guess we
can just have vanilla linux as orig.tar.xz instead of having to
build-dep on a linux-source-vanilla-3.13.
> 
> In any case, it needs long-term upstream support, which for jessie would
> presumably mean using 3.13 as a base, whereas src:linux will be a later
> version.

I guess so.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Yves-Alexis Perez]

On Tue, Apr 22, 2014 at 08:30:01PM +0100, Ben Hutchings wrote:
> On Mon, 2014-04-21 at 05:28 +0200, Carlos Alberto Lopez Perez wrote:
> > On 17/04/14 00:23, Aaron Zauner wrote:
> > > Now shipping grsec is a really good idea. I'd like to see that as well.
> > 
> > There has been an attempt to provide an official grsec-flavour of the
> > Debian kernel, but it didn't worked:
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090
> > 
> > For those interested, Corsac provides packages:
> > 
> > https://wiki.debian.org/grsecurity
> 
> There was a recent discussion on -private where I think there was some
> consensus that a grsecurity kernel package could be included in Debian
> as a separate source package.

I'm a bit unsure about that consensus. Right now there are two attempts
to provide a grsecurity package for Debian:

- mine, which is about adding a grsec featureset to the src:linux
  package (so basically adding grsec patch on top of the Debian patches,
  and re-using everything else). This attempt was already NACK-ed by the
  kernel team;
- the Mempo/SameKernel attempt, which is about using a vanilla kernel
  and adding grsecurity on top of it (and, I guess, a .config which
  looks like the src:linux one)

The latter is much easier in term of management since all the
integration is done by spender (he's actually working on providing
.deb builds of grsec packages), so I didn't really consider it worthy to
investigate time on it since basically everyone can do it with a simple
script.

NOTE: I don't want to dismiss Mempo attempts, especially the
reproducible build part, and I also think it's valuable to provide our
users a grsec kernel as part of the distribution, just that I prefered
to go the featureset way.

I had the impression that adding a new copy of the linux sources was not
really something appreciated by the project, and re-using linux-source
(binary) package means the patch porting needs to be done anyway.

But if I'm wrong or if things have changed since them, and there's
indeed a consensus for the vanilla + grsecurity + make deb-pkg as an
easy way to provide grsec kernels in the Debian archive, then I'm all
for it.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Yves-Alexis Perez]

On Sun, Mar 09, 2014 at 06:50:36AM +0800, Paul Wise wrote:
> On Sat, 2014-03-08 at 18:23 +0100, Florian Weimer wrote:
> > * Moritz Muehlenhoff:
> > 
> > > I agree we should stick with dpkg-buildflags until this is fixed upstream.
> > > Gentoo Hardened tried to upstream this a year ago, but apparently this 
> > > didn't make 
> > > the cut yet:
> > > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00473.html
> 
> It looks like the Gentoo Hardened folks addressed all of the concerns of
> the GCC folks but didn't push for the patches to be included after that
> had finished doing that. Perhaps also the GCC folks didn't have time to
> do a full review. The Gentoo Hardened folks say bootstrap was achieved.
> 
> > On the other hand, it is somewhat doubtful if we can come up with a
> > one-size-fits-all compile time option.  For example, Fedora wants to
> > enable -grecord-gcc-switches, but maybe Debian doesn't (e.g. because
> > it impacts reproducible builds).
> 
> It should at least be an option to enable these at GCC compile time so
> that all binaries compiled by GCC use them. As long as GCC supports the
> corresponding command-line options for turning off enabled options at
> runtime, this approach should be viable since upstreams that need these
> flags disabled can do that in their build systems.

I kind of agree here, but Matthias made it clear that upstream inclusion
was a prerequisite (and I'm not sure he's interested in actually pushing
that upstream).

It might be worth contacting Gentoo Hardened people, Ubuntu security
people (although I think Kees Cook was the most active one and he's now
working at Google) and gcc upstream, asking for status and maybe pushing
a little bit forward.

But right now I'm not sure that, in Debian, we have people knowledgeable
enough on the intimate gcc behavior to push that directly. That's a bit
unfortunate.

Regards,
-- 
Yves-Alexis Perez
Debian security team


signature.asc
Description: Digital signature

Re: Bits from the Security Team

[Yves-Alexis Perez]

On Thu, Mar 06, 2014 at 07:51:28AM +0800, Paul Wise wrote:
> On Thu, Mar 6, 2014 at 3:03 AM, Moritz Muehlenhoff wrote:
> 
> > * We're planning to request for hidepid to be enabled by default (to 1).
> >   This will squash an entire class of information leaks. If you have any
> >   comments or objections, please get in touch with us.
> 
> Apparently this breaks suspend with systemd and maybe causes some
> issues with login and other things under systemd:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1043134
> http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html
> http://lists.freedesktop.org/archives/systemd-devel/2012-October/006860.html

I do use systemd and hidepid=2 and it seems to work just fine here
(please keep me on CC:, I'm not subscribed to -devel anymore).

From the bug report, I'm quite unsure it's actually related to hidpid=2
and not just to the lack of systemd/logind support in current Xfce
stack.

Regards,
-- 
Yves-Alexis Perez
Debian security team


signature.asc
Description: Digital signature

Bug#730827: ITP: light-locker -- simple screen locker for LightDM display manager

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: pkg-xfce-de...@lists.alioth.debian.org

* Package name: light-locker
  Version : 1.1.0-1
  Upstream Author : William Jon McCann, Peter de Ridder, Simon Steinbeiß
* URL : https://github.com/the-cavalry/light-locker/
* License : GPL
  Programming Lang: C
  Description : simple screen locker for LightDM display manager

light-locker is a simple locker that aims to have simple, sane, secure
defaults and be well integrated with the desktop while not carrying any
desktop-specific dependencies.
.
It relies on lightdm for locking and unlocking your session via
ConsoleKit/UPower or logind/systemd.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131129213658.31627.85528.reportbug@scapa

Bug#679853: general: Too much downtime during a big dist-upgrade - avoidable with snapshots

[Yves-Alexis Perez]

On lun., 2012-07-02 at 11:11 +0600, Alexander E. Patrakov wrote:
> 3) Then a kexec-based reboot should happen, using the new subvolume as
> the root filesystem. 

Note that I just did a quick test with kexec-tools in sid on two boxes,
and kexec failed miserably, so maybe it works perfectly elsewhere, but
I'm unsure if it's a good idea to rely on it.

Regards,
-- 
Yves-Alexis


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

Re: The future (or non-future) of ia32-libs

[Yves-Alexis Perez]

On ven., 2012-06-22 at 11:34 +0200, Goswin von Brederlow wrote:
> #677787 gtk2-engines-xfce: Please add multiarch support

Note that this one (as investigated in the bug report by Goswin and me)
is a bit spurious. For multi-arch Gtk+ apps, a multi-arch engine
matching the theme used by the end user is needed. So, in fact *each
engine* should be multi-archified (Gtk2 and Gtk3).

But, in fact, only the most used engines might really be candidate. I
didn't really had time to check gtk2-engines-xfce (so patches are
welcome) but I think it should not be too hard (not sure if I'll have
time before the freeze though). Same goes for gtk2-engines-murrine.

Regards,
-- 
Yves-Alexis


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

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Yves-Alexis Perez]

On mar., 2012-06-12 at 02:23 +0800, Aron Xu wrote:
> On Tue, Jun 12, 2012 at 2:11 AM, Thomas Goirand  wrote:
> > On 06/12/2012 01:52 AM, Aron Xu wrote:
> >> IMHO I suggest to talk with Security Team before disclosing
> >> information that might be sensitive in the mean time on a Debian
> >> development mailing list.
> >>
> > Could you explain to me what exactly I'm disclosing?
> > The news is already on slashdot and so on, and I think
> > it'd be better to know, as hackers will.
> >
> 
> I'm not saying you are disclosing anything, but you are asking if
> someone knows it's in what status publicly in a Debian development
> mailing list. Then this may lead to some disclosing and even mislead
> some other people. Yes there are many people doing tests just like
> you, and they are reporting their results in many ways they prefer.
> But as you are a DD you'd better not ignore our Security Team when
> starting discussion publicly about a security incident your are not
> sure whether it's relevant to Debian. People at Security Team are not
> only responsible for fixing things when it breaks out, but also make
> sure sensitive information is being disclosed in a correct form at a
> correct time. In the end, I believe talking with them beforehand is
> always a right way to do, no matter if Debian is affected by this
> particular issue.
> 
> 
> 
To be honest, I think -devel is a bad place for this just because it's
more or less full of useless, hundred mails long threads, so for example
I barely can follow it (and consider removing my subscription). So it'd
be better on some less noisy, security related, debian list like
debian-secur...@lists.debian.org.

Regards,
-- 
Yves-Alexis


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

Re: sticky bit on devices

[Yves-Alexis Perez]

On mar., 2012-05-22 at 13:12 +1000, Russell Coker wrote:
> I've just noticed that a bunch of device nodes on my main system running 
> Unstable now have the sticky bit set.
> 
Google search seems to say that the question has already been asked and
replied on debian-user
http://lists.debian.org/debian-user/2012/02/msg01273.html


Regards,
-- 
Yves-Alexis


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

Re: why do people introduce stup^Wstrange changes to quilt 3.0 format

[Yves-Alexis Perez]

On mar., 2012-05-15 at 14:32 +0900, Norbert Preining wrote:
> Hi dpkg-* maintainers,

I think you missed the correct mailing list to reach the dpkg-*
maintainers.
-- 
Yves-Alexis


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

Re: big .debian.tar.xz - EG Wordpress

[Yves-Alexis Perez]

On mer., 2012-05-16 at 19:45 +1000, Russell Coker wrote:
> I just downloaded the source to Wordpress from Squeeze, it's got a 14M 
> .debian.tar.xz which is mostly sources for things that are included in the 
> upstream tarball.  The build process appears to only use the upstream tarball 
> code so the 13MB of data in the debian/missing-sources directory isn't used 
> for building.
> 
> It is a really good thing to have upstream sources available as dictated by 
> the GPL (well done to whoever did that).  But that availability doesn't 
> require that they be in the source package.
> 
> Would it be possible to have somewhere on the Debian servers for storing such 
> files so that they can be referenced in a README file or something rather 
> than 
> sent to everyone?  I'm sure that most people who build a Wordpress package 
> won't use them.
> 
Any reason you didn't CC: wordpress maintainers? (I guess they are
subscribed to -devel but considering the current mail rate, I'm unsure
they'll read everything so it might make sense to CC: them at first…)

Regards,
-- 
Yves-Alexis


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

Re: Bug#672695: wordpress: no sane way for security updates in stable releases

[Yves-Alexis Perez]

On sam., 2012-05-12 at 23:45 +0200, Bernd Zeimetz wrote:
> Being forced to upgrade to a new major version by a stable security support is
> nothing we should force our users to. Debian stable is known for (usually)
> painfree updates and bugfixes only, not for shipping completely new versions
> with a forced migration.

Yes, that's usually the case. But I think having (*few*) exceptions is
actually helpful. I was the one preparing the update, because of my
security team hat and because I do use wordpress on one small blog. I
tried to package latest point release (3.0.6) and backport some patches
from the various releases in the more recent branches, but it's just
doomed to fail. Wordpress upstream doesn't seem to be able to support a
stable branch long enough for us (and I don't blame them for that, we do
know how painful it is).


>  Therefore - in my opinion - we should not ship
> wordpress in Wheezy, at least not until upstream handles such issues in a sane
> way. 

I'm unsure if squeeze (and wheezy)-updates is really suited for that,
but I know that I prefer having a wordpress updated in Debian (either by
the security team or the maintainers) to a new upstream release than not
having it at all and having to handle it myself (even if in this case I
handled it myself).
-- 
Yves-Alexis


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

Re: Bug#672160: Directory /boot/console-setup

[Yves-Alexis Perez]

On ven., 2012-05-11 at 00:16 +0300, Anton Zinoviev wrote:
> On Thu, May 10, 2012 at 09:40:23PM +0100, Ben Hutchings wrote:
> > 
> > Generally the console has to work even before root is mounted, so
> > that the user can enter a decryption password if necessary.
> 
> Unfortunately, as far as I know currently this doesn't work in 
> Debian.  Proper wishlist bug reports have been filled but we 
> haven't come yet to a solution that is good for all developers. 

What do you mean with “this doesn't work in Debian”? Some people do use
encrypted root and they do have a working console asking for the
passphrase.

Regards,
-- 
Yves-Alexis


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

Re: The future of non-dependency-based boot

[Yves-Alexis Perez]

On mar., 2012-04-10 at 01:03 +0200, Marco d'Itri wrote:
> Or just say in the release notes that it's a good idea to run something 
> like this before upgrading:
> 
> dpkg -l | awk '/^rc/ {print $2}' | xargs --no-run-if-empty dpkg --purge
> 
That's a pretty dangerous line. People (sometimes) don't purge packages
for a reason, you might lose data here.

Regards,

-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

> On do, 2012-02-02 at 12:18 +1100, Russell Coker wrote: 
> > On Thu, 2 Feb 2012, dann frazier  wrote:
> > > Whilte it may help the kernel team to not have to worry about problems
> > > in the grsec flavor when preparing uploads, preventing delays for the
> > > non-grsec images. But, that just pushes the coordination down a ways -
> > > for stable updates we would need to add the grsec build into the
> > > pipeline, and there'd be delays in grsec security updates that go in
> > > via linux-2.6. Not nak'ing the idea, but it does extend some critical
> > > paths.
> > 
> > The current approach of having a kernel patch package seems to work well.  
> > It 
> > removes the need for involvement of the kernel and security teams 
> > (presumably 
> > security changes to the kernel will usually not require changes to the 
> > grsecurity patch) and allows the users to easily build their own kernels.
> > 
> > If a user has a choice between using Spender's Debian package and a kernel-
> > patch package to build their own kernel then I think that they should be 
> > able 
> > to do whatever they want.
> > 
> > Spender suggested that people who want GRSecurity on Debian would be better 
> > off using a .deb he provides and working on user-space hardening.
> > 

(please don't top-post)
If people on the CC: list want to be dropped, please ask :)

On jeu., 2012-02-02 at 07:18 +0100, Kees de Jong wrote:
> Perhaps you should contact Julien Tinnes of http://kernelsec.cr0.org/ 
> He has been too busy to work on the kernels lately but maybe he wants
to help.
> 
> 

Well Julien was aware of my initiative and, afaict, he didn't really
have time for that, nor was interested in the porting part.

And as I said before, I'm not interested in shipping just a patch in
Debian. If users want to patch the kernel, configure it and built it, I
think they're better off getting the latest patch from grsecurity.net
and kernel from kernel.org. The point was in shipping a binary package
with a default setup secure enough, and a way to tune the features
through sysctl.

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote:
> On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote:
> > On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> > > On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > > > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > > > What is stopping you from creating another package, that provides the
> > > > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > > > with it, and just maintain it yourself in the archive? Its free 
> > > > > software
> > > > > afterall. 
> > > > > 
> > > > 
> > > > Honestly, having multiple linux source package in the archive doesn't
> > > > really sound like a good idea. I don't really think the kernel team
> > > > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > > > member of the security team, It's definitely something I would object.
> > > 
> > > Well, that's what we have the 'linux-source' packages for: to allow
> > > other packages to build-depend on them.
> > > 
> > 
> > Hmhm, that might be a good idea indeed. I need to investigate and try
> > that a bit.
> > 
> > Ben, what would kernel team think of that?
> 
> I don't speak for the whole team, but I don't see that it solves any
> problem.  You would have to Build-Depend on exact versions of
> linux-source, so that you know your external patches will apply.  Then
> you would have to rebase the patches every time linux-2.6 is updated,
> making sure (without much help from upstream) that you don't introduce a
> subtle security problem.
> 
Well, that's already what I do and intended to do (and that's clear from
the beginning of the bug report).

Wrt not introducing subtle security problems, what I mostly do is remove
the security backports from the grsec patch which are already applied to
Debian kernel, so this part is fairly straightforward.

Now indeed when doing the job for Squeeze kernel it's a bit less
straightforward because of the huge amount of driver backports, but from
my own experience, the conflicts are still mostly about changed context
lines.

Regards,
-- 
Yves-Alexis


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

Re: lack of replacement for linux-vserver

[Yves-Alexis Perez]

On mer., 2012-02-01 at 10:33 +0800, Paul Wise wrote:
> On Wed, Feb 1, 2012 at 5:37 AM, Ben Hutchings wrote:
> 
> > Just to be clear, 'that work' is not just a matter of forwarding
> > messages back and forward between the Debian BTS and the Linux-VServer
> > developers.  Unless the VServer project continues to support whichever
> > version we use in a stable release (3.2 in this case) then Debian
> > users are likely to run into different bugs that they won't want to
> > deal with.  There will also be integration issues to be resolved when
> > fixes from the stable/longterm branch conflict with the VServer
> > changes.  This requires real understanding of Linux and VServer
> > internals (see #618485 for an example of what happens without that).
> 
> Data point; there is a VServer patch for 3.2 (marked as experimental though):
> 
> http://vserver.13thfloor.at/Experimental/patch-3.2.2-vs2.3.2.6.diff
> 
> It was also claimed on IRC that when using the Debian template for lxc
> (see below) that the security issues mentioned in the Linux 3.2 thread
> do not apply.
> 
> lxc-create -t debian
> /usr/lib/lxc/templates/lxc-debian

Note that the template “only” drops CAP_MAC_ADMIN, CAP_MAC_OVERRIDE,
CAP_SYS_ADMIN and CAP_SYS_MODULE. Are we really sure this is enough?
http://www.mail-archive.com/lxc-users@lists.sourceforge.net/msg00977.html 
thread gives some pointer, but it seems that in the end they advise to drop 
quite some more caps than just those.

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote:
> On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote:
> > On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> > > What is stopping you from creating another package, that provides the
> > > kernel with grsecurity patches applied? Don't bother the kernel team
> > > with it, and just maintain it yourself in the archive? Its free software
> > > afterall. 
> > > 
> > 
> > Honestly, having multiple linux source package in the archive doesn't
> > really sound like a good idea. I don't really think the kernel team
> > would appreciate, I'm pretty sure ftpmasters would disagree, and as a
> > member of the security team, It's definitely something I would object.
> 
> Well, that's what we have the 'linux-source' packages for: to allow
> other packages to build-depend on them.
> 

Hmhm, that might be a good idea indeed. I need to investigate and try
that a bit.

Ben, what would kernel team think of that?

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote:
> On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez  
> wrote:
> > So I think it's perfectly clear that nor Debian nor Grsecurity are
> > really interested in Debian shipping a Grsecurity kernel.
> 
> Well, I don't think its fair to say "Debian" is not interested in
> shipping a Grsecurity kernel. I think its more accurate to say that the
> current configuration of the Debian kernel team doesn't find the time to
> deal with it... but I'm not sure that speaks for all of Debian.

Well, in this case, that's mostly the same. I'm sure there are people in
Debian which are interested (even outside of me). But here, the kernel
team has the final word (well, or the tech ctte, but I really don't see
the point of that).
> 
[…]

> 
> > Anyway, I'll keep updating the current setup for interested people, but
> > without any interest from either party, that definitely looks like a
> > dead end.
> 
> What is stopping you from creating another package, that provides the
> kernel with grsecurity patches applied? Don't bother the kernel team
> with it, and just maintain it yourself in the archive? Its free software
> afterall. 
> 

Honestly, having multiple linux source package in the archive doesn't
really sound like a good idea. I don't really think the kernel team
would appreciate, I'm pretty sure ftpmasters would disagree, and as a
member of the security team, It's definitely something I would object.

Regards,
-- 
Yves-Alexis


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

Re: Bug#605090: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
> On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
> > (adding few CC:s to keep track on the bug)
> > 
> > On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
> > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > > > On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> > > > > Featuresets
> > > > > ---
> > > > > 
> > > > > The only featureset provided will be 'rt' (realtime), currently built
> > > > > for amd64 only.  If there is interest in realtime support for other
> > > > > architectures, we may be able to add that.  However, we do need to
> > > > > consider the total time taken to build binary packages for each
> > > > > architecture.
> > > > > 
> > > > > If there are particular container features that should be enabled or
> > > > > backported to provide a useful replacement for OpenVZ or VServer,
> > > > > please let us know.  We cannot promise that these will all be enabled
> > > > > but we need to know what is missing. 
> > > > 
> > > > So in the end what are the reasons for not trying the grsecurity
> > > > featureset? #605090 lacks any reply from the kernel team since quite a
> > > > while, and especially after answers were provided to question asked.
> > > 
> > > You already know the main reason:
> > > > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > > > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > > > example in RBAC code), while few of them reach mainline.
> > > 
> > > I realise that the mainline Linux developers have sometimes been
> > > unreasonably resistant to these changes and I'm not intending to assign
> > > blame for this.  But practically this means that we have to either carry
> > > the featureset indefinitely or disappoint users by removing it in a
> > > later release.  (See the complaints about removing OpenVZ in wheezy
> > > despite 4 years' advance notice of this.)
> > 
> > I understand this, and I still see the grsec featureset as a valuable
> > project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
> > important goal (especially considering the time involvement).
> > 
> > Now, I still think having a hardened Debian kernel inside the
> > distribution is helpful
> [...]
> 
> I agree and I would like to see hardening of *all* our configurations,
> where the performance cost is not too much.  That's going to protect all
> our users rather than just people who seek out a special paranoid
> configuration.

So I think it's perfectly clear that nor Debian nor Grsecurity are
really interested in Debian shipping a Grsecurity kernel.

I find that sad, because I do think there are users of both which would
benefit from that, and not only people who seek out a special paranoid
configuration.

Anyway, I'll keep updating the current setup for interested people, but
without any interest from either party, that definitely looks like a
dead end.

Regards,
-- 
Yves-Alexis


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

Re: Linux 3.2 in wheezy

[Yves-Alexis Perez]

(adding few CC:s to keep track on the bug)

On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
> On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> > > Featuresets
> > > ---
> > > 
> > > The only featureset provided will be 'rt' (realtime), currently built
> > > for amd64 only.  If there is interest in realtime support for other
> > > architectures, we may be able to add that.  However, we do need to
> > > consider the total time taken to build binary packages for each
> > > architecture.
> > > 
> > > If there are particular container features that should be enabled or
> > > backported to provide a useful replacement for OpenVZ or VServer,
> > > please let us know.  We cannot promise that these will all be enabled
> > > but we need to know what is missing. 
> > 
> > So in the end what are the reasons for not trying the grsecurity
> > featureset? #605090 lacks any reply from the kernel team since quite a
> > while, and especially after answers were provided to question asked.
> 
> You already know the main reason:
> > Feature-wise, Brad Sprengler and the PaX team still add stuff, like the
> > gcc plugins or hardening features like symbols hiding, fix bugs (for
> > example in RBAC code), while few of them reach mainline.
> 
> I realise that the mainline Linux developers have sometimes been
> unreasonably resistant to these changes and I'm not intending to assign
> blame for this.  But practically this means that we have to either carry
> the featureset indefinitely or disappoint users by removing it in a
> later release.  (See the complaints about removing OpenVZ in wheezy
> despite 4 years' advance notice of this.)

I understand this, and I still see the grsec featureset as a valuable
project. Indeed, reducing the diff wrt. upstream in Debian kernel is an
important goal (especially considering the time involvement).

Now, I still think having a hardened Debian kernel inside the
distribution is helpful and needed for some people (some of them have
said so on the bug report, some other directly told me). I can continue
providing kernels for stable and sid outside of Debian, but that means
it's painful to find them, so less people will use it. I'm sure I don't
have to remind people, but having a hardened kernel can buy you some
time when some vulnerabilities are found in the kernel, like
the /proc/pid/mem one (even when it does not prevent completely the
vulnerability, it can prevents the exploit to be successful, for
example).
> 
> It also appears that you never had any response to your question to
> upstream about minimising the patch set.

Indeed. Brad, I'm not sure if you received the initial mail, so if you
have any comment…
> 
> > Not doing anything is indeed a way to just get rid of the question, but
> > I would have at least appreciated a definitive answer on the bug rather
> > than via the dda mail.
> 
> I'm sorry about that; it completely slipped my mind as there have been
> no discussions about it for some months.

Well, the last mail from the kernel team on the bug was indeed months
ago (nov 10th afaict), but I kept adding info and replies since.

Anyway, thanks for your answer.

Regards,
-- 
Yves-Alexis


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

Re: Linux 3.2 in wheezy

[Yves-Alexis Perez]

On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
> Featuresets
> ---
> 
> The only featureset provided will be 'rt' (realtime), currently built
> for amd64 only.  If there is interest in realtime support for other
> architectures, we may be able to add that.  However, we do need to
> consider the total time taken to build binary packages for each
> architecture.
> 
> If there are particular container features that should be enabled or
> backported to provide a useful replacement for OpenVZ or VServer,
> please let us know.  We cannot promise that these will all be enabled
> but we need to know what is missing. 

So in the end what are the reasons for not trying the grsecurity
featureset? #605090 lacks any reply from the kernel team since quite a
while, and especially after answers were provided to question asked.

Not doing anything is indeed a way to just get rid of the question, but
I would have at least appreciated a definitive answer on the bug rather
than via the dda mail.

Regards,
-- 
Yves-Alexis


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

Re: what if a package needs to be "recalled"

[Yves-Alexis Perez]

On dim., 2011-11-20 at 20:56 -0500, Michael Gilbert wrote:
> If this thread is specifically related to the broken sandbox in
> chromium right now, then you can use "chromium --no-sandbox" until we
> find an appropriate fix the bug (or help us do that).  No need to come
> up with crazy versioning solutions. 

I'm not sure telling people to use --no-sandbox without telling them
what they lose is a good idea. Sandboxing is here for a reason.

Regards,
-- 
Yves-Alexis


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

Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl

[Yves-Alexis Perez]

On jeu., 2011-10-20 at 18:58 +1100, Russell Coker wrote:
> On Thu, 20 Oct 2011, Timo Jyrinki  wrote:
> > Actually, I already know a lot of people whose only desktop machine
> > network connection is a 3G dongle, since unlimited data with it is
> > about half the price of ADSL connection.
> 
> My parents have been using USB 3G net access on their Desktop system for 
> about 
> two years now.  It costs them $150 per annum instead of $30 per month.  If 
> they were to stop using a land-line phone service and use only mobile phones 
> then they could save another $20 per month.
> 
> In Australia ADSL and cable are only good value in urban areas if you need to 
> transfer more than about 2G of data per month or if you need reliable low 
> latency. 

I don't exactly want to debate on that. I never said nobody used that,
it's just that, imho, that's not really needed by default. Now if we
consider people using default install don't know how to install more
stuff, and use that as a basis for selecting what's in the default
install, I think we might have quite some issues.

Regards,
-- 
Yves-Alexis


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

Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl

[Yves-Alexis Perez]

On mar., 2011-10-18 at 15:55 +0200, Didier Raboud wrote:
> Yves-Alexis Perez wrote:
> > Drop usb-modeswitch completely from the default desktop install?
> 
> network-manager recommends modemmanager recommends usb-modeswitch.
> 
> network-manager wants modemmanager to handle "mobile network modems".
> modemmanager wants usb-modeswitch because most "mobile network modems" need 
> "modeswitching". Without usb-modeswitch installed, those devices are just 
> seen as "USB Mass Storage", often readonly with Windows installers on them 
> (aka "brick").
> 
> The presence of usb-modeswitch in the default desktop installs (of Ubuntu 
> and Debian fwiw) is not really my call, but I think it is justified: having 
> those "mobile network modems" work out-of-the-box is at least "nice to 
> have". Think for example about users that have no other internet connection 
> than trough such a mobile network modem. 

Not sure it'd help in this case but imho this is the case only on
laptops. People installing desktop usually don't need a 3G modem (and if
they do, they can manually install it). I'm not even sure
network-manager is needed on the desktop install, but eh.

Regards,
-- 
Yves-Alexis


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

Re: RFC: usb-modeswitch 1.2.0 release embedding jimtcl

[Yves-Alexis Perez]

On mar., 2011-10-18 at 13:36 +0200, Didier Raboud wrote:
> What's your opinion ?

Drop usb-modeswitch completely from the default desktop install?
-- 
Yves-Alexis


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

Re: Dependencies of metapackages

[Yves-Alexis Perez]

On mer., 2011-08-31 at 11:59 +0100, Wolodja Wentland wrote:
> 
> Could you elaborate on your reasons and your intentions for making the
> distinction?

Policy 7.2, mostly, and the fact depends are installed (obviously),
recommends are installed by default (but that can be disabled and one
can remove it safely) and suggests are just displayed.

>  Do you have reasons for not changing Depends into Recommends? I
> will probably file bugs, but do not want to do so if I already know that the
> maintainer is not going to change it. I am sincerely interested and my only
> motivation is to make Debian a better distribution. 

I'm not going to change it if you don't have good reason for specific
packages changes.

Regrds,
-- 
Yves-Alexis


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

Re: Dependencies of metapackages

[Yves-Alexis Perez]

On mar., 2011-08-30 at 16:11 +0100, Wolodja Wentland wrote:
> 
> I agree that a general change of all metapackages is probably not a good idea,
> but I think that changing the root-nodes of the metapackage tree (i.e.
> metapackages like gnome, xfce4, kde-full, ...) is a sensible change. It is in
> particular one that solves the problems without the need to introduce new
> package fields, change packaging tools or their semantics. 

If you think some dependencies in those metapackages are unneeded or too
strong, you're welcome to open a wishlist bug against them.

For xfce4, while I'm open to discussion, the distinction between
depends/recommends/suggests is intended, and at first sight I don't see
a need to change it.

On a totally different scale, is it a good idea that automatic
installation of recommends is recursive?

It is a really tricky question, and I'm not sure there's *one* answer.
In some cases you really want them (well, as long as you want automatic
recommends), but not all.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1314718667.2150.3.camel@oban

Re: Fwd: Re: BLAST+ speed & build issues

[Yves-Alexis Perez]

On jeu., 2011-08-04 at 13:27 +0200, Samuel Thibault wrote:
> Julian Taylor, le Thu 04 Aug 2011 12:32:27 +0200, a écrit :
> > You might be able to reduce startup time by only linking against the
> > libraries you need or lazyly dynamically loading them.
> 
> Or use prelink. 

Which as issues especially wrt. ASLR.

Regards,
-- 
Yves-Alexis


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

Re: Providing official virtualisation images of Debian

[Yves-Alexis Perez]

On mar., 2011-07-26 at 11:15 +0200, Luca Capello wrote:
> On Tue, 26 Jul 2011 00:46:47 +0200, Lars Wirzenius wrote:
> > On Tue, Jul 26, 2011 at 12:27:09AM +0200, Moritz Mühlenhoff wrote:
> >> I believe it's high time we start to providing Debian in form of
> official
> >> virtualisation images.
> 
> While the Debian Events team mainly needs a BabelBox, it would be also
> useful to have a standard and full Debian desktop that people at
> booths
> can easily download, better *before* being at a booth, and show to
> people.  We could also provide them in the BabelBox machine, so booth
> organizers can just copy the images:
> 
>    

Well, there are Debian live cds with main desktop environment which
would nicely fit the purpose, imho. See
http://cdimage.debian.org/cdimage/release/current-live/amd64/iso-hybrid/
and http://live.debian.net

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1311674304.32565.4.camel@oban

Re: Providing official virtualisation images of Debian

[Yves-Alexis Perez]

On mar., 2011-07-26 at 00:27 +0200, Moritz Mühlenhoff wrote:
> I believe it's high time we start to providing Debian in form of official
> virtualisation images. In contrast to the ISOs currently provided it
> allows a quicker evaluation/testing of Debian (and can also be very
> useful for testing (e.g. someone wrote on debian-release that he doesn't have
> access to oldstable/stable systems, with prepared virtualisation
> images that would no longer be an issue). For many setups this could even
> replace the installer since software selection and hostname can easily
> be tweaked post-install. 

Not completely relevant, but note that Aurélien Jarno provides Squeeze
images for various architectures under qemu at
http://people.debian.org/~aurel32/qemu/

Regards,
-- 
Yves-Alexis


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

Re: Whether should grub2 write MBR automatic

[Yves-Alexis Perez]

On mer., 2011-06-22 at 14:06 +0800, Aron Xu wrote:
> > What is your use case for the second behaviour?
> >
> 
> grub-pc will write MBR every time when triggered, and grub-pc-bin will
> not update grub entry after the kernel is updated. - It is weird when
> you have grub installed to an alternative place, then you upgrade a
> package and it write MBR regardless what you have chosen before. Write
> MBR when it is being installed for the first time is the right way,
> but it should not force user to write MBR when he has said no. 

Maybe what needs to be fixed is grub not writing to your “alternative
place”?

Regards,
-- 
Yves-Alexis


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

Re: Whether should grub2 write MBR automatic

[Yves-Alexis Perez]

On mer., 2011-06-22 at 14:10 +0800, YunQiang Su wrote:
> > What is your use case for the second behaviour?
> > 
> The second behavior means that: when update/reinstall grub or
> update/install/reinstall kernel will call update-grub but not call
> grub-install. 

Let me rephrase what Ben asked: why do you need that?

Regards,
-- 
Yves-Alexis


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

Re: [ltp] Re: double checking Debian's 686-pae vs. -486 probe

[Yves-Alexis Perez]

On mar., 2011-05-24 at 09:58 -0300, Stefan Monnier wrote:
> > Say, for the sake of sharing a single .deb offline, what bad thing might
> > happen if I run the -486 kernel on my other machines where I could run
> > the -pae kernel?
> 
> Nothing serious, unless they have a lot of RAM (in which case the kernel
> may not be able to make use of all of it).

And you lose NX too.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1306243091.25324.16.camel@oban

Re: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 in wheezy as default?

[Yves-Alexis Perez]

On dim., 2011-05-08 at 17:56 +0200, Sven Hoexter wrote:
> Beside that the default timeout setting for the dynamic address is something
> to be discussed, I believe the default is about a week which is rather
> long if you want to have a benefit over static assignment. After all the gain 
> of
> anonymity highly depends on the IP assignment rules your ISP will have.
> If you always end up with the same /64 you gain nearly nothing and there are
> better properties to track you anyway. 

Privacy extension addresses are more intended for the mobile people
(prevent you beeing tracked when you change provider, like  connecting
from some hotspot, the hotel, a conference, work, home etc.).

Regards,
-- 
Yves-Alexis


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

Re: Bits from the Release Team - Kicking off Wheezy

[Yves-Alexis Perez]

On jeu., 2011-03-31 at 14:30 +0200, Michael Biebl wrote:
> Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
> Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
> require hal or will it just have reduced functionality?
> 
On BSD it's reduced functionality (see
http://gezeiten.org/post/2011/01/Xfce-4.8-on-BSD-flavors ).

For volume management, thunar-volman won't be available on kFreeBSD so
no automount stuff. xfburn will just drop dep without too much issue.

For power-management, I'm not sure how xfpm will behaves without upower
at all, I'll have to investigate, but anyway newer xfpm doesn't use hal
at all.

Once the complete Xfce 4.8 stack is uploaded we'll have a more complete
picture of the whole situation.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1301574950.16871.4.camel@oban

Re: GNOME 3 and panel applets

[Yves-Alexis Perez]

On Mon, 2011-02-14 at 18:17 +0100, Josselin Mouette wrote:
> If you develop, maintain or use one of those packages, and you don’t
> want it to disappear, your options are now:
> 
>  1. Prepare to disable gnome-panel support (that’s for packages
> which already have other options, such as using the notification
> area). 
>  2. If meaningful (it depends on the applet), switch to another
> technology such as libappindicator or the notification area. 
>  3. Port your applet to GTK3 and the new D-Bus API. The bindings for
> Python and C# will probably not work either, so you might have
> to start with them. 
>  4. Step up and do the work to add support for bonobo applets in the
> panel.
> 
> Option 4 is the only way to keep all applets with low maintenance in
> Debian. It should be possible by developing a gateway D-Bus service that
> loads a bonobo applet in a process separate from the panel and proxies
> signals through it. If you are interested, please get in touch with
> upstream. If no one is interested, a large portion of the following list
> is going to leave the archive. 

Another option which may or may not be suitable (depending on the real
support) is xfce4-xfapplet-plugin which is an xfce4-panel plugin
enabling loading of gnome panel applets. 

I'm not even sure it'll still work (the applets still need to be built
against gnome panel for example) and xfapplet plugin isn't really
maintained upstream either but in case someone has interest in this
it /might/ be a solution for someone motivated to keep a gnome-panel
alternative.

Regards,
-- 
Yves-Alexis


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

Re: Disable ZeroConf: how to ?

[Yves-Alexis Perez]

On Fri, 2011-03-04 at 23:28 +0800, Paul Wise wrote:
> Ubuntu actually has better pro-active/defence-in-depth security than
> Debian right now. For example compiler hardening flags, kernel
> hardening (symlink, hardlink, ptrace, nx emulation), MAC (AppArmour).
> Perusing their roadmap pages is quite interesting too:
> 
> https://wiki.ubuntu.com/SecurityTeam/Roadmap

Note that we do try to improve that in Debian too. See #552688,
http://lists.debian.org/debian-devel-announce/2011/01/msg6.html,
#605090 (though it's not about the default install).

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299254746.26397.23.camel@oban

Re: Disable ZeroConf: how to ?

[Yves-Alexis Perez]

On Fri, 2011-03-04 at 12:24 +0100, Wouter Verhelst wrote:
> If you're unfamiliar with computers, on the other hand, chances that
> you'll be able to figure out how to enable convenience services are
> slim, at best. Since home users typically use computers in a desktop
> environment, I therefore think it's perfectly okay to have the default
> desktop installation enable such convenience services. 

Note that if you're unfamiliar with computers, it's helpful to be able
to trust the default install to “do the right thing” too wrt. security.
Even if “home user” might not have security concerns as high as
“business users”, I think they'd prefer their private stuff to stay
private, wether it's their family pictures, their bank account stuff, or
something else. It applies to various other threats too.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299242855.26397.17.camel@oban

Re: Disable ZeroConf: how to ?

[Yves-Alexis Perez]

On Thu, 2011-03-03 at 12:45 +0100, Bastien ROUCARIES wrote:
> main security problem is resolver,
> $host -v www.local
> www.local
> www.local.mydomain.com
> 
> see security issue in draft paper also in case
> http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-08

resolver is more like the “client” side of things, while service
publication is more the “server” side of things.

If you don't want your host to resolve “local” stuff at all, you can
edit /etc/nsswitch.conf and remove the mdns stuff.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299229500.26397.4.camel@oban

Re: Disable ZeroConf: how to ?

[Yves-Alexis Perez]

On Thu, 2011-03-03 at 16:08 +, Philipp Kern wrote:
> We don't like security by obscurity, as you might know.

Not shouting out loud that a service is available doesn't qualify as
“security by obscurity” for me.

Regards,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299229274.26397.1.camel@oban

Bug#615591: ITP: lightdm -- simple display manager with GTK+, Qt and Webkit greeters

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: lightdm
  Version : 0.2.3
  Upstream Author : Robert Ancell
* URL : https://launchpad.net/lightdm
* License : GPL-3
  Programming Lang: C/
  Description : simple display manager with GTK+, Qt and Webkit greeters

LightDM is a simple display manager which intents to support “modern”
standards (like ConsoleKit), various desktop environments (having three
greeters using GTK+, Qt and Webkit libs) and still be lightweight.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110227152533.4966.15374.reportbug@hidalgo

Re: Upcoming changes in Lintian & some bits

[Yves-Alexis Perez]

On Wed, 2011-02-23 at 22:47 -0600, Raphael Geissert wrote:
> As a consequence of these changes, the new Lintian release will cause
> many existing overrides to no longer apply.  We recognise that this will
> lead to some noise in the short term but are convinced that the longer
> term advantages make this worthwhile.
> 
Did you do an archive check with the new lintian and diff'ed it against
a check with previous lintian?

Regards,
-- 
Yves-Alexis


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

Bug#612110: ITP: tumbler -- d-bus thumbnailing service

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: tumbler
  Version : 0.1.6
  Upstream Author : Jannis Pohlmann 
* URL : http://www.xfce.org/
* License : GPL-2+/LGPL-2+
  Programming Lang: C
  Description : d-bus thumbnailing service

 Tumbler is a D-Bus service for applications to request thumbnails for various
 URI schemes and MIME types. It is an implementation of the thumbnail management
 D-Bus specification described on http://live.gnome.org/ThumbnailerSpec.
 
 It's not tied to Xfce.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110205234053.15259.48557.reportbug@hidalgo

Bug#612090: ITP: garcon -- freedesktop.org compliant menu library

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: "Yves-Alexis Perez" 


* Package name: garcon
  Version : 0.1.5
  Upstream Author : Jannis Pohlmann 
* URL : http://www.xfce.org
* License : GPL-2+/LGPL-2+
  Programming Lang: C
  Description : menu library 

garcon is a menu implementation that is compliant with the Desktop Menu
Specification of freedesktop.org. It's built by the Xfce project but can
be used outside without problem.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110205182700.6489.85885.reportbug@hidalgo

Bug#612048: ITP: libxfce4ui -- widget library for Xfce desktop environment

[Yves-Alexis Perez]

Package: wnpp
Severity: wishlist
Owner: Debian Xfce Maintainers 


* Package name: libxfce4ui
  Version : 4.8.1
  Upstream Author : the Xfce development team
* URL : http://www.xfce.org/
* License : LGPL-2+
  Programming Lang: C
  Description : widget library for Xfce desktop environment

libxfce4ui is used to share commonly used Xfce widgets among the Xfce
applications. It's a replacement for libxfcegui4 which will be dropped
once all depending packages are removed from the archive.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110205110605.25635.86951.reportbug@hidalgo

Re: binNMU for Arch: all packages.

[Yves-Alexis Perez]

On ven., 2011-01-14 at 18:05 -0200, Marco Silva wrote:
> This documentation is generated automatically
> from the source code, using a documentation generator called haddock.  Haddock
> is part of the compiler and is also updated when the ghc is.  It would be
> good to regenerate the documentation for each library too, when a new ghc
> arrives. 

I don't really know anything about haskell, but is it really needed to
regenerate library docs each time the compiler is updated? What does it
give?
-- 
Yves-Alexis


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

Re: compatibility analysis for Java libraries

[Yves-Alexis Perez]

On mer., 2010-12-08 at 18:00 +0300, Andrey Ponomarenko wrote:
> Hello,
> 
> I know that some Debian maintainers use ABI Compliance Checker (ACC)
> tool along with Ustream Tracker at LinuxTesting.org [1] for testing
> backward compatibility of C/C++ libraries. Now I want to inform you
> about opened Upstream Tracker for Java libraries [2]. Any feedback is
> much appreciated. Proposals to add libraries will be accepted at [3].
> Thanks!
> 
> [1] http://linuxtesting.org/upstream-tracker/
> [2] http://linuxtesting.org/upstream-tracker/java/
> [3] mailto:upstream-trac...@linuxtesting.org

The cross distribution mailing list might be interested to, adding them
to CC:.

Regards,
-- 
Yves-Alexis


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

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On ven., 2010-11-19 at 23:49 +0100, David Kalnischkies wrote:

> And i am usually not offended by someone blaming APT to be too dumb.
> APT is all about dependency resolution, so saying you are not to deep
> into it, but blaming APT to be wrong isn't the best tone either.
> Draw i would say…

Hey, please don't put words in my mouth, I never said apt was too dumb.
I said it looked to me like it was doing the wrong thing. And you don't
have to take that personally either.
> 
> 
> >> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> >> > work either, apt will still prefer to hold xfce4-session and keep
> >> > xfce4-mcs-*.
> >>
> >> You have way more information than APT - for example:
> >> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
> >> now obsolete? No. All which is said is that the new xfce4-session doesn't
> >> work with them (it breaks them).
> >
> > No, xfce4-session depends on xfce4-settings. And xfce4-settings
> > *replaces* xfce4-mcs-*.
> >
> >>  So, for APT its clear that we loose two
> >> packages just to get another one upgraded… that doesn't feel right.
> >
> > Even with the Replaces: bit?
> 
> Great, just that Replaces: only says that some files will be replaced,
> not the complete package… (so its mostly only used by dpkg).

Hmh, I missed that. I thought Replaces was package wide for apt.

> 
> They ship common files => Replaces
> Or is xfce4-mcs-plugins broken now that you replaces some of its files?
> (or better as footnote 46 suggests: Does it hurt if the files are gone?)
> Then it really also Breaks:, but you also give the indication that
> something in xfce4-mcs-plugins is left which can be broken and
> therefore functionality is lost by removing it… (or allowing the other
> package to replace files of it in the first place).
> So you might want to provide a new xfce4-mcs-plugins without
> these files (by depending on them) which still provides this functionality
> (or nothing as a dummy package).
> 
> > and xfce4-settings replaces
> > the functionality provided by xfce4-mcs-manager.
> 
> dummy xfce4-mcs-manager depending on xfce4-settings if it is
> a package rename. If its not, but they do not conflict just leave
> xfce4-mcs-manager alone. If they conflict as they use the same files,
> its the same as with the other package…

xfce4-settings replaces (functionnalities) xfce4-mcs-manager and
xfce4-mcs-plugins, and ships files contained in those two packages.

So Conflicts/Replaces is necessary, but indeed not enough. So I guess
I'll have to version them, and add dummy packages back (yeah, NEW!).
> 
> 
> >> Or in short: either make empty dummy packages out of them or
> >> just leave them alone.
> >
> > Which would then need to Depends on xfce4-settings in order to provide
> > the same set of functionality, adding complexity to the dependencies.
> 
> In general positive dependencies are easier to satisfy than negative
> as it is easier to install another package than to remove an installed.
> If we install a new package we have a relatively low probability that a
> negative dependency will effect it later. If we remove a package we can be
> nearly sure that another package depends on it and is now broken.
> (why would it be installed otherwise?)

In this case, I thought apt would use the Replaces: field for that.

> Also, a user normally doesn't complain too much if new functionality
> is added, but heavily if some functionality is gone without good reason…
> 
> 
> And the "good reason" is why APT doesn't remove the package on the
> breaks - the 'Considering' line in the output shows the scores the packages
> have. 0 vs 0 isn't a strong thing. If more packages would depend on
> one of the packages the decision will follow the highest scoring package.

Good point. In that case it's a simple package upgrade, while usually
the whole Xfce stack is installed. I've tried with the xfce4 metapackage
and the upgrade correctly picks xfce4-settings and wants to remove MCS.
So while the partial upgrade for only xfce4-session is a bit broken
(well, if you ask for xfce4-session install it works too), in general it
won't be a problem.

Thanks for your help and your time.

Regards,
-- 
Yves-Alexis


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

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote:

> 
> So, go and start reading. Debian has a lot of dependencies and you have a
> lot of possibilities because of that.
> You can't use them if you don't know them.
> And, more important, you can't blame APT for being stupid if you don't
> know what you talk about yourself.

Well, I thought that Recommends: and Depends: were different things,
which looks to me like a fair assumption. It seems I'm wrong.

Oh, and I don't really like your tone, and I'm not usually offended by
rudeness.

> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> > work either, apt will still prefer to hold xfce4-session and keep
> > xfce4-mcs-*.
> 
> You have way more information than APT - for example:
> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
> now obsolete? No. All which is said is that the new xfce4-session doesn't
> work with them (it breaks them).

No, xfce4-session depends on xfce4-settings. And xfce4-settings
*replaces* xfce4-mcs-*.

>  So, for APT its clear that we loose two
> packages just to get another one upgraded… that doesn't feel right.

Even with the Replaces: bit?

> 
> Before you ask, no, debian has no way to say: "this package is
> obsolete -
> its fine that it will be removed as other packages take care of its
> tasks."
> The closest thing to that is §7.6.2, but i doubt that this is really
> such
> a drop-in replacement in your case.
> (and that doesn't say anything about an upgrade path, too)

Well, it is a replacement, and I don't see such a thing as “drop-in”
replacement (and this is not a virtual package).

> 
> So, to solve your problem, you have more or less only one option:
> Do not try to clean up behind you, let the package managers do it
> (with autoremove or deborphan or whatever). Trying it yourself only
> complicates stuff -- and adding Breaks for this kind of stuff is even
> against the policy if you want to read it that way: §7.4

Except that in my case, I'm more in the $7.6. I'm not adding
Conflicts/Replaces just because I'd like to force people to get rid of
xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship
common files (along with xfce4-mcs-plugins) and xfce4-settings replaces
the functionality provided by xfce4-mcs-manager.

> > Neither Breaks nor Conflicts should be used unless two packages
> > cannot be installed at the same time or installing them both causes
> > one of them to be broken or unusable.

Which is the case here, and why the fields were added in the first
place.
> 
> 
> Or in short: either make empty dummy packages out of them or
> just leave them alone.

Which would then need to Depends on xfce4-settings in order to provide
the same set of functionality, adding complexity to the dependencies.

Cheers,
-- 
Yves-Alexis


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

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On 19/11/2010 12:29, David Kalnischkies wrote:
> xfce4-mcs-manager recommends it.
> As APT has no indication that this package can go away it does the
> only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
> the user will lose functionality…
> (recommends are defined as installed on all, expect "unusual" systems,
>  so their value is very close to a depends for APT)

Except it's not. System would be perfectly usable with xfce4-mcs-plugin
and without xfce4-mcs-manager (it wouldn't make much sense, but still).
Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
looks to me like the wrong thing to do, though I'm not fluent enough in
dependencies to be sure.

By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
work either, apt will still prefer to hold xfce4-session and keep
xfce4-mcs-*.

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce66692.1050...@debian.org

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On 19/11/2010 08:52, Yves-Alexis Perez wrote:
> Anyone knows why and how to fix that? Would a “breaks” instead of a
> “conflicts” fix it?

Seems that “Breaks:” doesn't work either:

> Investigating (0) xfce4-settings [ amd64 ] < none -> 4.6.5-3 > ( xfce )
> Broken xfce4-settings:amd64 Breaks on xfce4-mcs-plugins [ amd64 ] < 4.4.2-4 > 
> ( x11 )
>   Considering xfce4-mcs-plugins:amd64 0 as a solution to xfce4-settings:amd64 > 0
>   Holding Back xfce4-settings:amd64 rather than change xfce4-mcs-plugins:amd64
> Investigating (0) xfce4-session [ amd64 ] < 4.4.2-6 -> 4.6.2-2 > ( xfce )
> Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] < none -> 
> 4.6.5-3 > ( xfce )
>   Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0
>   Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64
>  Try to Re-Instate (1) xfce4-session:amd64
> Done

I'm not sure why apt doesn't want to remove xfce4-mcs-plugin at all. Any
idea?
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce65239.7040...@debian.org

Re: Full install/removal/upgrade test results available

[Yves-Alexis Perez]

On mer., 2010-11-17 at 08:37 -0600, Lucas Nussbaum wrote:
> I have been working on a piuparts rewrite that makes it easier to find
> install/removal/upgrade bugs. When running it on all packages in
> squeeze, I'm currently getting 682 failures. That doesn't mean 682 RC
> bugs, because some of the failures are caused by bugs in other packages,
> or only exhibit when the debconf frontend is set to noninteractive, or
> are caused by dbconfig-common problems, etc. But still, there's a fair
> number of issues that should be fixed in squeeze. 

I've tried to investigate xfce4-session upgrade failure. I've reproduced
it in a lenny chroot, but I can't explain apt-get behavior:

Investigating (0) xfce4-settings [ amd64 ] < none -> 4.6.5-2 > ( xfce )
   Broken xfce4-settings:amd64 Conflicts on xfce4-mcs-plugins [ amd64 ] < 
4.4.2-4 > ( x11 )
 Considering xfce4-mcs-plugins:amd64 0 as a solution to 
xfce4-settings:amd64 0
 Holding Back xfce4-settings:amd64 rather than change 
xfce4-mcs-plugins:amd64
   Investigating (0) xfce4-session [ amd64 ] < 4.4.2-6 -> 4.6.2-2 > ( xfce )
   Broken xfce4-session:amd64 Depends on xfce4-settings [ amd64 ] < none -> 
4.6.5-2 > ( xfce )
 Considering xfce4-settings:amd64 0 as a solution to xfce4-session:amd64 0
 Holding Back xfce4-session:amd64 rather than change xfce4-settings:amd64
Try to Re-Instate (1) xfce4-session:amd64
   Done

xfce4-session (4.6.2-2) depends on xfce4-settings which in turns
Conflicts: xfce4-mcs-plugins. For some reason, apt-get doesn't want to
remove xfce4-mcs-plugins and prefers to keep xfce4-settings uninstalled,
and thus xfce4-session at the previous version.

Anyone knows why and how to fix that? Would a “breaks” instead of a
“conflicts” fix it?

Cheers,
-- 
Yves-Alexis


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

Re: Squeeze Artwork: selection of default theme

[Yves-Alexis Perez]

On ven., 2010-11-12 at 10:37 +, Steve McIntyre wrote:
> Paul Wise wrote:
> >There was the possibility of mentioning the poll in DPN, but it was
> >noted that the deadline already passed. It was suggested that the
> >poll was quite short. It was suggested a more widely advertised and
> >longer running selectricity poll might have been a good idea. It was
> >noted that the email poll was simply an internal decision making
> >tool. Someone thought that it was kinda weird to have the poll only
> >limited to this list.
> 
> Um, yes. For something that's going to be so visible to many users, a
> wider-spread mention would be appreciated, and a poll running longer
> than 48 hours at a weekend.
> 
> In terms of the artwork choice itself (SpaceFun), I've seen a lot of
> comments along the lines of "looks like something even my kids would
> reject for looking too childish". I wouldn't go quite that far myself,
> but I can understand the sentiment. :-(
> 
> Please check again with a wider audience.

Ok, that's my last mail on the subject, I'll try to explain it *again*,
one last time.

I really think things could have done better. I think things could have
done better since 3 releases, to be honest. Now nobody hide the fact
that Debian artwork work is done on debian-desktop list (since 3
releases at least). Everybody could have sent his opinion *before*.
We're running out of time since quite some time already, we need to get
this done *now*.

To all people criticizing the decision-making process, feel free to be
here on time for Wheezy, participate in theme making, discussion,
packaging, whatever, I really think we need sensible input on this. 

But, once again, I don't think “a wider audience” is needed. In my
opinion, interested people *need* to take part in the work, give some
time, give some interest in the long run and not just in the final word
(a bit like everything else in Debian). And (again) those people are
really welcome on -desktop list and packaging team.

About Squeeze, I *will* upload desktop-base with Spacefun theme, when
ready. This was the decision made by the -desktop list, we knew
everybody couldn't agree on this (some people did vote for other themes
like SpaceFun, for example), but there was 4 themes, there had to be
people disappointed. But again, this was the decision and I can't really
deny it. And we're running out of time and really need to push this into
Squeeze fast.

Now, maybe the release team won't allow a freeze exception, maybe
someone will make an NMU or ask the TC to override this. Fine, do it, I
don't care, I have some (utterly cute) other things to take care of. But
if you do it, please really take care of the next artwork context, take
care of the people you're denying the decision.

Regards,
-- 
Yves-Alexis


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

Re: Bug#595106: ITP: faenza-icon-theme -- Faenza icon theme

[Yves-Alexis Perez]

On 01/09/2010 06:59, Adnan Hodzic wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Adnan Hodzic 
> 
> * Package name: faenza-icon-theme
>   Version : 0.7
>   Upstream Author : Matthieu James 
> * URL : http://tiheum.deviantart.com/art/Faenza-Icons-173323228
> * License : GPL
>   Description : Faenza icon theme
> 
> This icon theme for Gnome provides monochromatic icons for panels, toolbars 
> and buttons and colourful squared icons for devices, applications, folder,
> files and menu items.
>
Does it provide complete freedesktop.org coverage?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c7e3b6e.2000...@debian.org

Re: For those who care about their packages in Debian

[Yves-Alexis Perez]

On 25/08/2010 10:13, Russ Allbery wrote:
> Yves-Alexis Perez  writes:
>> Hmhm, out of curiosity, why is t-p-u “way riskier”.
> 
> Mostly because there isn't any large pool of systems using t-p-u the way
> there is for unstable,

Yeah, good point.

> 
>> Would it be possible (at one point) to “fix” it and stop using unstable
>> as t-p-u and experimental as unstable when freeze is in action?
> 
> We could try to get lots of people who normally use unstable to instead
> test testing plus t-p-u, but I'm not sure they'd be willing to do so.  I
> for example don't want to switch my unstable systems to testing plus t-p-u
> for a variety of reasons.
> 
I have a box running testing (well, not updated due to flaky net
connection right now) which I really should pass on testing+t-p-u.

But wouldn't CUT fit nicely there?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c74e5c9.3020...@debian.org

Re: For those who care about their packages in Debian

[Yves-Alexis Perez]

On 25/08/2010 10:02, Russ Allbery wrote:
> Uploading new versions of leaf software isn't *as* big of a disaster, but
> it does mean that updates to that software that should go into testing
> can't go through the normal testing process and have to go through
> testing-proposed-updates, which is way riskier.  This isn't good.  So for
> anything that's releasing with squeeze, please upload any subsequent
> versions *not* aimed at squeeze to experimental instead.

Hmhm, out of curiosity, why is t-p-u “way riskier”. Would it be possible
(at one point) to “fix” it and stop using unstable as t-p-u and
experimental as unstable when freeze is in action?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c74cf3b.1030...@debian.org

Re: Is Ryan Niebur MIA?

[Yves-Alexis Perez]

On mar., 2010-08-17 at 11:46 -0700, Ryan Niebur wrote:
> On Tue, Aug 17, 2010 at 08:13:54AM +0200, Yves-Alexis Perez wrote:
> > 
> > On a side note, I'd very much like to update midori, but doing a NMU for
> > a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
> > really prefer he we had news and if he's coming back soon :)
> > 
> 
> Alright, Please do go ahead with an NMU. Thanks in advance! 

Ok, will do. Glad to see you're still around. Any idea about what's next
(are you back and will you have time to take care, or should we proceed
with some other plan?)

Cheers,
-- 
Yves-Alexis


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

Re: Is Ryan Niebur MIA?

[Yves-Alexis Perez]

On 17/08/2010 15:51, Xavier Oswald wrote:
> Some times ago I sponsored him uploads of midori. I told him that Im 
> interested
> in helping maintaining midori and he said that he is active and will take care
> of it if I well remember. Im sad to hear this.

I asked him multiple time if he needed help, but apparently he didn't.
The 0.2.4 upload has needed some pings, but in the end it was
successful. For 0.2.5+, not so much (Ryan had concerns about some bugs
preventing him to upload, but there wasn't any recent news on the
subject on the BTS)
> 
> What do you suggest ?

If we don't manage to get some news from Ryan, I'm not sure. Midori
upstream is (kind of) part of Xfce project, so it could be maintained
there, but Ryan already uses git (pkg-xfce is on svn), and to be honest
I'm not that sure I'm quite prepared to add another waf-based project.

But yes, in the end, moving the project to collab maint and adding some
uploaders might be a sensible thing to do.

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c6a97ea.8000...@debian.org

Is Ryan Niebur MIA?

[Yves-Alexis Perez]

Hey,

did anybody have news from Ryan recently? Some time ago we discussed
midori new upstream release (debian has 0.2.4, 0.2.7 just came out), but
I heard no news since few months. I pinged him on irc, by mail and on
the BTS, but nothing. Seems the last activity was like a month ago, and
I don't know about a [VAC].

Do we know if he's ok?

On a side note, I'd very much like to update midori, but doing a NMU for
a new upstream release (he already packaged 0.2.6) is a bit rude, so I'd
really prefer he we had news and if he's coming back soon :)

Cheers,
-- 
Yves-Alexis


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

Re: why are there /bin and /usr/bin...

[Yves-Alexis Perez]

On 16/08/2010 14:00, Tollef Fog Heen wrote:
> ]] "Perry E. Metzger" 
> 
> | In the embedded space, which I know a lot about, it is true that the
> | root FS is on flash or other expensive media -- but it isn't like /usr
> | is on cheaper media in such an environment, it is always part of the
> | root fs anyway, so it makes no difference.
> 
> Take a look at the N900 where most of the user-installed applications
> are on /home (well, /opt, but that's a symlink to /opt/home), which is a
> 32GB eMMC flash, while the root file system is a 256MB NAND flash, which
> is vastly more expensive.  So while the situation you are describing
> might be common, it's not always true.

To be honest, I'm not sure the N900 /opt debacle is really to be taken
as an example. (and / and /usr are basically on the same media, when it
comes to boot)

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c69337c.7010...@debian.org

Re: .deb package for a library generation

[Yves-Alexis Perez]

I won't comment on the main issue since other people gave you the
solution.

On dim., 2010-08-08 at 16:45 +0300, Zvi Dubitzky wrote:
> I need to generate a Debian package for a library 
> As an exercise I tried it with   libvirt . 

Note that libvirt is already packaged so you can inspire you of the
existing packaging.

> I am running a Ubuntu 8.10 . and use the libvirt.0.6.1 tar.gz 
> 
> 
> For the library package I followed the Ubuntu instructions at  : 
> https://wiki.ubuntu.com/PackagingGuide/Basic 

You might want to look at :

http://www.debian.org/doc/maint-guide/ [New maintainer's guide]
http://www.debian.org/doc/debian-policy/ [Debian policy]
http://wiki.debian.org/HowToPackageForDebian [Packaging howto]
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
[Library packaging guide]

Cheers,
-- 
Yves-Alexis


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

Re: libcairo2 in squeeze & subpixel rendering

[Yves-Alexis Perez]

On lun., 2010-08-09 at 21:13 +0400, Stanislav Maslovski wrote:
> BTW, suboptimal
> subpixel rendering of fonts in Debian is one of the reasons why many
> desktop users switch to other distros. 

Is it?
-- 
Yves-Alexis


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

Re: segmentation fault (a.o. in /u/s/debconf/frontend)

[Yves-Alexis Perez]

On 04/08/2010 11:54, Fabian Greffrath wrote:
> Unfortunately, a reboot did not help to fix the issue on my system. I am
> running a testing/unstable mixture, by the way.

I think you want reportbug here.
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c597116.9090...@debian.org

Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling

[Yves-Alexis Perez]

On 27/07/2010 12:59, Ian Jackson wrote:
> Fernando Lemos writes ("Re: How to make Debian more attractive for users, 
> was: Re: The number  of popcon.debian.org-submissions is falling"):
>> This is free software. If you want to get your idea implemented,
>> either file a bug report and patiently wait (and leave debian-devel
>> alone) or implement it yourself. Talk is cheap.
> 
> In context this could be read as an invitation to write the code to
> allow web bug submission.  Of course such code would not be accepted,
> and no-one should be encouraged to write it.
> 
Isn't that what #590269 is about?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c4ecd6b.7060...@debian.org

Re: The number of popcon.debian.org-submissions is falling

[Yves-Alexis Perez]

On 26/07/2010 10:30, Raphael Hertzog wrote:
> I could not find that "submenu" while installing 10.04. It's quite
> possibly only in the alternate installer image nowadays (that is used
> for the server edition AFAIK).

So they have such a huge number of people installing the alternate
installer? I guess that's for the Xubuntu installation :)

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c4e9879.5050...@debian.org

Re: The number of popcon.debian.org-submissions is falling

[Yves-Alexis Perez]

On 21/07/2010 10:25, Paul Wise wrote:
> They also currently have almost 20 times as many popcon submissions as
> Debian and continuing growth:
> 
> http://popcon.ubuntu.com/
> http://popcon.ubuntu.com/stat/sub-i386.png

Is it enabled by default without asking the user? (I didn't do an ubuntu
install since warty or hoary so I wouldn't know)

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c47ff3c.1070...@debian.org

Re: The number of popcon.debian.org-submissions is falling

[Yves-Alexis Perez]

On 20/07/2010 16:56, Giacomo A. Catenazzi wrote:
> I mount filesystem with "noatime" (at home and on my servers),
> and AFAIK popcon don't work with such configuration, so I don't
> install it.

It can at least report the installed packages, I guess?

Cheers,
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c45c3b8.6060...@debian.org

Re: Bug#587514: ITP: cpupowerd -- daemon for frequency and voltage control of AMD K8 CPUs with undervolting/overvolting capability

[Yves-Alexis Perez]

On 29/06/2010 16:00, Michael Biebl wrote:
> What features does it have over existing packages?

And why not using ondemand? Is AMD support bad?
-- 
Yves-Alexis


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c29fdb4.1010...@debian.org

Re: xulrunner 1.9.2 into sid?

[Yves-Alexis Perez]

On lun., 2010-06-28 at 17:55 +0200, Olivier Bonvalet wrote:
> I agree : on 64bit systems Iceweasel 3.5 is way too slow, and Iceweasel 
> 3.6 should be included in Squeeze. 

Thank you for volunteering, I'm sure Mike will take all the help you'll
give.
-- 
Yves-Alexis


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

Re: ITP: php-recaptcha -- PHP interface to recaptcha.net

[Yves-Alexis Perez]

On dim., 2010-06-20 at 11:40 +0200, Marco d'Itri wrote:
> You are not even a Debian developer so please refrain from trying to
> re-interpret the DFSG to suite your opinions.
> 
Nice, very nice. I'm speechless.
-- 
Yves-Alexis


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

Re: cryptdisks(-early) initscripts, dependencies and loops

[Yves-Alexis Perez]

On ven., 2010-06-04 at 02:49 +0200, Petter Reinholdtsen wrote:
> 
> Those wanting another ordering can edit the init.d scripts directly to
> declare some other ordering or provide override headers in
> /etc/inssserv/overrides/ if they want to avoid editing in the
> conffiles included in the package.
> 
> It is possible event baset boot sequencing might make it easier to
> change the ordering, but also there the maintainer of a package need
> to decide on some ordering. 

One solution would be:

* pick the more common installed setup (maybe the one from d-i), and
configure dependencies for it
* provide documentation on how to easily change headers
* provide example init.d files for most common setups, with some
documentation on how to install them.

That way, people could chose what they need. It has to be done before
the first reboot, so maybe a warning when creating a new setup would be
necessary too (and at least provide a safe default setup, thus the d-i
based one?)

Cheers,
-- 
Yves-Alexis


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