Re: Fwd: Fw: Re: Fw: Re: debian-installer: call to update translations - Greek
Hi all, Apologies for the delay, it's a very busy period. Regarding bootloader, there is actually a translation for that "εκκινητής συστήματος", which is a common term even between amongst other Other OSes. It's up to the translator, most people I know will definitely make the connection with "bootloader", but there are some that might not. That does not apply to every term, some terms must not be translated, eg. compilation, even though there is a -totally unknown to the average user- term : "συμπίληση". That's why a technical text translation is not something that can be automated easily. I agree with Christian, it is all a matter of perspective, if you cater only to the tech-savvy people, then there is no need to translate anything, but if you want to target the average user -yes, even my mother who does not want/cannot afford Windows- then it should be something that she would at least be able to read. I hope that was helpful. Regards Konstantinos Στις 16-11-2017, ημέρα Πεμ, και ώρα 23:47 +, ο/η Sotirios Vrachas έγραψε: > And I am forwarding this to Kostas > > Also, I've subscribed to the mailing list in order to keep the "Fw: > Re: > Fw: Re:" to a minimum. > > Sotiri > > Forwarded Message > Subject: Fw: Re: Fw: Re: debian-installer: call to update > translations - > Greek > Date: Thu, 16 Nov 2017 23:37:34 +0100 > From: Holger Wansing > To: debian-boot > CC: Sotirios Vrachas > > I'm forwarding this info to Sotirios, so that he can ask Kostas. > > Holger > > > > > Date: Thu, 16 Nov 2017 06:36:15 +0100 > From: Christian PERRIER > To: debian-boot@lists.debian.org > Subject: Re: Fw: Re: debian-installer: call to update translations - > Greek > > > Quoting Holger Levsen (hol...@layer-acht.org): > > On Wed, Nov 15, 2017 at 08:50:00PM +, Sotirios Vrachas wrote: > > > More of standardization issue, if it can be considered an issue > > > at all. > > > For example, do we translate "Bootloader"? > > > > if "bootloader" were translated to German I would not understand > > the > > translation. Same for internet, proxy, email, and many many other > > things. > > > > So this is not a Greek problem. (Just that some languages are more > > affected by this than others.) > > > > In the end this is up to the translation team though. > > > Definitely. > > The key here is being consistent with what is done elsewhere in the > free software l10n world. > > You know about the reputation of the French l10n teams to translate > everything. It is indeed because this practice is now established all > over the free software ecosystem. > For other languages, the established practice is to keep English > words > for technical terms. Even though I do not agree with that (it > enforces the idea that technical terms are to be used by technical > people only while my localization work is made for the average random > person in the street), I think it's a matter of local culture. > > But, please always always always remember what I used to put in all > my > l10n talks : "not every sysadmin in the world speaks and understands > English..this is a very biased view to think that". And if not > every sysadmin is more comfortable in her own lmanguage, think about > the average user. > > For Greek translaiton, I'd recommend talking to Kostas Margaritis. He > did the initial work and know what he's talking about. > > > > > >
Re: Bug#880123: jessie-pu: package syslinux/3:6.03+dfsg-5+deb8u1
Control: tags -1 + pending On Sat, 2017-11-18 at 19:10 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2017-10-29 at 19:48 +0100, Lukas Schwaighofer wrote: > > I hereby ask for permission to update the syslinux package in > > jessie > > as > > well. The update fixes a bug in the isolinux isohybrid MBR causing > > boot > > failures with some old BIOS [1]. > > > > Please go ahead. Uploaded and flagged for acceptance. Regards, Adam
Processed: Re: Bug#882177: busybox: unzip creates world-writable directories
Processing commands for cont...@bugs.debian.org: > tags 882175 confirmed upstream Bug #882175 [busybox] busybox: out-of-bounds read in get_header_ar() Added tag(s) confirmed and upstream. > tags 882177 confirmed upstream Bug #882177 [busybox] busybox: unzip creates world-writable directories Added tag(s) upstream and confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 882175: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882175 882177: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882177 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#882177: busybox: unzip creates world-writable directories
tags 882175 confirmed upstream tags 882177 confirmed upstream thanks Jakub Wilk wrote... > Adding forgotten attachment... Thanks, was already able to reproduce without that one. Christoph signature.asc Description: Digital signature
Bug#882177: busybox: unzip creates world-writable directories
Package: busybox Version: 1:1.27.2-1 Tags: security When busybox's unzip creates a directory that is not shipped directly in the zip file, it makes the directory world-writable: $ zipinfo moo.zip Archive: moo.zip Zip file size: 112 bytes, number of entries: 1 -rw-r--r-- 3.0 unx0 b- stor 17-Nov-19 22:51 moo/moo 1 file, 0 bytes uncompressed, 0 bytes compressed: 0.0% $ busybox unzip moo.zip Archive: moo.zip inflating: moo/moo $ ls -ld moo drwxrwxrwx 2 jwilk users 4096 Nov 19 22:03 moo -- System Information: Architecture: i386 Versions of packages busybox depends on: ii libc6 2.25-1 -- Jakub Wilk
Bug#882175: busybox: out-of-bounds read in get_header_ar()
Package: busybox Version: 1:1.27.2-1 Apparently an out-of-bounds read can happen when unpacking ar archives: $ valgrind -q -- busybox ar p oob.ar > /dev/null ==2180== Invalid read of size 1 ==2180==at 0x4831403: __GI_strlen (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2180==by 0x48B9F5A: strdup (strdup.c:41) ==2180==by 0x1108BC: xstrdup (xfuncs_printf.c:81) ==2180==by 0x15C560: get_header_ar (get_header_ar.c:116) ==2180==by 0x15C26F: unpack_ar_archive (unpack_ar_archive.c:20) ==2180==by 0x14D956: ar_main (ar.c:291) ==2180==by 0x10F788: run_applet_no_and_exit (appletlib.c:916) ==2180==by 0x10FA50: run_applet_and_exit (appletlib.c:934) ==2180==by 0x10FA38: busybox_main (appletlib.c:875) ==2180==by 0x10FA38: run_applet_and_exit (appletlib.c:927) ==2180==by 0x10FADC: main (appletlib.c:1032) ==2180== Address 0x4a0715c is 0 bytes after a block of size 4 alloc'd ==2180==at 0x482E2BC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2180==by 0x110847: xmalloc (xfuncs_printf.c:47) ==2180==by 0x15C4A0: get_header_ar (get_header_ar.c:86) ==2180==by 0x15C26F: unpack_ar_archive (unpack_ar_archive.c:20) ==2180==by 0x14D956: ar_main (ar.c:291) ==2180==by 0x10F788: run_applet_no_and_exit (appletlib.c:916) ==2180==by 0x10FA50: run_applet_and_exit (appletlib.c:934) ==2180==by 0x10FA38: busybox_main (appletlib.c:875) ==2180==by 0x10FA38: run_applet_and_exit (appletlib.c:927) ==2180==by 0x10FADC: main (appletlib.c:1032) ... Found using American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ -- System Information: Architecture: i386 Versions of packages busybox depends on: ii libc6 2.25-1 -- Jakub Wilk oob.ar Description: Binary data
Re: Easier installer?
On Sun, Nov 19, 2017 at 07:51:24PM +0100, Samuel Thibault wrote: > Wouter Verhelst, on dim. 19 nov. 2017 19:27:16 +0100, wrote: > > On Sun, Nov 19, 2017 at 04:31:21PM +0100, Samuel Thibault wrote: > > > Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote: > > > > - That would require that at least part of the functionality that's > > > > already implemented in the other udeb (e.g., asking for username etc) > > > > be duplicated into the proposed new udeb. That seems like a waste. > > > > > > But the idea was precisely to reshape that question, to make it more > > > beginner-friendly. > > > > We can reshape questions reglardless of whether we implement the > > overview screen that I'm talking about. > > I believe there is a misunderstanding: I'm not saying that the existing > questions should be modified. I'm saying that the way questions should > be asked in the overview screen that you propose is very different from > the existing questions (basically they'll be extremely simple). And thus > it's not a duplication, since they'll be completely different. Mmm. I'm not sure that's actually true, but that's orthogonal to the point. > I agree that implementing the overview screen is a much faster step > to have something that doesn't frighten beginners away, rather than > rephrasing our existing questions yet another time. I was really not > suggesting the latter. Right. I'll see if I can find the time to have a stab at trying to come up with something that would work. We can then decide what to do with the actual questions that get asked from the overview screen later :-) -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Easier installer?
Wouter Verhelst, on dim. 19 nov. 2017 19:27:16 +0100, wrote: > On Sun, Nov 19, 2017 at 04:31:21PM +0100, Samuel Thibault wrote: > > Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote: > > > - That would require that at least part of the functionality that's > > > already implemented in the other udeb (e.g., asking for username etc) > > > be duplicated into the proposed new udeb. That seems like a waste. > > > > But the idea was precisely to reshape that question, to make it more > > beginner-friendly. > > We can reshape questions reglardless of whether we implement the > overview screen that I'm talking about. I believe there is a misunderstanding: I'm not saying that the existing questions should be modified. I'm saying that the way questions should be asked in the overview screen that you propose is very different from the existing questions (basically they'll be extremely simple). And thus it's not a duplication, since they'll be completely different. I agree that implementing the overview screen is a much faster step to have something that doesn't frighten beginners away, rather than rephrasing our existing questions yet another time. I was really not suggesting the latter. Samuel
Re: Easier installer?
On Sun, Nov 19, 2017 at 04:31:21PM +0100, Samuel Thibault wrote: > Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote: > > - That would require that at least part of the functionality that's > > already implemented in the other udeb (e.g., asking for username etc) > > be duplicated into the proposed new udeb. That seems like a waste. > > But the idea was precisely to reshape that question, to make it more > beginner-friendly. We can reshape questions reglardless of whether we implement the overview screen that I'm talking about. Even if we don't implement the overview screen, that would still be a step forward IMO. But in my opinion, the killer feature in anaconda (Fedora's installer) is not the way they present one particular bit of functionality, but the way in which they present all their questions in a single screen. That means having an overview screen, which to me is the higher priority. If you disagree, I won't stop you from reworking the user creation questions (there might be some room for improvement there), it's just that to me we'll take a larger step forward if we implement the overview screen. > > - It would necessarily be somewhat limiting > > That's the idea of making a beginner frontend :) True. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
libdebian-installer_0.112_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 19 Nov 2017 18:12:25 +0100 Source: libdebian-installer Binary: libdebian-installer4 libdebian-installer4-dev libdebian-installer4-udeb libdebian-installer-extra4 libdebian-installer-extra4-udeb Architecture: source Version: 0.112 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Aurelien Jarno Description: libdebian-installer-extra4 - Library of some extra debian-installer functions libdebian-installer-extra4-udeb - Library of some extra debian-installer functions (udeb) libdebian-installer4 - Library of common debian-installer functions libdebian-installer4-dev - Library of common debian-installer functions libdebian-installer4-udeb - Library of common debian-installer functions (udeb) Closes: 861598 882089 Changes: libdebian-installer (0.112) unstable; urgency=medium . [ Reiner Herrmann ] * src/exec.c: Include poll.h instead of sys/poll.h. Closes: #861598. . [ Helmut Grohne ] * Fix FTBFS with gcc-8: Mark di_parser_fieldinfo constants extern. Closes: #881932. . [ Aurelien Jarno ] * src/system/devfs.c: include instead of . Closes: #882089. Checksums-Sha1: fd56700aca959a06304b099c11f1f33f9cbf4540 libdebian-installer_0.112.dsc 3f7d6116200a737ceba5cb6a93fb6914833085fd 71236 libdebian-installer_0.112.tar.xz 9088c8f182b9a4636e6637f2046b3050e4e96c17 5536 libdebian-installer_0.112_source.buildinfo Checksums-Sha256: 736d19f6bfef7565232980669ec0f18fd884b3907e4ed0058c5b47d354a85623 libdebian-installer_0.112.dsc ab4f90b68404b1cd142eaa1a794b780a906c7adb75477625e0e3eaafedba61b9 71236 libdebian-installer_0.112.tar.xz 5b7ddcc09b0f1e4a47dba11dc04d6ab2ce9c4554e2e3ea31bdd7c87643151f6c 5536 libdebian-installer_0.112_source.buildinfo Files: d05dc5a8262cb6d4436b3ec7c615c11c libs optional libdebian-installer_0.112.dsc 8a57da737873ece271231c8c04b2dec1 71236 libs optional libdebian-installer_0.112.tar.xz a3be505cc4e2d675654ef3a7dadbd67b 5536 libs optional libdebian-installer_0.112_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEd0YmQqnvlP0Pdxltupx4Bh3djJsFAloRu68ACgkQupx4Bh3d jJsqCxAAi6hrWhujGubW+OYSIAfga9r7uEkhxGlGZqnRphXcQ++bx7E4/TS+H3WE lC2nYdhU9PtulPXKrgoAznz5SHKuYp4qpoOwCKXDxi6dX5qrTQc967s02QyduicS BOhIfdjZ4r4cSE0oSwhvxEmLPgcJs22/Jb2187D8w16lOuvz+dvaUojicjjti50G Xy8ciQRXE6V+Xd2yf/9i8ti5deCiCx7oKtN5Hr+oKEBjhnrkbJ1vUaRGzTmY7RpA MJ3v8v7CVVrCWZaFVQ1IRTi3dpZEgBwXu9MaCd1Qmgjyw/o9t3cpc5doa6M9UZQc cPqh9yBVuhNQUhiTur1LNXKb6acaV6bCJggwG9sPztEw71/Dc+zZYaPdUqg66oOB 1qOMwrk86S5ofrRNdDjUrKM1FJjwZYvW+zCL4Hxi7gFKGngkE6qzUt53QCZHQPh7 E1GyJWrCmoVuytuOT4yffHgTxX62maPju1zgRVAZ0+Z4EKJIT7SO5CU4B3R7u8aY eWA898P446hk2057EFfNCx6p/5MczJc4ras9J3521waL3HgOzQgdQJyg6znBrEqh 4YqFAxwWRgaoRmslAIlFQQH56Qg4mNe+uXe76kDlAPSiM611wRuft/+TRkz9oyts VAChdKLVFiZJSCle6SJ3Y+0M0q5W4BCFijRfWSxcNybBFZXV+1s= =QU39 -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#881932: marked as done (libdebian-installer FTBFS with gcc-8: multiple definitions of)
Your message dated Sun, 19 Nov 2017 18:41:07 +0100 with message-id <20171119174107.43ba4sj4mu5n5...@aurel32.net> and subject line Re: Bug#881932: libdebian-installer FTBFS with gcc-8: multiple definitions of has caused the Debian Bug report #881932, regarding libdebian-installer FTBFS with gcc-8: multiple definitions of 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.) -- 881932: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881932 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: libdebian-installer Version: 0.111 Tags: patch User: helm...@debian.org Usertags: rebootstrap libdebian-installer fails to build from source when built with gcc-8. It seems gcc-8 has become more strict in terms of multiple defined constants. As it happens, libdebian-installer defines constants of type di_parser_fieldinfo both in headers and C files. As the headers get included into multiple translation units, the constants are duplicated. I believe that the solution is to mark them extern in the headers. Since they are still defined (with values) in the C files that'll not make them go missing. Please consider applying the attached patch. Once gcc-8 becomes the default, this bug will become serious. I would like to thank James Clarke for helping me gain an understanding of the issue at hand. Consider the patch joint work. Helmut diff --minimal -Nru libdebian-installer-0.111/debian/changelog libdebian-installer-0.111+nmu1/debian/changelog --- libdebian-installer-0.111/debian/changelog 2017-06-25 18:42:05.0 +0200 +++ libdebian-installer-0.111+nmu1/debian/changelog 2017-11-16 17:48:06.0 +0100 @@ -1,3 +1,11 @@ +libdebian-installer (0.111+nmu1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS with gcc-8: Mark di_parser_fieldinfo constants extern. +(Closes: #-1) + + -- Helmut Grohne Thu, 16 Nov 2017 17:48:06 +0100 + libdebian-installer (0.111) unstable; urgency=medium [ Aurelien Jarno ] diff --minimal -Nru libdebian-installer-0.111/include/debian-installer/package_internal.h libdebian-installer-0.111+nmu1/include/debian-installer/package_internal.h --- libdebian-installer-0.111/include/debian-installer/package_internal.h 2017-06-24 19:14:56.0 +0200 +++ libdebian-installer-0.111+nmu1/include/debian-installer/package_internal.h 2017-11-16 17:48:04.0 +0100 @@ -33,7 +33,7 @@ * @internal * parser info */ -const di_parser_fieldinfo +extern const di_parser_fieldinfo internal_di_package_parser_field_status, internal_di_package_parser_field_essential, internal_di_package_parser_field_priority, diff --minimal -Nru libdebian-installer-0.111/include/debian-installer/packages_internal.h libdebian-installer-0.111+nmu1/include/debian-installer/packages_internal.h --- libdebian-installer-0.111/include/debian-installer/packages_internal.h 2012-10-20 13:07:58.0 +0200 +++ libdebian-installer-0.111+nmu1/include/debian-installer/packages_internal.h 2017-11-16 17:48:06.0 +0100 @@ -84,7 +84,7 @@ di_parser_write_entry_next internal_di_packages_parser_write_entry_next; -const di_parser_fieldinfo +extern const di_parser_fieldinfo internal_di_packages_parser_field_package; /** @} */ --- End Message --- --- Begin Message --- Version: 0.112 On 2017-11-16 19:11, Helmut Grohne wrote: > Source: libdebian-installer > Version: 0.111 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > libdebian-installer fails to build from source when built with gcc-8. It > seems gcc-8 has become more strict in terms of multiple defined > constants. As it happens, libdebian-installer defines constants of type > di_parser_fieldinfo both in headers and C files. As the headers get > included into multiple translation units, the constants are duplicated. > > I believe that the solution is to mark them extern in the headers. Since > they are still defined (with values) in the C files that'll not make > them go missing. Please consider applying the attached patch. > > Once gcc-8 becomes the default, this bug will become serious. > > I would like to thank James Clarke for helping me gain an understanding > of the issue at hand. Consider the patch joint work. > > Helmut This was fixed in version 0.112, but hasn't been closed automatically due to a non-breakable space which ended up in the changelog... Closing it manually. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net--- End Message ---
Processing of libdebian-installer_0.112_source.changes
libdebian-installer_0.112_source.changes uploaded successfully to localhost along with the files: libdebian-installer_0.112.dsc libdebian-installer_0.112.tar.xz libdebian-installer_0.112_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#861598: marked as done (libdebian-installer: please use POSIX-compliant poll.h header)
Your message dated Sun, 19 Nov 2017 17:34:57 + with message-id and subject line Bug#861598: fixed in libdebian-installer 0.112 has caused the Debian Bug report #861598, regarding libdebian-installer: please use POSIX-compliant poll.h header 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.) -- 861598: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861598 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: libdebian-installer Version: 0.110 Severity: wishlist Tags: patch Hi, Helmut Grohne noticed that libdebian-installer fails to build with musl, because it builds with -Werror and includes sys/poll.h, which triggers a warning in musl, as it is not the POSIX-specified location. Regards, Reiner From 45b5e23eb54a7da2da3d98af9732c89ff6d6304c Mon Sep 17 00:00:00 2001 From: Reiner Herrmann Date: Mon, 1 May 2017 11:14:11 +0200 Subject: [PATCH] Include poll.h instead of sys/poll.h --- src/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/exec.c b/src/exec.c index b435063..2815bbd 100644 --- a/src/exec.c +++ b/src/exec.c @@ -25,10 +25,10 @@ #include #include +#include #include #include #include -#include #include #include #include -- 2.11.0 signature.asc Description: PGP signature --- End Message --- --- Begin Message --- Source: libdebian-installer Source-Version: 0.112 We believe that the bug you reported is fixed in the latest version of libdebian-installer, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 861...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Aurelien Jarno (supplier of updated libdebian-installer package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 19 Nov 2017 18:12:25 +0100 Source: libdebian-installer Binary: libdebian-installer4 libdebian-installer4-dev libdebian-installer4-udeb libdebian-installer-extra4 libdebian-installer-extra4-udeb Architecture: source Version: 0.112 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Aurelien Jarno Description: libdebian-installer-extra4 - Library of some extra debian-installer functions libdebian-installer-extra4-udeb - Library of some extra debian-installer functions (udeb) libdebian-installer4 - Library of common debian-installer functions libdebian-installer4-dev - Library of common debian-installer functions libdebian-installer4-udeb - Library of common debian-installer functions (udeb) Closes: 861598 882089 Changes: libdebian-installer (0.112) unstable; urgency=medium . [ Reiner Herrmann ] * src/exec.c: Include poll.h instead of sys/poll.h. Closes: #861598. . [ Helmut Grohne ] * Fix FTBFS with gcc-8: Mark di_parser_fieldinfo constants extern. Closes: #881932. . [ Aurelien Jarno ] * src/system/devfs.c: include instead of . Closes: #882089. Checksums-Sha1: fd56700aca959a06304b099c11f1f33f9cbf4540 libdebian-installer_0.112.dsc 3f7d6116200a737ceba5cb6a93fb6914833085fd 71236 libdebian-installer_0.112.tar.xz 9088c8f182b9a4636e6637f2046b3050e4e96c17 5536 libdebian-installer_0.112_source.buildinfo Checksums-Sha256: 736d19f6bfef7565232980669ec0f18fd884b3907e4ed0058c5b47d354a85623 libdebian-installer_0.112.dsc ab4f90b68404b1cd142eaa1a794b780a906c7adb75477625e0e3eaafedba61b9 71236 libdebian-installer_0.112.tar.xz 5b7ddcc09b0f1e4a47dba11dc04d6ab2ce9c4554e2e3ea31bdd7c87643151f6c 5536 libdebian-installer_0.112_source.buildinfo Files: d05dc5a8262cb6d4436b3ec7c615c11c libs optional libdebian-installer_0.112.dsc 8a57da737873ece271231c8c04b2dec1 71236 libs optional libdebian-installer_0.112.tar.xz a3be505cc4e2d675654ef3a7dadbd67b 5536 libs optional libdebian-installer_0.112_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEd0YmQqnvlP0Pdxltupx4Bh3djJsFAloRu68ACgkQupx4Bh3d jJsqCxAAi6hrWhujGubW+OYSIAfga9r7uEkhxGlGZqnRphXcQ++bx7E4/TS+H3WE lC2nYdhU9PtulPXKrgoAznz5SHKuYp4qpoOwCKXDxi6dX5qrTQc967s02QyduicS BOhIfdjZ4r4cSE0oSwhvxEmLPgcJs22/Jb2187D8w16lOuvz+dvaUojicjjti50G Xy8ciQRXE6V+Xd2yf/9i8ti5deCiCx7oKtN5Hr+oKEBjhnrkbJ1vUaRGzTmY7RpA MJ3v8v7CVVrCWZaFVQ1IRTi3dpZEgBwXu
Bug#882089: marked as done (libdebian-installer FTBFS since glibc 2.25)
Your message dated Sun, 19 Nov 2017 17:34:57 +
with message-id
and subject line Bug#882089: fixed in libdebian-installer 0.112
has caused the Debian Bug report #882089,
regarding libdebian-installer FTBFS since glibc 2.25
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.)
--
882089: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882089
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libdebian-installer
Version: 0.111
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: helm...@debian.org
Usertags: rebootstrap
| make[5]: Entering directory '/<>/build/src/system'
| /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../../src/system -I../../../include -I../../ -Wdate-time
-D_FORTIFY_SOURCE=2 -Wall -W -Werror -ggdb -Wmissing-declarations -Os
-fomit-frame-pointer -c -o devfs.lo ../../../src/system/devfs.c
| libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../src/system
-I../../../include -I../../ -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -W -Werror
-ggdb -Wmissing-declarations -Os -fomit-frame-pointer -c
../../../src/system/devfs.c -fPIC -DPIC -o .libs/devfs.o
| ../../../src/system/devfs.c: In function 'di_system_devfs_map_from':
| ../../../src/system/devfs.c:127:13: error: In the GNU C Library, "major" is
defined
| by . For historical compatibility, it is
| currently defined by as well, but we plan to
| remove this soon. To use "major", include
| directly. If you did not intend to use a system-defined macro
| "major", you should undefine it after including . [-Werror]
| if (major (s.st_rdev) == e->major &&
| ^~~~
| ../../../src/system/devfs.c:128:13: error: In the GNU C Library, "minor" is
defined
| by . For historical compatibility, it is
| currently defined by as well, but we plan to
| remove this soon. To use "minor", include
| directly. If you did not intend to use a system-defined macro
| "minor", you should undefine it after including . [-Werror]
| ((e->type == ENTRY_TYPE_ONE && minor (s.st_rdev) == e->minor) ||
| ^~~~
| ../../../src/system/devfs.c:129:13: error: In the GNU C Library, "minor" is
defined
| by . For historical compatibility, it is
| currently defined by as well, but we plan to
| remove this soon. To use "minor", include
| directly. If you did not intend to use a system-defined macro
| "minor", you should undefine it after including . [-Werror]
| (e->type != ENTRY_TYPE_ONE && minor (s.st_rdev) >= e->minor))) {
| ^
| ../../../src/system/devfs.c:151:13: error: In the GNU C Library, "minor" is
defined
| by . For historical compatibility, it is
| currently defined by as well, but we plan to
| remove this soon. To use "minor", include
| directly. If you did not intend to use a system-defined macro
| "minor", you should undefine it after including . [-Werror]
|disc = minor (s.st_rdev) - e->minor + e->entry_first;
| ^~~
| ../../../src/system/devfs.c:159:13: error: In the GNU C Library, "minor" is
defined
| by . For historical compatibility, it is
|
Bug#858159: Chinese homepage not updated properly?
Control: unarchive 569136 Control: reopen 569136 I forgot to sent the mail to the BTS as well... Holger Wansing wrote: > Control: unarchive 569136 > Control: reopen 569136 > > > Laura Arjona Reina wrote: > > Hello > > > > I've had a look at this and made some tests, I didn't arrive to any > > conclusions but I'll write here what I've found, for the case it rings a > > bell for somebody: > > > > * The chinese/security/dsa-zh-*.rdf files are generated automatically > > when a new security file is published, but the > > chinese/security/index.zh-*.html are not re-generated (nor the general > > homepage) > > > > * The chinese/security/index.zh-*.html files were generated on Nov 13th, > > same date as the chinese/templates.zh.po were updated. I guess that the > > dependency triggered the rebuild of these, the homepage, and many other > > files. > > > > * I have removed the html files and ran "make" to generate them > > manually. Then ran "make install", I guess that with the next website > > rebuild the files will be copied through mirrors and the Chinese > > webpages (index and security/index) will show the updated list of > > security advisories. > > > > I've had a look at /english/Makefile and /english/security/Makefile and > > I see that specific code to generate zh variants is written for the > > generation of some files (sitemap, search, the rdf files in security...) > > but not for the corresponding "index" files. Maybe specific code should > > be written in order to get those files generated properly, but frankly I > > don't know why are they generated well, if I just remove the html files, > > and run "make"... > > Please note, that this is a longstanding issue. > > I remembered there was a bugreport on this, but I couldn't find it. > Then I found it, it has been closed in August 2017. It's here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569136 > > So, this has been closed in error. > Thus, I'm reopening it. > > Simon Paillard stated there, that the complicated Makefiles for Chinese > are the point ... > > Holger -- Created with Sylpheed 3.5.1 under D E B I A N L I N U X 9 " S T R E T C H " . Registered Linux User #311290 - https://linuxcounter.net/
Re: Easier installer?
Wouter Verhelst, on dim. 19 nov. 2017 16:12:13 +0100, wrote: > - That would require that at least part of the functionality that's > already implemented in the other udeb (e.g., asking for username etc) > be duplicated into the proposed new udeb. That seems like a waste. But the idea was precisely to reshape that question, to make it more beginner-friendly. > - It would necessarily be somewhat limiting That's the idea of making a beginner frontend :) Samuel
Upcoming oldstable point release
Hi, The next point release for "jessie" (8.10) is scheduled for Saturday, December 9th. Processing of new uploads into jessie-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Upcoming stable point release
Hi, The next point release for "stretch" (9.3) is scheduled for Saturday, December 9th. Processing of new uploads into stretch-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: Easier installer?
On Sun, Nov 19, 2017 at 03:15:08PM +0100, Samuel Thibault wrote: > Hello, > > Wouter Verhelst, on dim. 19 nov. 2017 15:03:03 +0100, wrote: > > - Selecting a particular option in the overview screen causes the > > installer to configure the selected udeb, as though it was selected > > from the main menu. > > Mmm, do we really need to actually configure the udeb? The way I see > it, the overview screen would merely preseed debconf, and that's it. That is another option, and I did consider it, but I see a few downsides: - That would require that at least part of the functionality that's already implemented in the other udeb (e.g., asking for username etc) be duplicated into the proposed new udeb. That seems like a waste. - It would result in two parts that would need to be kept in sync. - It would necessarily be somewhat limiting As such, my train of thought was that it would be better to have the bit that asks questions be shipped with the other udeb. Since that other udeb will already have an implementation of "asking questions," and since that implementation is called by configuring the other udeb, that seems like the most straightforward way to get things rolling. I do think it might be useful to revisit some of those other udebs in light of the fact that they would be called from the overview screen, and optimize them a bit for that, but that doesn't necessarily have to be part of a first implementation. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Easier installer?
Hello, Wouter Verhelst, on dim. 19 nov. 2017 15:03:03 +0100, wrote: > - Selecting a particular option in the overview screen causes the > installer to configure the selected udeb, as though it was selected > from the main menu. Mmm, do we really need to actually configure the udeb? The way I see it, the overview screen would merely preseed debconf, and that's it. Samuel
Re: Easier installer?
On Thu, Nov 16, 2017 at 01:17:47PM +0100, Samuel Thibault wrote: > Wouter Verhelst, on jeu. 16 nov. 2017 12:53:16 +0100, wrote: [...] > > since, in essence, we'd just be providing an alternate UI to the same > > installer, people who need some of the more advanced options can ditch > > the hand-holding UI and switch to the advanced UI. We could add a > > button "skip this screen" to make that easier, if needs be. > > That actually triggers me another thought: the installers you are > talking about ask basically the same set of questions, not so much > less. The main difference is that they are asked together in a dialog > box. I can understand that this can be less stressing for inexperienced > users: it's easier to leave things as defaults when it's all preset in a > dialog box and you just click "ok" than when one has to answer questions > one after the other, which can be stressing. > > I can understand that *that* can make a difference, and that could be > implemented indeed, to preseed the rest of questions. The difficult part > is to make sure that all such questions will be preseeded. So, I've been thinking about how we could implement something like this without requiring what in essense would be a rewrite of d-i, and this is what I came up with: - Create a new udeb for an overview screen, and make it show up early in main-menu so it gets run "fairly early"[1]. - In that overview screen, show the status of the "most important"[1] settings. Make these populated by files that are written by the particular udebs, similar to how partman populates its main menu. - Allow those udebs that are shown in the overview screen to also set a flag file which causes their option in that screen to be marked as "confirmation required". You cannot confirm the overview screen until none of its options have the "confirmation required" flag set. - Selecting a particular option in the overview screen causes the installer to configure the selected udeb, as though it was selected from the main menu. - Once the user confirms the overview screen, set the debconf priority to critical and quit successfully. The installation is handed over to main-menu, which will now run normally without asking any questions (unless an error occurs). - If the user selects the option "skip this screen", do not touch the debconf priority and quit successfully. The installation is handed over to main-menu, which will now run normally, asking questions as before. [1] what consists "fairly early" and "most important" are implementational details that can be fine-tuned later on and are not important for this discussion. With that plan, the only changes that would be required would be to: - Implement the required logic behind the overview screen. Much of this could be copied from main-menu - Make sure that the "skip this screen" option can be easily preseeded, so that preseeding still works. - Modify the relevant udebs so they write their status and optionally an "update required" flag file in the right location for the overview screen Everything else would function as before. In a first implementation, this would already be quite some improvement I think. In addition, I also think it would be beneficial if we were to add another type of debconf template that could be used by that overview screen instead of the "select" template that we use now for main-menu and partman-base, and which would allow for a more modern and shinier type of user interface. It could also be used by partman, then. This can be implemented later, however. Thoughts? -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Easier installer?
> On Sun, 19 Nov 2017 11:56:35 +0100, Thomas Lange > said: > JFTR, I just look at an openSuse Tumbleweed installation. They are > using a world map for selecting the timezone. And Linux Mint is showing a world map with timezones, but no country borders. -- regards Thomas
Re: Easier installer?
JFTR, I just look at an openSuse Tumbleweed installation. They are using a world map for selecting the timezone. -- regards Thomas
Re: Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]
Hi, intrigeri: > Update: the next upload of the linux-image packages will "Recommends: > apparmor" > (https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid&id=bd1e10f8bd85adf182f122417a843bf6ffbac80c) This happened. > … so it might be that we don't need "Priority: standard" in the end. Indeed, I think we don't need it ⇒ case closed, and sorry for the noise. Cheers, -- intrigeri
