Bug#981393: ltsp: Unable to generate image
Hello Peter, On 2/4/21 12:23 PM, Mgr. Peter Tuharsky wrote: > I hope the program or the documentation should give the information. A broken passwd should have been reported long ago by any of the tools that handle passwd, e.g. init, login, sudo, pam, gdm... You may file bug reports there for such a message. LTSP is the 5th wheel there, the python exception handling system is kind enough to show us the full call stack and pinpoint the problem, but we can't catch thousands of exceptions and write specific messages for any unrelated-to-ltsp problem that a system might have. Apart from the huge effort that would involve, it would also make the LTSP code unreadable. So IMHO the best approach is to use python exceptions like this one, and I've also set up a similar thing in shell, where the "re() - Run or die and show the Error" function tells which shell command fails. E.g. LTSP will tell you "LTSP command failed: cp blah blah", but it won't bother to check and tell you that cp failed because your SSD is dying; that's a task for a different package, not LTSP. Now if someone could properly close this bug report as I'm a bit time pressed currently to search how to do it... :D Cheers!
Bug#981393: ltsp: Unable to generate image
Hello, if at all possible, please use the following bug trackers for LTSP, for any distribution or version: For bugs: https://github.com/ltsp/ltsp/issues For discussions: https://github.com/ltsp/ltsp/discussions For example, I assume that the problem in this case is that you manually edited your /etc/passwd or /etc/group at some point, and now they're invalid. You may use `pwck` and `grpck` to locate the errors and fix them. On github, we could easily move this issue into discussions, but we can't do that here. Distribution bug trackers should still be used for distro-specific tasks though, such as managing backports or notifying about broken dependencies etc. Cheers, Alkis
Bug#979261: Stop using deprecated systemd-resolve tool
I committed a patch for this in https://github.com/ltsp/ltsp/issues/367. I'll leave it up to vagrantc to see if he prefers to do a 21.01-2 release + upload, or an ltsp 22.01-1 backport to bullseye next year right after that release, or we could just tell bullseye+backports ltsp users to get the newest ltsp from the upstream ppa (https://ltsp.org/docs/ppa/). Thanks!
Bug#979261: Stop using deprecated systemd-resolve tool
Hello Michael, thank you very much for both the issue and the patch; I would prefer to postpone its integration to LTSP until its next version in a few months, for the following reasons: * We released LTSP 21.01 a couple of days ago, in time for bullseye. It would be time-saving to apply the patch in the next release. * LTSP is used for netbooting various distributions and versions. So one can e.g. netboot debian-stretch.iso from a bullseye server; in that case, the patch would break their DNS there. So it's best to be as backwards-compatible as possible. * So, if it doesn't cause any ill effects, I would like to push a patch that makes LTSP use resolvectl but fall back to systemd-resolve, in a few months, when the next LTSP version will be released. I also reported this upstream in https://github.com/ltsp/ltsp/issues/367. Thanks again!
Bug#965126: p7zip processes OEM file names in .zip archives incorrectly
I confirm that the issue exists, and that the proposed patch addresses it. As many tools like GNOME's file-roller and MATE's engrama call p7zip, this issue is very important, and tens of bug reports have been filed over the years in various applications and bug trackers about it. This patch will indirectly solve all of them. Upstream p7zip hasn't been active in recent years, but the proposed patch has already been accepted in szcnick's p7zip more actively maintained fork: https://github.com/szcnick/p7zip/commit/e56ea97d89eb0cd59603402496a8208238b3fda2 It'd be great if we had this included in bullseye.
Bug#964526: epoptes-client: replace transitional bsdmainutils dependency
Thank you Chris, I completely removed the dependency upstream. Code line: https://github.com/epoptes/epoptes/commit/3ae07f57b88a8fb7d105bc92932f01d6d7a5a493#diff-257532fb77e85e27ac57919f5ef74a1fR367 debian/control line: https://github.com/epoptes/epoptes/commit/3ae07f57b88a8fb7d105bc92932f01d6d7a5a493#diff-d837a1c17de0268bcea321239ddbed47L53 We'll make a new epoptes release later on before bullseye freezes, so I guess this bug should be closed then. Cheers, Alkis
Bug#962161: Please use ipxe.efi under UEFI
Package: win32-loader Version: 0.10.0 Severity: important Hi, thank you very much for the initial UEFI support! Unfortunately, when I selected: PXE mode: install a PXE loader to allow remote kernel loading I didn't get ipxe.efi to be able to netboot, but it prompted me to download the stable or unstable debian kernel etc. Please see this bug report and patch for grub-ipxe, to see how a grub.cfg can use either ipxe.lkrn or ipxe.efi dynamically: https://salsa.debian.org/waldi/ipxe/-/merge_requests/1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927783 So, if a user selects the PXE mode, please install both ipxe.lkrn and ipxe.efi, and use the grub.cfg mentioned in that bug report. Thanks again!
Bug#961007: Re: Some directives are ignored under sshd_config.d
I believe it's this upstream bug: https://bugzilla.mindrot.org/show_bug.cgi?id=3122 "New Include functionality does not work as documented"
Bug#961007: Some directives are ignored under sshd_config.d
Package: openssh-server Version: 1:8.2p1-4 Severity: normal Hi, the following configuration is ignored if I put it in /etc/ssh/sshd_config.d/local.conf ...yet it works fine if I put it at the end of the file /etc/ssh/sshd_config: Match Group *,!sudo,!root ChrootDirectory /home ForceCommand internal-sftp Match all I.e. for some reason, some directives in sshd_config.d are ineffective. To reproduce, use the example above, and just run: ssh administrator@localhost It's supposed to reply with: """ administrator@localhost's password: This service allows sftp connections only. Connection to localhost closed. """ Yet it only works at the end of /etc/ssh/sshd_config.
Bug#959712: Add probe module to signed UEFI images
Package: grub2 Version: 2.04-7 Severity: wishlist I would like to boot debian.iso directly from grub, e.g. from a live USB stick: https://github.com/alkisg/liveusb For Debian, this requires to pass the following cmdline to the kernel: fromiso=/dev/disk/by-uuid/$rootuuid/$iso boot=live In order to "translate" grub's $root (e.g. hd0,msdos1) into kernel's $rootuuid (e.g. 1234-5678), the probe command is needed: probe --set=rootuuid --fs-uuid "$root" It's a very small module, please consider including it to signed images similar to this patch for the regexp module: https://salsa.debian.org/grub-team/grub/commit/07481aa3deecc58247525d4e69f1f4f7ffbefe33 Thank you!
Bug#959425: loopback command hangs in 2.04 under UEFI
I can confirm that running `rmmod tpm` is a workaround. After removing tpm, `loopback loop some.iso` works without hanging. Thank you Bernhard.
Bug#959425: loopback command hangs in 2.04 under UEFI
Source: grub2 Version: 2.04-7 Severity: important Hi, if I boot with grubx64.efi and run the following command: loopback loop some.iso ...it hangs in 2.04 under UEFI, while it worked fine up to 2.02. This affects Debian and Ubuntu, but not Fedora. BIOS mode isn't affected. I tested with grubx64.efi from the following packages: BAD: http://ftp.us.debian.org/debian/pool/main/g/grub2/grub-efi-amd64-bin_2.04-7_amd64.deb BAD: https://launchpad.net/ubuntu/+source/grub2-signed/1.117/+build/17277557/+files/grub-efi-amd64-signed_1.117+2.04-1ubuntu1_amd64.deb GOOD: https://launchpad.net/ubuntu/+source/grub2-signed/1.116/+build/17166212/+files/grub-efi-amd64-signed_1.116+2.02+dfsg1-12ubuntu3_amd64.deb GOOD: https://kojipkgs.fedoraproject.org//packages/grub2/2.04/15.fc33/x86_64/grub2-efi-x64-2.04-15.fc33.x86_64.rpm Related Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1851311 Thank you.
Bug#958452: Please package 1.7.3.4 as 1.7.3.3 breaks epoptes
Thank you Laszlo, No rush; I'd appreciate it if it was uploaded anytime before August 2020. :) On 4/22/20 12:15 PM, László Böszörményi (GCS) wrote: Control: tags -1 +pending Hi Alkis, On Wed, Apr 22, 2020 at 11:09 AM Alkis Georgopoulos wrote: Hi, all socat versions work fine with https://packages.debian.org/epoptes except for the current sid version, 1.7.3.3. Please consider packaging 1.7.3.4 that doesn't have the regression. It's pending already. I would like to fix its GCC 10 FTBFS problem as well - while I've fixed that locally I do wait for its upstream answer on that. How soon would you like to get this updated? Is it a severe problem for you? Regards, Laszlo/GCS
Bug#958452: Please package 1.7.3.4 as 1.7.3.3 breaks epoptes
Source: socat Version: 1.7.3.3-2 Severity: medium Hi, all socat versions work fine with https://packages.debian.org/epoptes except for the current sid version, 1.7.3.3. Please consider packaging 1.7.3.4 that doesn't have the regression. Details: Epoptes is a computer lab management tool, I'm upstream and Debian maintainer for it. It uses socat to forward a "student" terminal to the "teacher". To reproduce the issue without installing Epoptes, the following similar commands may be used instead: Teacher (just run it in a terminal tab): xterm -e socat tcp-listen:1234,reuseaddr,keepalive=1 stdio,raw,echo=0 Student (just run it in another terminal tab): TERM=xterm socat EXEC:'screen bash -l',pty,stderr tcp:localhost:1234 This works fine with all socat versions except 1.7.3.3. In 1.7.3.3, it's like line buffering is enabled or something similar, and pressing for example the up arrow in the keyboard shows "^[OA" instead of displaying the last bash command. Thus, the forwarded xterm is almost unusable.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 11:07 AM, Andrej Shadura wrote: Could you please provide more background? It’s not quite clear to me how this commit fixes the issue. Hello Andrej, I'm happy to provide the "end user" side of the story, but I can't provide the "developer" side, as it's the Realtek engineers that pinpointed this, I'm not familiar with the wpa codebase at all, and I can't comment why this patch fixes this issue. So, the background is: MAC address randomization was enabled for all wifi adapters; then users reported "keeps asking for a password" problems; the real problem was never pinpointed, they blamed "it's an issue with these Realtek drivers, tell them to fix them", and the "disable MAC randomization workaround" was proposed until the real issue is fixed. So I did report this to Realtek, and they came up with the fix, but it was not in their drivers as I expected, but in wpasupplicant. Nevertheless, I tested it and it indeed solves the issue. They also proposed a second workaround, that ifname=0 in the kernel cmdline also works around the issue, and I tested it, and indeed that works as well. Then, realizing that it's not related to Realtek drivers, I tested with an atheros-based wifi adapter, and that one was affected as well. So, to reproduce the issue, the following are needed (which are the default in Debian): 1) In /etc/NetworkManager/NetworkManager.conf, to either have the following, or leave it undefined (while e.g. Ubuntu has "no" there): [device] wifi.scan-rand-mac-address=yes 2) Make sure that the USB id isn't "blacklisted" in /usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf 3) Restart network manager if there were changes: systemctl stop network-manager killall wpa_supplicant systemctl start network-manager 4) Insert a wifi adapter that produces a name with 15 characters like wlx74ee2ae2436a. And the result is that without the patch it will keep asking for a password, while with the patch, it'll work fine. So I believe that if this is triaged / fixed, then there won't be any need to apply the "disable MAC randomization" workarounds. Thanks!
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 8:07 AM, Michael Biebl wrote: I'd prefer a separate, new bug report against wpasupplicant. The original bug report is about disabling mac randomization, so afaics a different issue from yours. My problem was exactly the one described here. With MAC randomization enabled, network manager kept asking for a password. The workaround mentioned here (disabling MAC randomization) did work around the problem. But it's just an unsafe workaround, not a solution. Then I reported the issue to Realtek, and they pinpointed the underlying bug in wpasupplicant. After applying their patch in wpasupplicant, there's no need to disable MAC randomization in network-manager anymore. I can file a separate issue, but it will have pretty much the same description, that "when MAC randomization is enabled, network-manager keeps asking for a password"... Maybe we can just put "wpasupplicant" in the "affects" list, and when someone else here confirms what I say, we can then remove "network-manager"? Unfortunately I'm not familiar with debian bug tags though... :/ Btw, another workaround than disabling MAC randomization, is to pass ifnames=0 in the kernel cmdline, as this then causes USB wifi adapters to have smaller interface names (wlan0) that do not trigger the wpasupplicant bug.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
On 3/24/20 5:22 AM, Michael Biebl wrote: You should file a bug report against wpasupplicant. Andrew, the wpasupplicant maintainer, is not reading network-manager bug reports. Thank you Michael, I was thinking of: 1) Getting feedback from someone affected by this bug (like me) that this patch indeed solves it, and then 2) Find out how to "reassign this issue to wpasupplicant instead of network-manager", without opening a new bug for the same issue and then having to manage two bugs... Is that an appropriate approach?
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
The two-liner patch made it upstream: http://w1.fi/cgit/hostap/commit/?id=7546c489a95a033c78331915fcdfa0e6fd74d563 It would be awesome if it was cherrypicked/backported, as it's rather significant and it solves this issue.
Bug#879484: Network-Manager should Default to Non-Random MAC Address on WiFi
I reported this to Realtek and they pinpointed it to a bug in wpasupplicant. I tested the patch and it works fine for 8812au, 88x2bu and 8821cu. I then reported it to launchpad in case it makes it for Ubuntu 20.04: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/1867908 If others here test that oneliner-patch and find that it solves this issue, maybe we can just report it upstream and to wpasupplicant in debian, not in network-manager.
Bug#927783: Load ipxe.efi under UEFI, not ipxe.lkrn
Hi, I filed an updated version of the patch as a merge request: https://salsa.debian.org/waldi/ipxe/merge_requests/1 The one additionally saves the default entry, so that the GRUB iPXE entry is consistent with all the other entries. It was a 2-line diff upon the previous one, in the same spot, so I thought I'd include that too.
Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails
I filed an upstream bug report, including more workarounds and possibly a link to the commit that caused the regression. https://github.com/mate-desktop/marco/issues/548
Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails
I'm seeing a similar problem here with older nvidia cards. Could you try this? 1. Login with metacity 2. Open a terminal 3. Run: marco --no-composite --replace For me, both metacity and `marco --no-composite` works fine. While the default `marco --composite`, * Crashes Xorg on TNT2 * Doesn't crash but causes tearing and display artifacts in newer cards I think that marco 1.20 started using some driver API which doesn't work in some nouveau cards. Another workaround for me is to use PageFlip Off in xorg.conf, but this hurts performance.
Bug#927783: Load ipxe.efi under UEFI, not ipxe.lkrn
Source: ipxe Version: 1.0.0+git-20190125.36a4c85-1 Severity: normal Dear maintainer, https://packages.debian.org/buster/all/ipxe/filelist ships the following files (among others): /boot/ipxe.efi /boot/ipxe.lkrn /etc/grub.d/20_ipxe But, when booting under UEFI, /etc/grub.d/20_ipxe tries to load ipxe.lkrn instead of the correct ipxe.efi, and crashes. Here's a proposed patch that addresses the issue: diff ./a/etc/grub.d/20_ipxe ./b/etc/grub.d/20_ipxe 22c22,29if [ "\$grub_platform" = "efi" ]; then >chainloader ${IPXEPATH%.lkrn}.efi >else >linux16 $IPXEPATH >if [ -f ${IPXEPATH%.lkrn}.ipxe ]; then >initrd16 ${IPXEPATH%.lkrn}.ipxe >fi >fi This dynamically checks if the platform is efi or not, and loads the correct ipxe.{efi|lkrn}, and additionally, in the BIOS case, it allows the user to provide an ipxe script in /boot/ipxe.ipxe, which is loaded as initrd. This functionality isn't yet supported by upstream iPXE under UEFI.
Bug#923855: Consider including ntfs in grubx64.efi
Package: grub2 Version: 2.02+dfsg1-12 Severity: wishlist Including the ntfs module in grubx64.efi would allow secure boot users to load things from ntfs partitions. For example, I could install grub-efi in a fat32 partition of a usb stick, then extract the windows.iso contents to an ntfs partition in the same stick (they don't fit in fat32 as install.wim is over 4 GiB), and easily create a multiboot stick, as grub would allow me to boot ubuntu.iso as well. I.e. live USB tool creators could use that method in their tools. Additionally, some Linux DVDs exceed 4 GiB, so people won't be able to store them in a fat32 partition, and ext4 handling is hard in Windows where some people will want to create the stick in.
Bug#923735: Don't autocomplete external modules under secure boot
Package: grub2 Version: 2.02+dfsg1-12 Severity: wishlist Pressing under secure boot lists the "regexp" module, which is available under grub/x86_64-efi, but not loadable under secure boot, so I think it should be hidden from the available commands list. Thanks!
Bug#921354: ltsp-server-standalone: No input on graphical boot on fat-clients
Στις 4/2/19 6:20 μ.μ., ο Lasse Flygenring-Harrsen έγραψε: recently input stopped working an all physical hardware, the system boots fine and the Displaymanager (LDM in my case) works fine except for the fact that keyboard and mouse input doesn't work. I haven't read all of the report, but this usually means that the TFTP kernel isn't contained in the NBD image. I.e. some bad run of ltsp-update-image / ltsp-update-kernels. On the client, via epoptes or SSH or a PS/2 keyboard, uname -r => will show the kernel loaded via TFTP dpkg -l '*linux*' | grep ^ii => will show the kernels contained in the NBD image P.S. for issues that aren't specific to the debian packaging, you might get more attention by using the upstream LTSP bug tracker: https://bugs.launchpad.net/ltsp
Bug#859213: x11vnc: stack smashing detected: x11vnc terminated
I too tested the patch that changes the following 3 lines, and I no
longer have x11vnc crashes. Please release that! :)
- if (num > stack_list_len + blackouts) {
- int n = 2*num;
+ if (num + blackouts > stack_list_len) {
+ int n = 2 * (num + blackouts);
- for (i=0; ilength; i++) {
+ for (i = 0; i < req->length - sz_xConfigureWindowReq / 4 && i < 4; i++)
{
Bug#819160: Bug#892626: Switch from freerdp-x11 to freerdp2-x11
Στις 06/04/2018 11:10 μμ, ο Vagrant Cascadian έγραψε: With my LTSP hat on, old and worn out though it may be, I'd think we'd maybe still want to provide support for the old variant for backports and legacy setups, so it might be appropriate to create a new script, especially in light of: #819160: ltsp-client-core: Please provide seperate usr/share/ltsp/screen.d/rdesktop and xfreerdp scripts As I wrote in that bug report, one generic "run something under a minimal xorg environment" script should be enough for any rdp/vnc/whatever-like application. We shouldn't keep supporting RDP_SERVER etc just because at some point in the past a company had an UI for that. A full command line provided in a single lts.conf variable, that may even contain "server" or "$SERVER" wherever appropriate, should be more than enough.
Bug#857615: mate-debian.gschema.override should begin with a "nn_" number
Package: mate-desktop-environment-core Version: 1.16.0+1 Severity: normal File: /usr/share/glib-2.0/schemas/mate-debian.gschema.override Dear Maintainer, http://manpages.debian.org/dh_installgsettings mentions: --priority priority Use priority (which should be a 2-digit number) as the override priority instead of 10. Higher values than ten can be used by derived distributions (20), blend distributions (50), or site-specific packages (90). According to that, the following changes should be made to debian/rules: -dh_install -pmate-desktop-environment-core debian/mate-ubuntu.gschema.override /usr/share/glib-2.0/schemas/ endif -dh_install -pmate-desktop-environment-core debian/mate-debian.gschema.override /usr/share/glib-2.0/schemas/ +dh_install -pmate-desktop-environment-core debian/mate-ubuntu.gschema.override /usr/share/glib-2.0/schemas/10_mate-ubuntu.gschema.override endif +dh_install -pmate-desktop-environment-core debian/mate-debian.gschema.override /usr/share/glib-2.0/schemas/10_mate-debian.gschema.override Thank you! -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.9.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mate-desktop-environment-core depends on: ii caja1.16.2-2 ii dconf-gsettings-backend [gsettings-backend] 0.26.0-2 ii gvfs-backends 1.30.3-1 ii gvfs-bin1.30.3-1 ii marco 1.16.0-1 ii mate-backgrounds1.16.0-1 ii mate-control-center 1.16.0-2 ii mate-desktop1.16.1-1 ii mate-icon-theme 1.16.0-1 ii mate-menus 1.16.0-2 ii mate-notification-daemon [notification-daemon] 1.16.1-1 ii mate-panel 1.16.0-2 ii mate-polkit 1.16.0-2 ii mate-session-manager1.16.1-1 ii mate-settings-daemon1.16.0-2 ii mate-terminal 1.16.1-2 ii mate-themes 3.22.6-1 ii notification-daemon 3.20.0-1 mate-desktop-environment-core recommends no packages. mate-desktop-environment-core suggests no packages. -- no debconf information
Bug#831409: [pkg-gnupg-maint] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work
On 06/09/2016 06:10 πμ, Daniel Kahn Gillmor wrote: > The original report does point out that the system in question doesn't > have gpg available. the awk|base64 pipeline was written to accomodate > that constraint :) gpg wasn't available in the chroot, (so it was an issue with debootstrap --variant=minbase not pulling gnupg) while now it's used in the server-side code (so ltsp-server just needs to depend on gpupg).
Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work
After creating a chroot with: 1) debootstrap 2) debootstrap --variant=minbase and installing ltsp-client-core in both of them, I got the following results: 1) stretch-minbase-ltsp: 314M 2) stretch-normal-ltsp: 350M The difference is small, mainly due to apt-utils, bsdmainutils, cron, debconf-i18n, gnupg, ifupdown, iptables, isc-dhcp-client, logrotate, nano, rsyslog, vim-tiny, wget, whiptale. Some of those are even useful for minimal ltsp chroots as well. Regardless of actions taken in other packages, maybe LTSP should stop using --variant=minbase?
Bug#831409: [Pkg-ltsp-devel] Bug#831409: ltsp-client lacks gnupg / gnupg2 for apt-key to work
So it sounds like something run apt with --no-install-recommends, right? I don't think that's LTSP, could it be Debian Edu? Maybe it could just drop the --no-install-recommends parameter?
Bug#796633: nbd-client: Has init script in runlevel S but no matching service file
On 28/04/2016 03:05 μμ, Felipe Sateler wrote: If you don't need the service you can mask it (create a symlink from /etc/systemd/system/nbd-client.service to /dec/null). I'm involved in this bug report as upstream developer for LTSP and as Debian co-maintainer for it, i.e. I'm trying to care for all Debian + Ubuntu LTSP users, not just for some local installation... I don't think the Debian policy allows me to do that as part of ltsp-client.postinst, so I don't think I can solve it from the LTSP code side. Sure, each and every LTSP user out there could possibly locate and read this bug report and mask the service for his local installation, but that's exactly what I'm trying to have centrally solved, to save thousands of users hours of frustration...
Bug#796633: nbd-client: Has init script in runlevel S but no matching service file
On 26/04/2016 11:16 μμ, Wouter Verhelst wrote: One workaround is to not combine NetworkManager and nbd-client on the same system. If you're going to try to run an important filesystem (say, the root filesystem) on something that lives somewhere on the network, giving the user the ability to play with network connections at will seems like a bad idea. Unfortunately we cannot uninstall network-manager as that will also remove the ubuntu-desktop package. Also, LTSP clients do have network-manager installed in order to allow it to manage wifi and VPN connections via a GUI, while the wired network card is tagged as "manual" so that users cannot break their nbd root filesystem. Another thought... is it possible to provide another "nbd-client-without-the-service" package that only provides the nbd-client executable and not its service (that we don't need at all in LTSP), and thus won't break network-manager? If so, then we can modify "ltsp-client" to Depend on that one instead... Thanks, Alkis
Bug#796633: nbd-client: Has init script in runlevel S but no matching service file
Unfortunately, testing showed that replacing: # Default-Start: S with: # Default-Start: 2 3 4 5 doesn't solve the issue. One workaround is to change instead: # Required-Start: $network $local_fs with: # Required-Start: $local_fs This solves the ordering cycle by starting nbd-client a little later. Should we use that until a proper fix is committed? Does anyone have any better immediate workarounds? Thanks, Alkis
Bug#796633: nbd-client: Has init script in runlevel S but no matching service file
One side effect of this issue is that it prohibits network-manager from starting, because systemd sometimes deletes it to break the dependency cycle: https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679 pitti there suggested a quick fix of setting "Default-Start:" to "2 3 4 5" instead of "S". Is that a reasonable thing to do until the implementation with the nbd-generators is released? Thanks!
Bug#819160: ltsp-client-core: Please provide seperate usr/share/ltsp/screen.d/rdesktop and xfreerdp scripts
Try something like this: SCREEN_07="xfreerdp /f /sec:rdp /rfx +fonts /cert-ignore /sound:sys:pulse /smartcard /v:192.168.0.16" i.e. put all your parameters in one line without setting the deprecated RDP_OPTIONS and RDP_SERVER variables. As I said, those are only there for backwards compatibility. Initially I wrote xfreerdp as a separate screen script and I didn't include those at all; then I put them there as an afterthought so that I could merge it with the older rdesktop script. What I don't like about them is that there's no matching between those options and the screen number; i.e. they would have to be RDP_OPTIONS_07 and RDP_SERVER_07 instead, which isn't very pretty. They were implemented as separate options for the web interface of ltsp-cluster, but that's not developed or supported anymore. If that answer satisfies you, then please close this bug report, otherwise please open a bug report upstream in LTSP as the problem isn't in the Debian packaging but in the upstream code, so https://bugs.launchpad.net/ltsp/ is the proper place for it. Cheers, Alkis
Bug#819160: ltsp-client-core: Please provide seperate usr/share/ltsp/screen.d/rdesktop and xfreerdp scripts
The idea is that the xfreerdp script doesn't contain any parameters at
all, and you provide them via the
SCREEN_07="xfreerdp " lts.conf directive, or the
SCREEN_07="rdesktop " directive,
so as long as it doesn't enforce any parameters, why are two separate
scripts needed?
The only hardcoded option in that script is
RDP_OPTIONS=${RDP_OPTIONS:-"-f -u ''"}
...which is only there for compatibility with older LTSP versions, and
can surely be replaced or completely omitted in lts.conf.
Bug#809166: networking.service does not prevent ifdown with network file systems
On 21/01/2016 11:10 μμ, Guus Sliepen wrote: On Fri, Jan 15, 2016 at 09:14:52AM +0100, Guus Sliepen wrote: ifupdown 0.8.9 can also mark interfaces with the "no-auto-down" keyword, which causes those interfaces to be ignored during "ifdown -a". This is a more explicit way to tell an interface should not be brought down during shutdown. An example: auto eth0 no-auto-down eth0 iface eth0 inet dhcp ... I hope this will help. Perfect, thanks a lot! :)
Bug#809166: networking.service does not prevent ifdown with network file systems
About the boot process of LTSP clients, I think it's better not to focus on LTSP, but on the simplest possible netbooted system that works out of the box in all Debian/Ubuntu versions (and many other Linux distros) without using a custom initramfs: Let's say we have an "rw" NFS export for a single client on some server. And we just pass "root=/dev/nfs ip=dhcp boot=nfs" in the client command line. The *stock* initramfs (related packages: initramfs-tools, klibc) then brings up the network interface and mounts the NFS root file system and chains to it. That NFS export (chroot) may have any package installed in it, gnome, kde, apache, network-manager, avahi etc. There's no special handling of anything; everything works without customizing any configuration file, the only part that is needed is to put "manual" in $CHROOT/etc/network/intefaces. If "manual" is not inserted there, then the packages that use ifupdown won't receive the appropriate events. We can get a list of those packages from http://packages.debian.org, but I don't think it's important; we don't want to special-case any one of them. For example, ntpdate needs an if-up.d event to sync the clock, ethtool adjusts the WOL and other NIC settings, and there's also avahi, openssh, resolvconf etc. So to sum up, a netbooted system needs a way to "have all the events sent for the boot interface, but prohibit its IP from being changed and prohibit it from getting down". In practise, the "manual" flag covered that fine so far. But if that's ...abusing its intented purpose, and another solution is necessary, I would propose this: 1) initramfs-tools, dracut etc could create a file somewhere in /run to mark the boot interface 2) ifupdown, network-manager, wicd etc could read that file and handle that interface in that aforementioned special way (send events, maybe even show the connection speed and status in the network-manager UI, but don't change the IP or ifdown it).
Bug#810934: Please hide initramfs eth card from NetworkManager more robustly
> it would be great if ltsp could more directly express what it really > wants to do by creating a /etc/NetworkManager/conf.d/ltsp.conf snippet Some thoughts on this: 1) LTSP chroots don't have network-manager installed by default, they are minimal images generated by debootstrap. It's possible to build LTSP "fat" chroots that do have nm installed though (along with a whole desktop environment). 2) Even if nm was installed, ifupdown would still ifdown the interfaces on shutdown (with the old ifupdown behaviour), right? So creating /etc/NetworkManager/conf.d/ltsp.conf wouldn't help there, would it? 3) Conceptually, ifupdown's "manual" isn't exactly the same as network-manager's "unmanaged". For example, nm could allow the users to see the connection speed or status or add VPNs over it, without allowing them to activate/deactivate the interface. 4) It's also possible to netboot clients using AoE (ATA over Ethernet), where the root file system is accessible with ethernet packets even if the interface doesn't have an IP, the only prerequisite is for it to always be up. So if nm could respect that, then it could manage the interface normally, it could use dhclient to assign an IP to it etc. I just wanted to mention these thoughts, I'll leave it up to the LTSP Debian maintainer to decide if he wants to tag the connection as unmanaged or not. Cheers!
Bug#809166: networking.service does not prevent ifdown with network file systems
Hi, I'm the LTSP developer that added the "manual" stanza a few years ago (r1944). I've answered in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810934#10 about it, but I should probably add a comment here as well as this bug sees the issue from a different view. The "manual" stanza isn't there just for network-manager. LTSP chroots don't have network-manager installed by default. A netbooted system needs these 2 things from ifupdown: 1) the scripts at /etc/network/if-up.d to get executed for the boot interface, 2) while preventing the boot interface from being DOWNed at shutdown. You mention that using "manual" is the wrong approach to accomplish this. Could you please advise us on how to notify ifupdown to do those 2 things in a backwards/forward compatible way?
Bug#546219: memtest86+: fails to load from pxelinux with default filename
In pxelinux.cfg/default, instead of using: kernel memtest86+.bin one can just disable extension autodetection and specify: linux memtest86+.bin
Bug#777031: Project folders are not localized
Package: scratch Version: 1.4.0.6~dfsg1-5 Severity: important In non-English environments, ~/Documents is localized according to XDG specs, for example in Greece it's ~/Έγγραφα. When a student tries to save a Scratch project, scratch tries to save it to ~/Documents though, which doesn't exist, and fails with this message: Save failed: Folder may be locked or read-only. The problem is in unixScratchOps.c, lines 63+: if (folderID == 2) strncat(path, /Desktop, maxPath); if (folderID == 4) strncat(path, /Pictures, maxPath); if (folderID == 5) strncat(path, /Music, maxPath); ... strncat(path, /Documents, maxPath); If those strings were not constant, but translatable (with the existing Scratch .po files), the problem would be very mitigated. Otherwise for a proper solution, a library function should be called, something like: https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-special-dir At the very least, please allow the sysadmin to localize those locations with the user's environment (XDG_DESKTOP_DIR, XDG_DOCUMENTS_DIR, XDG_MUSIC_DIR, XDG_PICTURES_DIR). He would at least be able to create a /usr/local/bin/scratch wrapper that sets those variables before chaining to the real scratch launcher. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700989: Merge request for complete Greek support
Στις 12/05/2014 10:21 πμ, ο/η Holger Levsen έγραψε: That changes 1 number in alphabet.c, otherwise the Greek letters overlap in the displayed keyboard, so in reality it'd consider it a part of the translation effort as well.:) but it changes it for all languages, doesnt it? Have you tested other languages with that patch? Hi Holger, Yes, it affects all languages, but it's not language-specific, it's just about math, better dividing the width of the image with the number of keyboard keys. I've tested with Greek and English, in both cases the result is much better with the patch applied. Example image: http://imagebin.org/310332 On the left, there's English without the patch applied. Note key 1. Then note key 0. See that 0 is drawn too much to the right. On the right, there's Greek with the patch applied (any other language would look similar too with the patch applied). Note key 0, now it has a better position. Also, compare keys M, =, P etc in both keyboards; again on the unpatched image, those keys are drawn too much to the right, to the point where a few pixels get cut off. Thanks a lot for the merge, Alkis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730176: Increase MaxStartups to 20
Package: openssh-server Version: 1:6.4p1-1 Severity: normal X-Debbugs-CC: alk...@gmail.com Hi, in LTSP (http://packages.debian.org/ltsp) we are using openssh-server for authenticating thin/fat clients against the LTSP server. Some installations, e.g. schools, have autologin enabled, so it's quite possible that a whole classroom boots up or reboots and ends up logging in at exactly the same time. The number of clients varies, but with 500+ school installations here in Greece and with 10 to 20 clients in each classroom, we had bug reports that ssh logins failed for a few users, and they succeeded on the second login attempt. By changing MaxStartups to 20:30:60 to all those schools, there were no more bug reports about it for 2+ years now. Would you please consider applying this change in the debian packaging of openssh-server? Thanks, Alkis Georgopoulos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701916: Kill local user processes on logout
Package: ltsp-client-core Version: 5.4.2-5 Severity: grave Tags: patch upstream LTSP fat clients and also thin clients that use localapps, mount /home/username with SSHFS and unmount it on logout. Unfortunately at the point where the unmount happens, local processes are still running, and when Xorg killed them later on, they end up writing their data to the local tmpfs filesystem because the SSHFS mount is no longer there. That's one reason for data loss (hence the grave severity), but there's another, worse one: On the next login of the same user, /home/username/data of the processes I mentioned above exist locally on the tmpfs, so the LTSP code thinks that the sysadmin has taken care to mount the user home dirs via other means (e.g. NFS), so the SSHFS mount is no longer needed. Thus, all user sessions after the first one, use a local tmpfs /home/username. Users don't see their existing documents or settings, and any new document they write, will be saved in the local tmpfs and lost on client reboot. Here's the upstream bug report: https://bugs.launchpad.net/ltsp/+bug/1093144 And the patch: http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2462 Only one file needs to be patched, client/localapps/ldm-rc.d/X99-zlocalapps-cleanup. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700989: Merge request for complete Greek support
Στις 20/02/2013 10:33 πμ, ο/η Holger Levsen έγραψε: I hope these are indeed only commits touching the greek translation. There's only one commit not directly related to the Greek translation, the one that says Align letters more accurately on the keyboard. That changes 1 number in alphabet.c, otherwise the Greek letters overlap in the displayed keyboard, so in reality it'd consider it a part of the translation effort as well. :) If you could provide it as a git branch, that would be much preferred. My first try in both git and github, I hope I got it right: https://github.com/alkisg/tuxtype/commits/ I left the alphabet.c change last in case you want to omit it. I cleaned up the commits a lot, so please completely ignore the previous bazaar branch I sent. Thanks, Alkis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#700989: Merge request for complete Greek support
Package: tuxtype Version: 1.8.1-5 Severity: wishlist Hi, we (a team of 3 Greek teachers) have massively updated the Greek translation of tuxtype, and we're requesting for it to be included upstream. It consists of commits 22 to 32 of this branch: http://bazaar.launchpad.net/~ts.sch.gr/sch-scripts/tuxtype/changes If bzr isn't OK and you prefer another merge format, please notify us. We've also sent a few mails to the upstream mailing list, but there was no response about a merge there: http://lists.alioth.debian.org/pipermail/tux4kids-tuxtype-dev/2012-November/001152.html http://lists.alioth.debian.org/pipermail/tux4kids-tuxtype-dev/2013-February/001166.html Changelog: 32: Alkis Georgopoulos 2013-02-17 Add greek script descriptions and Makefiles. 31: Alkis Georgopoulos 2013-02-17 Various small fixes in Greek scripts. 30: Nikos Konstantinou 2013-02-17 Add greek/scripts/basic_lesson_01 to 03 and 20 to 43. 29: Eleni Fatourou 2013-02-17 Add greek/scripts/basic_lesson_04 to 19. 28: Alkis Georgopoulos 2012-11-25 Update po/el.gmo. 27: Alkis Georgopoulos 2012-11-25 Add Greek phrases.txt to Makefile. 26: Eleni Fatourou 2012-11-25 Translate the words/ directory. 25: Alkis Georgopoulos 2012-11-16 Align letters more accurately on the keyboard. 24: Alkis Georgopoulos 2012-11-16 Update Greek translation. 23: Eleni Fatourou 2012-11-16 Add a Greek phrases.txt. 22: Alkis Georgopoulos 2012-11-16 Update Greek keyboard.lst. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692587: Don't use -xshm for remote displays
Package: scratch
Version: 1.4.0.6~dfsg1-2
Severity: normal
Hi, scratch doesn't work with LTSP thin clients because -xshm is forced.
Here's a patch that works around the problem:
=== modified file 'debian/bin/scratch'
--- debian/bin/scratch 2012-07-02 14:58:46 +
+++ debian/bin/scratch 2012-11-07 16:48:23 +
@@ -7,7 +7,8 @@
VM_VERSION=`find /usr/lib/squeak/ -name squeakvm -type f|cut -f5 -d/`
SQ_DIR=/usr/lib/squeak/$VM_VERSION
VM=$SQ_DIR/squeakvm
-VMOPTIONS=-encoding UTF-8 -vm-display-x11 -xshm -plugins
/usr/lib/scratch/plugins/:$SQ_DIR/
+test -z ${DISPLAY%:*} XSHM=-xshm
+VMOPTIONS=-encoding UTF-8 -vm-display-x11 $XSHM -plugins
/usr/lib/scratch/plugins/:$SQ_DIR/
IMAGE=/usr/share/scratch/Scratch.image
IMOPTIONS=
DOCUMENT=
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615017: The German translation of th, label user name is cut off by the text field
I had the same problem with the Greek translation of Username (Όνομα χρήστη) and Password (Κωδικός πρόσβασης), and solved it by padding the logo.png to become 400 pixels wide: http://imagebin.org/index.php?mode=imageid=233650 $ file /opt/ltsp/wheezy/usr/share/ldm/themes/*/logo.png /opt/ltsp/wheezy/usr/share/ldm/themes/default/logo.png: PNG image data, 400 x 122, 8-bit/color RGBA, non-interlaced /opt/ltsp/wheezy/usr/share/ldm/themes/joy/logo.png: PNG image data, 80 x 115, 8-bit/color RGBA, non-interlaced /opt/ltsp/wheezy/usr/share/ldm/themes/ltsp/logo.png:PNG image data, 300 x 115, 8-bit/color RGBA, non-interlaced It should also be possible to solve it from greeter.c so that it works with any logo size. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691201: keyboard-configuration: XKBLAYOUT=us,gr for Greece
Package: keyboard-configuration Version: 1.86 Severity: normal Hi, XKBLAYOUT=gr in keyboard-configuration.config is wrong, it should be us,gr instead: $ grep XKBLAYOUT=gr /var/lib/dpkg/info/keyboard-configuration.config XKBLAYOUT=gr # Greece $ grep ^XKB /etc/default/keyboard XKBMODEL=pc105 XKBLAYOUT=us,gr XKBVARIANT=, XKBOPTIONS=grp:alt_shift_toggle,grp_led:scroll /etc/default/keyboard does get the correct layout when selecting Greek language in the installation though, not sure which component puts the correct us,gr there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666981: Please make numlock default to off for laptops
notfixed 666981 numlockx 1.2-3 55numlockx now appears to have a syntax error: $ sh -n /55numlockx /55numlockx: 14: /55numlockx: Syntax error: word unexpected (expecting in) Also, the SET variable doesn't appear to be used... Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666981: numlockx: Please make numlock default to off for laptops
Package: numlockx Version: 1.2-2 Severity: wishlist We're using numlockx on LTSP, so it's installed by default for all clients. Currently, numlockx assumes that since the user has installed numlockx, he always wants numlock to be on, otherwise he can uninstall it or edit /etc/X11/Xsession.d/55numlockx. In LTSP, that assumption is not true. At least on laptops where the numeric pad overlaps with the alphanumeric keys, it would be better if it defaulted to off. I propose the following changes: * To help people that always want numlock off (bug #648013), introduce /etc/default/numlockx, which would contain: # Uncomment the following line to disable numlockx #NUMLOCK=off * And, replace /etc/X11/Xsession.d/55numlockx with the following, so that it's off by default for laptops: # X session startup script: /etc/X11/Xsession.d/55numlockx if [ -x /usr/bin/numlockx ]; then if [ -f /etc/default/numlockx ]; then . /etc/default/numlockx || true fi case $NUMLOCK in on|off|toggle) ;; *) NUMLOCK=on if [ -x /usr/sbin/laptop-detect ]; then if /usr/sbin/laptop-detect; then NUMLOCK=off fi fi ;; esac numlockx $NUMLOCK || true fi # EOF -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657830: win32-loader: Please make pxe.target depend on the ipxe package
Στις 31/01/2012 12:26 μμ, ο/η Didier 'OdyX' Raboud έγραψε: I propose the attached patch that would do even better, by providing a win32-loader-pxe.exe from the Debian mirrors, available on http://ftp.debian.org/debian/tools/win32-loader/unstable/win32-loader-pxe.exe ... What do you (and debian-boot ?) think about that ? Sorry my English aren't good enough, I don't know many words better than awesome, so perfect will have to do! Just a notice though, in case anyone tries it: the iPXE package in Debian and Ubuntu is currently broken, it errors with B: command not found when loaded from grub: https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/916489 That error was fixed in a later upstream iPXE version, and AFAIK lynxman is working on packaging a new git snapshot and he's almost ready to upload it to Debian+Ubuntu: https://code.launchpad.net/~lynxman/ubuntu/precise/ipxe/newsnapshot Thanks again Didier! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657830: win32-loader: Please make pxe.target depend on the ipxe package
Package: win32-loader
Version: 0.7.4.3
Severity: wishlist
Hello,
Quoting from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607417#43:
That's the point of the pxe.target to depend on pxe.lkrn.
I will enhance the code when {g,i}PXE enters Debian in order to
copy the pxe.lkrn directly (as is done for gl2dr and loadlin.exe).
An ipxe package is available in Debian wheezy and sid:
$ rmadison ipxe
ipxe | 1.0.0+git-2.149b50-1 | wheezy | source, all
ipxe | 1.0.0+git-2.149b50-1 | sid| source, all
It would be awesome if people could get win32-loader.exe directly from
the Debian archives (by decompressing the .deb of course).
Thank you very much,
Alkis Georgopoulos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643644: RFP: mythes-el -- Greek Thesaurus for OpenOffice.org/LibreOffice
Package: mythes-el Version: N/A; reported 2011-09-28 Severity: wishlist * Package name: mythes-el Version : 2 Upstream Author : Daniel Naber daniel.na...@t-online.de * URL : http://wiki.services.openoffice.org/wiki/Dictionaries#Greek_.28Greece.29 * License : GPLv2+ Description : Greek Thesaurus for OpenOffice.org/LibreOffice The above URL contains the Greek OpenThesaurus thesaurus for OpenOffice.org/LibreOffice. Direct link: http://www.ellak.gr/pub/oo_extras/th_el.zip Please consider packaging it for Debian. Kind regards, Alkis Georgopoulos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643644: RFP: mythes-el -- Greek Thesaurus for OpenOffice.org/LibreOffice
Here's another link that except for the mythes-el files, it also contains the necessary files for hyphen-el: http://extensions.services.openoffice.org/en/node/1060/releases (it might need some browser refreshes, their servers seem very overloaded) Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626238: Please offer a grub-ipxe.deb package
Package: ipxe Version: 1.0.0+git-1.293e34-2 Severity: wishlist Now that iPXE is in Debian, it'd be very nice to have a grub-ipxe binary package generated from the same iPXE source package, that would put ipxe.krn in the grub2 menu. Use case: a user installs grub-ipxe, reboots, gets a new grub entry to PXE - Network boot, selects it, and netboots his computer. Proposed implementation: * Put ipxe.lkrn to /boot * Use /etc/grub.d/20_memtest86+ as a template for a new grub hook in /etc/grub.d/grub-ipxe * Call update-grub on grub-gpxe.postinst 1 year ago I had made a similar grub-gpxe package, if needed it source is accessible in https://launchpad.net/~ts.sch.gr/+archive/ppa/+sourcepub/958067/+listing-archive-extra Thank you for getting iPXE to Debian! Alkis Georgopoulos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483290: Upstream fix in unzip 6.1b
It appears that this bug has been fixed upstream on 2010/12/10. From ftp://ftp.info-zip.org/pub/infozip/beta/unzip610b.zip, unzip610b.ann: Quick list of major changes in UnZip 6.10b: - Add -I and -O options for setting ISO and OEM character sets, respectively, used by UnZip when doing character set translations. This support is based on the unzip60-alt-iconv-utf8 patch suggested in an Info-ZIP forum thread and uses the iconv library which must be available. These options are enabled using the USE_ICONV_MAPPING compiler define. Suggestions welcome on how to improve this limited character translation support. About suggestions welcome: I suggest we just add some more locales to the hardcoded translations table upon request, and try to forward them upstream. For Greek users, this would do it: el_GR.UTF-8 == cp1253. 'libnatspec' wasn't used in the upstream fix, but it fails to autodetect some locales anyway (e.g. Greek), so I don't think it'd be more useful than the hardcoded table. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607417: ΑΠ: win32-loader: please offer a Boot from network with gPXE option
Στις 02-02-2011, ημέρα Τετ, και ώρα 15:09 +0100, ο/η Didier 'OdyX' Raboud έγραψε: So, given the messages received so far and my present answer, I am pretty confident that the PXE patch does basically what you need; I will proceed in merging the pxe branch to master. Other enhancements will certainly happen, but please report separate bugs (it's not a matter of blocking discussion, but to keep the one problem is one bug motto). Confirming everything that OdyX says. Awesome PXE integration, much more mature than our preliminary attempts. :) To compile, I did the following: git clone git://git.debian.org/d-i/win32-loader.git cd win32-loader git checkout -b pxe remotes/origin/pxe # remove --format=i386-pc from Makefile because I had an old grub version cp /usr/share/gpxe/gpxe.lkrn ./pxe.lkrn PXE=yes make Tested the resulting win32-loader.exe in a vbox XP installation, worked fine. The only thing that remains is the boot menu title, we'll file another bug for it once the pxe branch is merged to master. Again, thank you OdyX, you're great. :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532302: dash: lack a byte of multibyte character when redirect
Later on the same bug was reported again in launchpad: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/422298 A fix was committed upstream in http://git.kernel.org/?p=utils/dash/dash.git;a=commit;h=f8231aea37e921492fc7fbd972385ab5b90e8627 but it's not in any dash versions yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553978: usermode misses gettext as a build dependency
Package: usermode Version: 1.81-3.2 Package usermode lacks gettext in the Build-Depends line in debian/control. As a result, all the translations are stripped from the binary packages, e.g.: http://packages.debian.org/sid/i386/usermode/filelist This doesn't affect all architectures (I don't know why), you can see the affected architectures in the Download usermode table in this page: http://packages.debian.org/sid/usermode The architectures with Installed Size 1000 Kb are not affected (i.e. hppa, ia64 and mipsel), all the other ones are. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532302: dash: lack a byte of multibyte character when redirect
The same problem also happens with the Greek rho character (ρ), I've posted a similar bug to launchpad a week before this bug was filed: https://bugs.launchpad.net/ubuntu/+source/dash/+bug/382541 I verified that the problem with rho also exist in Debian, so I'm cross-linking the 2 bug reports in case it helps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474034: any progress?
I've talked to #etherboot about this, and the devs there are interested in helping to settle any licensing issues: Thanks for the Debian packaging thread [[link]]. I'd like to see gPXE (lkrn, virtio rom, and iso) in Debian. I'm very confident any licensing questions can be addressed. gPXE is used commerically and has been packaged for Fedora. mcb30 has recently added explicit license overview support (they mention it in the email thread). You can do make bin/virtio-net.rom.licence to get a breakdown of the licensing situation. If you contact them [[=the current thread]], perhaps they'd like to join #etherboot or send a mail to the etherboot-developers mailing list. I hope we can see gpxe in Debian soon; it's really valueable for creating bootable media for LTSP clients. Kind regards, Alkis GEorgopoulos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
