Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 05.02.2013 23:55, Don Armstrong wrote: On Wed, 06 Feb 2013, Cyril Brulebois wrote: Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] Given that the syslinux packages in sid are a different major upstream version from those in wheezy, with a raw diffstat of 621 files changed, 36622 insertions(+), 15023 deletions(-) and that upstream version has been in unstable for a little over a week in total, I'm certainly uncomfortable that accepting the new version at this point would be in the best interest of the release. We've already said no to changes in other packages which were significantly smaller and didn't carry the possibility of affecting something as key as the installer. Shipping an installer that was built with a differing version of syslinux than we eventually ship also causes me concern, since the first update to d-i in a point release will obviously be rebuilt against wheezy's syslinux. This introduces a situation that we can't reasonably test beforehand, as we could no longer be confident that the released version of the wheezy installer could be correctly booted on all of our architectures. (tl,dr; right now, yes, we believe the changes are too potentially disruptive.) Regards, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9700fa19d26232d0f5501dc6bcb64...@mail.adsl.funky-badger.org
installing on mdraid imsm arrays
On 08/13/2012 01:17 PM, Miquel van Smoorenburg wrote: At work, we're using mainly supermicro servers, and they have support in the BIOS for Intel Matrix raid (imsm), which is a form of sataraid/fakeraid. [...] I now have a version of the wheezy installer that succesfully installs and boots debian on a mdadm imsm array. It took a while, but I have now filed bug reports against several packages with all the patches and fixes that are needed to make this work. 699434: grub-installer: support for Intel Matrix Raid 699432: partman-base: parted: skip devices that are part of a mdraid device 699431: partman-auto: don't hide whole-disk partitionable mdraid arrays 684712: lvm2: automatically filter imsm and ddf formatted disks 691710: unblock: mdadm/3.2.5-5 There is also a meta bug that is blocked by all of the above bugs: 699430: debian-installer: support for Intel Matrix Raid (RST, imsm) The patches/fixes are trivial, except for the grub-installer patch which is slightly larger than the other ones, but I've taken care that it doesn't actually change any existing behaviour if you are not installing on a mdraid imsm array. Mike. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51124cf0.4090...@debian.org
live-installer important bugfix for Italian support
(Keep me on CC, I'm not on debian-boot)
Hello,
I just debugged an issue where live-installer would not work when
you opted for an Italian installation. The commit below has my explanation
of the problem and a tested fix. That said I'm not very familiar with
the internals of main-menu and this interpretation comes from my reading
of the source code, not from direct experience (main-menu's interesting
logs are commented out and since it's embedded in the initrd I couldn't
easily replace it on the live ISO used for the tests). Thus I would
appreciate a review by someone more familiar with main menu.
In particular, given my explanation of the problem, I would have expected
the problem to not be solved without changing the Italian translation but
keeping the duplicate Italian translation and reducing Installer-Menu-Item
to 6490 was enough to fix the problem.
I still fixed the Italian translation because it was the right thing to do
anyway. (Note that I fixed it in packages/po/sublevel3/it.po too...)
I believe that this fix should go into wheezy. If you want me to upload it
by myself, let me know. Otherwise I'll happily let Christian upload it.
Here's my commit:
commit 85fb0ea0b6147a62a53ec8f5c0940c8276b59145
Author: Raphaël Hertzog hert...@debian.org
Date: Wed Feb 6 15:06:41 2013 +0100
Reduce Installer-Menu-Item to 6490 and fix Italian translation
The goal is to ensure that the udeb takes precedence over bootstrap-base.
This fixes installation from a live media in Italian. TTBOMK the
explanation is the following:
bootstrap-base and live-installer are pulled in the menu via the
installed-base virtual package that they provide. Thus the following
comment of main-menu applies:
/* Compile a list of providing package. The default choice will be the
* package with highest priority. If we have ties, menu items are
* preferred. If we still have ties, the default choice is arbitrary */
bootstrap-base is of priority required while live-installer is of priority
optional, but udpkg doesn't store the Priority in /var/lib/dpkg/status
thus both packages are of equal priority when main-menu compares them.
Since both packages also have Installer-Menu-Item 6500, the default choice
is supposed to be arbitrary. But even if arbitrary, the choice always
ended up selecting live-installer (as wanted) in a somewhat consistent way
across all languages, except for Italian.
As far I could understand, the reason why Italian behaves differently is
that the translation of the menu items for bootstrap-base and
live-installer are the same string Installare il sistema base and this
is thus confusing the debian-installer/missing-provide debconf prompt
which lets the user choose between both. Other translations have different
strings (and the underlying English strings are also different Install
the base system vs Install the system).
diff --git a/debian/changelog b/debian/changelog
index 4562746..7af70a6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+live-installer (40) UNRELEASED; urgency=low
+
+ * Reduce Installer-Menu-Item to 6490 to take precedence over
+bootstrap-base in the ordering computed by d-i's main-menu.
+ * Change Italian translation of Install the system to something
+else than base-installer's Italian translation of Install the base
+system (“Installare il sistema base” → “Installare il sistema”) to
+avoid confusing debconf with a list of two identical entries.
+
+ -- Raphaël Hertzog hert...@debian.org Tue, 05 Feb 2013 18:35:23 +0100
+
live-installer (39) unstable; urgency=low
[ Raphaël Hertzog ]
diff --git a/debian/control b/debian/control
index d29aacf..9854c50 100644
--- a/debian/control
+++ b/debian/control
@@ -17,5 +17,5 @@ Depends:
${shlibs:Depends}, archdetect, base-installer (= 1.105),
busybox-udeb (= 1:1.13.3), cdebconf-udeb, created-fstab, mounted-partitions
Provides: installed-base, kernel-installer
-XB-Installer-Menu-Item: 6500
+XB-Installer-Menu-Item: 6490
Description: Install the system
diff --git a/debian/po/it.po b/debian/po/it.po
index c228831..b9edced 100644
--- a/debian/po/it.po
+++ b/debian/po/it.po
@@ -53,14 +53,14 @@ msgstr
#. :sl3:
#: ../live-installer.templates:1001
msgid Install the system
-msgstr Installare il sistema base
+msgstr Installare il sistema
#. Type: text
#. Description
#. :sl3:
#: ../live-installer.templates:2001
msgid Installing the system...
-msgstr Installazione del sistema base...
+msgstr Installazione del sistema...
#. Type: text
#. Description
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Bug#699742: syslinux 5.x support
On 02/05/2013 09:33 PM, Michael Biebl wrote: I tried this patch against cc123e0 from debian-installer git. Unfortunately the problem is still the same. indeed; only the first part of the patch was attached; here's the complete one. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ diff --git a/build/config/x86.cfg b/build/config/x86.cfg index 209b567..3db7b62 100644 --- a/build/config/x86.cfg +++ b/build/config/x86.cfg @@ -107,6 +107,10 @@ endif if [ $(SYSLINUX_CFG) != prompt ]; then \ mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/vesamenu.c32 ::vesamenu.c32; \ + if [ -e /usr/lib/syslinux/ldlinux.c32 ]; then \ + mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/libcom32.c32 ::libcom32.c32; \ + mcopy -i$(TEMP_BOOT) /usr/lib/syslinux/libutil.c32 ::libutil.c32; \ + fi; \ if [ -e $(TEMP_BOOT_SCREENS)/splash.png ]; then \ mcopy -i$(TEMP_BOOT) $(TEMP_BOOT_SCREENS)/splash.png ::splash.png; \ fi; \ @@ -240,6 +244,11 @@ arch_miniiso: x86_syslinux x86_grub_efi mkdir -p $(TEMP_CD_TREE) cp /usr/lib/syslinux/isolinux.bin $(TEMP_CD_TREE) cp /usr/lib/syslinux/vesamenu.c32 $(TEMP_CD_TREE) + if [ -e /usr/lib/syslinux/ldlinux.c32 ]; then \ + cp /usr/lib/syslinux/ldlinux.c32 $(TEMP_CD_TREE); \ + cp /usr/lib/syslinux/libcom32.c32 $(TEMP_CD_TREE); \ + cp /usr/lib/syslinux/libutil.c32 $(TEMP_CD_TREE); \ + fi; \ $(foreach file,$(wildcard boot/x86/*.txt), \ cat $(file) | \ @@ -338,6 +347,11 @@ arch_netboot_dir: x86_syslinux mkdir -p $(TEMP_NETBOOT_DIR)/$(NETBOOT_PATH)/pxelinux.cfg mkdir -p $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR) cp /usr/lib/syslinux/vesamenu.c32 $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR) + if [ -e /usr/lib/syslinux/ldlinux.c32 ]; then \ + cp /usr/lib/syslinux/ldlinux.c32 $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR); \ + cp /usr/lib/syslinux/libcom32.c32 $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR); \ + cp /usr/lib/syslinux/libutil.c32 $(TEMP_NETBOOT_DIR)/$(BOOT_SCREEN_DIR); \ + fi; \ [ $(BOOTMENU_BEEP) = y ] beep=$$(printf '\a'); \ $(foreach file,$(shell syslinux-cfgs $(TEMP_SYSLINUX)), \
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 12:55 AM, Don Armstrong wrote: Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] jftr, i never did nor intended to ask for having syslinux 5 in wheezy. what i care about is having it in unstable (for reasons said earlier). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511278ef.1030...@progress-technologies.net
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Sun, 2 Dec 2012 23:47:37 + Roger Leigh rle...@codelibre.net wrote: Please don't apply it just yet--we'll presumably need to get approval from the release team to change this in initscripts at the same time. I'll have a patch for initscripts shortly; might be a bit later in the week to allow for comprehensive testing. What’s the status on this? It’s been 2 months :-). Thanks! -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206165904.77ef5...@midna.rag.lan
Bug#694928: asks for confirmation on config-file change on /etc/default/rcS, while file didn't change
On Wed, Feb 06, 2013 at 04:59:04PM +0100, Michael Stapelberg wrote: On Sun, 2 Dec 2012 23:47:37 + Roger Leigh rle...@codelibre.net wrote: Please don't apply it just yet--we'll presumably need to get approval from the release team to change this in initscripts at the same time. I'll have a patch for initscripts shortly; might be a bit later in the week to allow for comprehensive testing. What’s the status on this? It’s been 2 months :-). I did send a mail to -release a week or so back, but haven't seen a response yet. Doing the change in initscripts is fairly trivial, but introducing a configuration file change at this point is probably not a great idea. If it's needed, I'll be happy to do it though. While editing a conffile isn't a good idea in general, the actual impact here is very low, and it's limited to ARM users, so if the consensus is that it's ignorable for wheezy, I'll be equally happy to postpone this for jessie and we can do the needed changes early in the jessie release cycle. Bottom line: I'll be happy to do whatever is needed. Just need some feedback on what is acceptable here. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206163445.ga21...@codelibre.net
Bug#699742: syslinux 5.x support
Hi, On 06.02.2013 16:36, Daniel Baumann wrote: On 02/05/2013 09:33 PM, Michael Biebl wrote: I tried this patch against cc123e0 from debian-installer git. Unfortunately the problem is still the same. indeed; only the first part of the patch was attached; here's the complete one. I can confirm that this patch works now. Thanks. That said, if the intention is not to have syslinux 5.0 in wheezy, I can understand adsb's concern, if the initial 7.0 release will use 5.01 and point releases later on syslinux from wheezy, i.e. 4.05. That sounds like an unwise thing to do. But then, I'm neither a member of the release team nor the installer team, so I best shut up at this point. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 10:38 AM, Daniel Baumann wrote: On 02/06/2013 12:55 AM, Don Armstrong wrote: Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] jftr, i never did nor intended to ask for having syslinux 5 in wheezy. what i care about is having it in unstable (for reasons said earlier). Well, the d-i development is happening in sid. Therefore, this upload disrupted the development process of syslinux dependent d-i components that have to end up, but are not yet in wheezy. Milan signature.asc Description: OpenPGP digital signature
Re: [d-i manual] Deactivate translations?
On Sun, Feb 03, 2013 at 06:38:08PM +0100, Christian PERRIER wrote: ca catalan hasn't receive any updates since the release of Squeeze / AND catalan is an xml based translation, what means that the translation stays the same even if there are changings in en! 52 files are not up-to-date ATM IMHO this translation should be deactivated for official builds! I agree it should be de-activated, but maybe try to CC debian-l10n-catalan, which is a quite busy list, while Guillem and Jordi are less involved in translations nowadays. So, how hard would it be to convert this thing into a po-based translation? Jordi -- Jordi Mallach Pérez -- Debian developer http://www.debian.org/ jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ GnuPG public key information available at http://oskuro.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206183607.gc30...@aigua.oskuro.net
POSTA CERTIFICATA: Fwd: Photos
--Questo è un Messaggio di Posta Certificata-- Il giorno 06/02/2013 alle ore 19:42:30 (+0100) il messaggio con Oggetto Fwd: Photos è stato inviato dal mittente marco.salom...@pec.it e indirizzato a: debian-boot@lists.debian.org Il messaggio originale è incluso in allegato, per aprirlo cliccare sul file postacert.eml (nella webmail o in alcuni client di posta l'allegato potrebbe avere come nome l'oggetto del messaggio originale). L'allegato daticert.xml contiene informazioni di servizio sulla trasmissione L'identificativo univoco di questo messaggio è: opec271.20130206194230.09313.04.2...@pec.aruba.it daticert.xml Description: XML document ---BeginMessage--- Hello, as pwomised your photos here http://gor.roshoster.com/gallery.htm---End Message--- smime.p7s Description: S/MIME cryptographic signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Tue, 05 Feb 2013, Julien Cristau wrote: - the latest of these uploads breaks the installer, making it impossible to build and upload the planned wheezy release candidate, since build-dependencies are fetched from unstable - when asked to revert this change, the syslinux maintainer refused, and said disagreements should be referred to the technical committee Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] Don Armstrong 0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#40 -- [Panama, 1989. The U.S. government called it Operation Just Cause.] I think they misspelled this. Shouldn't it be Operation Just 'Cause? -- TekPolitik http://slashdot.org/comments.pl?sid=59669cid=5664907 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206204100.gd17...@rzlab.ucr.edu
Re: [d-i manual] Deactivate translations?
Hi, Jordi Mallach jo...@debian.org wrote: On Sun, Feb 03, 2013 at 06:38:08PM +0100, Christian PERRIER wrote: ca catalan hasn't receive any updates since the release of Squeeze / AND catalan is an xml based translation, what means that the translation stays the same even if there are changings in en! 52 files are not up-to-date ATM IMHO this translation should be deactivated for official builds! I agree it should be de-activated, but maybe try to CC debian-l10n-catalan, which is a quite busy list, while Guillem and Jordi are less involved in translations nowadays. So, how hard would it be to convert this thing into a po-based translation? I am in private contact with Innocent De Marchi, who has mailed me because of my mail to debian-l10n-catalan. He has had similar ideas. But according to ../manual/doc/translations_po.txt we need a 100% complete translation for an automatic convertion from xml to po format. And a convertion by hand can only be done by someone, who is a native Catalan speaker IMHO. Probably Innocent wants to go that way... Holger -- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Created with Sylpheed 3.0.2 under D e b i a n G N U / L I N U X 6.0 ( S q u e e z e ) Registered LinuxUser #311290 - http://linuxcounter.net/ = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206214555.32c6169f.li...@wansing-online.de
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I believe this has even been made explicit in release-team updates, although I haven't gone back and checked the exact wording. I concur with Daniel and with Anthony that it does feel like a deficiency in our tools that we don't have a way to distinguish wheezy-targeted packages from post-wheezy development and build wheezy-targeted packages with the build dependencies that will be released with wheezy. If we had such a thing, I think it would save the release team some time, since it would limit the problems caused by uncoordinated library transitions during the release freeze. I also concur with Daniel that it can make development during the release freeze rather annoying when there are multiple branches of upstream that one wants to follow, since we only have one other archive available for packages that aren't eligible for release. But, well, that's the architecture we have right now and we're clearly not going to fix it immediately. Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. That does take over experimental for that purpose, but, well, there's always personal repositories; that's what I sometimes do when there are more branches of development to juggle than there is space in Debian. It's annoying, and we need better tools, but it's possible. In the longer term, I think it would be interesting to provide some more metadata and automation around the whole release request/unblock/build process than we have right now. For example, I could see some use in a system where one has to explicitly tag a package as being targeted for the next release or not targeted for the next release, which could be communicated to the buildds in some fashion so that they would build release-targeted packages against only the release-targeted packages, and new uploads of release-targeted packages would be automatically diffed and brought to the release team's attention. There could even be a convention for including the justification for the change. (I can see a lot of complexity here in how one would have to set up the archive suites, since you can't just point the buildds at testing since there would be no way to stage library transitions that *are* going into the release, so let me note that this is not a well-thought-out proposal, just the sketch of an idea.) But that's all outside the scope of tech-ctte deliberation, since that's technical design, and regardless isn't something that we would do right now. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vca5rvyu@windlord.stanford.edu
Bug#699742: syslinux 5.x support
On 06.02.2013 17:48, Michael Biebl wrote: Hi, On 06.02.2013 16:36, Daniel Baumann wrote: On 02/05/2013 09:33 PM, Michael Biebl wrote: I tried this patch against cc123e0 from debian-installer git. Unfortunately the problem is still the same. indeed; only the first part of the patch was attached; here's the complete one. I can confirm that this patch works now. Thanks. I have to correct myself: While the bootloader now does show up (when trying an installation in VBOX), and I no longer get the error message about the missing ldlinux.c32 file, it hangs after selecting the Install option. The screen just stays black. This didn't happen with syslinux 4. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Wed, 06 Feb 2013, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. Yeah, that was for the first incomplete patch. I was referring to the second one. Don Armstrong -- Let us chat together a moment, my friend. There are still several hours until dawn, and I have the whole day to sleep. -- Count Orlock in _Nosferatu (1922)_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013020624.gf17...@rzlab.ucr.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Russ Allbery r...@debian.org writes: In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. I agree that we need to bring this current situation to closure quickly so that the RC1 build of d-i for wheezy can proceed. We seem to have three options: patch d-i to build successfully against the syslinux in sid wiggle the d-i build processing to fetch syslinux from testing (re-)upload the previous syslinux version with a new epoch The first requires a patch that actually works, and there is at least one assertion that the patch Daniel pointed to does not. The second I can't speak to the complexity of since the last time I looked at d-i was just before the last stable release. The third is easy to accomplish but requires agreement from the maintainer or a TC vote to overrule him. I'm relatively unavailable for the next 24 hours. Hopefully by then further investigation and/or discussion will help make it clear which of the above options we should pursue. Bdale pgpy9AV6WD5V5.pgp Description: PGP signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee bd...@gag.com writes: I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! Yes. This is pretty much exactly how I feel. And I suspect it's a general feeling by a lot of people: we freeze for too long, and we don't like a lot of the implications of that, but we don't know how to do better and get releases out faster because there's a truly intimidating amount of work that has to get done to do the release and all the alternatives seem to make the work even worse. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3qlqdrq@windlord.stanford.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 06.02.2013 23:22, Don Armstrong wrote: On Wed, 06 Feb 2013, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. Yeah, that was for the first incomplete patch. I was referring to the second one. Unfortunately the second patch doesn't work either. See [1]. Cheers, Michael [1] https://lists.debian.org/debian-boot/2013/02/msg00115.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... Why should that source package be special? Yes, it's cumbersome, it needs many uploads, if only because we need kernel fixes and improvements, along with fixes for its 100+ components. I'm happy to consider improvements to the process when we have time for that, meaning not 8 months into the freeze, but I'd be happy to receive an answer to the above question. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! I concur. I agree that we need to bring this current situation to closure quickly so that the RC1 build of d-i for wheezy can proceed. We seem to have three options: patch d-i to build successfully against the syslinux in sid And chase all regressions between syslinux 4 and 5? I'd rather not do that, especially given how tested and working patches are failing to deliver. Over the last few months on the d-i front, we've had 1 alpha, 4 betas; we would be throwing away the testing efforts of those 5 releases! wiggle the d-i build processing to fetch syslinux from testing See above question, why should we special-case this build-dependency? (re-)upload the previous syslinux version with a new epoch I don't see a better solution than this one. On a personal note, I'm unsure how we came up with a situation where a single maintainer can *actively* stall a release… Not caring about the release process put into place years ago is a thing. Stopping people from fixing problems created by such carelessness is another one… Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Cyril Brulebois k...@debian.org writes: Bdale Garbee bd...@gag.com (06/02/2013): I personally consider this a regrettable situation, and hope that for jessie and beyond we can work out how to do this better. It is unacceptable to me to freeze anything in sid for more than a week or two at a time. Holding d-i's build dependencies static in unstable for more than half a year is just nuts to me! How is that different from e.g. refraining to upload new libraries to unstable, so that a package needing an upload (say, we need RC bugfixes) doesn't pick new dependencies (on libraries not in testing)? I personally think it's exactly the same problem. I think the situation with libraries is regrettable as well. (Note that, and I'm guessing I speak for Bdale here too, regrettable is not intended to assign any sort of blame! This is the best solution that we've been able to come up with to date as a project. It's just still has some problems.) That's how testing works; and it's been this way for years/releases now (since testing replaced frozen, I think). Yes. It's always a source of some tension, since there are always people who would prefer to have a place to continue to do development in an unstable context even during the release process. (Cue the standard debate over the usability of experimental for this purpose -- I'm sure nearly everyone reading this can fill it in from memory. *grin*) If we could find a way to release some of that tension, that would be great, but it's a hard problem, and there's no way that we're going to come up with a solution to it right now in the middle of the wheezy freeze. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq0dx6xk@windlord.stanford.edu
rfc: growlight as d-i partman replacement
Hello! Last summer, I was hoping to add ZFS support to the Debian installer. After playing around with partman a week or two, I ended up developing an entirely new application, growlight [0]. It is currently used in the SprezzOS installer [1], and has been used by a small, ZoL-intensive user base for several months (since ZoL 0.6.0-rc11 days). It has had open bugtracking [2] and git-based source control [3] since its first commit. I'd like to sound out the list on replacing partman in d-i proper with Growlight. I'm sure there's some use cases I've missed that partman handles, etc (for one, preseeding is not yet at all supported by growlight. then again, it was never very pleasant with partman, either). --Known shortcomings of growlight vs partman-- (1) No preseed support currently (2) Fullscreen ncurses UI diverges from the rest of the whiptail-based installer, though IMHO it's much more attractive (see screenshots at [1] to see what I'm talking about) (3) No support for guided partitioning, but I plan to do that soon (4) No online filesystem resizing yet (soon! [4]) (5) Probably misses some details that partman has accumulated over the years --Known benefits of growlight vs partman-- (1) ZoL (ZFS on Linux) support (2) Full knowledge and handling of alignment issues (3) Much more information available (4) Much more attractive (5) Fully dynamic UI in the face of device removal/addition (6) More functionality than partman (secure erase, smart, temp, etc) (7) One binary with coherent data model vs a bunch of scripts The SprezzOS installer is based on d-i, and growlight runs as a udeb from main-menu just as partman does. Here's the current postinst script [5], just to illustrate how I break the fullscreen UI out from main-menu: --- #!/bin/sh export LANG=C.UTF-8 TARGET=/target # Load ZFS so that growlight's loading of libzfs doesn't do it, prompting a # (potentially confusing) message to stderr. modprobe zfs # Load relevant MD modules, as they aren't typically autoloaded modprobe md-mod modprobe raid0 modprobe raid1 modprobe raid456 # Ensure the target mountpoint exists mkdir -p $TARGET # Ensure /dev/ entries exist, until we start monitoring for them at least FIXME mkdir /dev/md /dev/disk/by-path # -w: wait for process, then switch back to controlling terminal # -s: switch to new vt on launch # -v: verbose. someone might switch back to this vt purposefully; hopefully # this will kinda indicate what's going on. openvt -v -w -s -- fbvfbterm /usr/share/sprezzatech/sprezzos.png \ growlight-curses -i -t $TARGET --disphelp --- This leaves main-menu on VT1 in a blue screen, which is less elegant than I'd like, but otherwise I ran into console integrity problems of an unpleasant nature. I believe Growlight, suitably modified to implement all of partman's feature set, could serve as a well-engineered, powerful replacement for the venerable but creaky partman. I'm interested in helping make this happen, if it's at all feasible. Please take a look at the screenshots, design, and code, and let me know your thoughts. Thanks! --rigorously, nick Hacker-In-Charge, SprezzOS Project [0] http://nick-black.com/dankwiki/index.php/Growlight [1] ~20 screenshots: https://plus.google.com/photos/118364511747568235669/albums/5841122304857060513 [2] https://www.sprezzatech.com/bugs/buglist.cgi?component=Growlight [3] https://github.com/dankamongmen/growlight [4] https://www.sprezzatech.com/bugs/show_bug.cgi?id=411 [5] https://github.com/dankamongmen/sprezzos-world/blob/master/packaging/growlight/debian/growlight-udeb.postinst -- nick black http://www.sprezzatech.com -- unix and hpc consulting to make an apple pie from scratch, you need first invent a universe. signature.asc Description: Digital signature
Re: rfc: growlight as d-i partman replacement
Quoting nick black (nick.bl...@sprezzatech.com): Hello! Last summer, I was hoping to add ZFS support to the Debian installer. After playing around with partman a week or two, I ended up developing an entirely new application, growlight [0]. It is currently used in the SprezzOS installer [1], and has been used by a small, ZoL-intensive user base for several months (since ZoL 0.6.0-rc11 days). It has had open bugtracking [2] and git-based source control [3] since its first commit. .../... I'd like to followup on your suggestion as it seems well thought and prepared and not just one idea thrown in the wild as I was initially thinking (sorry for this). It would thus be a shame that you don't get any followup, whic hwould be likely to happen. You have well identified the difficulty in abandoning partman. The main problem is probably that partman is well modular and makes it easy to throw in some new fliesystem support (it seems this is not as easy as it seems, though, as you ended up in developing something else for ZFS support). It is quite easy, though to push for your proposal : develop growlight and the udebs it produces in the D-I infrastructure, eventually provide D-I images that use it instead of partmanand we'll see if people adhere to it. After all, the modular structure of D-I makes it easy to replace one component by another. However, given that most of what remains of the D-I team is now focused on the wheezy release, it is likely that you do'nt get much feedback in the beginning. But, eh, this is about all what we have to propose, I guess..:-) signature.asc Description: Digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511349f2.4010...@progress-technologies.net
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
07.02.2013 10:30, Daniel Baumann wrote: On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). This makes me wonder what other components are also buggy somehow and needs to be updated? How many (old) hardware machines has something similar too? And how much more testing we need to declare that everything we use is compatible? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51134b42.7030...@msgid.tls.msk.ru
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 07:30, Daniel Baumann wrote: On 02/06/2013 11:48 PM, Michael Biebl wrote: Unfortunately the second patch doesn't work either. See [1]. that is incorrect; the patch works, it's just the old vbox version in current debian testing/sid which has a bug (try the image on real hardware or any other virtualization and it works). Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:35 AM, Michael Tokarev wrote: This makes me wonder what other components are also buggy somehow and needs to be updated? first, this is a specific bug in vbox that was fixed some time ago but didn't make it into debian yet (because it lags a significant amount of upstream releases behind; and yes, i should and will fill a bug about it at some later point). How many (old) hardware machines has something similar too? And how much more testing we need to declare that everything we use is compatible? second, if you follow the bug, it's affecting sid and doesn't affect wheezy release images - they will have the same tested and working syslinux version that has proven to be stable during d-i alpha/beta images (unless i'm missing something and d-i *release* images are built with sid packages as well, in which case i personally would consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51134f1d.3070...@progress-technologies.net
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:45 AM, Michael Biebl wrote: Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. again, the syslinux in sid would not be in wheezy. making it a *temporary* problem until vbox has been fixed in debian (which i'm happy to NMU again, will look to cherry-pick the required patch later today). -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51135093.7070...@progress-technologies.net
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 07:58, Daniel Baumann wrote: On 02/07/2013 07:45 AM, Michael Biebl wrote: Well, VBOX is pretty popular, so shipping an installer which doesn't work for such an environment is certainly a no-go. again, the syslinux in sid would not be in wheezy. making it a *temporary* problem until vbox has been fixed in debian (which i'm happy to NMU again, will look to cherry-pick the required patch later today). I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 07:55 AM, Michael Biebl wrote: I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. 'obvious'? it requires two straight forward things, that, again, as said, are required to be applied for jessie anyway, and are wherey much desired to be applied on the wheezy source (to build images with syslinux backports): * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 and fixing one temporary breakage in vbox for convenience: * cherry-pick upstream commit to fix a bug in vbox not more, not less. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51135263.3090...@progress-technologies.net
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
sorry, forgot to put in the links to the patches.. On 02/07/2013 08:06 AM, Daniel Baumann wrote: * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699884#20 -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/511353a0.3090...@progress-technologies.net
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 08:06, Daniel Baumann wrote: On 02/07/2013 07:55 AM, Michael Biebl wrote: I think it is obvious by now that reverting to syslinux 4 from wheezy is the only sensible way forward at this point in the release. 'obvious'? Imho, yes. But then, it's not up to me to decide. * patch applied against debian-installer to include the additionally required .c32 modules when using vesamenu.c32 * patch applied against debian-cd to include the additionally required .c32 modules when using vesamenu.c32 * cherry-pick upstream commit to fix a bug in vbox This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. While I can understand (from personal experience) that freeze-time is sometimes frustrating, delaying the release even further doesn't help anyone. If we want to improve our procedures, how we handle d-i, freeze etc, now is not the time to discuss/work on this. Just my 2¢ Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 08:12 AM, Michael Biebl wrote: This list is getting longer with each email. Seeing that syslinux 5 has been in sid for less then 10 days, I'm worried what other issues might show up. apart from the two obvious things (debian-installer and debian-cd) that do need to be updated to copy in the additionally required c32 modules when using vesamenu.c32, there's only vbox broken. while i can see that one is inclined to jump to the conclusion that now each and every package in debian needs an update, it really isn't so. no package is directly interacting with a bootloader, except those that create images (debian-installer, debian-cd), or boot images *and* have bugs fixed-upstream-long-time-ago-but-not-in-debian (vbox). again, note that any other virtualization software, be it in wheezy directly (qemu, kvm) or otherwise (parallels, vmware) which i've tested with, has no bugs with syslinux 5. it's an isolated thing that vbox still has that bug in debian. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5113581b.3020...@progress-technologies.net
