NEW changes in stable-new
Processing changes file: netcf_0.1.9-2+deb7u2_sparc.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yie2r-j1...@franck.debian.org
Bug#746946: wheezy-pu: package distro-info-data/0.23~deb7u1
On Thu, 16 Apr 2015, Stefano Rivera wrote: +- Correct EOL date of Debian 6.0 Squeeze to 2014-05-31. FWIW, Debian 6 Squeeze is supported for at least 5 years (i.e. 2016-02-06) and most likely until Wheezy is no longer supported (i.e. 2016-04-24). cf http://wiki.debian.org/LTS -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416090058.gb6...@home.ouaza.com
Re: Bug#769355: reportbug: extend binNMU support to cover more distros besides unstable
Hi Sandro, On Donnerstag, 16. April 2015, Sandro Tosi wrote: That's great! now, last doubt: what type of suites are allowed in the nmu command? Andreas mentioned some (other than the default 'unstable'): * experimental * $STABLE-backports * $STABLE-proposed-updates * $STABLE are there any other acceptable? $OLDSTABLE-lts comes to my mind. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#782381: Bug#781995: motif/2.3.4-6.1 failed to build
retitle 782381 pre-approval: unblock: motif/2.3.4-6.2 thanks On 16/04/2015 07:46, Michael Gilbert wrote: On Thu, Apr 16, 2015 at 1:31 AM, Graham Inggs wrote: If you uploaded 2.3.4-6.2 now, could it cause any harm? At least this will get the package built and Release Team can still decide whether to grant the unblock request or not. If you can talk the release team into pre approving an unblock, then I'm willing to do the upload. Best wishes, Mike Great, thanks. Is there anywhere else I should be talking to Release Team, besides replying to bug #782381? For the record, I grepped /var/lib/dpkg/status and found: 49 instances of libxm4 ( 47 instances of libxm4 (= 46 instance of libxm4 (= 2.3.4 1 instance of libxm4 (= 2.3.3 (from arb) 0 instances of libxm4 (= 2.3.4- 2 instances of libxm4 (= (from libmotif-dev and libmotif4-dbg) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/552f7d9d.9030...@nerve.org.za
Processed: Re: Bug#781995: motif/2.3.4-6.1 failed to build
Processing commands for cont...@bugs.debian.org: retitle 782381 pre-approval: unblock: motif/2.3.4-6.2 Bug #782381 [release.debian.org] pre-approval: unblock: motif/2.3.4-8 Changed Bug title to 'pre-approval: unblock: motif/2.3.4-6.2' from 'pre-approval: unblock: motif/2.3.4-8' thanks Stopping processing here. Please contact me if you need assistance. -- 782381: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782381 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.14291757212374.transcr...@bugs.debian.org
NEW changes in stable-new
Processing changes file: netcf_0.1.9-2+deb7u2_mipsel.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yigcy-0002wq...@franck.debian.org
Bug#782599: marked as done (unblock: libdatetime-timezone-perl/1:1.75-2+2015c)
Your message dated Thu, 16 Apr 2015 13:31:44 +0100
with message-id
4d49d7cf275a262bd1a06e496c7f5...@mowgli.jungle.funky-badger.org
and subject line Re: Bug#782599: unblock:
libdatetime-timezone-perl/1:1.75-2+2015c
has caused the Debian Bug report #782599,
regarding unblock: libdatetime-timezone-perl/1:1.75-2+2015c
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
782599: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782599
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Please unblock package libdatetime-timezone-perl:
This version contains an update of the data files to the 2015c
version of the olsondb as a quilt patch. It contains contemporary
changes for Egypt.
Changelog:
libdatetime-timezone-perl (1:1.75-2+2015c) unstable; urgency=medium
* Update to Olson database version 2015c.
Add patch debian/patches olson-2015c, which updates the timezone *.pm
files, using upstream's tools/parse_olson script.
This update contains contemporary changes for Egypt.
-- gregor herrmann gre...@debian.org Tue, 14 Apr 2015 18:49:09 +0200
I'm attaching a manually stripped down debdiff.
unblock libdatetime-timezone-perl/1:1.75-2+2015c
Cheers,
gregor
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQJ8BAEBCgBmBQJVLUsvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGMGQQAIBPXHif9f6Qck+/kd+rHOXp
6BiNWueLajtal83V+1+0hBmQgcpwysccMQq1KLxMAh06nAc6cXMFgn/rqgsF6My6
4a/g7SZqh/UhKGPrei6ImoseKVcVKyIk+cNCH7DuYUjF6baaSmaALyXp0utNRUf1
cgvVEjVMD9/xDgaO0StfCwGfZi2X9X2V4XNn4DxFL3R+ZZZMUIPL7+Sqhjpxv3M8
kGQHBShCis+5FU9WO78RPNlA6BtMnKRmx6FgbZiXJ5QbUiU2ouAafpK2a02vj0Sv
ViXS9kyxRgGM96uCW1VT17LVh3+gaidFDbaq464zZJL1NQRwz+RxRAXH2SqYR5im
j+Xww0ocLgHJp0wsu7HwB7Mxtw4wF+TigC4JxkdaGDMpirx69a1PdC+/gU1FHInt
FrQ7OvENy24strmgZ6zG3OSMUe/uOUG3vRqR9fxbToy7Yvh5+irhFq/O6iiZoC9f
5HiJY4VRFE/8O4E8yj1HcoMaik2yAjAZ62DJhCumixoX1CY0R2bqC/Krk1nziLLB
AagxVxVP6E9YTyO1672JxnUVpNXgBZWqwb7ttMtM6fnrn6Y4MJISvek17FLgNoRT
R6qqdQeDopSnuyKxmlOqP1ICk5IcLyM1fKfobb2+OhhmBdK8TPCd+DxRhyfvuL8x
AJDd4ZCibLy/90KdAlzO
=XiVu
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-1.75/debian/changelog libdatetime-timezone-perl-1.75/debian/changelog
--- libdatetime-timezone-perl-1.75/debian/changelog 2015-03-21 17:40:02.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/changelog 2015-04-14 18:49:27.0 +0200
@@ -1,3 +1,12 @@
+libdatetime-timezone-perl (1:1.75-2+2015c) unstable; urgency=medium
+
+ * Update to Olson database version 2015c.
+Add patch debian/patches olson-2015c, which updates the timezone *.pm
+files, using upstream's tools/parse_olson script.
+This update contains contemporary changes for Egypt.
+
+ -- gregor herrmann gre...@debian.org Tue, 14 Apr 2015 18:49:09 +0200
+
libdatetime-timezone-perl (1:1.75-2+2015b) unstable; urgency=medium
* Update to Olson database version 2015b.
diff -Nru libdatetime-timezone-perl-1.75/debian/patches/olson-2015c libdatetime-timezone-perl-1.75/debian/patches/olson-2015c
--- libdatetime-timezone-perl-1.75/debian/patches/olson-2015c 1970-01-01 01:00:00.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/patches/olson-2015c 2015-04-14 18:49:27.0 +0200
@@ -0,0 +1,11810 @@
+Description: update to olson db 2015c
+Origin: vendor
+Author: gregor herrmann gre...@debian.org
+Last-Update: 2015-04-14
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2015b
++# Generated from debian/tzdata/africa. Olson data version 2015c
+ #
+ # Do not edit this file directly.
+ #
+@@ -39,7 +39,7 @@
+ ],
+ ];
+
+-sub olson_version { '2015b' }
++sub olson_version { '2015c' }
+
+ sub has_dst_changes { 0 }
+
+--- a/lib/DateTime/TimeZone/Africa/Cairo.pm
b/lib/DateTime/TimeZone/Africa/Cairo.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+
+ #
+-# Generated from debian/tzdata/africa. Olson data version 2015b
++# Generated from debian/tzdata/africa. Olson data version 2015c
+ #
+ # Do not edit this file directly.
+ #
+@@ -1164,17 +1164,17 @@
+ ],
+ [
+ 63547362000, #utc_start 2014-09-25 21:00:00 (Thu)
+-63565509600, # utc_end 2015-04-23 22:00:00 (Thu)
++63566114400, #
Re: Bug#746946: wheezy-pu: package distro-info-data/0.23~deb7u1
Hi Raphael, +- Correct EOL date of Debian 6.0 Squeeze to 2014-05-31. FWIW, Debian 6 Squeeze is supported for at least 5 years (i.e. 2016-02-06) and most likely until Wheezy is no longer supported (i.e. 2016-04-24). cf http://wiki.debian.org/LTS There is an on-going confusion in the wider Debian community about whether squeeze is still supported or EOL. The squeeze-lts work does not cover all of squeeze -- there are significant limitations in the packages and archs covered. It would be inappropriate to indicate to users that other archs were supported by saying that squeeze is still a supported release. From the very first line of the wiki page you linked to: LTS (Long Term Support) is a project for providing security patches after oldstable reached its end of life. which would agree with distro-info-data in stating that squeeze is EOL. As much as squeeze-lts is a great initiative, it's not true to say that squeeze is still a supported release. I guess that makes it EOL and it wants an EOL date that reflects when that change happened: 2014-05-31 Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mgo2uv$ofa$1...@ger.gmane.org
Re: Bug#769355: reportbug: extend binNMU support to cover more distros besides unstable
On 2015-04-16 0:48, Sandro Tosi wrote:
That's great! now, last doubt: what type of suites are allowed in the
nmu command? Andreas mentioned some (other than the default
'unstable'):
* experimental
* $STABLE-backports
* $STABLE-proposed-updates
* $STABLE
are there any other acceptable? is $STABLE 'stable' or 'wheezy' (the
former is preferred - from my POV - to avoid to update the suites list
at each release)? No binnmu in testing? so, really, what should I put
in this suites menu?! :)
The suites in wanna-build use codenames, and there are no
-proposed-updates suites. wanna-build also exposes aliases for a
handful of suites, but not all (wanna-build --distribution-aliases on
buildd.d.do will give you a list), and I assume the alias list is
managed by hand. Due to both of those considerations, I'd suggest using
the codenames.
As a not-necessarily-complete list, which will obviously change RSN:
- experimental
- sid/unstable (default if no suite is specified)
- jessie/testing
- wheezy/stable
- {wheezy,stable}-security
- wheezy-backports
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/49c0c92332b4b2667537d1bab1162...@mowgli.jungle.funky-badger.org
need email marketing solutions?
Hope you are doing well today! We specialize in providing email marketing services to a number of businesses. We would like to be your marketing partners and help your business reach the next level. We can increase your business sales 2-4 times than before. Please contact us if you would require more information about pricing or proposal. Looking forward to your positive response. Thanks, Louis Contact: cosm...@aliyun.com -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/f1f485034d335dbd58b2f11aaf8e6...@smythstoys.com
Re: Bug#746946: wheezy-pu: package distro-info-data/0.23~deb7u1
[ Moving it to -lts to continue the discussion ] Hi, On Thu, 16 Apr 2015, Stuart Prescott wrote: cf http://wiki.debian.org/LTS There is an on-going confusion in the wider Debian community about whether squeeze is still supported or EOL. Where did you notice any confusion? The squeeze-lts work does not cover all of squeeze -- there are significant limitations in the packages and archs covered. It would be inappropriate to indicate to users that other archs were supported by saying that squeeze is still a supported release. It's also inappropriate to say that it's EOL when 98% of the users who are using amd64/i386 are still covered. Yes there are packages which are unsupported in Squeeze but very much like there are unsupported packages in Wheezy right now: Squeeze: http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/plain/security-support-ended.deb6 Wheezy: http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/plain/security-support-ended.deb7 + chromium cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776904 It's just that the list expands over time as more and more packages get unsupportable when upstream no longer supports them. And we try to avoid this by backporting newer upstream version when there's no other solution (we did this recently for wireshark in squeeze). (And we would love to shorten the list of unsupported packages if we had more resources) From the very first line of the wiki page you linked to: LTS (Long Term Support) is a project for providing security patches after oldstable reached its end of life. which would agree with distro-info-data in stating that squeeze is EOL. Or that we should rephrase our description. We are working hand in hand with security team to provide a continuity in security support. EOL is in 2016 but in the interim, there are restrictions in what is truly supported. As much as squeeze-lts is a great initiative, it's not true to say that squeeze is still a supported release. I guess that makes it EOL and it wants an EOL date that reflects when that change happened: 2014-05-31 I disagree. But I really don't care about distro-info so I will not discuss this further in this context. That said I believe it's important to clarify the situation of squeeze. Your EOL description is misleading (and not really thankful of the work that Debian LTS team members have put into Squeeze). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416140223.gb18...@home.ouaza.com
Re: Bug#746946: wheezy-pu: package distro-info-data/0.23~deb7u1
On Thu, Apr 16, 2015 at 04:02:23PM +0200, Raphael Hertzog wrote: Yes there are packages which are unsupported in Squeeze but very much like there are unsupported packages in Wheezy right now: Also, all other distros with long support have some level of reduced support over time, see for example the requirements for fixes in RHEL in it's later support stages, so having a few packages not supported in squeeze-lts is fairly common. We shouldn't label the LTS phase as second class. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416160236.GB7902@pisco.westfalen.local
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello release team,
yesterday I discovered that systemd breaks a common way of setting up
plain cryptsetup partitions. Turns out that this has already been
known for a while, but the impact wasn't appreciated enough:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707
What happens is that systemd's cryptsetup integration ignores the
offset= parameter in crypttab and instead uses the whole device. So
if you had a swap or other partition underneath in order to identify
the partition via UUID or label instead of an unreliable hardcoded
device name, switching to systemd destroys the underlying metadata,
and causes a boot hang as crypttab now refers to a nonexisting
UUID/label. This is quite a common way to set up encrypted swap, the
way that ecryptfs' own swap setup tool does it (the Ubuntu installer
calls that if you select encrypt my home directory; I'm not sure
whether Debian's installer does the same).
IMHO this qualifies as data loss, and we cannot repair this
automatically after the damage happened. So I'd really like to fix
this in jessie, and I upgraded it to RC.
The patch is quite straightforward. It got a first review by upstream,
I made it a bit more defensive since the first version, and it'll
probably land today. I attached my test script to the upstream bug [1]
which allows you to play around with various offset= options and
verify that it doesn't destroy the initial part of the partition.
I realize this is a somewhat awkward timing as we want to deep-freeze
in two days, and this means an udeb change (although only formally as
there are no effective changes in udev). 215-16 should go into testing
tonight, and I'm prepared to upload 215-17 with that fix right after
that with urgency=high.
What would you recommend how to proceed?
Thank you in advance!
Martin
[1] https://bugs.freedesktop.org/show_bug.cgi?id=87717
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
diff --git a/debian/changelog b/debian/changelog
index 29ff5a3..103d8ce 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+systemd (215-17) UNRELEASED; urgency=medium
+
+ * cryptsetup: Implement offset and skip options. (Closes: #751707,
+LP: #953875)
+
+ -- Martin Pitt mp...@debian.org Thu, 16 Apr 2015 07:12:08 -0500
+
systemd (215-16) unstable; urgency=medium
[ Christian Seiler ]
diff --git a/debian/patches/cryptsetup-Implement-offset-and-skip-options.patch
b/debian/patches/cryptsetup-Implement-offset-and-skip-options.patch
new file mode 100644
index 000..f392bbc
--- /dev/null
+++ b/debian/patches/cryptsetup-Implement-offset-and-skip-options.patch
@@ -0,0 +1,66 @@
+From: Martin Pitt martin.p...@ubuntu.com
+Date: Thu, 16 Apr 2015 06:44:07 -0500
+Subject: cryptsetup: Implement offset and skip options
+
+These are useful for plain devices as they don't have any metadata by
+themselves. Instead of using an unreliable hardcoded device name in crypttab
+you can then put static metadata at the start of the partition for a stable
+UUID or label.
+
+https://bugs.freedesktop.org/show_bug.cgi?id=87717
+https://bugs.debian.org/751707
+https://launchpad.net/bugs/953875
+---
+ src/cryptsetup/cryptsetup.c | 21 +++--
+ 1 file changed, 19 insertions(+), 2 deletions(-)
+
+diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
+index a67d85e..6257c81 100644
+--- a/src/cryptsetup/cryptsetup.c
b/src/cryptsetup/cryptsetup.c
+@@ -50,12 +50,12 @@ static bool arg_discards = false;
+ static bool arg_tcrypt_hidden = false;
+ static bool arg_tcrypt_system = false;
+ static char **arg_tcrypt_keyfiles = NULL;
++static uint64_t arg_offset = 0;
++static uint64_t arg_skip = 0;
+ static usec_t arg_timeout = 0;
+
+ /* Options Debian's crypttab knows we don't:
+
+-offset=
+-skip=
+ precheck=
+ check=
+ checkargs=
+@@ -168,6 +168,20 @@ static int parse_one_option(const char *option) {
+ return 0;
+ }
+
++} else if (startswith(option, offset=)) {
++
++if (safe_atou64(option+7, arg_offset) 0) {
++log_error(offset= parse failure, refusing.);
++return -EINVAL;
++}
++
++} else if (startswith(option, skip=)) {
++
++if (safe_atou64(option+5, arg_skip) 0) {
++log_error(skip= parse failure, refusing.);
++return -EINVAL;
++}
++
+ } else if (!streq(option, none))
+ log_error(Encountered unknown /etc/crypttab option '%s',
ignoring., option);
+
+@@ -403,6 +417,9 @@ static int attach_luks_or_plain(struct crypt_device *cd,
+ } else
+ params.hash = ripemd160;
+
++params.offset = arg_offset;
++
Bug#746946: wheezy-pu: package distro-info-data/0.23~deb7u1
Hi Raphael (2015.04.16_11:00:58_+0200) FWIW, Debian 6 Squeeze is supported for at least 5 years (i.e. 2016-02-06) and most likely until Wheezy is no longer supported (i.e. 2016-04-24). cf http://wiki.debian.org/LTS We could hack that in, but we should really support LTS separately. This is #782685. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416164917.ga3...@bach.rivera.co.za
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
(Cc: debian-boot@ added.) Martin Pitt mp...@debian.org (2015-04-16): Hello release team, (With my d-i release manager hat.) yesterday I discovered that systemd breaks a common way of setting up plain cryptsetup partitions. Turns out that this has already been known for a while, but the impact wasn't appreciated enough: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751707 What happens is that systemd's cryptsetup integration ignores the offset= parameter in crypttab and instead uses the whole device. So if you had a swap or other partition underneath in order to identify the partition via UUID or label instead of an unreliable hardcoded device name, switching to systemd destroys the underlying metadata, and causes a boot hang as crypttab now refers to a nonexisting UUID/label. This is quite a common way to set up encrypted swap, the way that ecryptfs' own swap setup tool does it (the Ubuntu installer calls that if you select encrypt my home directory; I'm not sure whether Debian's installer does the same). Grepping for hash= in partman-* d-i packages led to partman-crypto, which seems responsible for this (no surprise here): http://anonscm.debian.org/cgit/d-i/partman-crypto.git/tree/finish.d/crypto_config There's no offset= there. Looking into partman-* in Ubuntu vivid, it turns out that one of them look at user-setup, and that's where the following is defined: | Template: user-setup/encrypt-home | Type: boolean | Default: false | # :sl2: | _Description: Encrypt your home directory? `---[ debian/user-setup-udeb.templates ]--- which is then used in user-setup-apply where there's a lot more (encryption-related) code than in Debian, which e.g. calls adduser with an option to encrypt home, which then calls some commands from the ecryptfs-utils package, but I don't see any offset in the ecryptfs-setup-private script. Anyway, asking for home encryption indeed leads to swap encryption, through a ecryptfs-setup-swap call, which in turn triggers: |echo cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 /etc/crypttab `---[ src/utils/ecryptfs-setup-swap ]--- The same file in the Debian package has no offset, so I guess that means Debian is rather safe. IMHO this qualifies as data loss, and we cannot repair this automatically after the damage happened. So I'd really like to fix this in jessie, and I upgraded it to RC. The patch is quite straightforward. It got a first review by upstream, I made it a bit more defensive since the first version, and it'll probably land today. I attached my test script to the upstream bug [1] which allows you to play around with various offset= options and verify that it doesn't destroy the initial part of the partition. I realize this is a somewhat awkward timing as we want to deep-freeze in two days, and this means an udeb change (although only formally as there are no effective changes in udev). 215-16 should go into testing tonight, and I'm prepared to upload 215-17 with that fix right after that with urgency=high. What would you recommend how to proceed? Provided a review by the release team, I'm OK with letting this go into testing between D-I Jessie RC3 (to be released at the end of this week) and a possible extra debian-installer upload (before the release). I'm not exactly entirely sure how to deal with D-I for Jessie past RC3 anyway: - Do nothing? - BinNMU to make sure it's built against last-migrated components? - Sourceful upload in case there's any changes staged in git during the last week? (I hope that won't be necessary.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Martin Pitt mp...@debian.org (2015-04-16): Hello Cyril, Cyril Brulebois [2015-04-16 19:40 +0200]: Anyway, asking for home encryption indeed leads to swap encryption, through a ecryptfs-setup-swap call, which in turn triggers: |echo cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 /etc/crypttab `---[ src/utils/ecryptfs-setup-swap ]--- The same file in the Debian package has no offset, so I guess that means Debian is rather safe. Well, it actually means that it's even more broken :-( If you don't specify an offset at all, then you can only boot this system once. Then your partition will be overwritten with random data entirely, and the next time you won't have any matching UUID any more, and you again get a hanging boot (this affects sysvinit and upstart too). I. e. you will have exactly the same effect. So to properly fix this, we need: (1) the fix to add the offset=: https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840 (Updating the used cipher would also be a good idea, but not essential) This fix alone is sufficient under sysvinit and upstart. (2) this systemd fix to actually respect offset= when booting under systemd. Huh? Last I checked, guided encrypted LVM just works… Mraw, KiBi. signature.asc Description: Digital signature
Bug#782728: unblock: glibc/2.19-18
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
The locales package (part of the glibc source package) recently got an
RC bug reported. While this RC bug is also present in Jessie, I think
it's a good idea to also fix it in Jessie as the C.UTF-8 locale is more
and more used. I have therefore uploaded version glibc/2.19-18 to
unstable, with the following diff:
Index: changelog
===
--- changelog (revision 6378)
+++ changelog (working copy)
@@ -1,3 +1,11 @@
+glibc (2.19-18) unstable; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debhelper.in/locales.templates: allow the C.UTF-8 locale to be
+selected as the default locale. Closes: #782241.
+
+ -- Aurelien Jarno aure...@debian.org Tue, 14 Apr 2015 19:50:11 +0200
+
glibc (2.19-17) unstable; urgency=medium
[ Adam Conrad ]
Index: debhelper.in/locales.templates
===
--- debhelper.in/locales.templates (revision 6378)
+++ debhelper.in/locales.templates (working copy)
@@ -15,7 +15,7 @@
Template: locales/default_environment_locale
Type: select
#flag:translate:1
-__Choices: None, ${locales}
+__Choices: None, C.UTF-8, ${locales}
Default: None
_Description: Default locale for the system environment:
Many packages in Debian use locales to display text in the correct
Could you please unblock it so that it moves into Jessie? Thanks in
advance.
Regards,
Aurelien
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20150416194642.1892.97621.report...@weber.rr44.fr
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Hello Cyril, Cyril Brulebois [2015-04-16 19:40 +0200]: Anyway, asking for home encryption indeed leads to swap encryption, through a ecryptfs-setup-swap call, which in turn triggers: |echo cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 /etc/crypttab `---[ src/utils/ecryptfs-setup-swap ]--- The same file in the Debian package has no offset, so I guess that means Debian is rather safe. Well, it actually means that it's even more broken :-( If you don't specify an offset at all, then you can only boot this system once. Then your partition will be overwritten with random data entirely, and the next time you won't have any matching UUID any more, and you again get a hanging boot (this affects sysvinit and upstart too). I. e. you will have exactly the same effect. So to properly fix this, we need: (1) the fix to add the offset=: https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840 (Updating the used cipher would also be a good idea, but not essential) This fix alone is sufficient under sysvinit and upstart. (2) this systemd fix to actually respect offset= when booting under systemd. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
On Thu, Apr 16, 2015 at 10:05:17PM +0200, Cyril Brulebois wrote: Martin Pitt mp...@debian.org (2015-04-16): Hello Cyril, Cyril Brulebois [2015-04-16 19:40 +0200]: Anyway, asking for home encryption indeed leads to swap encryption, through a ecryptfs-setup-swap call, which in turn triggers: |echo cryptswap$i UUID=$uuid /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 /etc/crypttab `---[ src/utils/ecryptfs-setup-swap ]--- The same file in the Debian package has no offset, so I guess that means Debian is rather safe. Well, it actually means that it's even more broken :-( If you don't specify an offset at all, then you can only boot this system once. Then your partition will be overwritten with random data entirely, and the next time you won't have any matching UUID any more, and you again get a hanging boot (this affects sysvinit and upstart too). I. e. you will have exactly the same effect. So to properly fix this, we need: (1) the fix to add the offset=: https://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/840 (Updating the used cipher would also be a good idea, but not essential) This fix alone is sufficient under sysvinit and upstart. (2) this systemd fix to actually respect offset= when booting under systemd. Huh? Last I checked, guided encrypted LVM just works… Worked for me about a month ago. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416205818.gu29...@csclub.uwaterloo.ca
Bug#782728: unblock: glibc/2.19-18
Aurelien Jarno aure...@debian.org (2015-04-16):
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
The locales package (part of the glibc source package) recently got an
RC bug reported. While this RC bug is also present in Jessie, I think
it's a good idea to also fix it in Jessie as the C.UTF-8 locale is more
and more used. I have therefore uploaded version glibc/2.19-18 to
unstable, with the following diff:
Index: changelog
===
--- changelog (revision 6378)
+++ changelog (working copy)
@@ -1,3 +1,11 @@
+glibc (2.19-18) unstable; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debhelper.in/locales.templates: allow the C.UTF-8 locale to be
+selected as the default locale. Closes: #782241.
+
+ -- Aurelien Jarno aure...@debian.org Tue, 14 Apr 2015 19:50:11 +0200
+
glibc (2.19-17) unstable; urgency=medium
[ Adam Conrad ]
Index: debhelper.in/locales.templates
===
--- debhelper.in/locales.templates(revision 6378)
+++ debhelper.in/locales.templates(working copy)
@@ -15,7 +15,7 @@
Template: locales/default_environment_locale
Type: select
#flag:translate:1
-__Choices: None, ${locales}
+__Choices: None, C.UTF-8, ${locales}
Default: None
_Description: Default locale for the system environment:
Many packages in Debian use locales to display text in the correct
Could you please unblock it so that it moves into Jessie? Thanks in
advance.
No objections, thanks.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#782728: marked as done (unblock: glibc/2.19-18)
Your message dated Thu, 16 Apr 2015 22:26:14 +0200
with message-id 55301ae6.80...@thykier.net
and subject line Re: Bug#782728: unblock: glibc/2.19-18
has caused the Debian Bug report #782728,
regarding unblock: glibc/2.19-18
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
782728: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782728
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
The locales package (part of the glibc source package) recently got an
RC bug reported. While this RC bug is also present in Jessie, I think
it's a good idea to also fix it in Jessie as the C.UTF-8 locale is more
and more used. I have therefore uploaded version glibc/2.19-18 to
unstable, with the following diff:
Index: changelog
===
--- changelog (revision 6378)
+++ changelog (working copy)
@@ -1,3 +1,11 @@
+glibc (2.19-18) unstable; urgency=medium
+
+ [ Aurelien Jarno ]
+ * debhelper.in/locales.templates: allow the C.UTF-8 locale to be
+selected as the default locale. Closes: #782241.
+
+ -- Aurelien Jarno aure...@debian.org Tue, 14 Apr 2015 19:50:11 +0200
+
glibc (2.19-17) unstable; urgency=medium
[ Adam Conrad ]
Index: debhelper.in/locales.templates
===
--- debhelper.in/locales.templates (revision 6378)
+++ debhelper.in/locales.templates (working copy)
@@ -15,7 +15,7 @@
Template: locales/default_environment_locale
Type: select
#flag:translate:1
-__Choices: None, ${locales}
+__Choices: None, C.UTF-8, ${locales}
Default: None
_Description: Default locale for the system environment:
Many packages in Debian use locales to display text in the correct
Could you please unblock it so that it moves into Jessie? Thanks in
advance.
Regards,
Aurelien
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
---End Message---
---BeginMessage---
On 2015-04-16 22:14, Cyril Brulebois wrote:
Aurelien Jarno aure...@debian.org (2015-04-16):
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
The locales package (part of the glibc source package) recently got an
RC bug reported. While this RC bug is also present in Jessie, I think
it's a good idea to also fix it in Jessie as the C.UTF-8 locale is more
and more used. I have therefore uploaded version glibc/2.19-18 to
unstable, with the following diff:
[...]
Could you please unblock it so that it moves into Jessie? Thanks in
advance.
No objections, thanks.
Mraw,
KiBi.
Ack, unblocked, thanks.
~Niels---End Message---
Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Cyril Brulebois [2015-04-16 22:05 +0200]: Huh? Last I checked, guided encrypted LVM just works… Yes, that's fine -- this creates an encrypted PV which then contains unencrypted root, swap, and home partitions. This error happens if you don't encrypt the full disk (with cryptsetup/LUKS), but just encrypt your home directory (with ecryptfs). The latter will create an encrypted swap partition with a random key, otherwise you'd find part of your /home data in your swap partition. Martin P. S. Swap partitions, will you please just die. Most systems don't need them any more, and those who do are better of with the swapspace package or similar. But that's waay out of reach for Jessie :-) -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
