Bug#730059: busybox-syslogd conflicts with systemd
Package: busybox-syslogd Version: 1:1.22.0-6 Followup-For: Bug #730059 In fact busybox-syslogd is the *only* package with Provides: klogd the others seem to Provides: linux-kernel-log-daemon I don't understand why this is the case. Does the difference signify a different interface, or is it just an oversight? The point is probably moot since journalctl replaces it, but couldn't the busybox-syslogd init script say if pid1 is systemd, start syslogd but not klogd ? -- 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/20140911054931.9562.61712.reportbug@frey
Processing of hw-detect_1.102_amd64.changes
hw-detect_1.102_amd64.changes uploaded successfully to localhost along with the files: hw-detect_1.102_amd64.udeb ethdetect_1.102_all.udeb disk-detect_1.102_all.udeb driver-injection-disk-detect_1.102_all.udeb archdetect_1.102_amd64.udeb hw-detect_1.102.dsc hw-detect_1.102.tar.xz Greetings, Your Debian queue daemon (running on host franck.debian.org) -- 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/e1xry1c-0002fu...@franck.debian.org
Processed: reassign 761135 to archdetect
Processing commands for cont...@bugs.debian.org: reassign 761135 archdetect 1.100.0.exp.1 Bug #761135 [debian-installer] archdetect: package rename/package-type change breaks d-i builds Bug reassigned from package 'debian-installer' to 'archdetect'. No longer marked as found in versions debian-installer/20140802. Ignoring request to alter fixed versions of bug #761135 to the same values previously set Bug #761135 [archdetect] archdetect: package rename/package-type change breaks d-i builds Marked as found in versions hw-detect/1.100.0.exp.1. thanks Stopping processing here. Please contact me if you need assistance. -- 761135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761135 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.c.14104176606526.transcr...@bugs.debian.org
hw-detect_1.102_amd64.changes is NEW
binary:archdetect is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html -- 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/e1xrybv-000373...@franck.debian.org
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
[Cyril Brulebois] Of course a failing d-i build means src:debian-installer FTBFS. What else would that be? Thanks for asking. To me, it could also mean a failing to build a ISO with d-i udebs on it. But I had already tested ISO builds, and thus was a bit unsure what was failing for you. Please explain how you managed to build installation images with a failing d-i build. The ISO build system understand and handle the provides header, and the ISO build is working as before the deb was introduced, as can be seen on for example URL: http://lists.alioth.debian.org/pipermail/debian-edu-commits/2014-September/008537.html . I'm not sure why you're insisting on the renaming. Please explain why you did that (see my first follow-up). Somehow I get the impression that you do not really want to understand why I did this change but just want a set of arguments to brush off before reverting it, but I hope it is just a language barrier issue. Anyway, here are the explanation why I introduced a archdetect deb and how the change have been tested so far. * A archdetect deb allow users on installed systems to figure out which kernel the installer want to install on a given machine. * The need for a normal deb for archdetect have been on the TODO list for years, see for example debian-installer/doc/TODO listing this entry in the Post-etch goals list: - real deb from archdetect udeb (luther) * The deb was already present in Ubuntu, under the name archdetect-deb. Adding the deb in Debian can reduce the diff with Ubuntu. * We normally in Debian name udebs with a -udeb postfix, and name packages after the binary they contain. Diverting from this common naming scheme should be avoided. This I decided to use the sensible name for the deb in Debian, and switch the udeb to have the name we commonly use for udebs in debian, package-udeb. * I knew d-i (anna-install and the rest of the d-i installation system) would handle the provides header, and tested this on a fresh install in a virtual machine before commiting the change. * I checked how many udebs were depending on archdetect (6, if I recall correctly), and new they would cope just fine with the change. * Knew the Debian archive would handle the rename, as udebs and debs have different name spaces, and we use the provides method with several library udebs already. So the change was tested and the installer was working as it should also after the rename. The only thing I didn't test was building the debian-installer source package itself, which broke as you correctly observed. The simple fix is to replace archdetect with archdetect-udeb, but a more proper fix is probably to teach the build of d-i initrds to understand the provides header, to ensure similar issues do not arise in the future. The simple fix is in look like this (commits 50506fe7643ecf44ccc388dab04e3c7fba085dcd and 9925e98994c4406b616e21d9db2703eca5b6ce32) in the debian-installer git repo: diff --git a/debian/changelog b/debian/changelog index a6d89a2..f732bcc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -29,6 +29,10 @@ debian-installer (2014) UNRELEASED; urgency=low - raise the xorriso build dependency to = 1.3.2-1~ on these architectures, for compatibility with grub-mkrescue in GRUB 2.02 + [ Petter Reinholdtsen ] + * Adjust package lists to cope with the archdetect-archdetect-udeb +rename, and remove the rename item from the TODO (Closes: #761135). + -- Cyril Brulebois k...@debian.org Sat, 02 Aug 2014 02:59:35 +0200 debian-installer (20140802) unstable; urgency=low diff --git a/build/pkg-lists/base b/build/pkg-lists/base index 4650288..12c66e2 100644 --- a/build/pkg-lists/base +++ b/build/pkg-lists/base @@ -2,7 +2,7 @@ # get them. busybox-udeb anna -archdetect +archdetect-udeb cdebconf-udeb cdebconf-priority di-utils diff --git a/build/pkg-lists/cdrom/m68k.cfg b/build/pkg-lists/cdrom/m68k.cfg index 61d6947..5ef5b33 100644 --- a/build/pkg-lists/cdrom/m68k.cfg +++ b/build/pkg-lists/cdrom/m68k.cfg @@ -7,4 +7,4 @@ console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-udeb kbd-udeb -archdetect +archdetect-udeb diff --git a/build/pkg-lists/hd-media/m68k.cfg b/build/pkg-lists/hd-media/m68k.cfg index d9c75bb..0b61609 100644 --- a/build/pkg-lists/hd-media/m68k.cfg +++ b/build/pkg-lists/hd-media/m68k.cfg @@ -5,4 +5,4 @@ console-setup-amiga-ekmap console-setup-ataritt-ekmap console-setup-udeb kbd-udeb -archdetect +archdetect-udeb diff --git a/doc/TODO b/doc/TODO index ed6167b..f73f37e 100644 --- a/doc/TODO +++ b/doc/TODO @@ -147,7 +147,6 @@ Post-etch goals - low(er) mem (zboob) - uml for testing d-i (anton) - post reboot network configuration (cjwatson) - - real deb from archdetect udeb (luther) - integrate selinux installation into the installer, for a painless install (joeyh/manoj?) - add a xen server task (joeyh)
Processed: tagging 761135
Processing commands for cont...@bugs.debian.org: # in NEW again tags 761135 + pending Bug #761135 [archdetect] archdetect: package rename/package-type change breaks d-i builds Added tag(s) pending. thanks Stopping processing here. Please contact me if you need assistance. -- 761135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761135 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.c.141041894915166.transcr...@bugs.debian.org
Bug#760712: WEP vs WPA2
With this installation I was using WPA2-Personal at the access point. I see the log messages look similar as in bug #741622, deauthenticating immediately after connect. For a later install on the same computer, also to USB target, I used WEP in the installer to connect to the access point (installation report #761148). So possibly the problem has to do with WPA2 as opposed to WEP. -- 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/cao299fvp970app22gegx4ev9qw9g8thwf3mdfz6drrfyy6n...@mail.gmail.com
Bug#760712: WEP vs WPA2
Hi Chris! Chris Tillman toff.till...@gmail.com (2014-09-11): With this installation I was using WPA2-Personal at the access point. I see the log messages look similar as in bug #741622, deauthenticating immediately after connect. For a later install on the same computer, also to USB target, I used WEP in the installer to connect to the access point (installation report #761148). So possibly the problem has to do with WPA2 as opposed to WEP. That's an interesting data point, thank you! (That reminds me I haven't yet submitted an installation report… the wireless part wasn't OK either.) Mraw, KiBi. signature.asc Description: Digital signature
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
Petter Reinholdtsen p...@hungry.com (2014-09-11): [Cyril Brulebois] Of course a failing d-i build means src:debian-installer FTBFS. What else would that be? Thanks for asking. To me, it could also mean a failing to build a ISO with d-i udebs on it. But I had already tested ISO builds, and thus was a bit unsure what was failing for you. That might be some kind of language barrier issue as you mentioned, but when I write “d-i build”, it's really about building d-i. If I want to talk about a cd/dvd/iso build, I write “cd/dvd/iso build”. Please explain how you managed to build installation images with a failing d-i build. The ISO build system understand and handle the provides header, and the ISO build is working as before the deb was introduced, as can be seen on for example URL: http://lists.alioth.debian.org/pipermail/debian-edu-commits/2014-September/008537.html . ACK. I'm not sure why you're insisting on the renaming. Please explain why you did that (see my first follow-up). Somehow I get the impression that you do not really want to understand why I did this change but just want a set of arguments to brush off before reverting it, but I hope it is just a language barrier issue. Certainly a communication problem somwhere since I'm asking about the *renaming* part, and you're talking about the whole changeset. Anyway, here are the explanation why I introduced a archdetect deb and how the change have been tested so far. * A archdetect deb allow users on installed systems to figure out which kernel the installer want to install on a given machine. * The need for a normal deb for archdetect have been on the TODO list for years, see for example debian-installer/doc/TODO listing this entry in the Post-etch goals list: - real deb from archdetect udeb (luther) This is the part I'm talking about: ,--- | * The deb was already present in Ubuntu, under the name | archdetect-deb. Adding the deb in Debian can reduce the diff with | Ubuntu. | * We normally in Debian name udebs with a -udeb postfix, and name | packages after the binary they contain. Diverting from this common | naming scheme should be avoided. This I decided to use the | sensible name for the deb in Debian, and switch the udeb to have | the name we commonly use for udebs in debian, package-udeb. `--- * I knew d-i (anna-install and the rest of the d-i installation system) would handle the provides header, and tested this on a fresh install in a virtual machine before commiting the change. * I checked how many udebs were depending on archdetect (6, if I recall correctly), and new they would cope just fine with the change. * Knew the Debian archive would handle the rename, as udebs and debs have different name spaces, and we use the provides method with several library udebs already. So the change was tested and the installer was working as it should also after the rename. The only thing I didn't test was building the debian-installer source package itself, which broke as you correctly observed. The simple fix is to replace archdetect with archdetect-udeb, but a more proper fix is probably to teach the build of d-i initrds to understand the provides header, to ensure similar issues do not arise in the future. I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). As I already mentioned, you had been told in advance more stuff would have to be adjusted! Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: | # These udebs will be needed on nearly every image. Include this file | # to get them. | busybox-udeb | anna | archdetect | cdebconf-udeb | cdebconf-priority | di-utils | di-utils-reboot | di-utils-shell | libdebconfclient0-udeb | libdebian-installer4-udeb | libnss-dns-udeb | lowmemcheck | main-menu | rootskel | udpkg | rescue-check | env-preseed | pciutils-udeb | | #include udev | | libkmod2-udeb [linux] | kldutils-udeb [kfreebsd] *-udeb really isn't mandatory in any way! So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. KiBi. signature.asc Description: Digital signature
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
[Cyril Brulebois] I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). Given that udebs and debs have different name spaces, I do not see any problem myself with dropping a name from one namespace and introducing it in another, which is what I did when I renamed archdetect to archdetect-udeb in the udeb namespace and introduced the archdetect name into the deb namespace. The freeze is two months away. I understand you see the freeze as very close, while I see it as a bit further away. I fully respect your view about the urgenzy, even if I do not quite share it. I believe fixing the d-i build could have been done this week (for example by uploading a new debian-installer package without the kernel change), and was prepared to get any required fixes in place as soon as possible. As I already mentioned, you had been told in advance more stuff would have to be adjusted! I noticed you mentioned IRC messages I hadn't seen before you mentioned them here in the mail, so I guess they were said while I was away from IRC. I had tested the change, but simply forgot to check the debian-installer initrd build. I am still sorry about this. Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: [...] *-udeb really isn't mandatory in any way! Sure, but it is used when there is a deb and an udeb. The common naming then is package for the deb name space and package-udeb for the udeb namespace. I did not check them all, but as far as I can tell, the examples without the '-udeb' ending do not have a package in the deb namespace. So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. My approach would have been to fix the remaining issues and keep the archdetect and archdetect-udeb names, but I'm not starting competing for commits uploads over this and will try to find time for the fix after Jessie instead. -- Happy hacking Petter Reinholdtsen -- 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/20140911075500.gr22...@ulrik.uio.no
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
Petter Reinholdtsen p...@hungry.com (2014-09-11): Given that udebs and debs have different name spaces, I do not see any problem myself with dropping a name from one namespace and introducing it in another, which is what I did when I renamed archdetect to archdetect-udeb in the udeb namespace and introduced the archdetect name into the deb namespace. Re-using package names has always been a pain, for users, for packages depending on them, for bug tracking purposes, for bisecting purposes (downloading older snapshots in an automated way, testing them), etc. This should be avoided. Always. Consistency with a naming scheme is not a reason good enough to outweigh the costs mentioned above. The freeze is two months away. I understand you see the freeze as very close, while I see it as a bit further away. I fully respect your view about the urgenzy, even if I do not quite share it. I believe fixing the d-i build could have been done this week (for example by uploading a new debian-installer package without the kernel change), and was prepared to get any required fixes in place as soon as possible. First thing first: I upload debian-installer only when it is needed, meaning we're targetting a release. Secondly, since the udeb change didn't reach testing, no, it wouldn't have worked. I know two months is a lot, somewhat. But there are many more important things to track already! So losing time, focus, and energy over such disruptive and avoidable changes is really not appreciated. As I already mentioned, you had been told in advance more stuff would have to be adjusted! I noticed you mentioned IRC messages I hadn't seen before you mentioned them here in the mail, so I guess they were said while I was away from IRC. No, you were in the middle of a conversation with Colin. I'm not going to copy/paste it because that'd be impolite, but you'll find it in your logs, 2014-09-09, around 10 UTC. Sticking to naming schemes is nice, but that certainly shouldn't be a reason for renaming packages and generating more work! You could look at the file you modified: [...] *-udeb really isn't mandatory in any way! Sure, but it is used when there is a deb and an udeb. The common naming then is package for the deb name space and package-udeb for the udeb namespace. I did not check them all, but as far as I can tell, the examples without the '-udeb' ending do not have a package in the deb namespace. That doesn't mean we have to enforce it. I'm pretty sure that someone 1. wanting to use archdetect 2. doing apt-get install archdetect can either press tab to try autocompletion, or use apt-cache search archdetect to discover the archdetect-deb package (if we ended up stealing this name from Ubuntu). So yes, I reverted these changes since renaming is unwarranted, already broke things, and might break others; I'm not interested in dealing with possible fallouts due to cosmetics. My approach would have been to fix the remaining issues and keep the archdetect and archdetect-udeb names, but I'm not starting competing for commits uploads over this and will try to find time for the fix after Jessie instead. Thanks. Mraw, KiBi. signature.asc Description: Digital signature
Bug#760904: installation-reports: no network on linkstation pro with jessie d-i
On Wed, 2014-09-10 at 14:14 -0700, Ryan Tandy wrote: On 10/09/14 10:28 AM, Ian Campbell wrote: In the meantime if you could collect the lsmod with a Wheezy kernel for comparison we can check if there is anything else there which ought to be exposed to the installer. Attaching dmesg and report-hw from wheezy and jessie for completeness. Thanks. The new networking related bits seem to be marvell.ko and mvmdio.ko. marvell.ko was already packaged in the right place and I added mvmdio.ko yesterday. I remain hopeful that will have solved your issue. Thanks, 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/1410429175.6166.53.ca...@kazak.uk.xensource.com
hw-detect_1.102_amd64.changes ACCEPTED into unstable, unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 11 Sep 2014 08:32:43 +0200 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source amd64 all Version: 1.102 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Cyril Brulebois k...@debian.org Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Closes: 761135 Changes: hw-detect (1.102) unstable; urgency=low . * Revert the archdetect vs. archdetect-udeb change (Closes: #761135). Reasons include: - Disruptive changes are not welcome so late in the release cycle (especially when little to nothing has to be gained). - No tests have been performed, since debian-installer starts failing to build from source. - Reusing a package name for a different package-type is a recipe for disaster. Checksums-Sha1: 674148bf3d429020f19d3e02d681c5ee06eda75b 2034 hw-detect_1.102.dsc ae94c3f9baa9222a164cfc1f6943053c2ce8cf99 179444 hw-detect_1.102.tar.xz b253df868deccb69f4e2f1fcede13dcdf9724587 128302 hw-detect_1.102_amd64.udeb 70e8c02a4d4b020555a22d5418d52e123fee3a50 36076 ethdetect_1.102_all.udeb 5a0289a768919d61cce5d0104f616cc7518224ca 27648 disk-detect_1.102_all.udeb 8eae703d8b2a5ac1ba10743a19a55f8dbd6e080c 15146 driver-injection-disk-detect_1.102_all.udeb 48d3691762a9cee908dc9bb49187e1db068e9aa5 2414 archdetect_1.102_amd64.udeb Checksums-Sha256: 3a3854867ade4052b6d5faa6fed80361d5b3c15fc0d35448142b4d5059ae1c86 2034 hw-detect_1.102.dsc 1280cbab6c430d2cd3958ef5eb5901d9c1efdaa448d6edba96d8dcb8e2779de9 179444 hw-detect_1.102.tar.xz bc4bdc8f393c28b330b90dbdd5699a519bd2a93a14929de4ad40b4b77cb5ec46 128302 hw-detect_1.102_amd64.udeb 7feafa832e6aa5424e87b5e6ba1fbf950b1438f19a719f54cc1b476865d23629 36076 ethdetect_1.102_all.udeb 9f737c85c18ee94399f469622bf3f1a5d8f78d054465713426cae60251f828bc 27648 disk-detect_1.102_all.udeb db0789415ae7f2445bd44c58c9c17f89b844ac31467c6d80403a73ae1c87bc30 15146 driver-injection-disk-detect_1.102_all.udeb 07cc785d56d366296f807b78384900d9d6324a5f95eba2a07f47257d13bf0dbd 2414 archdetect_1.102_amd64.udeb Files: 27b79e02d7e0a97938ea57f66b264f5a 128302 debian-installer standard hw-detect_1.102_amd64.udeb 9e4c4092042b7cd81bd97c10c7711669 36076 debian-installer optional ethdetect_1.102_all.udeb 395ab4c2122d029cc1d2a22f1b2a6c1c 27648 debian-installer optional disk-detect_1.102_all.udeb 9f58bdff7d2c5bd1bf50d37e3bbd9fe7 15146 debian-installer optional driver-injection-disk-detect_1.102_all.udeb fb5a777fcfca4bd738f7306ffacc1c44 2414 debian-installer standard archdetect_1.102_amd64.udeb b5ba38f9775aeb67c432bb57fcba3415 2034 debian-installer standard hw-detect_1.102.dsc 02e8cfd7822c475fc47f5976d5d169d3 179444 debian-installer standard hw-detect_1.102.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJUEUM5AAoJEP+RSvDCs1UgjlQQAMNFr2jyWicQCXRVkxO6dhIA FqRzV8mQrq9lvyw14NzABQtiP6azo/rxq4SOb1aLXO+SIdThXmRay0wi+aO2y0b+ QLxPI0WmpcuGwD/3E1t5BHtZXt9fp1euTENNNSYoaRGzPjpmujnFIbporFBz3dT8 cW7A3p1Gpr/7EeImi66cnuGaDEt/g8LHD9j3XyxxSPfCC4ypymPktgbOTNB+qlD1 7CGSp5YJA5iogpRjy1SK9sOgRnJKIyjYevm1Y6fGPv17lnVFErMDKEGwE2O0/bvz za74mY79RNQsa+Afw/SMCporgNn8nM8G9QBeqMVN+eN/XF54Pl48Y70GSxphpAeA CP/h5bUAefdpXy0KE8+5qJPIHPRqIDtD3p1hEI1iEGjKGSQztKzowGlG8+bUvo37 UuRTYdH0Prqq6cTdfZL/rlDgVnhVRz4bYC7AbRtyvubb4YyNKWw4zXNDdnmf0Q0p IkqUOzk/gK1RaMfj80evbC2i7/D8coZDfmsDMwFpIvE9MnAtqQhAQTtdMC6z1FpW 8CDpXSpY2U0+jJZzyQNnqwPlr6qzqekBsnU+3OhuxQGr7j+wrNCmYl5mI4rOlAeP oRZA0nktjQSU8Py6ef8sPcwoeKC8AivDsQAyH1UbDvMcoom2Hxp2H2jxzFQoVJ93 cFSqoYTPcDiAqwiyKVeB =BV9R -END PGP SIGNATURE- Thank you for your contribution to Debian. -- 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/e1xs1ag-0001wj...@franck.debian.org
Bug#761135: marked as done (archdetect: package rename/package-type change breaks d-i builds)
Your message dated Thu, 11 Sep 2014 10:00:10 + with message-id e1xs1ag-0001wv...@franck.debian.org and subject line Bug#761135: fixed in hw-detect 1.102 has caused the Debian Bug report #761135, regarding archdetect: package rename/package-type change breaks d-i builds 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.) -- 761135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761135 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: archdetect Version: 1.100.0.exp.1 Severity: grave Justification: renders package unusable Petter, I'm not sure why you thought it would be a good idea to mix renaming and reusing udeb/deb package name, but one thing is pretty clear: you never tested a d-i build using those udebs. You would have otherwise noticed the mess you created. I'm not even going to ask about runtime tests… Please unbreak! KiBi. ---End Message--- ---BeginMessage--- Source: hw-detect Source-Version: 1.102 We believe that the bug you reported is fixed in the latest version of hw-detect, 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 761...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Cyril Brulebois k...@debian.org (supplier of updated hw-detect 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: SHA1 Format: 1.8 Date: Thu, 11 Sep 2014 08:32:43 +0200 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source amd64 all Version: 1.102 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Cyril Brulebois k...@debian.org Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Closes: 761135 Changes: hw-detect (1.102) unstable; urgency=low . * Revert the archdetect vs. archdetect-udeb change (Closes: #761135). Reasons include: - Disruptive changes are not welcome so late in the release cycle (especially when little to nothing has to be gained). - No tests have been performed, since debian-installer starts failing to build from source. - Reusing a package name for a different package-type is a recipe for disaster. Checksums-Sha1: 674148bf3d429020f19d3e02d681c5ee06eda75b 2034 hw-detect_1.102.dsc ae94c3f9baa9222a164cfc1f6943053c2ce8cf99 179444 hw-detect_1.102.tar.xz b253df868deccb69f4e2f1fcede13dcdf9724587 128302 hw-detect_1.102_amd64.udeb 70e8c02a4d4b020555a22d5418d52e123fee3a50 36076 ethdetect_1.102_all.udeb 5a0289a768919d61cce5d0104f616cc7518224ca 27648 disk-detect_1.102_all.udeb 8eae703d8b2a5ac1ba10743a19a55f8dbd6e080c 15146 driver-injection-disk-detect_1.102_all.udeb 48d3691762a9cee908dc9bb49187e1db068e9aa5 2414 archdetect_1.102_amd64.udeb Checksums-Sha256: 3a3854867ade4052b6d5faa6fed80361d5b3c15fc0d35448142b4d5059ae1c86 2034 hw-detect_1.102.dsc 1280cbab6c430d2cd3958ef5eb5901d9c1efdaa448d6edba96d8dcb8e2779de9 179444 hw-detect_1.102.tar.xz bc4bdc8f393c28b330b90dbdd5699a519bd2a93a14929de4ad40b4b77cb5ec46 128302 hw-detect_1.102_amd64.udeb 7feafa832e6aa5424e87b5e6ba1fbf950b1438f19a719f54cc1b476865d23629 36076 ethdetect_1.102_all.udeb 9f737c85c18ee94399f469622bf3f1a5d8f78d054465713426cae60251f828bc 27648 disk-detect_1.102_all.udeb db0789415ae7f2445bd44c58c9c17f89b844ac31467c6d80403a73ae1c87bc30 15146 driver-injection-disk-detect_1.102_all.udeb 07cc785d56d366296f807b78384900d9d6324a5f95eba2a07f47257d13bf0dbd 2414 archdetect_1.102_amd64.udeb Files: 27b79e02d7e0a97938ea57f66b264f5a 128302 debian-installer standard hw-detect_1.102_amd64.udeb 9e4c4092042b7cd81bd97c10c7711669 36076 debian-installer optional ethdetect_1.102_all.udeb 395ab4c2122d029cc1d2a22f1b2a6c1c 27648 debian-installer optional disk-detect_1.102_all.udeb 9f58bdff7d2c5bd1bf50d37e3bbd9fe7 15146 debian-installer optional driver-injection-disk-detect_1.102_all.udeb
Bug#761135: archdetect: package rename/package-type change breaks d-i builds
On Thu, Sep 11, 2014 at 09:33:13AM +0200, Cyril Brulebois wrote: I disagree that reusing package names across package types is a nice thing to do. I very strongly disagree that it's OK to try that when we're close to the freeze (and not at the very beginning of the release cycle, where it hurts less to upload disruptive changes). So, I think the best way to handle this longer-term would be: * upload hw-detect with a transitional package archdetect (Package-Type: udeb) Depends: archdetect-udeb * make sure everything copes well with that * at some later point (e.g. in jessie+1) introduce archdetect as a .deb I would like to have archdetect as a .deb; the archdetect-deb name I made up a while back in Ubuntu sucks and I wouldn't like to perpetuate it; I don't think there's a fundamental problem with reusing package names across package types, but in cases like this where it has coordination issues we should make some effort to smooth the transition rather than just going straight for it. -- Colin Watson [cjwat...@debian.org] -- 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/20140911103024.ga20...@riva.ucam.org
Re: Summary from the d-i / debian-cd BoF at DC14
On Tue, Sep 09, 2014 at 11:45:28AM -0700, intrigeri wrote: Hi, Steve McIntyre wrote (09 Sep 2014 15:51:01 GMT) : * Regular live builds of testing - now we have stable release builds happening on pettersson, we should also be able to do regular weeklies too for Jessie. Still needs a little work, it's coming. Great! This has been on my todo list for too long now. I'm interested to give a hand, at least to test the resulting ISOs with the GNOME desktop. Any pointer to existing WIP in this area, or to the codebase that needs to be modified? http://anonscm.debian.org/cgit/debian-cd/pettersson-live.git/ is where I am at the moment. It's not pretty, but it basically works for me at the moment. It's not yet automated, but hey that shouldn't be hard, right? :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray -- 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/2014095755.gh14...@einval.com
Re: Summary from the d-i / debian-cd BoF at DC14
On Tue, Sep 09, 2014 at 08:23:10PM +0200, Ansgar Burchardt wrote: Hi, Steve McIntyre st...@einval.com writes: Debian-CD Plans === * Which images do we want to make for Jessie? Currently we have, for every architecture: + netinst + CD set + alternate versions of CD#1 for each of the desktops (gnome/kde/xfce/lxde) + DVD + BD (x86 only) [...] Discussion about trying to make desktops fit on 1 CD. XFCE and LXDE both fit on 1 CD, Gnome and KDE basically don't fit any more. We need to work out what to do there. Should we still build Gnome or KDE CDs at all? Not clear. Let's have the discussion. I was wondering if it was possible to build installer images without a specific size limit, i.e. include all packages for tasks x, y, z. Doing so might result in nice images for GNOME, KDE, XFCE, * that are just as large as they have to be. That's possible, yes. The way to do that right now would be to specify a (maximum) size to fit inside a DVD, then only pull in a particular set of tasks and packages and nothing more. That's how the netinst sizing works, for example. Discussion and questions * Question about the status of signed images. + All of the official images created and distributed via cdimage.d.o are signed: [...] + Both of these keys are in the WoT, cross-signed by Steve and a few other folks. Are both keys in debian-role-keys.gpg (in the debian-keyring package)? The main release key is, but not the testing images key yet. Thanks for reminding me... -- Steve McIntyre, Cambridge, UK.st...@einval.com Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html -- 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/20140911120305.gi14...@einval.com
Re: Summary from the d-i / debian-cd BoF at DC14
On Tue, Sep 09, 2014 at 08:51:15PM -0700, Steve Langasek wrote: Hi Steve, On Tue, Sep 09, 2014 at 04:51:01PM +0100, Steve McIntyre wrote: * Generating complete images (as opposed to installer images) brings up other issues - d-i already asks a set of useful questions (keymap, timezone, etc.) at installation time. For other types of images, we'd need to add a first-boot customisation/configuration tool to ask those questions. Preseeding could do it, but how do we do this? Defer some of the installer steps until first boot, like live-installer? One example of prior art that may be worth looking at is Ubuntu's oem-config, part of the 'ubiquity' source package: http://archive.ubuntu.com/ubuntu/pool/main/u/ubiquity/ http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk This has both graphical and console front-ends for use in configuring a system at first boot of a preinstalled image. ACK, thanks for the suggestion. As/when/if somebody finds time to work on this that could be very helpful! -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with Valor: Centurion represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. -- 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/20140911121731.gk14...@einval.com
Bug#678793: task-desktop: libreoffice-gcj no longer exists
Package: tasksel Version: 3.24 Followup-For: Bug #678793 Since this bug has been open for quite a while and the libreoffice-gcj packages weren't added back, is it safe to assume this will remain the case for jessie? In that case, please consider applying the attached patch. After all, we can always re-add those recommends. Cheers, Michael -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages tasksel depends on: ii apt 1.0.8 ii debconf [debconf-2.0] 1.5.53 ii liblocale-gettext-perl 1.05-8+b1 ii perl-base 5.20.0-6 ii tasksel-data3.24 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded diff --git a/debian/control b/debian/control index bf9217c..6f15347 100644 --- a/debian/control +++ b/debian/control @@ -90,7 +90,6 @@ Recommends: iceweasel, # libreoffice is the best word processor / office suite at the moment libreoffice, - libreoffice-gcj, # make help menu work libreoffice-help-en-us, # make thesaurus work @@ -137,7 +136,6 @@ Recommends: iceweasel, # libreoffice is the best word processor / office suite at the moment libreoffice, - libreoffice-gcj, # make help menu work libreoffice-help-en-us, # make thesaurus work @@ -172,7 +170,6 @@ Recommends: iceweasel, # libreoffice is the best word processor / office suite at the moment libreoffice, - libreoffice-gcj, # make help menu work libreoffice-help-en-us, # make thesaurus work @@ -227,7 +224,6 @@ Recommends: iceweasel, # libreoffice is the best word processor / office suite at the moment libreoffice, - libreoffice-gcj, # make help menu work libreoffice-help-en-us, # make thesaurus work @@ -270,7 +266,6 @@ Recommends: iceweasel, # libreoffice is the best word processor / office suite at the moment libreoffice, - libreoffice-gcj, # make help menu work libreoffice-help-en-us, # make thesaurus work
Re: default desktop: availability on all arches
On Wed, Sep 10, 2014 at 11:56:58AM +0100, Steven Chamberlain wrote: On 10/09/14 07:40, Adam Borowski wrote: I think the DebianDesktop requalification table lacks an important row: the availability of the desktop environment in question on all Debian architectures. Not everyone has been persuaded on that principle yet :P But on kfreebsd CDs we can at least override the default desktop if it's something we don't have. I just re-checked on powerpc in qemu, unlike my other setups it's not a real machine, but qemu is at least a reproducible setup without out-of-archive bits like all three of my armhf rigs. A d-i run takes two ages and three forevers, though... Powerpc is not a slow architecture, but is extremely slow in qemu. Let's discuss your other point about 3D acceleration though: llvmpipe is not a strict requirement, but I have yet to find a non-x86 opengl driver that gnome's compositor can work with. I tried: * an A10 laptop with non-free unpackaged Mali blob * Exynos4412 hardkernel, unpackaged opengl drivers * chroot on Raspberry Pi, non-free Broadcom stuff * qemu stuff has no accelerated opengl either What happens otherwise if trying to start GNOME3 (or others)? * without 3D, with llvmpipe * without both llvmpipe doesn't work at all -- not ported to -- on !x86 !armhf. Does it fall back gracefully to a fallback/flashback mode, and does that still work these days? All you get is a non-windowed screen that says: . Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again. Log Out. ` You can't even press Log Out, upon clicking the mouse cursor disappears and pressing any key on the keyboard turns the screen black, without no way out other than Alt-Ctrl-F1. According to what I read on the Interwebs, the fallback mode has been removed in Gnome 3.8, and flashback is just a plugin on gnome-shell. In this mode would it still meet the 'accessibility' or other criteria already on the Wiki page? 'Accessibility' is usually meant as being helpful to the blind, poor- sighted and those with hand-control disabilities: modes with big letters, contrasted screen elements, doubleclick and shift workarounds, etc. I'd say you'd need 'availability' or 'portability': gnome3 with a solid -1 (works only on 3 architectures at all -- 2 usably), no idea about kde, no problems for the rest. For example the Allwinner10-based laptop I had with me on DebConf 2013, I tested with xfce, but as A10 is terribly underpowered even for arm, I ended up with lxde with a bunch of programs from xfce. This worked great. Thus, it's safe to say anyone with a non-Nvidia non-Radeon non-Intel GPU will need llvmpipe. The Radeon users would need to be using non-free microcode too I guess? I'm well-armed but not well-x86ed, all my home boxes got nvidia, can't check. I'd say the default desktop environment should work on almost all setups. Yes, surely. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20140911153618.ga29...@angband.pl
Bug#760993: console-setup: CHARMAP no longer set properly
On Tue, Sep 09, 2014 at 08:18:01PM +0200, Kurt Roeckx wrote: In /etc/default/console-setup I have: CHARMAP=ISO-8859-1 However, my console acts like it's in UTF-8 mode. If I restart the console-setup service it does get properly set, so I'm guessing something else is overriding it. In order to be sure that that the culprit is not console-setup but other program, do this: Open /bin/setupcon in a text editor and find the following block: elif [ $do_verbose ]; then case $verbose in NONE) report executing $cmd $@. $cmd $@ ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ $verbose ;; esac else case $verbose in NONE) report executing $cmd $@. $cmd $@ /dev/null 21 ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ ;; esac Then remove the symbol '' from both lines $cmd $@ Does the problem disappear if you do this? Anton Zinoviev -- 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/20140911160313.ga24...@logic.fmi.uni-sofia.bg
Bug#760993: console-setup: CHARMAP no longer set properly
On Thu, Sep 11, 2014 at 07:03:13PM +0300, Anton Zinoviev wrote: On Tue, Sep 09, 2014 at 08:18:01PM +0200, Kurt Roeckx wrote: In /etc/default/console-setup I have: CHARMAP=ISO-8859-1 However, my console acts like it's in UTF-8 mode. If I restart the console-setup service it does get properly set, so I'm guessing something else is overriding it. In order to be sure that that the culprit is not console-setup but other program, do this: Open /bin/setupcon in a text editor and find the following block: elif [ $do_verbose ]; then case $verbose in NONE) report executing $cmd $@. $cmd $@ ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ $verbose ;; esac else case $verbose in NONE) report executing $cmd $@. $cmd $@ /dev/null 21 ;; FORK) # no arguments to suppress '\033%%@' and '\033%%G' report executing $cmd. $cmd $@ ;; *) report executing $cmd $@. $cmd $@ ;; esac Then remove the symbol '' from both lines $cmd $@ Does the problem disappear if you do this? So I changed both FORK cases to be: $cmd $@ That doesn't change anything, and I don't see why that should change anything. Kurt -- 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/20140911164437.ga21...@roeckx.be
Re: default desktop: availability on all arches
On 11/09/14 16:36, Adam Borowski wrote: What happens otherwise if trying to start GNOME3 (or others)? * without 3D, with llvmpipe * without both llvmpipe doesn't work at all -- not ported to -- on !x86 !armhf. Does it fall back gracefully to a fallback/flashback mode, and does that still work these days? All you get is a non-windowed screen that says: . Oh no! Something has gone wrong. A problem has occured and the system can't recover. Please log out and try again. Log Out. ` You can't even press Log Out, upon clicking the mouse cursor disappears and pressing any key on the keyboard turns the screen black, without no way out other than Alt-Ctrl-F1. Fair enough if a Debian desktop doesn't want to support toy architectures (I don't mind use of this term). But if the above is true, it is a step further: only 3D-accelerated, or i386/amd64/armhf systems seem to get a sensible out-of-box experience. It still isn't clear to me what default desktop means or the impact of deciding one. Ultimately I think we'll be saying the default Debian _system_ is an amd64 machine, with modern Intel, Nvidia (or Radeon + nonfree microcode) graphics, running the GNOME 3 desktop, and fair enough, the Debian homepage could serve a direct link to a GNOME amd64/i386 ISO download. That install media should default to installing GNOME. Is that what we're *really* deciding with the process here? https://wiki.debian.org/DebianDesktop/Requalification/Jessie In most _other_ situations (the 1 to 20%, who knows), where that .iso is not appropriate, it perhaps won't make sense to always suggest GNOME. Maybe where I'm going with this is a tier-1 default and a everything-else default, or maybe we don't even need that. I'm unsure. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/5411d7ba.7030...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
On Wed, Sep 10, 2014 at 09:39:24PM +0200, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2014-09-10): 3. for a user who blindly hits enter, they get our best guess to the correct device (instead of a bare now enter a device path prompt) Please stop pretending it's a best guess. IT'S NOT GOOD ENOUGH, and it has been known for *years*. But I haven't actually tested it yet :) Many users already have… and wedged their installation images. Slightly tired of repeating myself. KiBi. Does the installer no longer know to what device it installed the Debian system? Perhaps where it put /boot? Might *that* be a good place to put the bootloader? -- hendrik -- 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/20140911172303.ga12...@topoi.pooq.com
Re: default desktop: availability on all arches
On Thu, Sep 11, 2014 at 06:11:22PM +0100, Steven Chamberlain wrote: On 11/09/14 16:36, Adam Borowski wrote: What happens otherwise if trying to start GNOME3 (or others)? * without 3D, with llvmpipe * without both llvmpipe doesn't work at all -- not ported to -- on !x86 !armhf. Does it fall back gracefully to a fallback/flashback mode, and does that still work these days? All you get is a non-windowed screen that says: Oh no! Something has gone wrong. Fair enough if a Debian desktop doesn't want to support toy architectures (I don't mind use of this term). So you call all but two[1] of Debian architectures (14+9) toys[2]? Where has the universal operating system gone? Ultimately I think we'll be saying the default Debian _system_ is an amd64 machine, with modern Intel, Nvidia (or Radeon + nonfree microcode) graphics, running the GNOME 3 desktop, and fair enough, the Debian homepage could serve a direct link to a GNOME amd64/i386 ISO download. That install media should default to installing GNOME. XFCE has none of Gnome3's problems, and were it not a last-minute entry, I'd suggest going with Mate. Mate has the upside of having been the default for every but one releases that had tasksel. Is that what we're *really* deciding with the process here? https://wiki.debian.org/DebianDesktop/Requalification/Jessie I'd say that being available on most architectures warrants at least a row in that table. It's more important than, say, 2 points you get for a tasksel metapackage that _hasn't even worked until now_ -- the only desktop task that was even shown in d-i was task-desktop. No wonders the Mate team didn't even request one: users had the mate-desktop-environment metapackage which was for all purposes better. Until this qualification, which suddenly decided to give 2 points for this detail. So what I'm suggesting is to add the availability or portability row to the table. [1]. armhf machines typically rely on their GPUs to have any reasonable graphics performance, trying to emulate opengl in software isn't going to work. [2]. Ok, I admit hurd is a toy, so are some of -ports. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20140911182608.gb1...@angband.pl
Re: default desktop: availability on all arches
On Thu, Sep 11, 2014 at 05:36:18PM +0200, Adam Borowski wrote: I just re-checked on powerpc in qemu, unlike my other setups it's not a real machine, but qemu is at least a reproducible setup without out-of-archive bits like all three of my armhf rigs. I'd say you'd need 'availability' or 'portability': gnome3 with a solid -1 (works only on 3 architectures at all -- 2 usably), no idea about kde, no problems for the rest. Tried kde: massively slower than other desktop environments, but works. So it looks like gnome3 is the only one that doesn't work on most architectures. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- 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/20140911181028.ga1...@angband.pl
Re: Re: default desktop: availability on all arches
So it looks like gnome3 is the only one that doesn't work on most architectures. You tested qemu, not real hardware. For your tests to be really meaningful, they would have to be done on actual hardware. That said, I don't see a good reason why availability on architectures should be a deciding factor (as already pointed out by Joey and Christian). -- 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: default desktop: availability on all arches
On 11/09/14 19:26, Adam Borowski wrote: On Thu, Sep 11, 2014 at 06:11:22PM +0100, Steven Chamberlain wrote: Fair enough if a Debian desktop doesn't want to support toy architectures (I don't mind use of this term). So you call all but two[1] of Debian architectures (14+9) toys[2]? Where has the universal operating system gone? Well, Christian made reference the term in his mail, and it's something some people might use as a derogative. But I'm actually quite fond of the term. Toys still serve a purpose, perhaps an educational one, and making toys would also be a cool hobby. But anyway... XFCE has none of Gnome3's problems, and were it not a last-minute entry, I'd suggest going with Mate. Mate has the upside of having been the default for every but one releases that had tasksel. *If* most users do have modern amd64 hardware, lots of bandwidth and suitable 3D graphics, maybe it would be okay to recommend GNOME in that case? It may deliver the best possible experience on their computer. I've no problem with something like that being Debian's foremost product, even if it isn't right for everyone. But in other situations I don't think it is sensible; even suggesting it as the default seems unhelpful there. If someone uses other install media, I think a better default ought to be whatever we were able to fit on this disc or otherwise whatever is quickest to download and most likely work, and have Internet access. Is that what we're *really* deciding with the process here? https://wiki.debian.org/DebianDesktop/Requalification/Jessie I'd say that being available on most architectures warrants at least a row in that table. I think each row in that table is something the desktops should be looking to compete on and try to improve, as long as it fits with their goals. So I think it deserves a mention there... So what I'm suggesting is to add the availability or portability row to the table. What team within Debian would be the best judge of those criteria? [1]. armhf machines typically rely on their GPUs to have any reasonable graphics performance, trying to emulate opengl in software isn't going to work. I think the same will be true of old armel, and present-day mipsel systems for example. My Lemote Yeeloong can run a very productive XFCE desktop, but barely 15fps of full-screen video so I don't imagine it could handle GNOME. So it may turn out that *most* of Debian's architectures/ports can't run GNOME very well, and something more lightweight makes sense for them. But most of Debian's new users, and visitors to the website frontpage, might get a better overall experience with GNOME. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/541213aa.4060...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
On 11/09/14 18:23, Hendrik Boom wrote: Does the installer no longer know to what device it installed the Debian system? Perhaps where it put /boot? Might *that* be a good place to put the bootloader? I've been trying to document the existing processes here: https://wiki.debian.org/DebianInstaller/Bugs/GrubInstaller In limited circumstances grub-installer will guess (hd0) (the first disk detected by grub-mkdevicemap). When installing from USB this is often wrong. There are some circumstances where grub-installer will look at where /boot resides. I suspect most of the time this is a better guess. It will always ask for user confirmation. There are different dialogs shown to the user depending on which detections grub-installer used. It has become over-complicated. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/54121630.2070...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Steven Chamberlain ste...@pyro.eu.org (2014-09-11): On 11/09/14 18:23, Hendrik Boom wrote: Does the installer no longer know to what device it installed the Debian system? Perhaps where it put /boot? Might *that* be a good place to put the bootloader? I've been trying to document the existing processes here: https://wiki.debian.org/DebianInstaller/Bugs/GrubInstaller This page is missing cases involving firmware on a USB stick, so no, even installation from CD/DVD/PXE can fail the same way. Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
On 11/09/14 22:48, Cyril Brulebois wrote: I've been trying to document the existing processes here: https://wiki.debian.org/DebianInstaller/Bugs/GrubInstaller This page is missing cases involving firmware on a USB stick, so no, even installation from CD/DVD/PXE can fail the same way. OK, I'd like to document that as a test case. Actually with this there could be two situations: * the USB stick was plugged in already at boot time * the USB stick is plugged in later and could lead to different ordering. Regards, -- Steven Chamberlain ste...@pyro.eu.org signature.asc Description: OpenPGP digital signature
Re: default desktop: availability on all arches
I think there could be two distinct sets of criteria: 1. criteria for the premier desktop to suit most users - it's counter-productive for portability to be a major factor in this 2. criteria for the next-best desktop where 1. isn't practical - portability, versatility and media size are much more important here I think it is actually good to decide on a 2., so that we don't end up with needless inconsistency like: * mipsel suggesting MATE as default if it can't handle GNOME * LXDE being the default on the small CD images (for offline installs) * kfreebsd with XFCE as a default because it was for wheezy These are useful criteria for deciding what CD images we'd like, too. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/54121b9c.4050...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Hope you guys don't mind me adding my comment here?? I've noticed that this happens when I'm installing into a virtualbox vm, and there is only single partition. Seems like a silly question when there is only 1 choice. regards On Fri, Sep 12, 2014 at 7:51 AM, Steven Chamberlain ste...@pyro.eu.org wrote: On 11/09/14 22:48, Cyril Brulebois wrote: I've been trying to document the existing processes here: https://wiki.debian.org/DebianInstaller/Bugs/GrubInstaller This page is missing cases involving firmware on a USB stick, so no, even installation from CD/DVD/PXE can fail the same way. OK, I'd like to document that as a test case. Actually with this there could be two situations: * the USB stick was plugged in already at boot time * the USB stick is plugged in later and could lead to different ordering. Regards, -- Steven Chamberlain ste...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Hi, On 12/09/14 00:54, Ozi Traveller wrote: I've noticed that this happens when I'm installing into a virtualbox vm, and there is only single partition. Thanks, this is useful information for me. But please could you be more specific: was this a default, automatic (preseed) or expert-mode install? Of which version (wheezy, jessie daily build?)) and from what type of install media (ISO image? mounted as virtual CDROM drive or as a hard disk?) Did you get this dialog first: | Install the GRUB boot loader to the master boot record? | Go Back Yes No or do you only see this: | Device for boot loader installation: | [o] Enter device manually | [ ] /dev/sda (ata-QEMU_HARDDISK_QM1) and in case of the latter -- was Enter device manually the pre-selected option (if you were to hit Enter), or was /dev/sda pre-selected? Seems like a silly question when there is only 1 choice. There are actually other choices if you were to Enter device manually - you could install GRUB to a partition instead of the MBR. Or to some other device that GRUB wasn't able to detect. We need to provide a way to do that. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/54123bdb.5060...@pyro.eu.org
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
Hi Sorry for the lack of information. auto preseed, not expert: https://github.com/ozitraveller/star-live-build/blob/master/xfce-64/config/includes.installer/preseed.cfg version: jessie install media: iso image mounted as virtual CDROM : yes Yes that is the dialog I got, only not QEMU. Yes I understand the other options thanks. I hope this helps. regards On Fri, Sep 12, 2014 at 10:18 AM, Steven Chamberlain ste...@pyro.eu.org wrote: Hi, On 12/09/14 00:54, Ozi Traveller wrote: I've noticed that this happens when I'm installing into a virtualbox vm, and there is only single partition. Thanks, this is useful information for me. But please could you be more specific: was this a default, automatic (preseed) or expert-mode install? Of which version (wheezy, jessie daily build?)) and from what type of install media (ISO image? mounted as virtual CDROM drive or as a hard disk?) Did you get this dialog first: | Install the GRUB boot loader to the master boot record? | Go Back Yes No or do you only see this: | Device for boot loader installation: | [o] Enter device manually | [ ] /dev/sda (ata-QEMU_HARDDISK_QM1) and in case of the latter -- was Enter device manually the pre-selected option (if you were to hit Enter), or was /dev/sda pre-selected? Seems like a silly question when there is only 1 choice. There are actually other choices if you were to Enter device manually - you could install GRUB to a partition instead of the MBR. Or to some other device that GRUB wasn't able to detect. We need to provide a way to do that. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org
