Re: Bug#1061595: Debian Live 12.4.0 AMD64 Xfce Fails to Start Its Graphical Environment
je...@tuta.io wrote: >Package: debian-live >Severity: important >X-Debbugs-Cc: je...@tuta.io > > >Dear Debian Live Maintainers, > >Today, I have attempted to boot debian-live-12.4.0-amd64-xfce.iso, after >`dd`ing it to a USB stick, and I failed miserably :( Hmmm, odd. On release day we tested that and it worked fine. As Jonathan says, I'd check again on the USB stick: make sure you've run sync or similar after writing, and maybe also read back and check the checksum: https://www.debian.org/CD/faq/#verify -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Bug#1057853: KDE live images: no desktop icon to start calamares
Package: debian-live Severity: normal We don't have a KDE desktop icon to launch calamares on the Bookworm live images. No idea what's responsible for this...
Re: When will the Debian 12 32-bit Live ISO arrive?
Alessandro wrote: > >OK, but why not make them available with the warning "untested, use at >your own risk" >In this way, users will then provide feedback. We don't really need the feedback, I'll be honest. We already know that they are not going to work well for most people, so it's better to stop shipping them than waste people's time. i386 is reaching end of life. Modern live images will not work usefully on the vast majority of i386 systems, as they just won't have enough memory to work well. We've also stopped shipping i386 installer images for trixie. It's time to move on. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Enabling arm64 live image builds
Hey Emanuele! On Mon, Sep 25, 2023 at 12:59:46PM +0200, Emanuele Rocca wrote: > >Live images are currently only being built for x86 machines as far as I >can see on [1] and [2]. Yup. >I've tried building them on arm64 too, and everything worked perfectly >fine. I'm thus wondering whether it would be possible to build official >images for arm64 as well? It should be, but may need some extra build setup work. All the official installer and live images are built on casulana, our big amd64 build machine. We have some infra for doing builds in qemu VMs if needed, but I suspect that's going to be very slow. Meh, we can work our a solution for that at some point >Here's the commands I've used: > >$ lb config --distribution sid --updates false --bootloaders grub-efi >--archive-areas 'main non-free-firmware' >$ echo task-gnome-desktop > config/package-lists/desktop.list.chroot >$ sudo lb build > >The resulting image can be tested with qemu on a x86 host. > >For example: > >$ ISO=/var/tmp/live-image-arm64.hybrid.iso >$ cp /usr/share/AAVMF/AAVMF_VARS.fd /tmp >$ qemu-system-aarch64 -machine virt -cpu max,pauth-impdef=on -smp `nproc` -m >4G \ > -device qemu-xhci -device usb-kbd -device ramfb -device usb-tablet \ > -drive file=$ISO,format=raw,if=none,id=thumb -device > usb-storage,drive=thumb,bootindex=1 \ >-drive file=/usr/share/AAVMF/AAVMF_CODE.fd,if=pflash,readonly=true \ > -drive file=/tmp/AAVMF_VARS.fd,format=raw,if=pflash \ > -netdev user,id=net0 -device virtio-net-pci,netdev=net0 > >Click on View -> serial0 to follow the boot process, and switch back to >ramfb after gdm has started. OK. However, do we expect the image to be usable on any real machines as-is? -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: Bug#1032071: ARM firmware packages included in amd64 installation images
Control: severity 1035382 grave On Thu, Jul 06, 2023 at 06:29:49PM +0200, Magnus Wallin wrote: > >Hi Magnus, and thanks for the heads-up > >[ . . . ] > >Just because the raspi-firmware package is included on the d-i >installation media, it shouldn't necessarily be installed on an amd64 >host. Or is this coming from live images? > >Hi Steve! > >Speaking for myself: I installed from a live image on the release day of Debian >12. OK, that explains it. Let's try to get this fixed before 12.1... I can see that there is already #1035382 open on the live side, let's bump the severity on that. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: Link broken
On Tue, Jul 04, 2023 at 10:02:53AM -0400, Boyuan Yang wrote: >Hi, > >在 2023-07-04星期二的 15:53 +0200，Holger Wansing写道： >> Hi, >> >> Am 4. Juli 2023 15:17:12 MESZ schrieb Boyuan Yang : >> > Hi, >> > >> > Forwarding the email to debian-live team. >> > >> > Is the i386 live ISO still being built? If not, related link on >> > https://www.debian.org/distrib/ shall be purged (let me know and >> > I can delete that link if needed). >> >> No, https://www.debian.org/CD/live/ says, that live images are >> only built for amd64 currently. > > >Thanks. The change to drop mentioning of i386 Live ISO >on https://www.debian.org/distrib/ is committed now at >https://salsa.debian.org/webmaster-team/webwml/-/commit/57878bd6a7da08f6899198d6d830e614c4deebbb >, and it shall be online within the next few hours. Thanks! >However, https://cdimage.debian.org/cdimage/ still mentions i386 live >image on the web page. Whom should I contact to update such information? >The debian-cd list? Ah, I missed that. Fixed in git now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Link broken
On Tue, Jul 04, 2023 at 09:17:12AM -0400, Boyuan Yang wrote: >Hi, > >Forwarding the email to debian-live team. > >Is the i386 live ISO still being built? If not, related link on >https://www.debian.org/distrib/ shall be purged (let me know and >I can delete that link if needed). Please do, we no longer make i386 live images. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: .disk/info should contain flavour/version of live image
Hey Roland! rclo...@rclobus.nl wrote: > >On 21/06/2023 20:57, Andreas B. Mundt wrote: >> with the bookworm live images, the format of the .disk/info file on >> the iso images has been modified, for example: >> >> bullseye: >> # mount -o loop debian-live-11.2.0.amd64-kde+nonfree.iso /mnt >> $ cat /mnt/.disk/info >> Official Debian GNU/Linux Live 11.2.0 kde 2021-12-18T13:54 >> >> bookworm: >> # mount -o loop debian-live-12.0.0.amd64-gnome.iso /mnt >> $ cat /mnt/.disk/info >> Debian GNU/Linux 12 "Bookworm" - Official Snapshot amd64 LIVE/INSTALL >> Binary >20230610-08:51 >> >> The problem: There is no way to find the image flavour >> (gnome/kde/standard) of the image from .disk/info, it's identical for >> all images. > >That kind of information is available during the build, and is available > after building at another location: in `live/filesystem.packages` >there is a line with `live-task-kde` for KDE. >With bookworm the tool to build the live images was changed from >live-wrapper to live-build, hence the change. > >Do you know whether there is some standard for the .disk folder? There isn't a great deal of information, I'm afraid - it's something that we started using years ago for metadata for d-i media. The current contents of the directory (as used on 12.0.0 installation media) looks like: .disk/ base_components - lists the components in the image that base-installer should look for base_installable - a flag file - if present, all the packages for the base system are in the image cd_type - used by apt-setup to work out the type of image (and the set it came from), so it can DTRT in terms of asking about a mirror, etc. id/- a unique (empty) file, used to allow grub to find the correct disk safely when it boots info - human-readable information about the image, generated by the build. This should be clear and descriptive. mkisofs - contains the complete command line used to generate the ISO image, so people can reproduce/rebuild it later udeb_include - (optionally) lists udebs that should be installed by default udeb_exclude - (optionally) lists udebs that should *not* be installed by default Current live images include most of these, which is good - that helps d-i to use the media too! However, as noted the info file is missing some of the data people might expect. Current amd64 netinst says: Debian GNU/Linux 12.0.0 "Bookworm" - Official amd64 NETINST with firmware 20230610-10:21 while the current gnome live iso says: Debian GNU/Linux 12 "Bookworm" - Official Snapshot amd64 LIVE/INSTALL Binary 20230610-08:51 In the older bullseye live images, we used to have: Official Debian GNU/Linux Live 11.7.0 gnome 2023-04-29T16:30 It would be nice to be able to tweak this in live-build, to contain more information: * Full version number * image type / desktop -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Starting the weekly live images for Bookworm building again
Hey again, On Tue, Jan 31, 2023 at 03:36:53PM +, Steve McIntyre wrote: >> >>As you can see, this affects many teams: >>* live-setup: a MR to generate all live images for Bookworm [A2] So, after some delay from me and some further delays from various Debian machines committing suicide [1], I've got bookworm live builds running again. \o/ I've taken Roland's updated patches and tweaked a little more in the setup.git and live-setup.git repos, and we now have live builds integrated. Changes I've added: * turned on source tarball generation using LB_SOURCE=true, and disable the external source build that we dod for the older live-wrapper builds * when building on casulana, warn about archive updates rather than restarting builds * don't attempt to build i386 live images any more, they're not useful * tweaked logging So, *builds* work fine but I've not *yet* tested actually booting/using one of these images in any way. I've just triggered a full build of "testing" live images now, please help test if you can once they're in place at [2] in a couple of hours from now. I don't yet know how close we are to having full non-free-firmware integration with the live images; I expect there might be some more work needed there yet, but I'd love to be proven wrong. :-) [1] "yay" for the long-standing tradition of services failing as we get close to a release: this time it was casulana and salsa... [2] https://get.debian.org/images/weekly-live-builds/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Starting the weekly live images for Bookworm building again
Hey Roland, Apologies for leaving you waiting a while :-/ On Mon, Jan 16, 2023 at 05:35:50PM +0100, Roland Clobus wrote: > >This is a follow-up of my mail from 2022-11-21 [A1]. > >I've made progress in the last two months, but would like to have some merge >requests approved, to get more traction and to allow others to jump aboard >and make the live images for Bookworm possible. > >As you can see, this affects many teams: >* live-setup: a MR to generate all live images for Bookworm [A2] ACK, I'll take a look at this again shortly. >* localechooser: A minor fix [A3] No idea about that, leaving for somebody else. >* live-installer: A better user experience after the installer is finished >[A4] Merred just now. >* live-build: Various installer improvements, including off-line installation >[A5] Not sure who might review that, let's see -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: live-setup | Reintroduce regular building of live-build images (!2)
Hey Roland! On Tue, Nov 29, 2022 at 08:40:05AM +0100, Roland Clobus wrote: >On 28/11/2022 00:49, Steve McIntyre wrote: > >If I did it right, every single build will run in its own directory, so they >will not collide. (See the line with 'export BUILDDIR') >For utmost speed, I assume that the environment variable 'http_proxy' is set. >See also https://wiki.debian.org/ReproducibleInstalls/LiveImages. OK, cool. We don't need (and don't want!) a proxy for the build machine here, as it has a complete mirror available on the host. That mirror is also pushed directly during release weekends so we can build straight away, before updates have made it all the way through the mirror network. IIRC live-build used to apply locks on the build machine, outside of the build tree. Hopefully that's long fixed. Checking: does your rebuild script try to install packages in the rootfs, or only inside chroots? >> > Thanks for your work so far! I'm hoping to get something working in >> > the weekly image builds soon. > >You've done a lot, I didn't intend to bring you so much additional work. No worries, I didn't want to be blocking you here! I also want to try and get this all sorted well before the bookworm freeze... >> I've made quite a bit of progress - see my recent commits in the >> live-setup repo. One thing that I'm not convinced about in your script >> is building d-i as part of a build, I'd be happier to have the option >> for grabbing builds from d-i.debian.org like we use elsewhere (for the >> weekly builds), and then of course we'll pull from the archive >> directly for release builds. > >I'll try to find some time to comment on your additional changes soon. > >A few thoughts, primarily focussed on reproducibility: >* I've used the git rebuild for d-i, because the d-i.debian.org images are >fleeting, and cannot be used for long-term reproducibility tests. The git >rebuild also contains a kernel detection part, so it would also produce a >runnable d-i, even if the kernel version was not updated yet in git. >* I've used the snapshot service instead of deb.debian.org also for long-term >reproducibility reasons. deb.debian.org-based live images can only be >reproduced within the same DAK-sync (every 6 hours) Right. I'm much less bothered about reproducibility *here* tbh, I'm more interested in getting things up and running so I can test something that looks more like a release image. We're never going to use snapshot stuff for official builds, as we have the full archive readily available. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: live-setup | Reintroduce regular building of live-build images (!2)
On Sun, Nov 27, 2022 at 06:15:08PM +, Steve McIntyre wrote: ... >Now I can see what you're do in your script, I'm working on merging to >something more current. > >I've just remembered one thing that used to cause major issues with >live-build: multiple image builds in parallel would sometimes trip >over each other. For us on release weekends, this is a critical >featire: we have a large build machine to make things go fast. I hope >this is now fixed in live-build, I guess we'll see! > >Thanks for your work so far! I'm hoping to get something working in >the weekly image builds soon. I've made quite a bit of progress - see my recent commits in the live-setup repo. One thing that I'm not convinced about in your script is building d-i as part of a build, I'd be happier to have the option for grabbing builds from d-i.debian.org like we use elsewhere (for the weekly builds), and then of course we'll pull from the archive directly for release builds. I'll carry on playing tomorrow, I've run out of energy tonight. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: live-setup | Reintroduce regular building of live-build images (!2)
Hi Roland! On Tue, Nov 22, 2022 at 08:40:05PM +, Roland Clobus (@rclobus-guest) wrote: >Roland Clobus created a merge request: !2 > >Project:Branches: rclobus-guest/live-setup:rclobus/reintroduce_live-build to >images-team/live-setup:master >Author: Roland Clobus >Assignees: >Reviewers: > >Build the bookworm images on a regular basis again. > >The script is based on old/run-30live-build and the script that currently runs >in Jenkins I've reviewed and cherry-picked your commit here into master, but I'm afraid there's more work and refactoring needed here. Apologies if you've been misled by the old/run-30live-build script - that's now very outdated and doesn't fit the setup we have. We *used* to start our build VM, then let run-30live-build do all of its work inside the VM, then stop the VM. But (like some of the rest of our scripts!) that didn't parallelise very well, and when I heavily re-factored our build scripts back in 2020 I didn't update this to match. The new setup is driven by a top-level Makefile (Makefile.weekly) that we call with -j, and to make this work well things are organised quite differently. We need the set of desktops listed in that Makefile, and then using Make dependencies and targets: * cause the live-building VM to be started * start separate build processes for -live- * when an architecture's worth of binary builds are all finished: * do the work needed for publishing * build the list of source files needed to match * when *all* the binary builds are done: * stop the VM# * use the source lists for all arches to build source tarballs Now I can see what you're do in your script, I'm working on merging to something more current. I've just remembered one thing that used to cause major issues with live-build: multiple image builds in parallel would sometimes trip over each other. For us on release weekends, this is a critical featire: we have a large build machine to make things go fast. I hope this is now fixed in live-build, I guess we'll see! Thanks for your work so far! I'm hoping to get something working in the weekly image builds soon. -- 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.
Re: Issue installing Debian Live on hardware that supports many other distros
Hi! lucas...@me.com wrote: > >I havenât submitted anything about this previously, as I thought for >whatever reason I was the only user impacted by this issue, but there >seem to be other users posting on Reddit with similar issues which >could be linked. > >My problem is with the Debian 11.4 Live Image installer. > >The installation works like a charm on KVM-based virtual machines (I >have proxmox in my home lab), the issue is that on physical hardware, >it the Calamares installer doesnât write a boot record, leaving the >system in an unboottable state after installation. > >This has occurred with two of my Dell Laptops, an XPS 9575 as well as >a Latitude E5470. Iâve used Legacy and UEFI modes, no >improvement. Both my laptops have no problem installing and running: >Fedora 36, RHEL 8.4 (and clones), Ubuntu 22.04, Manjaro, Pop OS >22.04. Literally every other distro Iâve tested installs fine, the >issue is solely with Debian Live images Hmmm. This sounds suspiciously like a a firmware bug that we've seen before with XPS machines: https://bugs.debian.org/905319 If you boot the live image, could you run "sudo efibootmgr -v" from a terminal and grab the output please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#863180: live-wrapper: Add keyboard shortcuts and revamp menus
Hey Samuel, On Wed, Jun 29, 2022 at 11:47:31PM +0200, Samuel Thibault wrote: >Steve McIntyre, le mar. 25 juil. 2017 00:10:24 +0100, a ecrit: >> >As discussed on >> >https://lists.debian.org/debian-accessibility/2017/04/msg00130.html >> >it would be useful to have keyboard shortcuts in the live boot menu. The >> >attached patch implements it in both isolinux and grub. The shortcuts >> >are marked with '^', so that they can be implemented correctly in >> >syslinux. The patch also revamps the boot menu so as to integrate the >> >whole debian installer options (expert, rescue, auto, speech). >> >> But I'm not so sonvinced about this one. It's making big changes to >> the existing menu structure, particularly moving the main "install" >> options off to a submenu which I don't like. > >Ok, we can just stick to the debian installer main menu, with just the >additional live entries at the top. > >> It's also adding the ^ into menu titles - can we fix that too please? > >? That's expected, these are the keyboard shortcuts, and only shows up >as highlighted letters to document the shortcuts, not as actual ^. > >I'm wondering, though, where this code is living now that live-wrapper >was removed from unstable? live-wrapper is now dead - written in python2 and not maintained for quite a while. My plan is to keep it running on build machines until the EOL of bullseye *only*. We've not made any live images for bookworm at all yet - I turned off live builds when the bookworm cycle started. Roland looks to be interested in picking up live builds again, switching to live-build. I'm hoping he can help you. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Live CD for Debian Jr.
Hi Stefan! Sorry for not responding sooner... On Wed, Mar 23, 2022 at 01:57:44PM +, Stefan Kropp wrote: >Hello, > >I have started to work on a Live CD for Debian Jr. The live CD is >still in status "experimental". Is it possible to build this CD >on a Debian server and put it in a "experimental" / "unstable" >folder or maybe somewhere here [1]. > >To build the live CD, I used the "live-build" package. The files >are one salsa [2]. > >Would be nice if somebody can help me to get a build for >development / testing. We don't currently have anybody looking after live image releases for unstable/testing, but you might get some help on the debian-live list (in CC). -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Questions from a new Debian Live Build user
John wrote: >On 12/02/2022 11:02, Steve McIntyre wrote: >> Roland Clobus wrote: >>> The Debian installer installs from scratch, you can select any desktop >>> environment and other settings, even though they are not present on the >>> live image. >>> Calamares installs a copy of the live environment on your hard disk, and >>> removed the live part afterwards. That's why there are so few questions >>> asked. >>> >>> So depending on the installer part, you might end up with totally >>> different Debian installations. >> >> Sorry, but you're wrong here. The version of d-i that runs on a live >> image *also* installs the exact content of the live image. It runs >> through the normal process of user creation, partitioning, etc. but >> then instead of installing the base system and running tasksel it >> simply unpacks the squashfs onto the new system - see the >> live-installer package if you're not sure. >> >> If the d-i on the live image tried to install packages nowrmally, we'd >> end up having to include a lot of extra .debs into the build to >> support that. > >Live-build config offers the option --debian-installer with choices of >cdrom|netinst|netboot|businesscard|live|none >. Of these I have only used "live", but wouldn't the other choices result in >an iso that did download and install >packages in the normal d-i way? Oh wow, I wasn't aware of the options here. (Apologies Roland!) To the best of my knowledge we've never used anything but the live installer version for official live images. Using any of the other options doesn't seem like a good choice to me; I certainly wouldn't recommend it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Questions from a new Debian Live Build user
Roland Clobus wrote: > > >On 11/02/2022 18:10, Lucas Krupinski wrote: >> Iâve been experimenting with Live Build lately, and am now building my new >> images successfully for the most >part. I do have a couple of questions, though: >> >> 1) When I use lb config to install the Debian installer, and then try to >> launch the installer from the Live Build, >I get an error that the kernel versions of my live and normal builds donât >match. I thought the benefit of Live >Build is that its a repeatable process, but some how Iâm ending up with two >different kernels? > >The installer is totally separate from the regular live content. The >installer is started directly from the boot menu. Occasionally the >kernel version of the installer and the kernel version of Debian drift >apart. I assume that you are creating live builds from bookworm. Right. d-i needs to be built knowing the version of the kernel that's available, so it uses the right package names for kernel modules etc. As that changes, there are (sually short) periods where d-i builds are broken. >> 2) Iâve since abandoned trying to be able to install from the boot screen, >> have installed Calamares to do the >installation, and itsâ working great. >> >> 3) My next question is: I understand that Calamares installs the live image, >> whereas the Debian installer installs >the ânormalâ image. If Iâm only using Calamares, should I be using any >ânormalâ hooks, or is it just >adding time to the build if Iâm replicating my steps between live and normal? > >There is a difference: >The Debian installer installs from scratch, you can select any desktop >environment and other settings, even though they are not present on the >live image. >Calamares installs a copy of the live environment on your hard disk, and >removed the live part afterwards. That's why there are so few questions >asked. > >So depending on the installer part, you might end up with totally >different Debian installations. Sorry, but you're wrong here. The version of d-i that runs on a live image *also* installs the exact content of the live image. It runs through the normal process of user creation, partitioning, etc. but then instead of installing the base system and running tasksel it simply unpacks the squashfs onto the new system - see the live-installer package if you're not sure. If the d-i on the live image tried to install packages nowrmally, we'd end up having to include a lot of extra .debs into the build to support that. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Installing shim-signed:amd64 is met with a "cat: /sys/firmware/efi/fw_platform_size: No such file or directory" error
Hi Derrick! Derrick Karpo wrote: > >I'm using live-build 1:20210407 and on Friday the build worked fine >but today during the build it errored. Note: This may be a shim-signed >issue and not a live-build issue! > > >Setting up shim-signed:amd64 (1.34+15.4-2) ... >cat: /sys/firmware/efi/fw_platform_size: No such file or directory >dpkg: error processing package shim-signed:amd64 (--configure): > installed shim-signed:amd64 package post-installation script >subprocess returned error exit status 1 >Errors were encountered while processing: > shim-signed:amd64 >E: Sub-process /usr/bin/dpkg returned an error code (1) >Setting up shim-signed:amd64 (1.34+15.4-2) ... >cat: /sys/firmware/efi/fw_platform_size: No such file or directory >dpkg: error processing package shim-signed:amd64 (--configure): > installed shim-signed:amd64 package post-installation script >subprocess returned error exit status 1 >Errors were encountered while processing: > shim-signed:amd64 > > >I went into the chroot and when manually installing shim-signed it >still fails. I bind mounted /sys and /dev and the failures still >happen in that it "cat: /sys/firmware/efi/fw_platform_size: No such >file or directory". Apologies, you've hit bug #988059 in shim-signed. I've just uploaded a fixed version to sid which should now work for you. I've been updating the packaging a lot recently to fix other bugs, and added this new one. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Some Debian Live testing
Jonathan wrote: .. > * On the KDE iso, sddm doesn't autologin, so you have to type 'live' >and press enter. I think I saw a bug about this, not sure if there's >still time to fix it. If not, this will have to be a release note. More >of a desktop-base bug, but we also have the default KDE wallpaper >instead of the Debian one. Other than that the KDE live session is in >great shape. Hmmm. We had a problem with sddm quite a while back, and we fixed it. #865382. Is this a regression here, or has something else broken? -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Replacing live-wrapper for live images by live-build?
Hi Roland!
On Wed, Apr 14, 2021 at 12:27:24PM +0200, Roland Clobus wrote:
>Hello Debian-Live list, Debian-Images list, debian-boot list,
>
>About a year ago I wrote [2] about my steps to reproduce the command
>line that is currently used to generate the live images. By then it was
>already clear that live-wrapper needs a replacement.
>
>Steve McIntyre wrote at that time: "The current live-wrapper code, and
>vmdebootstrap, are both basically dead IMHO. I've suggested moving to
>something else supported like FAI instead, like the Debian cloud images.
>highvoltage has other ideas. I'm not working on anything live-related at
>all any more."
>
>In November [1] I wrote to the live list about 'Porting the standard
>image from live-wrapper to live-build'.
>Since then I've continued working on live-build, which is now IMHO in a
>good shape (it even creates reproducible images [3]), but live-build
>would need some final features to be a proper replacement.
>
>These final features can be subdivided in a few categories:
>* Accessibility: better support for speech-synthesis and adding beeps to
>isolinx/grub
>* Localisation: support for running the live image in another language
>starting from the boot
>* Cosmetic: using the official Debian 11 artwork during the boot
>* Branding: the live image might need to differ between 'official' and
>'unofficial' images
>
>Each of these categories can be tackled with reasonable effort, but some
>coordination might be required.
>
>My questions:
>* Has it already been decided what the replacement for live-wrapper will be?
>* If no, would you consider using live-build again?
Thanks for asking, and for your efforts so far. I'm going to be frank
in my response - please don't take this personally!
My experiences with live-build over the years have been so bad that I
personally never want to touch it again [1]. However, if you and
others think it is now a reasonable piece of software, then of course
I'm not going to stand in your way and try to stop you from using it.
My main worry, however, is that we need some *people* (plural) to own
Debian's live builds going forwards: maintaining the software we use
(whatever that might be), running it, debugging it, making and testing
releases with it. In particular, the latter is not a small
undertaking. This is an ongoing commitment.
I've been burned so badly by lack of support here over the years that
I do not want to be involved, beyond simply helping people to get up
to speed on how our infrastructure works. If we don't get a team of
people committed to the work here, I'm planning on simply turning off
live builds. When I asked for developer effort in this area nearly
four years ago, I had lots of responses like "oh no! you can't turn
them off!" from users, but *no* help showed up to do the work of
maintaining them.
[1] In particular, I found that it was incredibly hard to debug
live-build failures due to its design: written in shell fragments,
with "set -e" used so things would just exit on any failure with
no log output. On release days in the past, I ended up having to
go digging into why builds had failed with very little
information, and that caused *massive* amounts of stress.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect."
-- Bruce Schneier
signature.asc
Description: PGP signature
10.5.0 images published
Hi folks, I've just pushed the images for the 10.5.0 point release. As already promised, these will be the right images for people to use including fixes for the UEFI SecureBoot bugs described as "BootHole" [1] There are a couple of image issues that I'm highlighting; I don't think they're big enough to warrant a re-spin at this time: 1. The i386 xfce CD has grown too much and no longer fits onto a standard-sized CD. The image built, but didn't include several critical xfce packages. I have *removed* this image to save people from downloading it and reporting errors. Maybe for the next Buster point release we'll be able to make it fit, but I'm not sure. 2. The Gnome live images work fine as live images and support installation using d-i from the boot menus. However, an update for the Calamares live installer has caused a bug that means it will not work on these Gnome images (both amd64 and i386). It works fine for the other live images. [1] https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. signature.asc Description: PGP signature
Re: Documenting the generation of the live images in Debian
Hi Roland! On Sat, Mar 21, 2020 at 05:27:55PM +0100, Roland Clobus wrote: >Hello Steve McIntyre, Eduard Bloch and lists, > >On 11/07/2019 12:21, Steve McIntyre wrote on debian-live: >> On Thu, Jul 11, 2019 at 03:13:48PM +0700, Azure Zanculmarktum wrote: >>> Where can I find the source to build debian live? ... the live-build >config. >> >> The setup we use is in git: >> https://salsa.debian.org/images-team/live-setup/ >... >> >https://salsa.debian.org/images-team/live-setup/blob/master/available/run-30live-wrapper > >As part of my documentation effort for live-manual, I would like to >include the procedure for the official Debian CD image generation (which >will effectively replace chapter 16) in >https://live-team.pages.debian.net/live-manual/html/live-manual/procedures.en.html > >This mail is rather technical, but I want to document the steps that >I've taken. > >From what I've seen in the live-setup repository [5], there are two >strategies for generating Debian CD images. > >A) Use lb config (run-30live-build) >B) Use lwr (run-30live-wrapper) > >I downloaded 'debian-live-10.3.0-amd64-standard.iso' from [1], which >contains the string 'Official Debian GNU/Linux Live 10.3.0 standard >2020-02-08T12:27'. This string is generated by the run-30live-wrapper >script, so I assume that the official images are generated by method B, lwr. Correct. We used to use live-build up to and including 8.x (Jessie). Then we switched to live-wrapper. >I've read through run-30live-wrapper, and I think by now I have >correctly extracted the commands for the generation of the Debian Stable >CDs, but I'm unsure how to proceed. > >I have the following questions/requests: >* lwr depends on vmdebootstrap, which is currently only in Buster >(stable). According to its author vmdebootstrap is to be replaced by >vmdb2 or something else [2]. Is someone working on this? The current live-wrapper code, and vmdebootstrap, are both basically dead IMHO. I've suggested moving to something else supported like FAI instead, like the Debian cloud images. highvoltage has other ideas. I'm not working on anything live-related at all any more. >* I've seen a huge speed-up when I'm using a ramdisk, but that needs a >merge request to be accepted [3]. > When invoking 'chroot' in live-setup/available/live-customise.sh the >variable TMPDIR must not be set, otherwise it is not possible to >generate temporary files within the chroot. Ah, thanks for mentioning. For some reason I'd not seen any notifications for that. Now merged. >* To reduce the amount of downloads, I am using a slightly patched >version of apt-cacher-ng, in order to be able to use the installer. See >my bug report [4] ACK. On the official build machine we have a local mirror on the host, and the VMs doing the build all point to that. > The live-wrapper script downloads the installer, but apt-cacher-ng >rejects a path ending in a slash. The following command simulates this >download: > > wget -S >"http://localhost:3142/deb.debian.org/debian/dists/buster/main/installer-amd64/current/images/cdrom/; > >* The run-30live-wrapper mentions wheezy and jessie, so it is rather old > >I would like to add to the live-manual the steps to build an image from >the current stable and testing versions of Debian. Do you have >hints/ideas how I can proceed? It sounds like you understand the process well already! -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Problem with EFI install custom Debian ISO
[ Re-added cc to the mailing list, and added debian-live too. I'm not responding in private. ] On Sat, Jan 11, 2020 at 06:57:55PM +0100, Kaisen wrote: >Thank you for your answer, my problem is as follows: >GRUB2 installs correctly with Debian Installer booting on isolinux on a classic >BIOS boot, however when booting on UEFI, the GRUB installation step does not >work indicating that the GRUB installation step failed (it is trying to install >GRUB2 but not grub-efi and shim, the crash therefore makes sense), but I can't >integrate the shim and grub-efi packages on my installer with live-build. This doesn't sounds anything like a "crash" to me. Instead, from what you're saying it sounds like a problem with live-build. You'll need to ask the debian-live folks for support with that, I'm afraid. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Missing Firmware
On Fri, Sep 06, 2019 at 04:37:17PM +0100, Steve McIntyre wrote: >[ Please respond on the mailing lists - that way other people might > see things and help too. ] > >On Thu, Sep 05, 2019 at 12:43:19PM -0400, slow_sp...@att.net wrote: >>In lieu of any other response, I wanted to point out that while the firmware >>may indeed be on the flash drive, the install routine is still not able to >>find it. Therefore the install will not finish correctly. > >ACK, understood. I'm hoping somebody will take a look, but I'm already >busy on other things I'm afraid... Trying again with the correct mailing list address. Today is typo city :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: Dropping older, less-secure checksums files
On Tue, Jul 16, 2019 at 03:58:13PM +0100, Steve McIntyre wrote: >Hey folks, > >We currently make 4 different checksums files for installer, live and >openstack images published from cdimage.d.o (aka get.d.o, cloud.d.o): >MD5SUMS, SHA1SUMS, SHA256SUMS and SHA512SUMS. > >Prompted by a discussion on irc a couple of days back, I'm looking >into dropping generation of the older, less secure MD5 and SHA1 >checksums. I'm planning on leaving these alone for existing releases, >including for future stretch and buster point release builds. But for >regular daily/weekly builds of testing/bullseye images, I'm going to >drop the MD5SUMS and SHA1SUMS files. > >Shout now if you have a problem with that... I've done the work needed in 3 repos and a test build is ongoing now. Looks good so far... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Dropping older, less-secure checksums files
Hey folks, We currently make 4 different checksums files for installer, live and openstack images published from cdimage.d.o (aka get.d.o, cloud.d.o): MD5SUMS, SHA1SUMS, SHA256SUMS and SHA512SUMS. Prompted by a discussion on irc a couple of days back, I'm looking into dropping generation of the older, less secure MD5 and SHA1 checksums. I'm planning on leaving these alone for existing releases, including for future stretch and buster point release builds. But for regular daily/weekly builds of testing/bullseye images, I'm going to drop the MD5SUMS and SHA1SUMS files. Shout now if you have a problem with that... -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: Scheduling 10.1 and maybe 9.10
On Sun, Jul 14, 2019 at 07:35:01PM +0100, Jonathan Wiltshire wrote: >Hi, > >So, the first point release for buster would normally be about a month >after release, or something like 3rd August. But I'm aware that already >doesn't work for some people, so we might have to get a bit creative with >it. > >Please indicate your availablility out of: > > - August 3rd > - August 10th > - August 17th I'm away on a 2-week vacation covering all 3 of those weekend. >and failing those, let's look ahead as far as: > > - August 24th BBQ. Could be tricky! > - Auguest 31st > - September 7th Either of these would work for me. >We also have a point release of 9.10 to fit in some time - would the same >day or adjacent weekends be preferable? Happy to do a double-header again. -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Debian Live source?
On Thu, Jul 11, 2019 at 03:13:48PM +0700, Azure Zanculmarktum wrote: >Where can I find the source to build debian live? I'm not talking >about https://cdimage.debian.org/debian-cd/current-live/source/tar/ >which contains source packages for .deb, but the live-build config. >Also from what I read from Debian documentation, the upstream uses >live-wrapper, the question is did the upstream just execute lwr and >that's it? The setup we use is in git: https://salsa.debian.org/images-team/live-setup/ In particular look at https://salsa.debian.org/images-team/live-setup/blob/master/available/run-30live-wrapper as the core script. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Testing release images - Call for help
On Tue, Jul 02, 2019 at 10:30:37PM +0900, Hideki Yamane wrote: >On Sun, 30 Jun 2019 15:42:09 +0100 >Andy Simpkins wrote: >> [0] https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Buster_r0 > > Links from this page are not found > e.g. https://get.debian.org/images/.buster_release/debian-cd > > > Just two links are okay > https://get.debian.org/images/weekly-builds > https://get.debian.org/images/weekly-live-builds "As we build images during release day, they will appear ready for download." -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Testing release images - Call for help
On Sun, Jun 30, 2019 at 05:34:06PM +0200, Narcis Garcia wrote: >-> >https://get.debian.org/images/.buster_release/live-free > >Not Found > >The requested URL /images/.buster_release/live-free was not found on >this server. ACK, that will only appear when we start things on Saturday. Those images should be *very* close to what's in the current weekly live build: https://get.debian.org/images/weekly-live-builds/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Fwd: debian buster (weekly build of 2019-04-22) ISO-Hybrid LXQt no gui on dell optiplex
Hi Chris, You're better off talking about this on the debian-live mailing list, so forwarding there. On Tue, Apr 30, 2019 at 10:29:51PM +1000, Chris Guiver wrote: >I've included the prior email for reference. > >Testing >https://cdimage.debian.org/mirror/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-lxqt.iso > >dated : 2019-04-29 06:28 > >This week's boots on both >dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt) >dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550) >(mentioned as it failed on the first d755 [e8300,8gb] last week) > >But fails (going to bash shell only) on >dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd >5000/6000/7350/8350) >(booted fine on this box last week) > >I haven't tried yet on the d960 (failed [bash only] using last week's >ISO); it's the machine I'm writing this on and haven't been willing to >reboot to try it today, and it booted to gui on other desktop boxes I >tried, plus all laptops (as per last week's) that I tried it on. > >Same thumb drive used on each machine, and tried at least twice on any >failed machine (non-consecutive, ie. after a successful boot on >another box) like last time. > >Chris Guiver >-- Forwarded message -- >From: Chris Guiver >Date: Fri, 26 Apr 2019 16:29:01 +1000 >Subject: debian buster (weekly build of 2019-04-22) ISO-Hybrid LXQt no >gui on dell optiplex >To: debian...@lists.debian.org > >I've been testing > >https://cdimage.debian.org/mirror/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-lxqt.iso > >dated 2019-04-22 06:17 (copy/paste from web site) > >(I've had troubles getting into #debian-live so apologies for how this >is presented.) > >The Debian Buster (10) LXQt ISO fails to boot into gui (booting into >terminal) on > >dell [optiplex] 755 (c2d-e8300, 8gb, amd/ati radeon rv610/radeon hd2400 pro/xt) >dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd >5000/6000/7350/8350) > >(these are how I report these systems in Ubuntu testing; details being >from `lshw` copy/pasted from a list of hardware) > >however of note I had NO issues on > >dell [optiplex] 755 (c2d-e6850, 5gb, amd/ati radeon rv516/x1300/x1550) >hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290) >hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600) >& others using same thumbdrive (I'm excluding multi-screen issues >already reported, on debian, ubuntu and/or upstream, eg. >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916105) > >The [first] working system was used primarily as example; it's very >similar hardware (same model as one of the failed though it has >different external IO ports so yes it's different and with different >video card). I haven't had issues with any laptop thus far tested. > >There was no `reportbug` on the system, and if you need more >information, or want me to report another way - please just ask. > >Chris Guiver > > -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Scheduling 9.9
On Wed, Feb 20, 2019 at 06:28:05PM +, Jonathan Wiltshire wrote: >Hi, > >Please indicate your availablility out of: > > - April 13 > - April 20 (Easter weekend) I'm away on holiday for both of these, I'm afraid, and so is chief CD tester Andy. > - April 27 But this works. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall signature.asc Description: PGP signature
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hi Matthijs, There's quite a lot of text here - I hope it helps! :-) On Thu, Feb 14, 2019 at 05:18:42PM +0100, Matthijs Kooijman wrote: > >> For feature parity, I'd encourage to look into supporting Secure Boot >> like the grub-efi implementation does, since we are preparing to ship >> that in Debian 10. It's not much extra work on top of adding the rest >> anyway. >Can you elaborate a bit on how grub-efi supports Secure Boot exactly? I >can't really find anything about this in the code? > >Looking at build/scripts/binary_grub-efi and build/scripts/efi-image, I >see that a new efi firmware binary is built using grub-mkimage, so I >suppose that that image is not already signed, and there is nothing >suggesting that image is be signed at that time. Looking at binary_iso >there is also no reference to signing or secure boot. > >AFAIU, to support secure boot, you need to sign the bootloader, >typically using a key from MS. I've read about the Shim bootloader, >which is signed and typically used to then load grub or other >bootloaders (signed by the Debian key or other keys included in Shim). >However, I can see no reference to shim either. > >Looking at the grub package more closely, I *think* that it installs shim >alongside grub when using grub-install, but that is not used here? MS won't sign GRUB directly due to the licensing. So that's one of the reasons why shim was developed. It's a small piece of software which lives entirely in the UEFI environment and can be readily verified. The shim binary shipped by each distro includes a public key *specific to that distro* which is used to verify the rest of the stack that comes afterwards (GRUB -> Linux, normally). Machine Owner Keys (MOK) can be added too, under the control of the Machine Owner (hence the name!) rather than by the distro. GRUB has some knowledge of how SB works, but AFAIK there's not much needed - it's calling into APIs provided by the UEFI platform and shim underneath it. Debian has a shim binary signed by Microsoft, including our own key. We have implemented a process to create signed versions of a very small number of our own packages: * GRUB * Linux * fwupd * fwupdate and you can find those signed versions in the archive in Sid and Buster. In terms of building a grub binary is well-understood, as you can see in the build/scripts/efi-image script in live-build. But that will never give you a signed binary. Instead, if you look in the equivalent efi-image script in the d-i build system you'll see that it's been updated. For some arches (amd64 only so far, with others to come), we still build the grub.efi binary, but where possible we grab the binary directly from the -signed package in the archive so we can keep that signature. For Debian's official live images built with live-wrapper, we just pull in the same files that d-i has created so we inherit the same SB support. >Regardless, how would you suggest we "support Secure Boot" with >syslinux-efi exactly? AFAICT there is no syslinux-efi image available >signed with the MS key, and I suspect it is not signed with the Debian >key or any other key used by shim (also, since syslinux does not seem to >support key verification on kernels, I guess there is no secure way to >get syslinux booting under secure boot without compromising secure boot, >but I might be missing an important point about SB here...). No, you're correct. syslinux is not in a state to do SB at all, and I can't see it happening any time soon. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
[ Gah, missed this bit... ] On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote: ... >Maybe Steve McIntyre can contribute an anecdote how he came to the >decision in debian-cd to use GRUB2 for EFI and thus to create the need >for two independent boot menu configurations. We already had working isohybrid media and I didn't want to drop that - in my opinion it's a very important feature. Plus, when I first started hacking on EFI things back in 2011 (or was it 2012? not sure) I genuinely could not get syslinux to do anything useful with EFI. As I already knew that people had EFI working with GRUB for booting off disk, I went that way and had a prototype running in a couple of days. Hacking on menus etc. was relatvely easy in comparison after that. Once we had that, it was an obvious step to use the same setup on live media as was already known to work on installation media. In fact, one of the projects I've been trying to get to for a couple of years now is simplifying things by going the other way: using GRUB for everything and dropping syslinux on Debian media. I guess I can see the attraction of syslinux, but I don't want to use it any more if I can avoid it. GRUB is massively more flexible and powerful. It's cross-platform (x86, arm32/arm64, sparc, powerpc, mips at least), actively maintained and reasonably well understood by quite a large group of people. It's far from perfect (as we all know!), but I think it's the best solution we have. That's my story for Debian EFI... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Bug#922251: live-build: support syslinux-efi as (additional) bootloader
Hey folks, On Thu, Feb 14, 2019 at 05:35:48PM +0100, Thomas Schmitt wrote: ... >Regrettably there is still no official position towards the failure with >SYSLINUX EFI code booting via El Torito from optical media. >But already the inventor of the "isohybrid" program's --uefi option, >Matthew J. Garrett equipped his Fedora ISOs by EFI software from GRUB2 >together with BIOS software from SYSLINUX. (Plus some HFS+ filesystem >image pointed to by an Apple Partition Map.) >Maybe Steve McIntyre can contribute an anecdote how he came to the >decision in debian-cd to use GRUB2 for EFI and thus to create the need >for two independent boot menu configurations. > >Klaus Knopper, on the other hand, believes that it could work on some >machines. But he tested only with virtual machines and i found no >confirmation that it works on any real iron in native EFI mode from DVD. >See e.g. this 4 GB image: > http://ftp.uni-kl.de/pub/linux/knoppix-dvd/KNOPPIX_V8.2-2018-05-10-EN.iso Ady on the syslinux list has repeatedly argued against people suggesting that syslinux-efi will work for disk/CD hybrid media. I've not looked at the code to see why - I have no desire to, :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: Scheduling 9.7
On Fri, Jan 18, 2019 at 06:44:56PM +, Jonathan Wiltshire wrote: >Hi, > >9.7 is a bit overdue already (current events being a bit of a time-sink). > >Please indicate your availablility out of: > > - (Feb 2 unlikely, FOSDEM) Quite. > - Feb 9 > - Feb 16 Both of those currently look free for 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
Re: Proposed changes to live-tasks
On Wed, Dec 26, 2018 at 09:56:37PM +0200, Jonathan Carter wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA512 > > >Hi Live team > >It's probably a good idea to do some housekeeping on live-tasks ahead of >the upcoming freezes, how about: > >1. Merge MR#1 re-introducing live-task-standard: >https://salsa.debian.org/live-team/live-tasks/merge_requests/1 > >2. Move out calamares-settings-debian from live-task-recommended to >individual desktop-based builds (closes: #900576) > >3. Anyone know why we don't have plymouth on the live desktop images? >Any objection if that's added? Go for it... -- 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.
Re: Are Debian i386 ISOs produced on 32 bit systems ?
On Sat, Dec 08, 2018 at 09:50:12AM +0100, Thomas Schmitt wrote: >Hi, > >i am puzzled by a report of Guix that their ISOs for 32-bit systems come >out truncated by about xorriso's default fifo size of 4 MB. 64-bit is >reported to emerge as complete image. > https://issues.guix.info/issue/33639 > >I now checked that debian-9.6.0-i386-DVD-1.iso and >debian-live-9.6.0-i386-xfce.iso are not truncated. (Whew.) > >So i wonder: >Are Debian's i386 ISOs produced on 32 bit systems ? >(Or is the job done on amd64 ?) Hi Thomas, All our images have been made on amd64 for years now. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Bug#913001: live-wrapper: Handle firmware list more robustly by using proper whitespace split
Contro: tag -1 pending
On Mon, Nov 05, 2018 at 07:50:37PM +, Witold Baryluk wrote:
>Package: live-wrapper
>Version: 0.7
>Severity: normal
>Tags: patch
>
>Hi,
>
>Patch against current master branch in attachement.
>
>"
>Fix splitting of firmare package names
>
>split(' ') literally splits on a single space:
>
>'firmware-a firmware-b'.split(' ') == ['firmware-a', '', 'firmware-b']
>
>Use split() that automatically removes empty elements (equivelent to
>strip + remove if empty), and splits on tabs and newlines.
>
>This makes human provided arguments be handled more robustly.
>"
Apologies for the delay. I've just pushed this change into git
now. It'll also get picked up by our builds from ths point. (Glad I
checked - they were still trying to pull from alioth!)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
Re: building scripts source
On Fri, Dec 07, 2018 at 01:34:27AM +0100, Aissam Hidoussi wrote: >Hello, > >Where I can find the source of scripts used to build the Debian-live images >hosted at https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/ > >i.e., from the log file of the image: debian-live-9.6.0-amd64-gnome.iso >I see that you're using a /w/in/live-customise.sh script along with many >options to generate the iso. Hi Aissam, The git repo at https://salsa.debian.org/images-team/live-setup/ contains the setup we're using. Look in the "available" directory for the live-customise script (for example). -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Question regarding current debian-live downloads
Hi Stefan, On Fri, Nov 16, 2018 at 01:42:47PM +0100, Stefan Baur wrote: > >Three questions, > >1) What are the images on >https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/ >based on? Live-Build or Live-Wrapper? live-wrapper >2) Would it be possible to offer downloads not only for iso-hybrid, but >also for netboot builds again? I firmly believe they were available >previously, and while I didn't need them that often, they proved very >handy when I did need them (especially when there still was a small >rescue-image flavor). live-wrapper has never made that type of image. It's possible to add support, but it's just not happened. You're about the first person I've seen ask for them, so I'm guessing that they're not used very much. >3) Said rescue-image flavor - I think I occasionally saw messages on >this list about people asking for one to be created again, but somehow >it never happened. What needs to be done to make this happen? It needs a couple of things: 1. Somebody to work out a package list and add it to the live-tasks source package for us to use. That list needs to be maintained over time by somebody who cares about it, it's not just a fire-and-forget thing. I spoke to Jose M Calhariz at DC18 and he said he was working on it, but I've not heard anything since July. Then I've just seen a MR mentioned by Steven Monai 2 days ago. 2. Then for that build type to be enabled in the live-setup code that we use for building the live images. This should be a matter of a few minutes at most. HOWEVER... In the longer term, we really need somebody (with DD access) to take over the work of developing and maintaining our official live builds. I asked for help last summer, and although there's been some discussion, I've not seen much work yet. While I've continued to run our setup using live-wrapper and do tests when we do releases, I just don't have the time available to commit to any further development. I'm just too busy elsewhere in Debian to do this. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth signature.asc Description: PGP signature
Bug#909718: debian-live: it is a UEFI 32 only system.
On Sun, Oct 14, 2018 at 12:39:22PM +0200, beta-tester wrote: >Package: debian-live >Followup-For: Bug #909718 > >Dear MaintaineSteve McIntyre, > >my system have UEFI 32 only, a "legacy" BIOS mode does not exist. > >i can not disable SecureBoot. >the Windows System Partition is encrypted by BitLocker on the har drive, >and i saw a video where somebody disabled SecureBoot to boot Linux Live >and after re-enabling SecureBoot later to boot into Windows again, >the system run into BitLocker Recovery mode, >and he had to use BitLocker Recovery to decrypt and re-encrypt everything >again. > >so disabling SecureBoot will destroy the stored BitLocker-key somehow. > >thats because disabling SecureBoot is not an option. OK, so that's a limitation on your system. >why are UEFI32 only tablet/netbook users disadvantaged or excluded >from using Linux / Debian? >i mean to me it looks like it is only a matter of providing proper signed >grub-efi-ai32-signed package or shim-signed or what ever packages are involved. We're working on providing appropriate signed packages for various architectures, but we're not 100% there yet. We already support 32-bit UEFI systems in general, but if something else is stopping you from disabling Secure Boot then that is a blocker *for now*. >or is Debian Linux Live friendly only for big customers with big hardware? I don't understand why you're making that unhelpful comment. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Scheduling 9.6
On Sat, Oct 06, 2018 at 05:24:47PM +0100, Adam Barratt wrote: >On Sun, 2018-07-29 at 08:40 +0100, Steve McIntyre wrote: >> On Fri, Jul 27, 2018 at 09:29:22PM +0800, Jonathan Wiltshire wrote: >> > On Fri, Jul 27, 2018 at 09:20:57PM +0800, Jonathan Wiltshire wrote: >> > > On Fri, Jul 27, 2018 at 06:18:06PM +0800, Jonathan Wiltshire >> > > None >> > > of these work for CDs; let's try for 28th September, and >> > > meanwhile we have schemed to fix the CD SPOF :) >> > >> > Um, that's Saturday 29th Sept of course. Debconf beer gd >> >> As mentioned to Jonathan IRL at DC18, that works better for me. > >That didn't work out so well in the end, and in the meantime we rather >let the ball drop. :-( > >In the interests of getting things moving, some more current >suggestions: > >- October 20th (means freezing next weekend) >- October 27th >- November 3rd >- November 10th All of those work for me... -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#909718: debian-live: bootia32.efi + UEFI32 + SecureBoot => certificate error
On Thu, Sep 27, 2018 at 08:45:17AM +0200, beta-tester wrote: >Package: debian-live >Severity: normal > >Dear Maintainer, > >i have a tablet/netbook with: > >- 32bit UEFI (only), >- SecureBoot enabled, >- 32/64bit CPU, >- Windows 10 Pro (32bit) > >i can't use the live-dvd 64bit, 32bit version nor the multi-arch >(debian-9.5.0-amd64-i386-netinst.iso) to boot LiveDVD or LiveUSB, >because bootia32.efi on the Live iso media isn't signed properly. i >get a signed certificat error at boot time from UEFI. > >on a PC with 64bit UEFI and SecureBoot enabled i don't have that problem. > >why is the bootx64.efi signed properly for SecureBoot an UEFI 64bit, >but bootia32.efi isn't signed properly for SecureBoot an UEFI 32bit ? We don't have Secure Boot enabled for *any* of our 9.x images yet. Your 64-bit PC must have SB disabled, or it's ignoring the lack of signature. Maybe it's booting in BIOS mode? -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Scheduling 9.6
On Fri, Jul 27, 2018 at 09:29:22PM +0800, Jonathan Wiltshire wrote: >On Fri, Jul 27, 2018 at 09:20:57PM +0800, Jonathan Wiltshire wrote: >> On Fri, Jul 27, 2018 at 06:18:06PM +0800, Jonathan Wiltshire wrote: >> > Hi, >> > >> > It's that time again and I'm aiming for 15th September, i.e. freeze on >> > 8th September. Please indicate your availablility out of: >> > >> > - Sept 8th (freeze on the 1st, bit early) >> > - Sept 15th (ideal) >> > - Sept 22nd >> >> None of these work for CDs; let's try for 28th September, and meanwhile we >> have schemed to fix the CD SPOF :) > >Um, that's Saturday 29th Sept of course. Debconf beer gd As mentioned to Jonathan IRL at DC18, that works better for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Scheduling 9.6
On Fri, Jul 27, 2018 at 06:18:06PM +0800, Jonathan Wiltshire wrote: >Hi, > >It's that time again and I'm aiming for 15th September, i.e. freeze on >8th September. Please indicate your availablility out of: > > - Sept 8th (freeze on the 1st, bit early) > - Sept 15th (ideal) > - Sept 22nd Apologies, none of those work for me. I'm off to Vancouver for a VAC then conference trip, away all 3 weekends. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
Re: Missing the rescue CD image, what can I do?
On Wed, Jul 25, 2018 at 04:28:37PM +0100, Jose M Calhariz wrote:
>On Wed, Jul 25, 2018 at 03:27:24PM +0100, Steve McIntyre wrote:
>> That's exactly it, yes. And be prepared to maintain the list
>> as/when/if other people want changes.
>
>OK, I will.
>
>But let me first test the creation of live rescue CD. So I can test
>result in a VM. Does the scripts can run on a testing machine, like
>my laptop? Or do I need to do some changes?
They should do, yes. live-wrapper is the tool to use, and it depends
on vmdebootstrap etc. underneath. From the code used to build our
weekly images (see [1] for context):
lwr $OPTS --architecture $ARCH \
-d $CODENAME \
--isolinux \
--grub \
--log stderr \
--installer ${INSTALLER_VERSION} \
-t live-task-${BUILD} -f "${FIRMWARE_PKGS}" \
--base_debs "${BASE_DEBS}" \
--description "${DESCRIPTION}" \
--volume_id "${VOLID}" \
--image_output ${NAME}.iso
[1]
https://salsa.debian.org/images-team/live-setup/blob/master/available/run-30live-wrapper
--
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Missing the rescue CD image, what can I do?
On Wed, Jul 25, 2018 at 01:36:56PM +0100, Jose M Calhariz wrote:
>
>Just to check I am on the right path. You mean to create a task
>like this:
>
>0 9 SSH-AGENT Wed Jul 25 13:23:50 CWD=~/debian_work/cd-images/live-tasks.git
>cal@riker[582]>git diff
>diff --git a/debian/control b/debian/control
>index b7728a4..a4a2f08 100644
>--- a/debian/control
>+++ b/debian/control
>@@ -357,3 +357,14 @@ Recommends: live-task-localisation,
> Description: Live environment support for Mate
> This metapackage installs packages and documentation to support the Debian
> live Mate environment.
>+
>+Package: live-task-rescue
>+Architecture: all
>+Depends: ${misc:Depends},
>+live-task-base,
>+live-task-recommended,
>+live-task-extra,
>+amanda-client
>+Description: Live environment support for Rescue CD
>+ This metapackage installs packages and documentation to support the Debian
>+ live Rescue CD.
That's exactly it, yes. And be prepared to maintain the list
as/when/if other people want changes.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Re: Scheduling 9.5
On Fri, Jun 08, 2018 at 06:51:18PM +0100, Adam Barratt wrote: >[Cc += debian-kernel] > >On Sun, 2018-05-20 at 12:04 +0200, Joerg Jaspert wrote: >> On 15037 March 1977, Jonathan Wiltshire wrote: >> > - May 26th (meaning freeze this coming weekend, which might be a >> > big >> > ask) >> >> No. >> >> > - Jun 2nd (which may require an unusual SRM) >> >> Possible. >> >> > - Jun 9th (getting quite a way out of cadence, but maybe that >> > can't be >> > helped) >> >> Possible. > >We're past any of the above by now, and while looking through the to-do >list for the final jessie point release, I noticed that we currently >have some packages in opu with versions higher than stable. > >We can either accept the packages and put up with the situation for a >short while, or do 9.5 before 8.11. In practical terms, that would >likely mean both 9.5 and 8.11 on June 23rd, freezing both next weekend. >How do people feel about that? That works ok for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Bug#900576: live-task-recommended: dependency on calamares brings in qt dependencies in every image
Hi Iain! On Fri, Jun 01, 2018 at 03:35:52PM +0100, Iain R. Learmonth wrote: >Package: live-task-recommended >Severity: normal > >Hi, > >Jonathan Carter has recently uploaded version 0.4 for >live-tasks that contains a change adding calamares to all live images. >The primary complaint in this bug report is that this has now introduced >Qt dependencies for every image where they previously did not exist, >including console only images. Hmmm, that's not ideal. >Further, I do not believe that any consultation was made with debian-cd, >debian-boot, or the named Uploader for this package. There was no bug >filed for this discussion either. Jonathan did ask about this on irc and I suggested he go ahead and experiment. Apologies - I should have told him to talk to you/Ana specifically as well. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Scheduling 9.5
On Mon, May 14, 2018 at 06:19:00PM +0100, Jonathan Wiltshire wrote: >Hi, > >We're due a point release any day now. Please indicate your availablility >out of: > > - May 26th (meaning freeze this coming weekend, which might be a big ask) Awkward, but doable. > - Jun 2nd (which may require an unusual SRM) Works for me. > - Jun 9th (getting quite a way out of cadence, but maybe that can't be > helped) Nope, away on VAC. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Scheduling final Jessie point release, 8.11
On Mon, May 14, 2018 at 06:26:08PM +0100, Jonathan Wiltshire wrote: >Hi, > >According to my records main security support for Jessie can end any time >after 17th June. > >So to the security team: do you have a date in mind? > >I also presume that LTS will take over the existing security suites as >before. [1] lists the current delta between security and o-p-u-new which >would ideally be as short as possible before the EOL date. > >For everyone else, assuming it'll be soon after that date please >indicate your availability from: > > - 23rd Jun Looks possible. > - (30th Jun I already know is impossible, for the sake of completeness) ACK :-) > - 7th July Looks possible. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: Current Live Systems Manual still applies to Debian Stretch ?
On Sun, Apr 22, 2018 at 01:03:05PM +, X. wrote: >(As I am not on the list, please reply to me with CC) > >Greetings, > >I am eager to learn how to reproduce Debian 9.4 XFCE official Live Image >using live-build. >However, I have noticed the manual was intended for Jessie: > >https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html#4 > >Everything should still applies to Debian Stretch, but I'm also affraid >about missing any possible steps variance. > >Which ultimately brings me to ask you these questions: > >- Is the "Live Systems Manual"'s current state still applies for Debian >9.4 ? Sorry, no. For older live images (Jessie and older) we used live-build. But for the Stretch live images we switched to using live-wrapper instead. >- Are every steps you do use to build Debian's official Live Image there >in this manual ? >- Is this the whole and only script you're using to build the Debian 9.4 >XFCE official Live Image ?: > >https://salsa.debian.org/live-team/live-images/tree/debian/images/xfce-desktop > >- Since I will check my mistakes through that script, does it still >applies to 9.4 ? The scripts we're using are in https://salsa.debian.org/images-team/live-setup/tree/master/available In particular, look at run-30live-wrapper and live-customise.sh. It's slightly obfuscated by the way things are built inside a VM, but should hopefully be clear enough... -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Reproducing unofficial weekly images?
On Wed, Mar 28, 2018 at 01:02:57AM -0300, Leandro Doctors wrote: >On 25 March 2018 at 05:02, Michael . <keltoi...@gmail.com> wrote: > >Hi, Michael, all, > >Thank you very much for your comments, Michael! > > >> I tried the auto/config method years ago and it just wouldn't work, >> that is the reason I do it the way I do it. > >Hmm... >Is there a way to get the scripts that are currently used for the cron >jobs that generate those images every week on the Debian servers? >I don't see the point in trying to re-invent the wheel... Apologies for the delayed response on this thread - I've been travelling and at a conference with very little time to keep up with email. The current weekly images aren't using live-build, so the suggestions you've had aren't going to help you if you want to reproduce what we have. We're using live-wrapper instead. The scripts we use are in the live-setup git repo: https://salsa.debian.org/images-team/live-setup/ There's complication in there due to the way we build inside a VM, but look at available/run-30livewrapper and available/live-customise.sh for the core of how we build things. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: oficial project files
On Mon, Mar 05, 2018 at 03:33:42PM -0300, Fernando Toledo wrote: >Hi! > >where can i find the commands and files that are used to build the >oficial live images with live-wrapper? Hi Fernando, The config and script are all in the live-setup git repo: https://salsa.debian.org/images-team/live-setup -- 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.
Re: New team on salsa, which repositories shall we migrate?
On Fri, Feb 23, 2018 at 08:28:55PM +0100, Raphael Hertzog wrote: >On Fri, 09 Feb 2018, Steve McIntyre wrote: >> 10 repos moved now: > >I just noticed that you did not setup the email integration with the >package tracker and the hook tagpending. I just did this for all the >repositories. I've no idea how to do that, so thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: New team on salsa, which repositories shall we migrate?
On Sat, Feb 17, 2018 at 08:12:49AM +0100, intrigeri wrote: >Hi, > >Steve McIntyre: >> 10 repos moved now: > >Thanks! > >> debian-live/debian-live live-team/debian-live > >This seems to be an old copy of the live-build repo. >Do we need it? That was what I thought, too, hence I left it. -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Weekly livecd builds broken?
On Sun, Feb 11, 2018 at 12:41:10PM +0100, Clemens Eisserer wrote: >Hi, > >> Clemens Eisserer wrote: >>> https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/ >>> However I don't see any downloadabe images, only .contents and .log >>> files in that directory. >> >> Oops. The page promises >> "The files here are complete ISO images, ready to use." >> >> The .log files, e.g. >> >> https://cdimage.debian.org/cdimage/weekly-live-builds/i386/iso-hybrid/debian-live-testing-i386-cinnamon.log >> show possible reasons: >> >> ERROR command failed: ['vmdebootstrap', '--sudo', ... >> ... >> EEEK! Something bad happened... >> >> The mailing list in charge is >> >> debian-live@lists.debian.org >> >> Please report the problem there. It needs attention. Hi Clemens, There was a problem on the build system and the regular build last Monday failed. We've reconfigured and I'm just doing a manual rebuild right now. Expect new images in a few hours. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Scheduling 9.4
On Sat, Feb 10, 2018 at 12:27:43PM +0100, Julien Cristau wrote: >Hi, > >we shipped 9.3 a couple of months ago, so we're overdue for 9.4. > >Can you please let us know your availability on the following: >- March 3 >- March 10 Both doable for me. >- March 17 >- March 24 I'm away at a conference 15-25, so no for me. >- March 31 Likely to be awkward, with a big family celebration that weekend. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: New team on salsa, which repositories shall we migrate?
On Fri, Feb 09, 2018 at 05:14:29PM +0100, Raphael Hertzog wrote: >Hi, > >On Thu, 08 Feb 2018, Steve McIntyre wrote: >> Happy to do that for all the other debian-live --> live-team repos too >> if people would like me to - just say so. I've done a couple of other > >Please go ahead! 10 repos moved now: debian-live/debian-live live-team/debian-live debian-live/live-bootlive-team/live-boot debian-live/live-build live-team/live-build debian-live/live-config live-team/live-config debian-live/live-images live-team/live-images debian-live/live-manual live-team/live-manual debian-live/live-support live-team/live-support debian-live/live-tasks live-team/live-tasks debian-live/live-tools live-team/live-tools debian-live/live-wrapper live-team/live-wrapper I've disabled pushes on alioth and added rewrite entries for each in AliothRewriter. I'll go through and update Vcs-* fields where it makes sense now, but I'm not going to upload things. I've left out all the "archive" repos and the empty live-www repo. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: New team on salsa, which repositories shall we migrate?
On Thu, Feb 08, 2018 at 06:34:40PM +, Steve McIntyre wrote: >On Thu, Feb 08, 2018 at 06:22:14PM +, Iain Learmonth wrote: >> >>This is the spiritual predecessor to the live-tasks package that >>contained the live-build configurations used to build the live images >>for different desktop environments. If it's not been updated, it should >>probably just be removed. > >NONONONO - the repo is still used for the live-build images we do for >jessie point releases. I'll move it to salsa and update our config to >point there. Done. I've imported to salsa, blocked pushes to alioth and added an entry in AliothRewriter. Happy to do that for all the other debian-live --> live-team repos too if people would like me to - just say so. I've done a couple of other bulk imports for other teams where I'm an owner so I've had some practice! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
Re: debian live (9.2.0) user? + no3d ...
On Wed, Dec 06, 2017 at 11:36:01AM -0500, Albretch Mueller wrote: > After burning onto a DVD: > > amd64/iso-hybrid/debian-live-9.2.0-amd64-kde.iso > > and running it from it, I am confronted with a user selection at start up. > > I have tried: "live" (and many other such combinations) to no avail. >All DL does is clearing the screen every 15 seconds and asking me >again. Apologies, you've been bitten by a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865382 This should be fixed with the new 9.3.0 release due this weekend. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
On Mon, Dec 04, 2017 at 10:50:53AM +0100, intrigeri wrote: >Hi, > >Thomas Goirand: >> After booting a Stretch live image, I tried to upgrade it to Sid, and >> it fails with this error: > >Upgrading a *Live* system from one version of Debian to the other is >arguably a corner case and this bug does not affect the usability of >live-boot in the vast majority of cases. Besides, I would feel wrong >to see live-boot automatically removed from testing merely because of >this bug. So perhaps this could be demoted to severity:important? At best, yes. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Scheduling 9.3
On Wed, Oct 25, 2017 at 05:00:16PM +0100, Adam Barratt wrote: >On 2017-09-24 17:38, Jonathan Wiltshire wrote: >> Hi, >> >> Our target for 9.3 and 8.10 is the first weekend in December (this >> happily >> makes the following target the beginning of February, avoiding the >> festive >> season). >> >> Accordingly I'm looking at one of: >[...] >> 2nd December >> 9th December (but preferably earlier, or we start gradually extending >> the cycle) > >Those both look ok to me. Did we make a decision yet? Both still look OK for me, but my tester helpers are asking! -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Multiarch live CDs
[ Apologies for the delayed response - really realy busy... :-( ] On Mon, Nov 13, 2017 at 11:48:09AM +1100, Michael . wrote: >Live wrapper has replaced live build for official images. >Live build is still being maintained by a Debian Developer (Raphael) and is >being used by the wider community and many Debian based offshoots. >The link you provided for multiarch is a netinst image not a live image. As far >as I am aware Debian has never released a multiarch live image but I am happy >to be proven wrong. Correct. The multiarch images we have are all installer images. We've also now started recommending amd64 images by default instead of the multiarch image for most people (see the link on the front page of www.debian.org). The vast majority of machines built and sold in the last 10 years have been 64-bit capable. >Building a multiarch live image with live build may be possible but you will >need 2 different squashfs filesystems at the very least. It is something I have >wanted to try but have never had the time to sit down and work out all the >different requirements. Nod. For the multiarch installer images, there's at least some overlap between packages (the -all .debs included). For a multiarch live image, and you'd end up having two complete, separate squashfs filesystems on the media. It's not something worth spending time on, IMHO. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Can we get a simple fix for #864927 into unstable/testing please?
On Sat, Nov 11, 2017 at 03:25:29PM -0500, Lou Poppler wrote: >This seems to be OK as of the weekly testing live build of Nov 5, 2017, with >plasma-desktop-data (4:5.10.5-2) > >That live build boots OK here. kde-l10n has been removed from testing, and that looks to have solved the live build problem. Doesn't like the best of ways, maybe? -- 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
Re: Padding and filesystem size in debian-live-9.2.0-amd64-cinnamon.iso
On Tue, Nov 07, 2017 at 08:59:37PM +0100, Thomas Schmitt wrote: >Hi, > >while inspecting debian-live-9.2.0-amd64-cinnamon.iso i wondered why its >ISO 9660 filesystem size is smaller than its image file size. >That's a problem with the advise how to verify ISOs on DVD or USB stick > https://www.debian.org/CD/faq/#verify >because programs "isosize" or "./check_debian_iso" will use the filesystem >size for computing checksums. > >The file /.disk/mkisofs in the ISO tells the reason: >xorriso was used in its native command mode, not in its mkisofs emulation. >This mode by default does not count the padding as part of the filesystem. > >To change to the desired behavior one would have to give command > > -padding included > >or, because the image will never fit on a CD, it is safe to disable padding >and to save 300 KiB of image file size: > > -padding 0 > >The command may be given at any position in the xorriso command list. ACK, thanks! I'll get this fixed up in live-wrapper. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Can we get a simple fix for #864927 into unstable/testing please?
On Fri, Sep 15, 2017 at 06:15:08PM +0100, Steve McIntyre wrote: >It's blocking KDE live builds at the moment... *tumbleweed* Two months later, we still have no fix for this "closed" bug anywhere except experimental. Any chance of this being properly fixed soon? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Can I install from Stretch or Buster Mate Live System?
On Wed, Oct 04, 2017 at 12:28:42PM -0400, Dave Hunt wrote: >Is there a command I can run from these systems that will allow installation >to hard drive? I find nothing on menus or desktop, and the package >'debian-installer' seems not to be in the repository. Also, if I have the >assistive technologies and orca screen readers set to run at start, will the >installed system have accessibility at start? There are options to install directly from the boot menu on those live images. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Scheduling 9.3
On Sun, Sep 24, 2017 at 05:38:51PM +0100, Jonathan Wiltshire wrote: >Hi, > >Our target for 9.3 and 8.10 is the first weekend in December (this happily >makes the following target the beginning of February, avoiding the festive >season). > >Accordingly I'm looking at one of: > >25th November >2nd December >9th December (but preferably earlier, or we start gradually extending > the cycle) > >Please advise your availability. The 25th is really difficult with the Cambridge mini-debconf that weekend, but the other two should be fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
Re: Scheduling 9.2
On Sun, Sep 17, 2017 at 03:20:05PM +0100, Jonathan Wiltshire wrote: >On Mon, Aug 28, 2017 at 09:31:22PM +0100, Steve McIntyre wrote: >> On Sun, Aug 27, 2017 at 04:48:14PM +0100, Jonathan Wiltshire wrote: >> >Hi, >> > >> >I'm working on dates for 9.2; by a two month cycle we're aiming for around >> >23rd September. How about one of: >> > >> >23rd/24th September >> >30th Septmber/1st October >> >> I'm out in San Francisco for the week ib between them. I can't do the >> first weekend, but might be able to do the second while >> jetlagged. Another weekend would be preferred, though > >Ok, does 7th October work any better? I'm keen not to get too far adrift >from the interval though. Works fine for me, yep. -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Bug#866364: Partial implementation of live boot localisation
On Tue, Aug 29, 2017 at 12:07:44PM +0200, Raphael Hertzog wrote: >Hello, > >On Thu, 29 Jun 2017, Narcis Garcia wrote: >> No keyboard localisation when choosing "Debian Live with Localisation >> Support". For example, choosing "Spanish" at this boot submenu, keyboard >> is set to an USA layout (in any X, TTY and pty). >> >> Keyboard layout should do same associations as Debian-Installer suggests >> for choosen language. > >What are you referring to? > >live-config is a generic tool that integrates in the boot sequence, the >boot menu is not under its control and it's definitely not responsible >of the "Debian Live with Localisation Support" thingie that you are >speaking of. > >I'm tempted to close this bug right away but maybe it must be reassigned >somewhere so please let us know what live image you did use for your test. > >Where did you get it from? If its a custom image, what tool did you use >to build it? It's something that live-wrapper generates, so it's in the official Stretch images. Unfortunately, as we can see, it's not complete - it would need more work in live-config to make it properly functional. -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Please consider to let live-build add file /.disk/mkisofs to the ISO
On Fri, Jul 28, 2017 at 12:17:17PM +0200, Thomas Schmitt wrote: >Hi, > >please consider to include a /.disk/mkisofs file in the resulting ISO >of live-build, like debian-cd does. Hi Thomas, I've just added support for this in live-wrapper. I'll let Raphaël do the changes in live-build. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#865382: Possible solution of #865382
On Wed, Jul 26, 2017 at 12:56:17PM +0300, Алексей Шилин wrote:
>Hi,
>
>I've investigated this issue a bit, and it looks like there are actually two
>things to look at:
>
> 1. Live user doesn't log in automatically.
>
> This is due to autologin not being configured for SDDM by live-config
> scripts. In fact, there is no script to
> configure SDDM at all.
>
> 2. When one enters the password ("live" by default), session startup fails.
>
> Looks like this is connected to the previous one. As there is no script
> which configures SDDM, nothing prevents
> xinit configuration script (/lib/live/config/0140-xinit) from being run,
> which installs the following snippet to
> /etc/profile.d/:
>
>if [ -z "${DISPLAY}" ] && [ $(tty) = /dev/tty1 ]
>then
>while true
>do
>if grep -qs quiet /proc/cmdline
>then
>startx > /dev/null 2>&1
>else
>startx
>fi
>done
>fi
>
> Given that console autologin is enabled by default, this script tries to
> start the X server in infinite loop. Under
> certain circumstances this interferes with normal session startup by the
> display manager, leading to the issue
> described above.
>
> Indeed, if one starts the system with "nottyautologin" boot option, the
> issue vanishes, and it becomes possible to
> successfully log in after typing the default live user password.
>
>I've attached a patch for live-config which adds SDDM configuration script. It
>*should* solve both issues. However,
>testing is required.
Thanks very much, this seems to be exactly the fix needed. I've just
tested it now... :-)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.
Re: zsync support for jessie but not for stretch
On Mon, Jul 24, 2017 at 08:35:17AM +0200, igo...@free.fr wrote: >Hi, > >Is there a reason for stretch not having zsync support? > >jessie had and still has: > >https://get.debian.org/images/archive/8.9.0-live/amd64/iso-hybrid/ > > debian-live-8.9.0-amd64-standard.iso.zsync2017-07-23 15:04 1.4M > >It saves bandwidth! Does it work well? We tried zsync for the installer images some time ago, and it didn't work too well at the time and I disabled it again. IIRC there were issues with the redirects and the setup we use on cdimage.d.o (aka get.d.o)... See #444159 -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#865382: [st...@einval.com: Please help with #865382]
On Fri, Jul 21, 2017 at 03:30:24PM +0100, Steve McIntyre wrote: >On Fri, Jul 21, 2017 at 11:17:54AM -0300, Lisandro Damián Nicanor Pérez Meyer >wrote: >>On viernes, 21 de julio de 2017 15:00:46 -03 Steve McIntyre wrote: >>[snip] >>> >I have taken a look at #865382 (CCing) but I see no further info. Is there >>> >a backtrace available? >>> >>> Unfortunately, no. It's not the easiest thing to work on in the live >>> environment. I was hoping that you (plural!) might have more >>> experience and could possibly suggest some tips to help debug this at >>> least... >> >>I've talked to maxy trough IRC and he said we should try the live ourselves. >>I >>can't promise anything but maybe I get to it during the weekend. > >If you can, that would be great. We're going to be doing 9.1 this >weekend so that's most likely going to show the same problem I >expect... It does. I've managed to grab an X logfile off - attached. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine. [ 140.602] X.Org X Server 1.19.2 Release Date: 2017-03-02 [ 140.602] X Protocol Version 11, Revision 0 [ 140.602] Build Operating System: Linux 4.9.0-3-amd64 x86_64 Debian [ 140.602] Current Operating System: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 [ 140.602] Kernel command line: BOOT_IMAGE=/live/vmlinuz-4.9.0-3-amd64 initrd=/live/initrd.img-4.9.0-3-amd64 boot=live components [ 140.602] Build Date: 07 July 2017 06:14:06AM [ 140.602] xorg-server 2:1.19.2-1+deb9u1 (https://www.debian.org/support) [ 140.602] Current version of pixman: 0.34.0 [ 140.602]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 140.602] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 140.602] (==) Log file: "/home/user/.local/share/xorg/Xorg.1.log", Time: Sun Jul 23 00:56:52 2017 [ 140.603] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 140.604] (==) No Layout section. Using the first Screen section. [ 140.604] (==) No screen section available. Using defaults. [ 140.604] (**) |-->Screen "Default Screen Section" (0) [ 140.604] (**) | |-->Monitor "" [ 140.604] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 140.604] (==) Automatically adding devices [ 140.604] (==) Automatically enabling devices [ 140.604] (==) Automatically adding GPU devices [ 140.604] (==) Max clients allowed: 256, resource mask: 0x1f [ 140.604] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 140.604]Entry deleted from font path. [ 140.604] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 140.604] (==) ModulePath set to "/usr/lib/xorg/modules" [ 140.604] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 140.604] (II) Loader magic: 0x55ef70af4e00 [ 140.604] (II) Module ABI versions: [ 140.604]X.Org ANSI C Emulation: 0.4 [ 140.604]X.Org Video Driver: 23.0 [ 140.604]X.Org XInput driver : 24.1 [ 140.604]X.Org Server Extension : 10.0 [ 140.605] (++) using VT number 1 [ 140.608] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_33 [ 140.609] (II) xfree86: Adding drm device (/dev/dri/card0) [ 140.610] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 1 [ 140.610] (EE) Error systemd-logind returned paused fd for drm node [ 140.610] (II) systemd-logind: releasing fd for 226:0 [ 140.613] (--) PCI:*(0:0:2:0) 8086:0126:17aa:21da rev 9, Mem @ 0xf000/4194304, 0xe000/268435456, I/O @ 0x6000/64, BIOS @ 0x/131072 [ 140.613] (II) LoadModule: "glx" [ 140.614] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 140.615] (II) Module glx: vendor="X.Org Foundation" [ 140.615]compiled for 1.19.2, module version = 1.0.0 [ 140.615]ABI class: X.Org Server Extension, version 10.0 [ 140.615] (==) Matched modesetting as autoconfigured driver 0 [ 140.615] (==) Matched fbdev as autoconfigured driver 1 [ 140.615] (==) Matched vesa as autoconfigured driver 2 [ 140.615] (==) Assigned the driver to the xf86ConfigLayout [ 140.615] (II) LoadModule: "modesetting
Bug#869379: Images created without pulling in from 'updates' and 'security' repos
On Sat, Jul 22, 2017 at 04:18:31PM -0500, Jeff Epler wrote:
>On Sat, Jul 22, 2017 at 09:43:40PM +0100, Phil Wyett wrote:
>> Images created without pulling in from 'updates' and 'security' repos.
>>
>> This leaves images very out of date. Images should have all the latest
>> packages.
>
>In linuxcnc's stretch image, I compensate for this in customise.sh by adding an
>additional list within sources.list.d before the first packages:
>
>cat > ${rootdir}/etc/apt/sources.list.d/updates.list <deb http://ftp.debian.org/debian stretch-updates main contrib non-free
>deb http://security.debian.org/debian-security stretch/updates main
>EOF
>
>and also I add a step where I
>
>chroot ${rootdir} apt-get -y dist-upgrade
>
>to upgrade any packages that had been installed previously by
>vmdebootstrap.
Yes, it's the obvious workaround. As discussed with Phil in IRC, on a
system installed from the live images updates and security are enabled
appropriately so they're fine. I'm not sure of the best approach for
*live* live images - will people be massively annoyed by the system
stopping and demanding security updates as it boots?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Topic of this list (was: live-build: how to include .deb files not in any repository?)
On Fri, Jul 21, 2017 at 12:49:04PM -0400, PICCORO McKAY Lenz wrote: >i was my faul too, i not specified what i using, as i understand one of that >command/packages are deprecated right? live-build is the older tool that a lot of people are still using. For official Debian images we've switched over to using live-wrapper instead for Stretch onwards. >for debian wheeze what are recomended? live-build backporte or live-wrapper >backported ? If you're still targeting wheezy, then I'd suggest sticking with live-build. I'm curious why wheezy still, though - that's getting very old now... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Bug#865382: [st...@einval.com: Please help with #865382]
On Fri, Jul 21, 2017 at 11:17:54AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: >On viernes, 21 de julio de 2017 15:00:46 -03 Steve McIntyre wrote: >[snip] >> >I have taken a look at #865382 (CCing) but I see no further info. Is there >> >a backtrace available? >> >> Unfortunately, no. It's not the easiest thing to work on in the live >> environment. I was hoping that you (plural!) might have more >> experience and could possibly suggest some tips to help debug this at >> least... > >I've talked to maxy trough IRC and he said we should try the live ourselves. I >can't promise anything but maybe I get to it during the weekend. If you can, that would be great. We're going to be doing 9.1 this weekend so that's most likely going to show the same problem I expect... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#865382: [st...@einval.com: Please help with #865382]
On Thu, Jul 20, 2017 at 11:23:29PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: >On miércoles, 19 de julio de 2017 22:51:22 -03 Steve McIntyre wrote: >> Stuart suggested I was asking on the wrong list, so forwarding here... > >Right :-) > >> From: Steve McIntyre <st...@einval.com> >> Date: Mon, 10 Jul 2017 00:09:40 +0100 >> To: debian-...@lists.debian.org >> Cc: debian-live@lists.debian.org >> Subject: Please help with #865382 >> X-attached: unknown >> >> [ Let's see if this works better without a typo in the To: line... :-( ] >> >> Hey folks, >> >> We have a big problem with our Stretch KDE live images, and the >> problem seems to be KDE-specific. None of the other desktops show the >> same problem. Can you help please? > >(mostly a Qt packager here, but...) > >I have taken a look at #865382 (CCing) but I see no further info. Is there a >backtrace available? Unfortunately, no. It's not the easiest thing to work on in the live environment. I was hoping that you (plural!) might have more experience and could possibly suggest some tips to help debug this at least... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Re: Topic of this list (was: live-build: how to include .deb files not in any repository?)
On Fri, Jul 21, 2017 at 09:12:16AM +0200, Andreas Heinlein wrote: >> >Sorry for hijacking this thread, but the two answers above are a good >example of the problem I see on this list - what is the topic of this >list now? > >At the moment, debian-live@lists.debian.org is the "Maintainer Address" >of both live-build and live-wrapper. So we see that user A asks a >question, user B gives an answer which is probably correct for >live-wrapper, and user C gives another answer which is correct for >live-build. From the topic here, we can assume that user A is using >live-build and that user B has overlooked this, but it's not always clear. > >What can we do about this? Should the list be split? At least we should >ask users to clearly indicate what they are using, e.g. by adding a >'tag' in the subject like '[live-build] ...'. What do you think? I don't think we necessarily need to split the list, but at least making it very clear in the subject line sounds like a good plan. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
Re: RFS: live-wrapper/0.6+nmu2
On Sat, Jul 15, 2017 at 04:35:25AM +0100, Phil Wyett wrote: >Package: sponsorship-requests >Severity: important > >Dear mentors, > >I am looking for a sponsor for an update to the package "live- >wrapper": > >* Package name: live-wrapper > Version: 0.6+nmu2 > Upstream Author : Debian Live - debian-live@lists.debian.org >* URL: https://debian-live.alioth.debian.org/live-wrapper/ >* License: BSD, GPLv3 > >This update addresses: > >* Remove incorrect instance of converting to UTF-8. >* Eliminate 'pyversions' warnings at build time. >* Add 'python-requests' build dependency. Fixes docs build. >* Add 'squashfs-tools' dependency. (Closes: #867282). > >Last entry relates to RC bug: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867282 > >Source can be obtained from: > >https://kathenas.org/debian/package_uploads/ > >Signing key: > >https://keyserver.ubuntu.com/pks/lookup?op=vindex=philwyett%40k >athenas.org=on In incoming now, and imported on my master branch ready for pushing as soon as I've got git access sorted. Thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Bug#864955: live-boot: Non ASCII chars aren't displayed correctly
On Sun, Jun 18, 2017 at 02:45:54AM +0200, Antoni Villalonga wrote: >Package: live-boot >Version: 1:20170112 >Severity: normal > >Dear Maintainer, > >Testing stretch live kde some non-asci chars are shown incorrectly. > >I've found that console-setup is configured iso-8859-15 instead of utf8. >Switching to utf8 solves the problem. That's a start, but things are rather more complicated. At the moment the live setup is only setting locale. It works for display on the X desktop, but: * as you've discovered it doesn't work on the console * it's not selecting an appropriate keyboard layout, either under X or on the console To get all this *right* will be a major undertaking, I think. We *could* simply add a default keyboard layout to the setup for each language as well, but that's quite likely to be wrong for a lot of users... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Latest master code tree for live-wrapper
On Tue, Jul 11, 2017 at 02:14:02AM +0100, Phil Wyett wrote: > >The pettersson tree seems to be missing the 0.6 nmu1 patch: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861994#24 > >Is this intentional? Better to ask the question now. :-) Well spotted. :-) It's not a deliberate oversight, I've just not taken it yet. I was working directly on the code changes in live-wrapper rather than the packaging thus far. I'll make sure that all is merged... -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Please help with #865382
[ CC to the right list this time, gah ] Phil wrote: >-=-=-=-=-=- > >On Mon, 2017-07-10 at 00:04 +0100, Steve McIntyre wrote: >> Hey folks, >> >> We have a big problem with our Stretch KDE live images, and the >> problem seems to be KDE-specific. None of the other desktops show >> the same problem. Can you help please? > >Hi, > >Can you indicate some of the issues as you know them at this time? Hi Phil, The issues I'm aware of currently are listed in http://get.debian.org/images/release/current-live/amd64/iso-hybrid/ but specifically the one I'm hoping to get help with from the KDE folks is issue #1 there: KDE live desktop unstable on some (tested) hardware Status: still a problem with 9.0.1 There is a segmentation fault in kmanage - the first obvious symptom will be a failure to automatically log in. A workaround is to switch to VT1 and wait for the desktop to start there. This has been reproduced on hardware (using Intel graphics?), but not when testing in a virtual machine. See #865382. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: Latest master code tree for live-wrapper
Phil wrote: > >Where is the latest version of development code for testing? I've been working on a development branch at https://git.einval.com/cgi-bin/gitweb.cgi?p=live-wrapper.git;a=shortlog;h=refs/heads/pettersson_production_changes I'm hoping to get changes merged and a new 0.7 release out shortly... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Please help with #865382
[ Let's see if this works better without a typo in the To: line... :-( ] Hey folks, We have a big problem with our Stretch KDE live images, and the problem seems to be KDE-specific. None of the other desktops show the same problem. Can you help please? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Please help with #865382
Hey folks, We have a big problem with our Stretch KDE live images, and the problem seems to be KDE-specific. None of the other desktops show the same problem. Can you help please? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Scheduling 9.1, maybe 8.9
On Sun, Jul 02, 2017 at 09:53:13PM +0100, Adam Barratt wrote: >[sorry for the delay in replying] > >On Sun, 2017-06-25 at 20:10 +0100, Jonathan Wiltshire wrote: >> Hi, >> >> A month or so from 9.0 bring us to about 15th July. How would any of these >> suit? Is 8.9 at the same time feasible? > >It's worked before. > >> 8/9 July (probably a bit soon) > >Definitely now too soon, and didn't really work for me anyway. > >> 15/16 July >> 22/23 July >> >> [SRMs: needs one of you too please :) ] > >One of those should work for me. Working out which is currently blocking >on other people. :| Can we get a decision please? Summer weekends are busy... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Use of '--sudo' in vmdebootstrap; live-wrapper package
On Wed, Jul 05, 2017 at 01:10:33AM +0100, Steve McIntyre wrote: >Phil wrote: >> >>In a previous mail I mentioned removal of '--lock-root-password'. >> >>On the same line (36) of 'vm.py' is the argument passed to >>'vmdebootstrap' of '--sudo'. Ok, according to the manual pages this >>will force the install of the 'sudo' package. Also if a user is >>created, it will add them to the 'sudo' group. >> >>However, under 'live-wrapper' I see no user creation at >>'vmdebootstrap' creation time, thus this leaves us with 'sudo' >>installed but any user created at install of the end result ISO image, >>not part of the 'sudo' group. >> >>I see the primary purpose of the correct usage is to create a username >>and password that can be used while running in live mode. >> >>Example: >> >>vmdebootstrap --user=debian/debian --sudo >> >>The above would create a user 'debian' with password 'debian' who can >>use 'sudo' whilst running in live mode; and it is probably this >>behaviour we would want? > >Not really, no. There's a special live-specific sudo config file >/etc/sudoers.d/live which gives sudo rights to the live user without >password. > >If you're trying to track down the su/sudo problem with the live >installer, that's somewhere different. The installer is meant to write >changes to the passwd/shadow/sudoers files at the end of the >installation, and that does't seem to be working. I've been too busy >in the last few days to look into that any deeper. In fact, I've found the problem now. vmdebootstrap explicitly locks the password for root in /etc/shadow using "passwd -l". That changes the crypted root passwd from "*" to "!*". Later on, user-setup-udeb in the installer only looks for a locked root account containing "*". It doesn't recognise the "!*" and assumes that's a valid password so doesn't change it. I'll get user-setup-udeb fixed, but for now I have a quick-hack fix in live-customise.sh to replace '!*' with '*'. All works after that point. \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: IMPORTANT: Do live Debian images have a future?
metalsm...@rangeweb.net wrote: >-=-=-=-=-=- > >I would like to know what is wanted in testing these images. The >installer itself I am sure. But what else is really desired? > >I am sure that there is a list of test cases somewhere but it would be >nice to know where that is. That's one of the missing pieces, I'll be honest - we *don't* have a sensible list of test cases to help evaluate images. If you'd like to help right now, this would be a good thing to start with. A page in the Debian wiki would be lovely. :-) As a start, my own simple testing for the last few years has basically been: * does the image boot to a sensible-looking desktop? * can I start a browser? * will it load and display http://news.bbc.co.uk/? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: IMPORTANT: Do live Debian images have a future?
On Tue, Jul 04, 2017 at 04:25:48AM -0700, Rick Thomas wrote: > >On Jul 3, 2017, at 8:53 AM, Steve McIntyre <st...@einval.com> wrote: > >> arm64 >> live images are on my todo list already for the buster cycle. > >Great! Will they work with RaspberryPi-3? I honestly have no idea. :-) Let's find that out when we get there... -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: IMPORTANT: Do live Debian images have a future?
On Mon, Jun 26, 2017 at 02:09:00PM -0700, Rick Thomas wrote: >I'm a user and a tester, not a dev, and I know nothing (and don't >want to know anything) about the personal politics between Debian >developers. So that's all I'll say on that subject. > >To Steve's original point: > >First, a big THANK YOU! to Steve for taking this job on. I, for one, >an grateful. > >I use Debian a lot, but I'm only an occasional user of the Debian >Live images. But when I need them, I need them. And when I need >them, I want them to just work. If having them there and working when >I need them means I have to add them to my list of things to test and >report on, I'm willing to make that investment. > >Please add me to your "testers" list. Thanks! >PS: On a related topic: What I think would be really cool, would be >Debian Live images for some of the ARM architectures. Something I >could dd to a USB stick and boot right away when I get a new box in >for testing. Even cooler would be the ability to use that self-same >live image to install Debian after the testing phase was over. We have some armhf images for installation, but not for live yet. The hard bit there is reliably *booting* an image on many of the platforms. As more and more of them start supporting UEFI (if nothing else, via the minimal U-Boot UEFI boot hacks) that will help. arm64 live images are on my todo list already for the buster cycle. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: IMPORTANT: Do live Debian images have a future?
On Tue, Jun 27, 2017 at 03:47:13PM +0530, shirish शिरीष wrote: >On 26/06/2017, Steve McIntyre <st...@einval.com> wrote: ... >> If our live images are going to be good enough to meet the standards >> that Debian users deserve and expect, we need *consistent*, >> *sustained* involvement from a lot more people. Please tell me if >> you're going to help. If we don't see a radical improvement soon, I'll >> simply disable building live images altogether to remove the false >> promises they're making. >> >> [1] >> https://get.debian.org/images/release/current-live/amd64/iso-hybrid/#issues > >One of the things at least to my mind is we (the users) do not know >which is most closest testing release near to the final release. For >e.g. take the last/latest announcement done by Cyril Brulebois on >13th June talking about the Stretch RC5 release. In the whole >announcement, there is not even a hint to potential testers that this >might be the closest to the final released (gold) image. I am >presuming/assuming that Cyril was also talking about the live image >and not the just the installer improvements. Actually, no. Cyril is the d-i release manager (and most active developer), and that's what he's focussing on. The "Stretch d-i RC5" announcements were specifically for d-i, not for Stretch as a whole. The final *Stretch* release was under the control of the release team, obviously with attendant discussion with the installer and images people too. >What would be nicer/better perhaps if debian-live does announcements >on d-d-a and more importantly hint as when it's going to be nearer to >release (final image). ACK. We need more effort to do this kind of thing, and volunteers to help drive it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Scheduling 9.1, maybe 8.9
On Sun, Jun 25, 2017 at 08:10:04PM +0100, Jonathan Wiltshire wrote: >Hi, > >A month or so from 9.0 bring us to about 15th July. How would any of these >suit? Is 8.9 at the same time feasible? > >8/9 July (probably a bit soon) Impossible for me, I'm busy all weekend. >15/16 July >22/23 July Both look fine for me. I'm happy to do 8.9 on the same weekend, but media will take a short while to come out after 9.1. The first point release always throws up surprises IME... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
New live images released (9.0.1)
Hi folks, We found multiple issues in the live images released at the weekend. Since then, I've been working on fixes for the worst problems. I've just published a new set of images as 9.0.1. Here's a summary of the issues found, and current status: 1. KDE live desktop unstable on some (tested) hardware == Status: still a problem with 9.0.1 There is a segmentation fault in kmanage - the first obvious symptom will be a failure to automatically log in. A workaround is to switch to VT1 and wait for the desktop to start there. This has been reproduced on hardware (using Intel graphics?), but not when testing in a virtual machine. See #865382. 2. Live images isolinux menu display problems = Status: Fixed in 9.0.1 When booted in BIOS mode (using isolinux), some of the localisation options from the "Debian Live with Localisation Support" submenu are displayed incorrectly. They may appear intermittently and then disappear. They can still be selected and used and will work - just be careful when selecting one. See #861421. 3. Live images are not configuring UTF-8 console correctly == Status: still a problem with 9.0.1 After boot, X-based terminal programs will display non-ASCII characters correctly, but the Linux console does not. The system is configured to use UTF-8 locales, but the console is defaulting to ISO-8859-15. There is a quick workaround: "dpkg-reconfigure console-setup" and select "UTF-8". See #864955. 4. Installation from the live image boot menu does not work === Status: Fixed in 9.0.1 There is a bug in the Packages files included on the live images, causing the included Debian Installer code to fail with the error "There was an error reading data from the CD-ROM. Please make sure it is in the drive. If retrying does not work, you should check the integrity of your CD-ROM." See #865015. 5. Incorrect Volume ID used for all live images === Status: Fixed in 9.0.1 live-wrapper does not currently set the Volume ID on images it creates, so they use the default supplied by xorriso: "ISOIMAGE". See #865384. 6. The root directory of the live images has very restrictive permissions = Status: Fixed in 9.0.1 The root directory is mode 0700 (i.e. drwx--) See #865386. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall signature.asc Description: PGP signature
Bug#865386: Overly tight permissions on the root of images made with live-wrapper
Source: live-wrapper Version: 0.6+nmu1 Severity: minor The root directory of the ISO image is mode 0700 (i.e. drwx--). This is clearly coming through from the temporary directory it's derived from, created using tempnam. This is rather silly and pointless, but hardly critical. Patch coming soon. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#865384: Volume ID not set
Source: live-wrapper Version: 0.6+nmu1 Severity: important live-wrapper doesn't specify a Volume ID when calling xorriso, so all its output images will end up with the xorriso-default Volume ID "ISOIMAGE". Patch shortly... -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#865382: Stretch KDE live image is not stable
Package: debian-live Severity: important When tested on (some) real hardware, the 9.0.0 and 9.0.1 live images containing the KDE desktop are unstable, exhibiting crashes. There is a segmentation fault in kmanage - the first obvious symptom will be a failure to automatically log in. A workaround is to switch to VT1 and wait for the desktop to start there. This has been reproduced on hardware (using Intel graphics?), but not when testing in a virtual machine. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
