Bug#782574: installation-reports: d-i does not boot on beaglebone black
On Wed, 2015-04-15 at 23:39 +0200, Cyril Brulebois wrote: > Karsten Merker (2015-04-15): > > On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: > > > Did some troubleshooting (far more than I expected, now I remember > > > why I hadn't already done this for BBB), and came up with a patch > > > for u-boot that makes it work with d-i by emulating some distro > > > bootcmd variables (similar to the patch for wandboard), and a small > > > patch to flash kernel to support the change in how the "bootpart" > > > variable is used. > > Since Karsten mentions both have to reach jessie in lockstep, I'm > wondering whether there should be a Breaks: somewhere to avoid some > breakages in case of a partial update. > > > > I've tested that it boots the armhf daily hd-media installer and > > > boots an installed system. I could upload a new version of u-boot if > > > it's deemed worth it; otherwise we'll just need more complicated > > > instructions for manually loading the installer on d-i. FWIW, The > > > netboot media via tftp works without any changes. > > > > > > If the user ever used u-boot's "saveenv" command, it may take > > > considerable effort resetting the environment using "env default -a" > > > followed by manually setting board_name, findfdt and/or fdtfile > > > variables so that it detects the correct .dtb. I didn't have > > > consistant success zeroing out the boot device, but in theory that > > > should work too. > > > > I had hoped to be able to spend some more time on the issue > > today, but things didn't work out as planned and as things are > > looking curently, I probably won't be able to dedicate time to it > > tomorrow as well. > > > > As the deadline for d-i-relevant changes is Friday, the question > > is what to do now. AFAICS due to the necessity to change the BBB > > boot script in flash-kernel when the patch is applied to u-boot, > > both flash-kernel and u-boot would have to enter Jessie in > > lockstep. As there is not enough time for regular migration to > > Jessie, the release team would have to urgent both packages in > > addition to an unblock to keep the deadline. The involved DDs > > are in vastly different timezones, which makes all this even more > > problematic. As stated above, I probably won't be able to take > > care of flash-kernel in time, so unless Ian would like to handle > > that, I do not see a a realistic chance to get this solved for > > Jessie. > > > > Ian, what is your take on the issue? > > So I've been thinking about this for a while and I'm not too happy about > possibly rushing these changes at this point. What could be considered > instead is having these changes staged into unstable, let them migrate > to testing/stretch when the freeze is lifted, and possibly backport them > in to the jessie first point release. A workaround can be documented in > the D-I Jessie RC3 errata. > > Would that seem reasonable to all people involved? Yes, IIRC from the thread the workaround is pretty simple, certainly in comparison with the scope of the proposed changes. Ian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1429168841.5660.42.ca...@debian.org
Bug#782683: installation-reports: installing of GNU\Hurd with crosshurd, the package libparted0debian1 is not supported
Control: reassign -1 crosshurd thanks -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150416083207.gk3...@type.youpi.perso.aquilenet.fr
Processed: Re: Bug#782683: installation-reports: installing of GNU\Hurd with crosshurd, the package libparted0debian1 is not supported
Processing control commands: > reassign -1 crosshurd Bug #782683 [installation-reports] installation-reports: installing of GNU\Hurd with crosshurd, the package libparted0debian1 is not supported Bug reassigned from package 'installation-reports' to 'crosshurd'. Ignoring request to alter found versions of bug #782683 to the same values previously set Ignoring request to alter fixed versions of bug #782683 to the same values previously set -- 782683: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782683 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b782683.142917313219027.transcr...@bugs.debian.org
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
(Cc: debian-boot@ added.) Martin Pitt (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
Re: Bug#782712: pre-upload unblock request: systemd/215-17 for RC bug #751707
Martin Pitt (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
Re: 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#782731: debian-installer: hangs after network configuration with dhcpv6
Package: debian-installer Version: debian-jessie-DI-rc2-amd64-netinst.iso Severity: important Dear Maintainer, the installation hung indefinitely with a blue screen after dhcp configuration of ipv6 and ipv4. Analyzing the situation showed that dhcp6c was the blocking process. After killing that process, installation proceeded without a problem. I found this problem with several machines with rc1 and rc2 installer. Yours Christoph -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55301b1b.4070...@uni-mainz.de
Bug#782731: marked as done (debian-installer: hangs after network configuration with dhcpv6)
Your message dated Thu, 16 Apr 2015 22:40:44 +0200 with message-id <20150416204044.gf1...@mraw.org> and subject line Re: Bug#782731: debian-installer: hangs after network configuration with dhcpv6 has caused the Debian Bug report #782731, regarding debian-installer: hangs after network configuration with dhcpv6 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.) -- 782731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-installer Version: debian-jessie-DI-rc2-amd64-netinst.iso Severity: important Dear Maintainer, the installation hung indefinitely with a blue screen after dhcp configuration of ipv6 and ipv4. Analyzing the situation showed that dhcp6c was the blocking process. After killing that process, installation proceeded without a problem. I found this problem with several machines with rc1 and rc2 installer. Yours Christoph -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi Christoph, Christoph Martin (2015-04-16): > Package: debian-installer > Version: debian-jessie-DI-rc2-amd64-netinst.iso > Severity: important > > Dear Maintainer, > > the installation hung indefinitely with a blue screen after dhcp > configuration > of ipv6 and ipv4. > > Analyzing the situation showed that dhcp6c was the blocking process. > > After killing that process, installation proceeded without a problem. > > I found this problem with several machines with rc1 and rc2 installer. This is indeed a known issue, documented on the errata page: https://www.debian.org/devel/debian-installer/errata Mraw, KiBi. signature.asc Description: Digital signature --- End Message ---
Re: 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
Re: 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 (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-boot-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#782574: installation-reports: d-i does not boot on beaglebone black
Le 16/04/2015 09:20, Ian Campbell a écrit : > On Wed, 2015-04-15 at 23:39 +0200, Cyril Brulebois wrote: >> Karsten Merker (2015-04-15): >>> On Tue, Apr 14, 2015 at 06:42:57PM -0700, Vagrant Cascadian wrote: Did some troubleshooting (far more than I expected, now I remember why I hadn't already done this for BBB), and came up with a patch for u-boot that makes it work with d-i by emulating some distro bootcmd variables (similar to the patch for wandboard), and a small patch to flash kernel to support the change in how the "bootpart" variable is used. >> >> Since Karsten mentions both have to reach jessie in lockstep, I'm >> wondering whether there should be a Breaks: somewhere to avoid some >> breakages in case of a partial update. >> I've tested that it boots the armhf daily hd-media installer and boots an installed system. I could upload a new version of u-boot if it's deemed worth it; otherwise we'll just need more complicated instructions for manually loading the installer on d-i. FWIW, The netboot media via tftp works without any changes. If the user ever used u-boot's "saveenv" command, it may take considerable effort resetting the environment using "env default -a" followed by manually setting board_name, findfdt and/or fdtfile variables so that it detects the correct .dtb. I didn't have consistant success zeroing out the boot device, but in theory that should work too. >>> >>> I had hoped to be able to spend some more time on the issue >>> today, but things didn't work out as planned and as things are >>> looking curently, I probably won't be able to dedicate time to it >>> tomorrow as well. >>> >>> As the deadline for d-i-relevant changes is Friday, the question >>> is what to do now. AFAICS due to the necessity to change the BBB >>> boot script in flash-kernel when the patch is applied to u-boot, >>> both flash-kernel and u-boot would have to enter Jessie in >>> lockstep. As there is not enough time for regular migration to >>> Jessie, the release team would have to urgent both packages in >>> addition to an unblock to keep the deadline. The involved DDs >>> are in vastly different timezones, which makes all this even more >>> problematic. As stated above, I probably won't be able to take >>> care of flash-kernel in time, so unless Ian would like to handle >>> that, I do not see a a realistic chance to get this solved for >>> Jessie. >>> >>> Ian, what is your take on the issue? >> >> So I've been thinking about this for a while and I'm not too happy about >> possibly rushing these changes at this point. What could be considered >> instead is having these changes staged into unstable, let them migrate >> to testing/stretch when the freeze is lifted, and possibly backport them >> in to the jessie first point release. A workaround can be documented in >> the D-I Jessie RC3 errata. >> >> Would that seem reasonable to all people involved? > > Yes, IIRC from the thread the workaround is pretty simple, certainly in > comparison with the scope of the proposed changes. As far as I'm involved, I comfirm that the workaround is simple and could easily be documented. If needed, I could help documenting the it. -- François-Régis -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55302fbf.4060...@miradou.com
Bug#234470: Online Arbeitsagentur Angebote 2015 für Sie
Lieber Bewerber, die Arbeitsvermittlung stellt Ihnen nachfolgend eine interessante Stelle in einem internationalen Team von zu Hause aus vor, ohne Fahrtkosten, ohne Anfahrt, ohne Stau: Wir bieten qualifizierte und moderne Stellen auch in ländlichen Regionen im ganzen europäischen Raum und bieten gleichzeitig exzellente Qualität für unsere Kunden. Zur Erweiterung unseres Teams suchen wir ab sofort: Mitarbeiter (m/w) für den Support im Home Office in der Abteilung Office und Kommunikation Ihre Aufgaben wären: - Dokumente empfangen, bearbeiten und weiterleiten - Dokumente kopieren/einscannen - Emails bearbeiten - Arbeit im Home Office in freien Zeiteinteilung - Umgang mit zur Verfügung gestellten Systemen Anforderungen an Sie: - Unproblematischer Umgang mit Email, PC und Internet - Deutsch fließend, Fremdsprachen wären vorteilhaft - kundenorientiertes Teamwork - Genauigkeit und Zielstrebigkeit Wir bieten Ihnen einen Arbeitsplatz als Festangestellter oder als Freiberufler mit einem Stundenlohn von 20 € Brutto pro Stunde in eigenverantwortlichen Arbeitsweise und einer modernen Beschäftigungsform, sowie eine abwechslungsreiche Tätigkeit ohne Arbeitsweg mit flexiblen Arbeitszeiten. Es werden keine fachlichen Kenntnisse vorausgesetzt. Die Einarbeitung findet detailliert durch professionelle Mitarbeiten statt. Die benötigte technische Ausstattung stellen wir Ihnen ohne weitere Kosten zur Verfügung. Die Arbeitsstelle kann gerne nebenberuflich aufgenommen werden sowie von Rentnern und Hausfrauen. Sie sind bereit für flexible Arbeitszeitmodelle und die Arbeit im Home-office? Wenn wir Ihr Interesse geweckt haben, senden Sie uns Ihre Bewerbung per E-Mail an: alleneln...@rocketship.com Ihre persönlichen Unterlagen behandeln wir vertraulich. Es grüßt Sie Ihre Lorenz LTD -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/01081df0.165043d734a37c5a@ordi1
Processed: Re: Bug#782673: installation-guide: doesn't notice errors within the for loop
Processing control commands: > tags -1 + pending Bug #782673 [src:installation-guide] installation-guide: doesn't notice errors within the for loop Added tag(s) pending. -- 782673: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782673 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b.142923065524445.transcr...@bugs.debian.org
Processed: Re: Bug#782673: installation-guide: doesn't notice errors within the for loop
Processing control commands: > tags -1 + pending Bug #782673 [src:installation-guide] installation-guide: doesn't notice errors within the for loop Ignoring request to alter tags of bug #782673 to the same tags previously set -- 782673: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782673 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b782673.142923065524454.transcr...@bugs.debian.org
Bug#782673: installation-guide: doesn't notice errors within the for loop
Control: tags -1 + pending Cyril Brulebois, le Thu 16 Apr 2015 00:47:28 +0200, a écrit : > Samuel mentioned errors aren't recorded in the for loop, and have that > bug report on his todolist. Ok, it wasn't in the for loop, but close enough :), it was indeed the move of the code to the Makefile, I forgot to also include the set -e from the beginning of build.sh, now fixed. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417003051.gl3...@type.youpi.perso.aquilenet.fr
Please avoid trivial changes in the manual
Hello, Thanks a lot for helping with the installation manual, but please understand that the more changes we make in the manual, the less translated it will be. Very recently we added documentation for ppc64el and arm64, and while it'd have been better to add them earlier so they get a chance to get translated, it's strictly better than nothing to add them late. Changes to existing documentation are often however actually *worse* than nothing, since unless translators have the time to translate the changes, those part of the manual will become untranslated! (for po translations, i.e. almost all). So when doing changes, please consider that. Some changes such as command lines, device names etc. can actually be easily applied in all languages, so it is fine to do it *provided that you do the propagation of the change in all languages yourself*. If you don't propagate the changes to all languages, there is a quite strong chance that the translators will not have the time to do the propagation before the release. Also, doing the change in all languages at the same time is way easier than for a translator to figure out what small thing has changed and unfuzzy po files after they have been fmtmerged... The more we do things like this, the more tired translators become, and the less translated our manual gets, and the less users will read it. If somebody could take the time to unfuzzy the u-boot -> U-Boot change, that'd be very helpful for languages which already have a translation. Thanks again for considering, Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417015859.gn3...@type.youpi.perso.aquilenet.fr
Re: Bug#780573: release-notes: Review from the d-i team
On 2015-04-11 08:07, Baptiste Jammet wrote: > Hello, > > Dixit Niels Thykier, le 16/03/2015 : > >> I am contacting you to do a final review of the release-notes for the >> d-i related topics (as listed on [1]): > > Here are some items I think it's important to highlight, taken from d-i > release announces. > I tried to clean the page a bit and mark some old stuff as wheezy. > Please review because I'm not a native english, and I surely forgot > some important changes. > > Baptiste > > P.S. diff against installing.dbk r10511 > Thanks, I have applied the patch mostly as-is (though dropping most of the Wheezy-only items) and followed up with a new patch on top. I tried to ask in #debian-i18n about the new languages, but so far no one has replied me. I am a bit overbooked, so if any you have time to follow on that, then I would greatly appreciate it. If there are further changes, please by all means let me know. Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5530ab45.3080...@thykier.net
