Bug#1068732: prometheus-ipmi-exporter: debian path patch breaks local collection with sudo
Hi Daniel, On Thu, Apr 11, 2024 at 09:41:44AM +0200, Daniel Swarbrick wrote: > In the upstream bug report, it is suggested that one should "complain to > [Debian] to get this fixed". Yea - upstream's tone was not kind. I hope I didn't come across as complaining, and apologies if I did. > Have you tried overriding the --freeipmi.path flag back to an empty string > (e.g. --freeipmi.path="") so that ipmi_exporter falls back to searching on > the PATH? No, that didn't occur to me. But thanks, that works great! Ross signature.asc Description: PGP signature
Bug#1065649: e17: changes for libddcutil 2.1.4
Control: tags -1 pending Hi Sanford, On Fri, Mar 08, 2024 at 02:10:12AM -0500, Sanford Rockowitz wrote: > The version of ddcutil in Debian is being updated to release 2.1.4. Shared > library package libddcutil5 replaces libddcutil4. > > Source package e17 has been identified as using libddcutil. > > File e_system_ddc.c should be modified to try opening libddcutil.so.5 before > libddcutil.so.4. > > In debian/control, consider adding: > > Recommends: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4) > or > Suggests: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4) Thanks for the heads up. Both changes will be in the next upload. Upstream's also merged support in: https://git.enlightenment.org/enlightenment/enlightenment/pulls/68 Thanks, Ross
Bug#1068732: prometheus-ipmi-exporter: debian path patch breaks local collection with sudo
Package: prometheus-ipmi-exporter Version: 1.8.0-1 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, The Debian package for prometheus-ipmi-exporter carries a patch [1] to set freeipmi.path by default. Due to a surprising design, this breaks the config required to run a local exporter as an unprivileged user. That involves using sudo as follows: modules: default: collectors: - bmc - ipmi collector_cmd: bmc: sudo ipmi: sudo custom_args: bmc: - bmc-info ipmi: - ipmimonitoring Surprisingly, freeimpi.path applies to the collect_cmd entires. So the exporter prepends /usr/bin to those entires, and fails to find sudo. Since there is no way to override this, I don't see any way to run without root. There's an upstream report of this issue at [2]. Thanks, Ross [1] - https://salsa.debian.org/go-team/packages/prometheus-ipmi-exporter/-/blob/debian/sid/debian/patches/0001-Set-sane-defaults-for-Debian-systems.patch [2] - https://github.com/prometheus-community/ipmi_exporter/issues/153 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.8.2 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages prometheus-ipmi-exporter depends on: ii adduser 3.137 pn freeipmi-tools ii init-system-helpers 1.66 ii libc62.37-15 ii systemd-sysv 255.4-1 prometheus-ipmi-exporter recommends no packages. prometheus-ipmi-exporter suggests no packages.
Bug#1068107: cloud.debian.org: pull images with compromised xz packages
Package: cloud.debian.org Severity: important X-Debbugs-Cc: rvandegr...@debian.org Hi team, We should probably pull the daily sid and trixie images built with the compromised xz-utils. Looking at the json manifests, this would be: sid: all images since 2024-02-27 trixie: 2024-03-05 through 2024-03-28, inclusive I determined these dates by looking at the azure amd64 manifest, since it's first in the dir listing. I haven't looked into why the sid builds still say they include liblzma5 5.6.0-0.2. Finally, apologies for not being able to do this myself - I still do not have my account setup for access to core machines. Ross
Bug#1057548: cloud-init: FTBFS: failing tests
Control: tags -1 pending On Mon, Feb 19, 2024 at 01:47:24PM -0800, Ross Vandegrift wrote: > On Tue, Dec 05, 2023 at 11:04:12PM +0100, Santiago Vila wrote: > > During a rebuild of all packages in unstable, your package failed to build: > > I started updating to the latest upstream release, which fixes this FTBFS. > But > I'm reluctant to push to the team repo, due to an issue with the network > nocloud datasource. > > With a local webserver hosting cloud-init seed data, cloud-init 23.4.3 never > hits my local http server. The same setup with 23.3.1 from sid works fine. > Disk based nocloud seeds work fine with 23.4.3. Upstream found and fixed this issue in 23.4.4 But before I could get to packaging it, they also released 24.1. I just pushed updates with the new version to salsa. The new version is working for me. I don't have upload access for cloud-init - we can work out an upload at the team meeting next week. Ross
Bug#1057548: cloud-init: FTBFS: failing tests
On Tue, Dec 05, 2023 at 11:04:12PM +0100, Santiago Vila wrote: > During a rebuild of all packages in unstable, your package failed to build: I started updating to the latest upstream release, which fixes this FTBFS. But I'm reluctant to push to the team repo, due to an issue with the network nocloud datasource. With a local webserver hosting cloud-init seed data, cloud-init 23.4.3 never hits my local http server. The same setup with 23.3.1 from sid works fine. Disk based nocloud seeds work fine with 23.4.3. So far, I haven't found any obvious failure - under 23.4.3, DataSourceNoCloudNet either doesn't run or can't reach the http server. In case anyone has time to poke, the new release is pushed to my personal repo at https://salsa.debian.org/rvandegrift/cloud-init Ross
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
On Mon, Nov 13, 2023 at 01:48:09PM +0900, Osamu Aoki wrote: > But not for LXD since it uses different images. Image normally downloaded and > used by `lxc launch ...` becomes buggy once its instance is started because > then > cloud-init starts system initialization with its default setting. Oh right, that's what I wasn't putting together. Sorry for making you repeat yourself. > Here is how I get around this problem by removing toxic netdev out of > installed > file /etc/cloud/cloud.cfg: Is unusual GID numbering the only impact, or does this cause more significant problems? I guess user code that tries to statically assign GID 1000 will break. I agree it should be fixed. In unstable it seems reasonable to change the config. But I'm not sure I think it warrants a stable update. Ross
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote: > Package: cloud-init > Version: 22.4.2-1 > Severity: normal > > ## Background: > > The problem and possible root cause fix are reported on upstream github > issue: https://github.com/canonical/cloud-init/issues/4603 > > ## Issue: > I noticed instance generated from Debian bookworm cloud image on > linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a > system group, this situation violates Debian policy. Hi Osamu, As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691. Is that incorrect? Ross [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700#25
Bug#1043304: Latest Debian 12 AMI will not allocate a public IP at creation time
Control: tags -1 moreinfo Hi Tom, > I created an EC2 instance in us-east-1 using the command line below. The > instance does not have a public IP, although I requested one. It is not > possible to add a public IP after creation time, except for elastic IPs, > which carry additional cost. I tried to reproduce, and was not able to. Using the same AMI as you, as well as the latest build (ami-0cb7a724e5bafff67 in us-west-2), the instance was assigned a public IP. The initial response to run-instances does not include a PublicIpAddress, but it is there a describe-instances response within a few seconds. I observed the same behavior when I laucnhed Ubuntu 22.04 from i-0f0d0cdaa7102be65 in us-west-2. Do you see a public ip if you describe the new instance after creation? Thanks, Ross
Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal
Hi Simon, On Sat, Sep 16, 2023 at 07:37:31PM +0100, Simon McVittie wrote: > On Sat, 16 Sep 2023 at 08:54:11 -0700, Ross Vandegrift wrote: > > That's correct - but I'm afraid this is the only item in this bug report > > that I > > understand. I tried to read the documentation you linked, but both assume > > general familiarity with what's going on here. For me, this all might as > > well > > be greek. > > Sorry, I'm doing my best to strike a balance between "wall of text" and > being clear. > > Adapted from an issue report I sent upstream in Xfce, > https://gitlab.xfce.org/xfce/xfce4-session/-/issues/181, which they seem > to have found useful: That was incredibly helpful. I think I'm clear on what needs to be done now, and should be able to tackle it soon. Also, thanks a million for helping me understand the big picture and providing references to useful tools. It's very kind of you! Ross
Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal
Hi Simon,
On Thu, Aug 31, 2023 at 02:20:51PM +0100, Simon McVittie wrote:
> xdg-desktop-portal 1.17.x introduces a new way to select which portals will
> be used for which desktop environments, modelled on mimeapps.list:
>
> - each desktop environment should provide a file like
> /usr/share/xdg-desktop-portal/enlightenment-portals.conf
>
> - the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
> environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
> from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case
>
> - sysadmins and users can override this via files named portals.conf or
> ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
> and ~/.config/xdg-desktop-portal
>
> Please see portals.conf(5) or its source code
> https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
> for full details.
>
> If I'm reading its code correctly, I think Enlightenment asks the display
> manager
> to set XDG_CURRENT_DESKTOP to "Enlightenment"? (But if I'm wrong, please
> adjust my suggestions accordingly.)
That's correct - but I'm afraid this is the only item in this bug report that I
understand. I tried to read the documentation you linked, but both assume
general familiarity with what's going on here. For me, this all might as well
be greek. :)
I don't know of any portal requirements for Enlightenment, but I'm not really
clear whether or not that's what you're asking for. Is there a more basic
description of what this does? How would I test a change that implemented what
you're requesting? And what are the consequences of not doing this?
Thanks,
Ross
Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes
Hi Lucas, On Wed, Aug 02, 2023 at 10:38:24PM -0700, Ross Vandegrift wrote: > The system tests need some easy fixes. The end to end test tries to boot the > image on the native arch. It probably needs a feature to check if qemu is > needed. Time permitting, I plan to look at these in the next few days. I have the tests fixed and added support for non-native arch E2E test runs with qemu. I've opened: - system test fixes: https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/16 - arm64 pipeline support wip: https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/17 The first could be merged, the second needs some more work. I'm not really clear on how to work on this pipeline - is the `debvagrant` script available anywhere? Ross
Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes
Hi Lucas,
On Wed, Jul 26, 2023 at 08:53:29PM +0200, Lucas Nussbaum wrote:
> On 24/07/23 at 22:00 -0700, Ross Vandegrift wrote:
> > I've been in touch with folks from the kdevops project [1]. They are
> > looking
> > for more vagrant images for arm64. Would it be possible to publish the
> > arm64
> > boxes that debian-vagrant-images can build?
> >
> > I started looking into this. I'm pretty new to vagrant, but here's what I
> > learned so far:
> >
> > - vagrant doesn't handle boxes with different architectures [2]. The advice
> > seems to be to publish under a different name: e.g.
> > "debian/testing-arm64".
> >
> > - Building the arm64 box works just fine, and I can import it sucessfully.
> >
> > - I'm trying to get vagrant to boot it, but still not quite there yet.
>
> If you manage to get working images for arm64, I would then be happy to
> maintain them at the same time as the amd64 images.
I've confirmed the vagrant arm64 build works with qemu on amd64. If you have
qemu-system-arm and qemu-efi-aarch64 installed, the following Vagrantfile
should boot up:
Vagrant.configure("2") do |config|
config.vm.box = "debian/bookworm-arm64"
config.vm.provider :libvirt do |libvirt|
libvirt.cpu_mode = "custom"
libvirt.cpu_model = "max"
libvirt.driver = "qemu"
libvirt.emulator_path = "/usr/bin/qemu-system-aarch64"
libvirt.graphics_type = "none"
libvirt.input :type => "mouse", :bus => "virtio"
libvirt.loader = "/usr/share/AAVMF/AAVMF_CODE.fd"
libvirt.nvram = "/var/lib/libvirt/qemu/nvram/vagrant.fd"
libvirt.machine_arch = "aarch64"
libvirt.machine_type = "virt"
libvirt.memory = 512
end
end
The system tests need some easy fixes. The end to end test tries to boot the
image on the native arch. It probably needs a feature to check if qemu is
needed. Time permitting, I plan to look at these in the next few days.
Ross
Bug#1041900: cloud.debian.org: please publish arm64 vagrant boxes
Package: cloud.debian.org Severity: wishlist User: cloud.debian@packages.debian.org Usertags: vagrant image X-Debbugs-Cc: rvandegr...@debian.org Hello, I've been in touch with folks from the kdevops project [1]. They are looking for more vagrant images for arm64. Would it be possible to publish the arm64 boxes that debian-vagrant-images can build? I started looking into this. I'm pretty new to vagrant, but here's what I learned so far: - vagrant doesn't handle boxes with different architectures [2]. The advice seems to be to publish under a different name: e.g. "debian/testing-arm64". - Building the arm64 box works just fine, and I can import it sucessfully. - I'm trying to get vagrant to boot it, but still not quite there yet. Thanks, Ross [1] - https://github.com/mcgrof/kdevops/ [2] - https://github.com/hashicorp/vagrant/issues/12610
Bug#1040406: python3-azure-cli - fails with No module named 'azure.mgmt.compute.v2022_11_01'
Package: azure-cli Version: 2.45.0-1 Followup-For: Bug #1040406 X-Debbugs-Cc: rvandegr...@debian.org Hi Luca, I'm hitting this issue on azure-cli in bookworm. It sounds like this package is difficult - but is there any possibility of a stable update? $ az vm The command failed with an unexpected error. Here is the traceback: No module named 'azure.mgmt.compute.v2022_11_01' ... Thanks, Ross -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-rc3 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages azure-cli depends on: ii python33.11.2-1+b1 ii python3-azure-cli 2.45.0-1 azure-cli recommends no packages. azure-cli suggests no packages. -- no debconf information
Bug#1040681: devscripts: transition-check disagrees with tracker.d.o
Package: devscripts Version: 2.23.4 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, I just happened to notice that https://tracker.debian.org/pkg/efl lists a transition that src:efl is involved in, but transition-check doesn't notice: $ transition-check transition-check: No packages examined are currently blocked Ross -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- DEBSIGN_KEYID="B008 D750 B6B7 8361 ED53 56F0 DAB3 8932 9A4C FA16" -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-rc3 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.21.22 ii fakeroot 1.31-1.2 ii file 1:5.44-3 ii gnupg 2.2.40-1.1 ii gpgv 2.2.40-1.1 ii libc6 2.36-9 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl0.12-2 ii libfile-which-perl1.27-2 ii libipc-run-perl 20220807.0-1 ii libmoo-perl 2.005005-1 ii libwww-perl 6.68-1 ii patchutils0.4.2-1 ii perl 5.36.0-7 ii python3 3.11.2-1+b1 ii sensible-utils0.0.17+nmu1 ii wdiff 1.2.2-5 Versions of packages devscripts recommends: ii apt 2.6.1 ii curl7.88.1-10 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2022.12.24 ii dput1.1.3 ii equivs 2.3.1 ii libdistro-info-perl 1.5 ii libdpkg-perl1.21.22 ii libencode-locale-perl 1.05-3 ii libgit-wrapper-perl 0.048-2 ii libgitlab-api-v4-perl 0.26-3 ii liblist-compare-perl0.55-2 ii liblwp-protocol-https-perl 6.10-1 ii libsoap-lite-perl 1.27-3 ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl0.31-2 ii liburi-perl 5.17-1 ii licensecheck3.3.5-1 ii lintian 2.116.3 ii man-db 2.11.2-2 ii patch 2.7.6-7 ii pristine-tar1.50 ii python3-apt 2.6.0 ii python3-debian 0.1.49 ii python3-magic 2:0.4.26-3 ii python3-requests2.28.1+dfsg-1 ii python3-unidiff 0.7.3-1 ii python3-xdg 0.28-2 ii strace 6.1-0.1 ii unzip 6.0-28 ii wget1.21.3-1+b2 ii xz-utils5.4.1-0.2 Versions of packages devscripts suggests: ii adequate 0.15.7 pn at ii autopkgtest 5.28 pn bls-standalone ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.11.4 pn diffoscope pn disorderfs pn dose-extra pn duck ii elpa-devscripts 40.5 pn faketime ii gnuplot 5.4.4+dfsg1-2 ii gnuplot-qt [gnuplot] 5.4.4+dfsg1-2+b2 pn how-can-i-help ii libauthen-sasl-perl 2.1600-3 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-3 pn libterm-size-perl ii libtimedate-perl 2.3300-2 ii libyaml-syck-perl 1.34-2+b1 ii mailutils [mailx] 1:3.15-4 ii mmdebstrap1.3.5-7 pn mozilla-devscripts pn mutt ii openssh-client [ssh-client] 1:9.2p1-2 ii piuparts 1.1.7 ii postgresql-client-15 [postgresql-client] 15.3-0+deb12u1 pn pristine-lfs ii quilt 0.67+really0.66-1 pn ratt pn reprotest pn svn-buildpackage pn w3m -- no debconf information
Bug#1010291: postgresql-common: Does /var/log/postgresql really need chmod +t?
Package: postgresql-common Version: 248 Followup-For: Bug #1010291 X-Debbugs-Cc: rvandegr...@debian.org Control: tags -1 patch After upgrading to bookworm, I was reminded of this bug when /var/log/postgresql's sticky bit re-appeared. So I dug a bit more. postgresql-common's postinst unconditionally changes owners and modes on /var/log/postgresql. The patch below makes it respect dpkg-statoverride. Thanks, Ross diff --git a/debian/postgresql-common.postinst b/debian/postgresql-common.postinst old mode 100644 new mode 100755 index 545146a..638c8b8 --- a/debian/postgresql-common.postinst +++ b/debian/postgresql-common.postinst @@ -65,8 +65,10 @@ Please fix this and reinstall this package." >&2 # nicer log directory permissions mkdir -p /var/log/postgresql -chmod 1775 /var/log/postgresql -chown root:postgres /var/log/postgresql +if ! dpkg-statoverride --list /var/log/postgresl > /dev/null; then +chmod "$LOG_MODE" /var/log/postgresql +chown root:postgres /var/log/postgresql +fi # create socket directory [ -d /var/run/postgresql ] || \
Bug#1037166: libelementary-data: versions of libelementary1 and libelementary-data don't match on ia64
Control: tags -1 wontfix Hi Thomas, On Tue, Jun 06, 2023 at 08:42:18PM +0200, Thomas Uhle wrote: > So libelementary1 (version 1.25.1-1) expects to have libelementary-data from > version 1.25.1-1 as well which is but from version 1.26.3-1 in the > repositories. That is why this dependency cannot be fulfilled on i64. That's correct - EFL requires all of its components to be upgraded jointly. And Debian likes to build arch-indep packages separately from arch-dependent. > That is why some packages currently fail to build on Debian's ia64 build > servers although they would compile if libelementary1 could be installed > along with libefl-all-dev. So I see two options: could you please either > compile src:efl on ia64 using gcc-10 as long as the newer gcc versions are > crashing, or could you please put back libelementary-data from version > 1.25.1-1 into the ia64 repository. I don't think either plan is workable. Requiring gcc 10 is a temporary fix, and is more drastic than I'm keen to accommodate. And reverting libelementary-data won't work either - afaik, I'd have to do a new source upload which would fail due to this bug. I think this requires fixing the bugs in gcc > 10. You might ask about this on debian-i...@lists.debian.org though the thread at [1] makes me doubt you'll get a fix. Sorry, Ross [1] - https://lists.debian.org/debian-ia64/2023/05/msg0.html
Bug#1034102: UDD patches: incorrect handling of Forwarded?
Package: qa.debian.org Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, I think there are some issues with the Forwarded handling here: https://udd.debian.org/patches.cgi?src=e17=0.25.4-2 DEP3 has this description for Forwarded: > Any value other than "no" or "not-needed" means that the patch has been > forwarded upstream. Ideally the value is an URL proving that it has been > forwarded and where one can find more information about its inclusion status. > > If the field is missing, its implicit value is "yes" if the "Bug" field is > present, otherwise it's "no". The field is really required only if the patch > is vendor specific, in that case its value should be "not-needed" to indicate > that the patch must not be forwarded upstream (whereas "no" simply means that > it has not yet been done). The patch linked above is tagged Forwarded=yes - which is not ideal, but not invalid. Looking for more info, I found that the html source has: > invalid This doesn't show up in firefox - was this was meant to go into the content of the span? And as far that error - to my reading, DEP3 doesn't require a Bug when Forwarded=yes. Bug's presence or absence only changes the implicit value. A note that Forwarded=yes without a Bug is not informative would be helpful. :) Thanks, Ross
Bug#1033159: terminology: When using vim with Terminology the underline atribute gets turned on when scrolling.
Control: tags - 1 pending On Sat, Mar 18, 2023 at 03:16:14PM +, Jon Westgate wrote: > How to produce: > open vim inside terminology enit a file that is larger than the > terminal and requires scrolling (it shows best with a 2 page document > with a reasonable coverage of text) simply scroll up of down past the > current view point and you will note that new text has the underline > atribute set. Scrolling back up will result in off screen text being > rendered with underline attribute set as it comes back down into view. I wasn't able to reproduce this, but the upstream developer knew of the issue. It's been fixed upstream, and is waiting for the next debian upload. Due to the release freeze, I won't be able to upload this until after the bookworm release. Ross
Bug#1005318: Any update for this request?
On Fri, Apr 07, 2023 at 01:26:48AM +, Winnie Yue wrote: > Could you please upgrade cloud-init to the latest release 23.1.1? Your > help will be greatly appreciated. Thanks. We are currently in the freeze period for the bookworm release, so this won't happen until after the release is complete. Ross
Bug#1033159: terminology: When using vim with Terminology the underline atribute gets turned on when scrolling.
Control: -1 tags moreinfo Hi Jon, On Sat, Mar 18, 2023 at 03:16:14PM +, Jon Westgate wrote: > How to produce: > open vim inside terminology enit a file that is larger than the > terminal and requires scrolling (it shows best with a 2 page document > with a reasonable coverage of text) simply scroll up of down past the > current view point and you will note that new text has the underline > atribute set. Scrolling back up will result in off screen text being > rendered with underline attribute set as it comes back down into view. I've seen this bug occasionally, thanks for the details. I suspect it's a bug in terminology, but I can't reproduce with my current window a large log file I happen to have lying around. Could you provide some more info? - what's your window geometry? - can you provide a sample file (or generation instructions) that trigger it? - what do you mean "scrolling"? (scrolling in vim via mouse or keyboard vs. scrolling back in the terminology scrollback buffer) Thanks, Ross
Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command
On Fri, Feb 17, 2023 at 09:54:08PM +0100, Santiago Vila wrote: > After applying the suggested patch, the reported error > does not show anymore. > > Instead, I get this: > > /scripts/local-bottom/growroot: line 97: wait-for-root: not found > > Where does this "wait-for-root" come from? > I can't find it in any package. There's a relevant MR in salsa: https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/2 Would you mind testing the patch there? I don't know how widely used this package is. Thanks, Ross
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
On Fri, Dec 16, 2022 at 03:48:00PM -0800, Ross Vandegrift wrote: > At a high level the issue is: firewalld.service forces network-pre.target > after > sysinit.target, but cloud-init.service forces the other way around. In > detail, > using < to represent Before, the imposed orderings look like: > > - from firewalld: > sysinit.target < dbus.service < firewalld.service < network-pre.target > - from cloud-init: > cloud-init-local.service < network-pre.target < > systemd-networkd-wait-online.service < cloud-init.service < sysinit.target > > There's a few approaches to resolving this. As far as I can tell, the only > immediately viable one (at the bottom) requires users to manually fix this > and accept some trade-offs. Anyone have any better ideas? We discussed this issue on the recent cloud-team meeting and had some revised options. > Modify firewalld to run before sysinit.target > - [snip] This one still seems impossible. > Modify cloud-init to run after sysinit.target > - [snip] The main downside of this one, is that cloud-init will be running too late to configure block devices. But this feature didn't always work well. So maybe we'd affect a non-working feature. I've confirmed that cloud-init's block device setup is working well on AWS at least. So I think this will break working cloud-init features. IMO, that means it is not viable. > Locally override firewalld.service's order > -- [snip] This remains unattractive since unsuspecting users will be left with broken images and no clear path to fix the problem. Modify dbus to run later We discussed a way improve things by shuffling dbus later, but I didn't take good enough notes, and I can't reconstruct the details. Sorry for forgetting - Bastian do you recall the details? Add Breaks or Conflicts to prevent coinstallation - None of the alternatives seem reasonable and installing cloud-init and firewalld cannot produce a working Debian image. So we should prevent this state. We thought Conflicts might be required because once both are unpacked, the problematic cycle technically exists. Though it may not cause harm unless both services are (re-)started simultaneously. Ross
Bug#1028266: libegl-mesa0: terminology segfaults after ugprade to 22.3.2-1
Control: tags -1 forwarded https://gitlab.freedesktop.org/mesa/mesa/-/issues/7949 Hello, I think this is the issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7949 And the fix is in this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20479/diffs The diff applies to the version in unstable. I ran into some challenges trying to test, but will try again another day. Ross On Mon, Jan 09, 2023 at 10:19:20AM +0100, Fabio Pedretti wrote: > Can you check if a similar issue is already reported at > https://gitlab.freedesktop.org/mesa/mesa/-/issues and eventually open > a new issue there? > > Il giorno lun 9 gen 2023 alle ore 00:09 Ross Vandegrift > ha scritto: > > After upgrading to mesa 22.3.2-1, terminology (a terminal emulater, package > > has > > the same name) began randomly crashing. Crashes were triggered by tab > > switching or window resizing. Downgrading back to 22.2.4-1 fixes the issue. >
Bug#1019521: blhc: False positive for Qt6 moc
Package: blhc
Version: 0.13-2
Followup-For: Bug #1019521
X-Debbugs-Cc: rvandegr...@debian.org
Hello,
I also ran into this- moc is now at /usr/lib/qt6/libexec/moc. I think the
attached patch should address this.
Thanks,
Ross
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (40, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages blhc depends on:
ii libdpkg-perl 1.21.9
blhc recommends no packages.
blhc suggests no packages.
-- no debconf information
From a6efb36f50164e3a6099e9e2b09ae598413d68fa Mon Sep 17 00:00:00 2001
From: Ross Vandegrift
Date: Tue, 20 Dec 2022 22:39:29 -0800
Subject: [PATCH] update moc handling to be aware of Qt6
moc is now at /usr/lib/qt6/libexec/moc in qt6.
---
bin/blhc | 2 +-
t/logs/qt4 | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/bin/blhc b/bin/blhc
index e3c14b4..6199967 100755
--- a/bin/blhc
+++ b/bin/blhc
@@ -1076,7 +1076,7 @@ foreach my $file (@ARGV) {
# C++ files. No hardening flags are relevant during this step,
# thus ignore `moc-qt*` lines. The resulting files will be
# compiled in a separate step (and therefore checked).
-next if $line =~ m{^\S+/bin/moc(?:-qt[45])?
+next if $line =~ m{^\S+/(?:bin|lib/qt6/libexec)/moc(?:-qt[45])?
\s.+\s
-I\S+/mkspecs/[a-z]+-g\++(?:-64)?
\s}x;
diff --git a/t/logs/qt4 b/t/logs/qt4
index e816ce1..57b89b8 100644
--- a/t/logs/qt4
+++ b/t/logs/qt4
@@ -18,3 +18,7 @@ dpkg-buildpackage: source package test
# From qtcreator (2.7.0-1), uses different paths.
/usr/lib/arm-linux-gnueabi/qt4/bin/moc -DQT_WEBKIT
-DIDE_LIBRARY_BASENAME=\"lib/arm-linux-gnueabi\" -DQT_NO_CAST_TO_ASCII
-DQT_NO_CAST_FROM_ASCII -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION
-DQTCREATOR_UTILS_LIB -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_GUI_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++
-I../../../../src/libs/utils -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtScript -I/usr/include/qt4 -I../../../src
-I../../../../src/libs -I/«PKGBUILDDIR»/tools -I../../../../src/plugins
-I../../../../src/libs/utils -I.moc/release-shared -I.uic -I.
../../../../src/libs/utils/environmentmodel.h -o
.moc/release-shared/moc_environmentmodel.cpp
/usr/lib/arm-linux-gnueabi/qt4/bin/moc -DQT_WEBKIT
-DIDE_LIBRARY_BASENAME=\"lib/arm-linux-gnueabi\" -DQT_NO_CAST_TO_ASCII
-DQT_NO_CAST_FROM_ASCII -DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_FAST_CONCATENATION
-DQTCREATOR_UTILS_LIB -DQT_NO_DEBUG -DQT_SCRIPT_LIB -DQT_GUI_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++
-I../../../../src/libs/utils -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtScript -I/usr/include/qt4 -I../../../src
-I../../../../src/libs -I/«PKGBUILDDIR»/tools -I../../../../src/plugins
-I../../../../src/libs/utils -I.moc/release-shared -I.uic -I.
../../../../src/libs/utils/qtcprocess.h -o
.moc/release-shared/moc_qtcprocess.cpp
+
+# test to check that moc from qt6 is handled
+
+/usr/lib/qt6/libexec/moc -DEXTERN_QUAZIP -DQT_CORE_LIB -DQT_GUI_LIB
-DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_SQL_LIB
-DQT_WIDGETS_LIB -DQT_XML_LIB
-I/builds/rvandegrift/mediaelch/debian/output/source_dir/obj-x86_64-linux-gnu
-I/builds/rvandegrift/mediaelch/debian/output/source_dir
-I/builds/rvandegrift/mediaelch/debian/output/source_dir/src
-I/usr/include/x86_64-linux-gnu/qt6/QtSql -I/usr/include/x86_64-linux-gnu/qt6
-I/usr/include/x86_64-linux-gnu/qt6/QtCore
-I/usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++
-I/usr/include/x86_64-linux-gnu/qt6/QtWidgets
-I/usr/include/x86_64-linux-gnu/qt6/QtGui
-I/usr/include/x86_64-linux-gnu/qt6/QtMultimedia
-I/usr/include/x86_64-linux-gnu/qt6/QtNetwork
-I/usr/include/x86_64-linux-gnu/qt6/QtXml -I/usr/include -I/usr/include/c++/12
-I/usr/include/x86_64-linux-gnu/c++/12 -I/usr/include/c++/12/backward
-I/usr/lib/gcc/x86_64-linux-gnu/12/include -I/usr/local/include
-I/usr/include/x86_64-linux-gnu --include
/builds/rvandegrift/mediaelch/debian/output/source_dir/obj-x86_64-linux-gnu/src/scrapers/tv_show/tmdb/mediaelch_scraper_tv_tmdb_autogen/moc_predefs.h
--output-dep-file -o
/builds/rvandegrift/mediaelch/debian/output/source_dir/obj-x86_64-linux-gnu/src/scrapers/tv_show/tmdb/mediaelch_scraper_tv_tmdb_autogen/EWIEGA46WW/moc_TmdbTvShowSearchJob.cpp
/builds/rvandegrift/mediaelch/debian/output/source_dir/src/scrapers/tv_show/tmdb/TmdbTvShowSearchJob.h
--
2.35.1
Bug#1026434: ITP: mediaelch -- media tagger/manager for Kodi
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: mediaelch Version : 2.8.18 Upstream Author : Andre Meyering * URL : https://www.mediaelch.de/mediaelch/ * License : LGPL-3.0 Programming Lang: C++ Description : media tagger/manager for Kodi MediaElch is a MediaManager for Kodi. Information about Movies, TV Shows, Concerts and Music are stored as NFO files. Fanarts are downloaded automatically from fanart.tv. MediaElch is one of the media managers listed on the Kodi wiki [1] for tagging media. None are available in Debian. I've been using it occasionally and suspect others might like it too. Ross [1] - https://kodi.wiki/view/NFO_files/Creating#Media_Managers
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
On Mon, Dec 12, 2022 at 05:41:46PM -0800, Noah Meyerhans wrote: > On 12/12/2022 6:44 AM, Sam Hartman wrote: > > >> From my quick read: Michael Biebl proposes dropping > > >> network-pre.target > > Ross> from cloud-init's After=, and replacing it with each of the > > Ross> config backends that cloud-init supports. This sounds pretty > > Ross> reasonable, but also like something that upstream should > > Ross> address first. > > > > Why wait for upstream? > > It's a bug affecting Debian users, our systemd maintainer has a solution > > that you (and I) think is reasonable. > > The symptom is quite serious. > > We often make changes before upstream in situations like that, > > especially when the alternative is: > > > > Ross> Should we consider adding "Conflicts: firewalld" to cloud-init > > Ross> before the freeze? That's not optimal of course, but it'd > > Ross> prevent a user from ending up in this situation for now. > > > > I'd much rather see Debian local changes than conflicts. > > We should simply move this discussion to an upstream pull request rather > than wait passively for their response. I agree that diverging from upstream > is preferable to unnecessary conflicts, but it shouldn't be done without > first consulting with upstream on our proposed solution. I played with the suggested solution and was unable to get it working: cloud-init.service doesn't have a /direct/ Before=network-pre.target to remove. The ordering is implicit in the combination of units. Probably, I think Michael knew that when he made the suggestion - but I had to play with it for a few hours first. :) At a high level the issue is: firewalld.service forces network-pre.target after sysinit.target, but cloud-init.service forces the other way around. In detail, using < to represent Before, the imposed orderings look like: - from firewalld: sysinit.target < dbus.service < firewalld.service < network-pre.target - from cloud-init: cloud-init-local.service < network-pre.target < systemd-networkd-wait-online.service < cloud-init.service < sysinit.target There's a few approaches to resolving this. As far as I can tell, the only immediately viable one (at the bottom) requires users to manually fix this and accept some trade-offs. Anyone have any better ideas? Modify firewalld to run before sysinit.target - This would let cloud-init and firewalld agree to do network-pre.target before sysinit.target. This is probably not possible since firewalld requires dbus, which starts after sysinit.target. There's a thread at [1] about why moving firewalld to be an early boot service is difficult. Modify cloud-init to run after sysinit.target - This would let cloud-init and firewalld agree to do network-pre.target after sysinit.target. This might not be advisable (see comments in [1] about running network management services in late boot), but it looks like this is how RHEL does it [2]. >From [3], I think cloud-init.service added Before=basic.target (which eventually became Before=sysinit.target) to ensure cloud-init configured block device mounts were ready early enough in boot process. The network needs to be online for this, since some block device config can come from network sources. So changing this in the Debian package seems risky to me. Locally override firewalld.service's order -- If you need to use both together, create an override unit that removes Before=network-pre.target. This eliminates the cycle by allowing cloud-init's order to win. But it the network will be up without firewalld for a period. Unfortunately, dependencies can't be removed in a drop-in - so I think you need to copy the unit to /etc/systemd/system and modify it. Ross [1] - https://lists.freedesktop.org/archives/systemd-devel/2022-March/047538.html [2] - https://github.com/canonical/cloud-init/blob/main/systemd/cloud-init.service.tmpl#L4-L6 [3] - https://github.com/canonical/cloud-init/commit/80f5ec4be0f781b26eca51d90d51abfab396b3f6
Bug#1025720: emacs: systemd user unit runs automatically, even when disabled
On Wed, Dec 07, 2022 at 07:41:50PM -0600, Rob Browning wrote: > Ross Vandegrift writes: > > But it starts on my system without (as far as I recall) me enabling > > it. > > > > > > What's the appropriate way to disable it? `systemctl --user disable --now > > emacs.server` only lasts until I reboot. Masking it works. > > > > I've noticed that even after disabling, status shows it's enabled: > > $ systemctl --user disable --now emacs.service > > $ systemctl --user status emacs.service | head -n 3 > > ○ emacs.service - Emacs text editor > >Loaded: loaded (/usr/lib/systemd/user/emacs.service; enabled; > > preset: enabled) > >Active: inactive (dead) since Wed 2022-12-07 15:03:03 PST; 4s ago > > > > I don't really understand how systemd user stuff works - > > ~/.config/systemd/user > > is empty (until masking), but I don't know if that's informative. > > I suspect you're having the same problem I was, which I believe is > caused by the fact that earlier versions of the package (in untable) > didn't have --no-enable, and the auto-run behavior seems to be sticky. > > I "fixed" it here by purging and reinstalling emacs-common, but I'd hope > there's a better way. If so, I'd be happy to consider adding some notes > to a suitable /usr/share/doc file, and/or trying to automate a fix. > > Though if the fix isn't simple, I might hesitate attempting to automate > it, since the problem (I hope) only existed somewhat briefly in > unstable. Aha, thanks that's a good hint. Purging emacs-common didn't do the trick for me, but purging all emacs packages did. etckeeper then revealed the culprit: /etc/systemd/user/default.target.wants/emacs.service I couldn't easily find any tool to manage files there, since systemdctl --user does not. But probably, deleting it and doing daemon-reload or reboot would've done the job. Agreed that it probably isn't worth automating a solution to this in the package. Thanks, Ross
Bug#1025618: cloud-init and firewalld systemd unit files have ordering cycles
Control: forwarded -1 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1956629 Hi Guillaume, On Tue, Dec 06, 2022 at 06:26:26PM +0100, Guillaume Knispel wrote: > firewalld and cloud-init have ordering cycles between their systemd unit > files, leading to more or less broken boot results when both are installed > and active, because at each boot systemd decides to skip a > non-deterministically choosen service (not necessarily cloud-init or > firewalld) to break the cycle. Thanks for bringing this to our attention. There's a few useful discussions: https://github.com/firewalld/firewalld/issues/414 https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1956629 >From my quick read: Michael Biebl proposes dropping network-pre.target from cloud-init's After=, and replacing it with each of the config backends that cloud-init supports. This sounds pretty reasonable, but also like something that upstream should address first. Should we consider adding "Conflicts: firewalld" to cloud-init before the freeze? That's not optimal of course, but it'd prevent a user from ending up in this situation for now. Thanks, Ross
Bug#1025720: emacs: systemd user unit runs automatically, even when disabled
Package: emacs Version: 1:28.2+1-8 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, Should the systemd user unit be started by default? The changelog indicates no (see 1:28.1+1-4) and dh_installsystemduser is invoked with --no-enable. But it starts on my system without (as far as I recall) me enabling it. What's the appropriate way to disable it? `systemctl --user disable --now emacs.server` only lasts until I reboot. Masking it works. I've noticed that even after disabling, status shows it's enabled: $ systemctl --user disable --now emacs.service $ systemctl --user status emacs.service | head -n 3 ○ emacs.service - Emacs text editor Loaded: loaded (/usr/lib/systemd/user/emacs.service; enabled; preset: enabled) Active: inactive (dead) since Wed 2022-12-07 15:03:03 PST; 4s ago I don't really understand how systemd user stuff works - ~/.config/systemd/user is empty (until masking), but I don't know if that's informative. Thanks, Ross -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs depends on: ii emacs-lucid 1:28.2+1-8 emacs recommends no packages. emacs suggests no packages. -- no debconf information
Bug#1025099: plocate: autofs pruning doesn't seem to work
On Tue, Nov 29, 2022 at 09:27:26PM +0100, Steinar H. Gunderson wrote: > On Tue, Nov 29, 2022 at 11:31:39AM -0800, Ross Vandegrift wrote: > >> Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work > > That subject wasn't too clear- updatedb.plocate does not index the > > remote filesystem, it just triggeres the automount unnecessarily. > > I don't think that's possible to avoid; the directory must be stat()-ed > to get to know what type of filesystem it is, and I guess that would trigger > the mount? Interesting - stat -f does the same, and it always returns nfs. Here's a lame idea: /proc/mounts knows it's actually autofs... But if there's no non-hacky way to filter out unmounted autofs mounts early, I'm not sure this is worth fixing. The only impact is delayed updates when e.g. I'm not home and so the nfs won't mount. Shortening the mount timeout should help with that. > I guess it's an interesting question why it even knows how to enter that > directory, if it's not mounted; are you running with ghost on? I'm using a systemd automount unit. There's no autofs config or ghost option, but the effect is similar: systemd-1 on /mnt/storage type autofs vanvanmojo.lan:/mnt/storage on /mnt/storage type nfs4 The first is created when the unit is started, the second after automounting is triggered. Ross
Bug#1025099: plocate: autofs pruning doesn't seem to work
Control: retitle -1 autofs mount triggered in spite of pruning On Tue, Nov 29, 2022 at 11:24:03AM -0800, Ross Vandegrift wrote: > Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work That subject wasn't too clear- updatedb.plocate does not index the remote filesystem, it just triggeres the automount unnecessarily. Ross
Bug#1025099: plocate: autofs pruning doesn't seem to work
Package: plocate Version: 1.1.17-2 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, I noticed that an autofs mount is being triggered by updatedb.plocate: systemd[1]: mnt-storage.automount: Got automount request for /mnt/storage, triggered by 63669 (updatedb.plocat) It looks like the bind mount checking is involved. Here's the --debug-pruning output: $ sudo journalctl -fu mnt-storage.automount & $ mount | grep storage systemd-1 on /mnt/storage type autofs (rw,relatime,fd=55,pgrp=1,timeout=600,minproto=5,maxproto=5,direct,pipe_ino=14748) $ sudo updatedb.plocate --debug-pruning conf_block: prune_bind_mounts\000 1\000 \000 prunefs\000 AFS\000 AUTOFS\000 BINFMT_MISC\000 CEPH\000 CGROUP\000 CGROUP2\000 CIFS\000 CODA\000 CONFIGFS\000 CURLFTPFS\000 DEBUGFS\000 DEVFS\000 DEVPTS\000 DEVTMPFS\000 ECRYPTFS\000 FTPFS\000 FUSE.CEPH\000 FUSE.CRYFS\000 FUSE.ENCFS\000 FUSE.GLUSTERFS\000 FUSE.GOCRYPTFS\000 FUSE.GVFSD-FUSE\000 FUSE.MFS\000 FUSE.RCLONE\000 FUSE.ROZOFS\000 FUSE.SSHFS\000 FUSECTL\000 FUSESMB\000 HUGETLBFS\000 ISO9660\000 LUSTRE\000 LUSTRE_LITE\000 MFS\000 MQUEUE\000 NCPFS\000 NFS\000 NFS4\000 OCFS\000 OCFS2\000 PROC\000 PSTORE\000 RPC_PIPEFS\000 SECURITYFS\000 SHFS\000 SMBFS\000 SYSFS\000 TMPFS\000 TRACEFS\000 UDEV\000 UDF\000 USBFS\000 \000 prunenames\000 \000 prunepaths\000 /home/.ecryptfs\000 /media\000 /tmp\000 /var/lib/ceph\000 /var/lib/os-prober\000 /var/lib/schroot\000 /var/spool\000 \000 --- Rebuilding bind_mount_paths: `/sys' (22 on 28) is `/' of `sysfs' (0:20), type `sysfs' `/proc' (23 on 28) is `/' of `proc' (0:21), type `proc' `/dev' (24 on 28) is `/' of `udev' (0:5), type `devtmpfs' `/dev/pts' (25 on 24) is `/' of `devpts' (0:22), type `devpts' `/run' (26 on 28) is `/' of `tmpfs' (0:23), type `tmpfs' `/' (28 on 1) is `/' of `/dev/mapper/root' (254:0), type `ext4' `/sys/kernel/security' (29 on 22) is `/' of `securityfs' (0:6), type `securityfs' `/dev/shm' (30 on 24) is `/' of `tmpfs' (0:25), type `tmpfs' `/run/lock' (31 on 26) is `/' of `tmpfs' (0:26), type `tmpfs' `/sys/fs/cgroup' (32 on 22) is `/' of `cgroup2' (0:27), type `cgroup2' `/sys/fs/pstore' (33 on 22) is `/' of `pstore' (0:28), type `pstore' `/sys/firmware/efi/efivars' (34 on 22) is `/' of `efivarfs' (0:29), type `efivarfs' `/sys/fs/bpf' (35 on 22) is `/' of `bpf' (0:30), type `bpf' `/proc/sys/fs/binfmt_misc' (37 on 23) is `/' of `systemd-1' (0:31), type `autofs' `/dev/hugepages' (38 on 24) is `/' of `hugetlbfs' (0:32), type `hugetlbfs' `/dev/mqueue' (39 on 24) is `/' of `mqueue' (0:19), type `mqueue' `/sys/kernel/debug' (40 on 22) is `/' of `debugfs' (0:7), type `debugfs' `/sys/kernel/tracing' (41 on 22) is `/' of `tracefs' (0:12), type `tracefs' `/sys/kernel/config' (42 on 22) is `/' of `configfs' (0:33), type `configfs' `/sys/fs/fuse/connections' (43 on 22) is `/' of `fusectl' (0:34), type `fusectl' `/run/credentials/systemd-sysusers.service' (67 on 26) is `/' of `ramfs' (0:35), type `ramfs' `/run/credentials/systemd-tmpfiles-setup-dev.service' (69 on 26) is `/' of `ramfs' (0:36), type `ramfs' `/run/credentials/systemd-sysctl.service' (71 on 26) is `/' of `ramfs' (0:37), type `ramfs' `/efi' (82 on 28) is `/' of `systemd-1' (0:38), type `autofs' `/mnt/storage' (100 on 28) is `/' of `systemd-1' (0:39), type `autofs' `/boot' (103 on 28) is `/' of `/dev/sda1' (8:1), type `vfat' `/run/credentials/systemd-tmpfiles-setup.service' (135 on 26) is `/' of `ramfs' (0:40), type `ramfs' `/proc/sys/fs/binfmt_misc' (106 on 37) is `/' of `binfmt_misc' (0:41), type `binfmt_misc' `/run/rpc_pipefs' (182 on 26) is `/' of `sunrpc' (0:44), type `rpc_pipefs' `/run/user/1000' (252 on 26) is `/' of `tmpfs' (0:55), type `tmpfs' `/run/user/1000/doc' (259 on 252) is `/' of `portal' (0:50), type `fuse.portal' `/efi' (815 on 82) is `/' of `/dev/sda1' (8:1), type `vfat' Matching bind_mount_paths: => adding `/efi' (duplicate of mount point `/boot') ...done Checking whether filesystem `/boot' is excluded: `/sys', type `sysfs' => type matches, dir `/sys' `/proc', type `proc' => type matches, dir `/proc' `/dev', type `devtmpfs' => type matches, dir `/dev' `/dev/pts', type `devpts' => type matches, dir `/dev/pts' `/run', type `tmpfs' => type matches, dir `/run' `/', type `ext4' `/sys/kernel/security', type `securityfs' => type matches, dir `/sys/kernel/security' `/dev/shm', type `tmpfs' => type matches, dir `/dev/shm' `/run/lock', type `tmpfs' => type matches, dir `/run/lock' `/sys/fs/cgroup', type `cgroup2' => type matches, dir `/sys/fs/cgroup' `/sys/fs/pstore', type `pstore' => type matches, dir `/sys/fs/pstore' `/sys/firmware/efi/efivars', type `efivarfs' `/sys/fs/bpf', type `bpf' `/proc/sys/fs/binfmt_misc', type `autofs' => type matches, dir `/proc/sys/fs/binfmt_misc' `/dev/hugepages', type `hugetlbfs' => type matches, dir `/dev/hugepages' `/dev/mqueue', type `mqueue' => type matches, dir `/dev/mqueue' `/sys/kernel/debug', type `debugfs' => type matches,
Bug#1025080: enlightenment does not start
Control: tags -1 moreinfo Hi Pierre, I think you've misdiagnosed the problem. How are you starting enlightenment, and what error messages are you getting? Also, please provide the output of `dpkg -l dbus*` from your system. enlightenment already has: Depends: default-dbus-session-bus | dbus-session-bus See #836090 and the linked mailing list post for details on why this is the right way to depend on dbus. Ross On Tue, Nov 29, 2022 at 06:05:41PM +0100, Pierre Couderc wrote: > Package: enlightenment > > Version: 0.24.2 > > Enlightenment does not start because dbus is not started. > > dbus-x11 should be a dependency in case no session manager is used. > > I recommend a enlightenment-x11 package or including x11 in enlightenment as > nobody uses wayland... > > Pierre Couderc > >
Bug#1021045: gdm3: gdm-fingerprint fails if fprintd is installed but libpam-fprint is not
Control: reassign -1 fprintd Hello, On Sun, Nov 13, 2022 at 03:00:26PM +, Simon McVittie wrote: > On Fri, 30 Sep 2022 at 21:37:20 -0700, Ross Vandegrift wrote: > > If fprintd and gdm3 are installed, but libpam-fprintd is not installed, then > > users with enrolled fingerprints cannot login. > ... > > Installing libpam-fprintd fixes the issue. Perhaps it should be in > > Recommends > > instead of Suggests? > > I'm not sure about this as a solution. I don't think it would be true > to say that installations of gdm3 that don't need (libpam-)fprintd > are unusual, which is the level of dependency where Recommends are > necessary. Most gdm3 users log in with a password and don't use a > fingerprint reader. Yea, fair enough. I've posted an issue to gdm upstream gitlab with a request for better UX in this case. FingerForce team - Would you consider adding libpam-fprintd to fprintd's Recommends? After installing fprintd and enrolling a fingerprint, I couldn't login with gdm even though the option was presented. Strictly, it might be excessive (enlightenment could use fprintd without libpam-fprintd for unlock). But there's an awkward usability issue now since nothing pulls it in automatically. If not, I can add it to enlightenment (along with fprintd). But it seems non-optimal to require this on every WM/desktop env package. Thanks, Ross
Bug#966573: progress packaging awscli v2
On Fri, Nov 04, 2022 at 02:56:45PM -0700, Noah Meyerhans wrote: > Given the number of packages involved, though, I expect it'll take a > while for everything to have a properly managed SONAME. Given that, I > see a few alternatives: > > 1. We package aws-crt-python with all the aws-c-* packages included in a >single source package. Given that upstream maintains this structure >in a single repo using git submodules and that their build system >supports it directly, it appears to be the way they expect the package >to be consumed. > > 2. We package the individual aws-c-* dependencies but only ship static >libraries, and handle them as standard buid-deps for aws-crt-python. > > 3. We manage the SONAME versions ourselves until upstream does it for >us. > > 4. We ignore awscli v2 and continue shipping v1. > > I actually prefer #1 and suggest we do that. My reasoning is: > > 1. It's well supported by upstream, > > 2. It prevents other packages from picking up the aws-c-* packages as >dependencies before they expose a stable API/ABI, > > 3. It is simple to split out the submodules into standalone packages >one-by-one as their interfaces stabilize. > > 4. It's quite simple to implement > > What do folks think of this idea? Sounds reasonable. My initial thought was #2, but I hadn't considered the value of insulating others from upstream's changes. Ross
Bug#966573: progress packaging awscli v2
On Wed, Nov 02, 2022 at 10:26:50PM -0700, Noah Meyerhans wrote:
> Honestly, filing some of the ITPs would be quite helpful at this point.
> We'll need to get the following projects packaged:
>
> aws-c-auth
> aws-c-cal
> aws-c-compression
> aws-c-event-stream
> aws-c-http
I got this far, and then:
> SMTP send failure: {'sub...@bugs.debian.org': (451, b'sorry, only 5 reports
> per hour for
> submission')}. You can retry, or save the report and exit. Do you want to
> retry [Y|n|q|?]?
Ross
Bug#1023434: ITP: aws-c-http -- C99 implementation of the HTTP/1.1 and HTTP/2 specifications
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: aws-c-http Version : 0.6.24 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-http * License : Apache-2.0 Programming Lang: C Description : C99 implementation of the HTTP/1.1 and HTTP/2 specifications C99 implementation of the HTTP/1.1 and HTTP/2 specifications. This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#1023433: ITP: aws-c-event-stream -- C99 implementation of the vnd.amazon.event-stream content-type
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: aws-c-event-stream Version : 0.2.15 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-event-stream/tags * License : Apache-2.0 Programming Lang: C Description : C99 implementation of the vnd.amazon.event-stream content-type C99 implementation of the vnd.amazon.event-stream content-type. This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#1023432: ITP: aws-c-compression -- C99 implementation of huffman encoding/decoding
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: aws-c-compression Version : 0.2.15 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-compression * License : Apache-2.0 Programming Lang: C Description : C99 implementation of huffman encoding/decoding This is a cross-platform C99 implementation of compression algorithms such as gzip, and huffman encoding/decoding. Currently only huffman is implemented. This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#1023431: ITP: aws-c-cal -- Cross-Platform, C99 wrapper for cryptography primitives
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: aws-c-cal Version : 0.5.20 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-cal * License : Apache-2.0 Programming Lang: C Description : Cross-Platform, C99 wrapper for cryptography primitives AWS Crypto Abstraction Layer: Cross-Platform, C99 wrapper for cryptography primitives. This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#1023430: ITP: aws-c-auth -- C99 library implementation of AWS client-side authentication
Package: wnpp Severity: wishlist Owner: Ross Vandegrift X-Debbugs-Cc: debian-de...@lists.debian.org, rvandegr...@debian.org * Package name: aws-c-auth Version : 0.6.18 Upstream Author : Amazon Web Services * URL : https://github.com/awslabs/aws-c-auth * License : Apache-2.0 Programming Lang: C Description : C99 library implementation of AWS client-side authentication C99 library implementation of AWS client-side authentication: standard credentials providers and signing. This package will be maintained by the cloud team. Packaging is initially being driven by awscli v2 dependencies.
Bug#966573: progress packaging awscli v2
Hi Noah, On Mon, Oct 31, 2022 at 10:50:19PM -0700, Noah Meyerhans wrote: > On Tue, Oct 05, 2021 at 11:10:43PM -0600, Ross Vandegrift wrote: > > > awscli v2 remains quite difficult to package, but it seems that upstream > > > is looking to address this. See > > > https://github.com/aws/aws-cli/issues/6186 for details and tracking. > > > > Using the source dist poc from https://github.com/aws/aws-cli/pull/6352 I've > > made enough progress to get a packaged aws-cli v2 working. There's a lot > > more > > that needs to be done, but idea of the above linked PR could work for us. > > I'm > > going to document my findings here. > > So, only a year later, I've picked this up and made some additional > progress: > > I have no name!@b02f1db79f9e:/src$ aws --version > aws-cli/2.8.7 Python/3.10.8 Linux/6.0.0-2-amd64 source/x86_64.debian > prompt/off > I have no name!@b02f1db79f9e:/src$ dpkg -s awscli | grep Version > Version: 2.8.7-1 Great news! > > - some repos have tests disabled due to failing during builds. So far, I > > don't > > know if these are real failures, or if upstream's build method. > > I think I've got most of these fixed. 落 > > - copyright attribution for aws-lc is very hard. It's a fork of Google's > > BoringSSL, which is a fork of pre-3.0 OpenSSL. > > > > - That also means that aws-lc inherits the openssl gpl incompatibility. > > Here's the good news: We don't actually need aws-lc at all. awscli v2 > and its various dependencies (including s2n-tls) can build against > OpenSSL 3. 落 > > - the aws-cli2-temp repo is based on upstream, not our awscli repo. I was > > intentionally being sloppy to quickly get through a test. > > Same. I essentially Debianized the upstream v2 repo from scratch, > pulling in some of your packaging metadata as it made sense. Given that > v2 is developed on a different branch and by now differs quite > significantly from v1, a case could be made for introducing a new > awscli2 package as a new source package and retiring the original awscli > package. However, the debian package metadata isn't really all that > complex, so it may not actually be necessary. Is there any reason to have both versions available to install at once? > > - aws-lc and s2n-tls may be hard to maintain. Both are complicated, > > security > > critical crypto libraries. > > Fortunately, aws-lc isn't an issue. But s2n-tls remains one. Not sure > we're going to be able to do anything about that. The difficult thing > is that it's typically expected to be used as a statically linked > library, which means updates end up being tedious. Agreed, there's nothing we can do about it. But I think it's good news to be able to use OpenSSL and just have one highly security sensitive package. > I haven't pushed my changes anywhere, yet. Once I do, the remaining > tasks will be to any lintian issues or other obvious problems and get > these packages into NEW. I think they're in reasonably good shape, but > we don't have a lot of time before bookworm starts freezing, so I'd love > any help with these steps. I might have some time to help. Would it be useful to transfer my original repos to the cloud-team group? Ross
Bug#1021045: gdm3: gdm-fingerprint fails if fprintd is installed but libpam-fprint is not
Package: gdm3 Version: 43.0-1 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, If fprintd and gdm3 are installed, but libpam-fprintd is not installed, then users with enrolled fingerprints cannot login. As soon as I selected my user, the password box flashes up and away. Then I'm returned to the original user list. gdm-fingerprint logs: Sep 30 21:22:54 stgulik gdm-fingerprint][2109]: PAM unable to dlopen(pam_fprintd.so): /lib/security/pam_fprintd.so: cannot open shared object file: No such file or directory Sep 30 21:22:54 stgulik gdm-fingerprint][2109]: PAM adding faulty module: pam_fprintd.so Sep 30 21:22:54 stgulik gdm-fingerprint][2109]: gkr-pam: no password is available for user Installing libpam-fprintd fixes the issue. Perhaps it should be in Recommends instead of Suggests? Thanks, Ross -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (40, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_DIE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 22.08.8-1 ii adduser 3.129 ii dbus [default-dbus-system-bus]1.14.2-1 ii dbus-bin 1.14.2-1 ii dbus-daemon 1.14.2-1 ii dconf-cli 0.40.0-3 ii dconf-gsettings-backend 0.40.0-3 ii debconf [debconf-2.0] 1.5.79 ii enlightenment [x-window-manager] 0.25.4-1 ii gir1.2-gdm-1.043.0-1 ii gnome-session [x-session-manager] 42.0-1 ii gnome-session-bin 42.0-1+b1 ii gnome-session-common 42.0-1 ii gnome-settings-daemon 43.0-1 ii gnome-shell 42.4-2 ii gnome-terminal [x-terminal-emulator] 3.46.1-2 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-1 ii libaudit1 1:3.0.7-1.1 ii libc6 2.35-1 ii libcanberra-gtk3-00.30-10 ii libcanberra0 0.30-10 ii libgdk-pixbuf-2.0-0 2.42.9+dfsg-1 ii libgdm1 43.0-1 ii libglib2.0-0 2.74.0-1 ii libglib2.0-bin2.74.0-1 ii libgtk-3-03.24.34-3 ii libgudev-1.0-0237-2 ii libkeyutils1 1.6.3-1 ii libpam-modules1.5.2-2 ii libpam-runtime1.5.2-2 ii libpam-systemd [logind] 251.4-3 ii libpam0g 1.5.2-2 ii librsvg2-common 2.54.5+dfsg-1 ii libselinux1 3.4-1+b2 ii libsystemd0 251.4-3 ii libx11-6 2:1.8.1-2 ii libxau6 1:1.0.9-1 ii libxcb1 1.15-1 ii libxdmcp6 1:1.1.2-3 ii lsb-base 11.4 ii polkitd 0.105-33 ii procps2:3.3.17-7+b1 ii systemd-sysv 251.4-3 ii sysvinit-utils [lsb-base] 3.05-6 ii terminology [x-terminal-emulator] 1.12.1-3 ii ucf 3.0043 ii x11-common1:7.7+23 ii x11-xserver-utils 7.7+9+b1 Versions of packages gdm3 recommends: ii at-spi2-core 2.46.0-3 ii desktop-base 11.0.3 ii gnome-session [x-session-manager] 42.0-1 ii x11-xkb-utils 7.7+7 ii xserver-xephyr 2:21.1.4-2 ii xserver-xorg 1:7.7+23 ii zenity 3.43.0-1 Versions of packages gdm3 suggests: ii libpam-fprintd1.94.2-2 ii libpam-gnome-keyring 42.1-1 pn libpam-pkcs11 pn libpam-sss ii orca 42.3-1 -- debconf information: * shared/default-x-display-manager: gdm3 gdm3/daemon_name: /usr/sbin/gdm3
Bug#1019955: elpa-devscripts: errors on emacs startup
Package: elpa-devscripts Version: 40.5 Severity: normal Hello, I just installed elpa-devscripts after upgrading to bookworm. The package generates lots of warnings that I don't recall on my bullseye system. Nothing seems broken, once I clear the warnings. On the first start up: Warning (comp): debian-el.el:90:26: Warning: reference to free variable ‘dired-mode-map’ Disable showing Disable logging Warning (comp): dpkg-dev-el.el:117:44: Warning: reference to free variable ‘filename’ Disable showing Disable logging When I opened a d/changelog file: Warning (comp): debian-changelog-mode.el:495:13: Warning: Package cl is deprecated Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1273:36: Warning: ‘previous-line’ is for interactive use only; use ‘forward-line’ with negative argument instead. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1382:4: Warning: ‘easy-menu-add’ is an obsolete function (as of 28.1); this was always a no-op in Emacs and can be safely removed. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1382:18: Warning: reference to free variable ‘debian-changelog-menu’ Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1423:4: Warning: make-face called with 2 arguments, but accepts only 1 Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1428:4: Warning: set-face-foreground called with 5 arguments, but accepts only 2-3 Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1750:17: Warning: ‘imenu-progress-message’ is an obsolete macro (as of 28.1). Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1755:19: Warning: ‘imenu-progress-message’ is an obsolete macro (as of 28.1). Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1778:11: Warning: ‘imenu-progress-message’ is an obsolete macro (as of 28.1). Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1683:12: Warning: the function ‘set-extent-property’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1676:25: Warning: the function ‘make-extent’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1654:18: Warning: the function ‘delete-extent’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1653:42: Warning: the function ‘extent-end-position’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1652:42: Warning: the function ‘extent-start-position’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1651:22: Warning: the function ‘extent-detached-p’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:1625:14: Warning: the function ‘set-keymap-name’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-changelog-mode.el:880:4: Warning: the function ‘debian-bug-build-bug-menu’ is not known to be defined. Disable showing Disable logging Warning (comp): debian-bug.el:496:16: Warning: assignment to free variable ‘debian-bug-menu-action’ Disable showing Disable logging Warning (comp): debian-bug.el:652:37: Warning: ‘mapcar’ called for effect; use ‘mapc’ or ‘dolist’ instead Disable showing Disable logging Warning (comp): debian-bug.el:652:50: Warning: ‘mapcar’ called for effect; use ‘mapc’ or ‘dolist’ instead Disable showing Disable logging Warning (comp): debian-bug.el:944:41: Warning: ‘next-line’ is for interactive use only; use ‘forward-line’ instead. Disable showing Disable logging Warning (comp): debian-bug.el:1792:6: Warning: ‘easy-menu-add’ is an obsolete function (as of 28.1); this was always a no-op in Emacs and can be safely removed. Disable showing Disable logging Warning (comp): debian-bug.el:1843:6: Warning: ‘easy-menu-add’ is an obsolete function (as of 28.1); this was always a no-op in Emacs and can be safely removed. Disable showing Disable logging Warning (comp): debian-bug.el:2347:20: Warning: Use ‘with-current-buffer’ rather than save-excursion+set-buffer Disable showing Disable logging Warning (comp): debian-bug.el:2276:21: Warning: Use ‘with-current-buffer’ rather than save-excursion+set-buffer Disable showing Disable logging Warning (comp): debian-bug.el:2351:33: Warning: Use ‘with-current-buffer’ rather than save-excursion+set-buffer Disable showing Disable logging Warning (comp): debian-bug.el:2360:10: Warning: ‘easy-menu-remove’ is an obsolete function (as of 28.1); this was always a no-op in Emacs and can be safely removed. Disable showing Disable logging Warning (comp): debian-bug.el:2371:10: Warning: ‘easy-menu-remove’ is an obsolete
Bug#1017584: bullseye launch failures in IPv6-only VPC subnets
On Wed, Aug 17, 2022 at 07:40:04PM -0700, Noah Meyerhans wrote: > Adding some tracing to the dhclient-script, I can see that > /etc/dhcp/dhclient-exit-hooks.d/rfc3442-classless-routes is trying to add > the routes with calls like: > > ip -4 route add 169.254.169.254/32 via 169.254.0.1 dev ens5 > > However, because there's no route to 169.254.0.1, the call fails with > "Error: Nexthop has invalid gateway." > > On systems where the routes are properly configured, there's a link scope > route to that address, e.g. on sid: > > 169.254.0.1 dev ens5 proto dhcp scope link src 169.254.2.187 metric 100 > > If we create this route on bullseye, then the rest of the IPv4 routes are > installed as expected. Something like the following could work, but I'm > open to other options: > > services/admin@i-07e63055bb304147c:~$ cat /etc/dhcp/dhclient-exit-hooks.d/gw > case "$reason" in > BOUND|RENEW|REBIND|REBOOT) > if [ -z "$old_ip_address" ] || >[ "$old_ip_address" != "$new_ip_address" ]; then > case "$new_ip_address" in > 169.254.*) > ip -4 ro add 169.254.0.1 dev "$interface" scope link Should this also have "src $new_ip_address"? I can't think of a case where it would clearly make a difference, but it might be worth matching sid exactly. Ross
Bug#1016627: git-buildpackage: confusing behavior with --release and --dist
Package: git-buildpackage Version: 0.9.22 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Hello, I had built a snapshot with `gbp dch -S`, and wanted to prepare an upload to experimental. I ran: $ gbp dch -R --dist experimental But this gave me a changelog with unstable. I wasn't careful enough and uploaded the result :(. The manpage documents that --release sets the distribution to unstable. So maybe this behavior is intentional? If so, it'd be really nice to get an error message if I also supply --dist. But I think it may be a bug. When run with --verbose, the log makes it look like gbp is setting the dist to experimental. Example from 0.9.28 is below, 0.9.22 behaves the same. Starting situation: $ head -n 1 debian/changelog efl (1.26.2-3~exp1~1.gbp7d7265) UNRELEASED; urgency=medium Update changelog for a release: $ gbp dch -R --dist experimental --ignore-branch --verbose gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'symbolic-ref', 'HEAD'] gbp:debug: ['git', 'show-ref', 'refs/heads/gbp-bug'] gbp:info: Continuing from commit '7d72650852767b5308fe9f4c0ff1a8dbd7f504d1' gbp:debug: ['git', 'log', '--pretty=format:%H', '--no-show-signature', '7d72650852767b5308fe9f4c0ff1a8dbd7f504d1..HEAD', '--no-merges', '--'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'ef0ec43479de56c266f7a8680bffcc6712f3af93^0'] gbp:debug: ['git', 'show', '--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', '-z', '--date=raw', '--no-renames', '--name-status', '--no-show-signature', 'ef0ec43479de56c266f7a8680bffcc6712f3af93'] gbp:debug: debchange ['--no-auto-nmu', '--nomultimaint-merge', '--multimaint', '--', '[[[insert-git-dch-commit-message-here]]]'] [] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', '3e3486545ceafae9fc2d8eff789addf0a6b95600^0'] gbp:debug: ['git', 'show', '--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', '-z', '--date=raw', '--no-renames', '--name-status', '--no-show-signature', '3e3486545ceafae9fc2d8eff789addf0a6b95600'] gbp:debug: debchange ['--no-auto-nmu', '--nomultimaint-merge', '--multimaint', '--', '[[[insert-git-dch-commit-message-here]]]'] [] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'c8929207ddc7721c81d5d8b9776e595d7c525d2f^0'] gbp:debug: ['git', 'show', '--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', '-z', '--date=raw', '--no-renames', '--name-status', '--no-show-signature', 'c8929207ddc7721c81d5d8b9776e595d7c525d2f'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', '329535b39b82520c0d4e2823490cf3406f4567bf^0'] gbp:debug: ['git', 'show', '--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', '-z', '--date=raw', '--no-renames', '--name-status', '--no-show-signature', '329535b39b82520c0d4e2823490cf3406f4567bf'] gbp:debug: Set header option 'distribution' to 'experimental' gbp:debug: Set header option 'urgency' to 'medium' gbp:debug: debchange ['--no-auto-nmu', '--nomultimaint-merge', '--multimaint', '--distribution=experimental', '--urgency=medium', '--nomainttrailer', '--', ''] [] libdistro-info-perl is not installed, Debian release names are not known. libdistro-info-perl is not installed, Ubuntu release names are not known. gbp:debug: debchange ['--no-auto-nmu', '--release', '--no-force-save-on-release', '--nomultimaint-merge', '--multimaint', '--', ''] [] gbp:debug: sensible-editor ['debian/changelog'] [] Oops: $ head -n 1 debian/changelog efl (1.26.2-3~exp1) unstable; urgency=medium Thanks, Ross -- System Information: Debian Release: 11.4 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (40, 'unstable'), (40, 'testing'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-0.bpo.1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.22.2~bpo11+1 ii git1:2.30.2-1 ii man-db 2.9.4-2 ii python33.9.2-3 ii python3-dateutil 2.8.1-6 ii python3-pkg-resources 52.0.0-4 ii sensible-utils 0.0.14 Versions of packages git-buildpackage recommends: ii cowbuilder0.89 ii pbuilder 0.231 ii pristine-tar 1.49 ii python3-requests 2.25.1+dfsg-2 ii sbuild0.81.2 Versions of packages git-buildpackage suggests: ii python3-notify2 0.3-4 ii sudo 1.9.5p2-3 ii unzip6.0-26 -- no debconf information
Bug#1012552: Text on cloud.d.o incorrectly says all checksums are signed
Package: cloud.debian.org Severity: normal Hi Olaf, On Fri, Jun 03, 2022 at 10:03:35AM +0200, Olaf Seibert wrote: > The PGP signature files, such as SHA512SUMS.sign, are missing from the pages > https://cdimage.debian.org/images/cloud/bullseye/latest/ and > https://cloud.debian.org/images/cloud/bullseye/latest/. They are promised at > https://cdimage.debian.org/images/cloud/ and > https://cloud.debian.org/images/cloud/. The promises here are misleading - they only apply to the images from the older OpenStack process, in the OpenStack/ directory. The other images in the per-release directories are built by a pipeline on salsa, and we do not currently have signing infrastructure in place. I'm filing this bug to clarify the text on https://cdimage.debian.org/cdimage/cloud/ Sorry for the confusion, Ross
Bug#1010291: postgresql-common: Does /var/log/postgresql really need chmod +t?
Package: postgresql-common Version: 240 Severity: minor Hello, /var/log/postgresql has the sticky bit set, starting I think with bullseye: # ls -lad /var/log/postgresql/ drwxrwxr-t 2 root postgres 4096 Apr 27 23:11 /var/log/postgresql/ This causes some pain with file-based backups. In particular, `rsync -a --inplace` is affected. Since the dir is sticky, rsync makes the backup dir sticky. But since the files are not owned by root on the backup target, even root will be prevented from overwriting them. A more careful explanation can be found at [1]. Is the sticky bit really necessary here? I've worked around this with dpkg-statoverride, but I don't understand why this dir is +t anyhow. Thanks, Ross [1] https://superuser.com/questions/1708317/rsync-permissions-errors-at-destination-even-though-root-possibly-due-to-sticky -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable'), (40, 'unstable'), (30, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-common depends on: ii adduser 3.118 ii debconf [debconf-2.0] 1.5.77 ii libjson-perl 4.03000-1 ii lsb-base 11.1.0 ii perl 5.32.1-4+deb11u2 pn postgresql-client-common ii ssl-cert 1.1.0+nmu1 ii ucf 3.0043 Versions of packages postgresql-common recommends: ii e2fsprogs 1.46.2-2 ii logrotate 3.18.0-2 Versions of packages postgresql-common suggests: ii libjson-perl 4.03000-1
Bug#1010219: terminology: When Terminology is autostarted it launches without window decorations.
Control: reassign -1 kwin-x11 Hi Jon, On Tue, Apr 26, 2022 at 04:16:31PM +0100, Jon Westgate wrote: > I'm running KDE / Plasma, I've noticed that sometimes if I just restart my PC > having not closed Terminology it is autostarted but launches without any > window decorations or handles so you can't move it about. Luckily you can > close it by typing exit. > I also note that there is no transparency. > > I note that closing Terminology and reopening it fixes these issues > > I'm guessing that this is a KDE race condition type bug but none of the other > apps that I use have this > problem. Agreed, but that means ther'es probably nothing terminology can do. I've reassigned to kwin-x11, assuming that you're not using wayland. > I also notice that when I run Terminology from the launcher it opens so > quickly that the launch feedback take a while to catch up. This is > not a complaint btw :) > > Is there any way to slow down the startup that you know of? Or make > Terminology check and wait for compositing / GL to start before it > continues. No, but it'd be simple to workaround with a shell script: #!/bin/sh sleep 2 exec /usr/bin/terminology Put that in your path somewhere, make it executable, and try using it instead of the default launcher. Ross
Bug#1009023: libconfig-model-dpkg-perl: warning output suggests incorrect config filename
Package: libconfig-model-dpkg-perl Version: 2.143 Severity: normal X-Debbugs-Cc: rvandegr...@debian.org Dear Maintainer, While trying to update a package's d/copyright, I ran into this: Warning in 'Files:"minidlna.c[...]" License short_name': licensecheck found an ambiguous license statement. Please: - check the source code to find the actual license association - override this value using "override-license" parameter in "debian/fill-copyright-blank.yml" file. I think this should be "fill.copyright.blanks.yml" (the suggested filename didn't work). Ross -- System Information: Debian Release: 11.3 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (40, 'unstable'), (40, 'testing'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libconfig-model-dpkg-perl depends on: ii debhelper 13.3.4 ii libapt-pkg-perl0.1.39 ii libarray-intspan-perl 2.004-1 ii libconfig-model-backend-yaml-perl 2.134-1 ii libconfig-model-perl 2.141-1 ii libexporter-lite-perl 0.08-1 ii liblog-log4perl-perl 1.54-1 ii libmouse-perl 2.5.10-1+b1 ii libparse-recdescent-perl 1.967015+dfsg-2 ii libsoftware-licensemoreutils-perl 1.005-1 ii libsort-versions-perl 1.62-1 ii libtext-autoformat-perl1.75-1 ii libtext-levenshtein-damerau-perl 0.41-1.1 ii libtoml-tiny-perl 0.11-1 ii liburi-perl5.08-1 ii libwww-perl6.52-1 ii libyaml-libyaml-perl 0.82+repack-1+b1 ii licensecheck 3.1.1-2 ii lintian2.104.0 ii perl [libmodule-corelist-perl] 5.32.1-4+deb11u2 Versions of packages libconfig-model-dpkg-perl recommends: ii libconfig-model-tkui-perl 1.373-1 libconfig-model-dpkg-perl suggests no packages. -- no debconf information
Bug#1008040: libelementary1 1.26.2-1+b1 should recommend same version of libelementary-bin
Control: tags -1 pending On Mon, Mar 21, 2022 at 11:17:19AM +0100, Pavel Reznicek wrote: > the bookworm version of libelementary1 (1.26.2-1+b1) recommends old (now > non-existing in archives) version of libelementary-bin: 1.26.2-1 instead of > 1.26.2-1+b1. Thanks for the report, this will be fixed in the next upload. Ross
Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core
On Sun, Jan 30, 2022 at 12:01:51AM +, Amr Ibrahim wrote: > Am Donnerstag, dem 27.01.2022 um 21:05 -0800 schrieb Ross Vandegrift: > > Is ttf-bitstream-vera going away? > > No, ttf-bitstream-vera is not going away because there are still many > packages that depend on it. > > The real issue of the Bitstream Vera font is that when it's installed, > it takes precedence over the DejaVu font and becomes the default serif, > sans-serif and monospace font on the system, and that's fontconfig's > responsibility. That causes some issues displaying some characters, > which are not supported by Bitstream Vera, in addition to being uglier > than DejaVu. > > Upstream fontconfig fixed that by completely removing Bitstream Vera > from 60-latin.conf: > https://gitlab.freedesktop.org/fontconfig/fontconfig/-/merge_requests/99 > > But that fix has not reached Debian yet because fontconfig has not seen > real maintainer-ship for over a year now: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961386 > > So the alternative solution is, if feasible, to drop the dependency on > ttf-bitstream-vera. If not feasible, then we'll just have to wait until > fontconfig is fixed in Debian. Thanks for the additional info. The pain will be for users who end up having a worse experience due to Bitstream Vera being installed. Since it's just used in EFL examples (and so isn't installed in any search paths for fonts), I will: 1) drop the dependency on ttf-bitstream-vera 2) go back to distributing upstream's copy for the examples This ensures that efl-doc's examples are unchanged, and that users aren't forced to fallback to a worse font option. Thanks, Ross
Bug#998280: Please switch the dependency from ttf-bitstream-vera to fonts-dejavu-core
Hi Amr, On Mon, Nov 01, 2021 at 07:33:35PM +, Amr Ibrahim wrote: > Please switch the dependency from ttf-bitstream-vera to fonts-dejavu- > core. The dejavu font extends the bitstream vera font, the bitstream > vera font is very obsolete, looks worse than dejavu and sometimes as a > negative side-effect it takes over as a default font when installed. Is ttf-bitstream-vera going away? If so, I'll just go back to distributing the copy from upstream. Otherwise, I'd prefer to stick with upstream's choice. EFL embeds font files in some of it's data structures. Bitstream Vera is used in one of the examples. So it isn't displayed anywhere. Ross
Bug#975074: libefreet-bin has circular Depends on libeio1
Control: tags 975074 wontfix Control: tags 963881 wontfix On Thu, Nov 19, 2020 at 08:58:43AM -0800, Ross Vandegrift wrote: > EFL's various libraries have dependency cycles between them. We haven't been > able to robustly eliminate them with split binary packages. The next step is > to bundle them into a single binary package. > > Upstream is working on linking all of them into a single lib. I'd like to > hold > off on the bundling until that is ready or abandoned. I played around with this and wrote about the results at [1]. The result was more complex, less maintainable, and didn't clearly result in the elimination of all cycles. Ross [1] - https://alioth-lists.debian.net/pipermail/pkg-e-devel/2021-May/004009.html
Bug#1003887: terminology: outputs error on start: Could not fetch a node located at 0x40000004529e
On Mon, Jan 17, 2022 at 06:29:37PM +0100, Tomas Pospisek wrote: > When starting terminology I see: > > ``` > ERR<148513>:elementary ../src/lib/elementary/efl_ui_focus_manager_calc.c:1529 > _efl_ui_focus_manager_calc_efl_ui_focus_manager_manager_focus_set() Could not > fetch a node located at 0x4004529e > ## Copy & Paste the below (until EOF) into a terminal, then hit Enter [snip] Yea, EFL's logging is quite profligate. Upstream has recently tried to reduce this somewhat. But I'm not in a good position to do much. Good news: this particular message looks gone in terminology 1.12, which I'm about to upload to unstable. Bad news: there's a new comparable message when you close a window. One step forward, one step back. :) Ross
Bug#1003195: enlightenment: E crashes after coming back from a different VTY
On Thu, Jan 06, 2022 at 12:32:44AM +0100, Robert Waldner wrote: > F'rex, switching to VTY1 (text console) works as expected, but after > switching back to Enlightenment on VTY7 E crashes. > Same after switching back to VTY7 from VTY8 (where a different user runs > XFCE4). Switching to a different vty and back works fine for me, but I don't have another desktop session running anywhere. Does the issue still happen if you only have one session running? > Backtrace log / ~/.e-crashdump.txt from when I get the back screen/red > writing situation: It looks like you're missing the debug symbols. Please follow the instructions at https://wiki.debian.org/HowToGetABacktrace and try again. Ross
Bug#1001626: enlightenment: Starting gkrellm or qmmp, enlightenment process takes too much cpu cycles
On Wed, Dec 15, 2021 at 11:37:24AM +0100, Adrian Immanuel Kiess wrote: > I can sharpen this in the way that I use the gkrellm instances remotely > over SSH connections. Also, other GTK+/GNOME3 applications executed > remotely over SSH and displayed locally on my Enlightenment XOrg window > manager session take a lot of high CPU% cycles. > > Maybe this helps identify the bottle-neck. > > Sometimes it takes a low CPU% percentage at start right after booting > into Englightenment, but having eight gkrellm instances (seven remotely > via SSH) make take Enlightenment one full CPU core after having it > run for a while. > > This does not happen when I don't run gkrellm. Enlightenment takes as > low as 0,7-6% CPU% usage, even after having running Enlightenment for > two days. Spurring on gkrellm, the same affect happens again. > > Changing the refresh time/rate of gkrellm in the gkrellm preferences > does not change the effect. That's strange - changing the refresh rate has a large impact for me. At 20Hz, enlightenment uses ~25%; at 1Hz, enlightenment uses ~2%. Running local vs remote over ssh doesn't seem to make any difference. > I hope this can be fixed! If no solution can be found (maybe it has to > do with some library, I don't know) I will contact > https://www.enlightenment.org/contact. Good luck! Ross
Bug#1001626: enlightenment: Starting gkrellm or qmmp, enlightenment process takes too much cpu cycles
Control: tags -1 upstream Hello, On Mon, Dec 13, 2021 at 01:29:34PM +0100, Adrian Immanuel Kiess wrote: > Enlightenment from Debian/testing takes too much CPU cycles running instances > of gkrellm or qmmp. > > I usually start up to eight instances of gkrellm for my virtual machines and > starting those gkrellm > processes inside a Enlightenment session, issues full load to one CPU core > (Two > gkrellm program instances are enough). The same applies to the program qmmp, > which also issues high load to the machine. One gkrellm instance on my laptop causes ~6% enlightenment cpu + ~4% Xorg CPU on my laptop. gkrellm is constantly updating the screen - every screen update must be composited and rendered by enlightenment & X. I also tried under gnome on wayland. It caused about ~3% for each of 2 gnome processes - so about half as much. gkrellm didn't let me start multiple instances. The manpage indicates that it prevents that for performance reasons. You're probably best contacting the upstream developers for this issue. IRC, email, etc info is at https://www.enlightenment.org/contact Ross
Bug#979100: Legally problematic GPL-3+ readline dependency
Control: tags -1 pending
Hello,
On Sat, 2 Jan 2021 18:47:07 +0100 Bastian Germann wrote:
> This package depends on libreadline8 which is GPL-3+ licensed. According
> to debian/copyright parts of your package are GPL-2-only licensed. If
> that is also (transitively) the case for the binaries that link with
> libreadline.so.8 it might be legally problematic (see
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility).
Since enlightenment Build-Depends on connman, I took a look. I think this
isn't actually a problem.
According to the docs, readline is only used in the cli client. I confirmed in
a fresh sid container:
# dpkg -l connman*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=-===--===
ii connman 1.36-2.2amd64Intel
Connection Manager daemon
ii connman-dev:amd64 1.36-2.2amd64Development
files for connman
ii connman-doc 1.36-2.2all ConnMan
documentation
ii connman-vpn 1.36-2.2amd64Intel
Connection Manager daemon - VPN daemon
root@b7aa1f65ab2d:/# for i in $(dpkg -l connman* | grep connman | awk '{print
$2}'); do dpkg -L $i | xargs ldd 2> /dev/null | grep -E '(^/)|libreadline';
done | grep -B 1 readline
/usr/bin/connmanctl:
libreadline.so.8 => /lib/x86_64-linux-gnu/libreadline.so.8
(0x7f3b73d8b000)
Upstream relicensed the client source to GPL v2 or later in 27e37a50
specifically to address this issue [1]. That change was released in 1.10, but
d/copyright does not reflect it.
I've opened an MR with the fix at [2], but need a sponsor to upload since I'm
DN. Since the uploader and maintainer have been inactive for some years, and
since this bug has had no reply since January, I'll open a sponsorship request
bug today.
[1] -
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=27e37a50f35cc54c266cbd37e32dadbf3016e5e8
[2] - https://salsa.debian.org/debian/connman/-/merge_requests/6
Ross
Bug#996004: RFS: connman/1.36-2.2 [NMU] [RC] -- Intel Connection Manager daemon
Package: sponsorship-requests Severity: important X-Debbugs-Cc: rvandegr...@debian.org Dear mentors, I am looking for a sponsor for the package "connman": * Package name: connman Version : 1.36-2.2 Upstream Author : Marcel Holtmann * URL : * License : GPL-2.0, GPL-2.0+ * Vcs : https://git.kernel.org/pub/scm/network/connman/connman.git/ Section : net The release is waiting in this MR: https://salsa.debian.org/debian/connman/-/merge_requests/6 I cannot upload since I am DN, and this package isn't in my dak ACL. The uploader and maintainer seem inactive for some years, and #979100 has been open without reply since January. I don't know if I'm willing to salvage - enlightenment has a B-D on connman, but I don't actually use it. Changes since the last upload: connman (1.36-2.2) unstable; urgency=medium . * Non-maintainer upload. * d/copyright: license on client/* is GPL-2+ Upstream commit 27e37a50 relicensed this to GPL-2+ to fix the license incompatibility with GPL-3+ releases of libreadline. (Closes: #979100) Thanks, Ross
Bug#995811: enlightenment: Firefox does not respond to mouse cursor/keys until you double press F11
Hi Dmitri, On Wed, Oct 06, 2021 at 01:02:06PM +0200, Dmitri Sinitin wrote: > Unlike other wayland compositors (weston etc) in enlightenment you have to > enter fullscreen mode at least in Firefox so it begun to react at the mouse > pointer events. > After that the menus are still immune to clicks. Hotkeys works flawless. > > ffstart command: > MOZ_ENABLE_WAYLAND=1 firefox I tried this with firefox-esr from bullseye, and I only got the client-side decorations. The main content is all black, and nothing brings the mouse to life. :( Upstream usually suggests that if you want to use wayland, you should build from git. So even though it's enabled in the packages, I'm not surprised to hear that it isn't usable. Sorry, Ross
Bug#966573: progress packaging awscli v2
On Tue, Oct 05, 2021 at 11:10:48PM -0600, Ross Vandegrift wrote: > A few known issues: > > - some repos have tests disabled due to failing during builds. So far, I > don't > know if these are real failures, or if upstream's build method. > > - copyright attribution for aws-lc is very hard. It's a fork of Google's > BoringSSL, which is a fork of pre-3.0 OpenSSL. > > - That also means that aws-lc inherits the openssl gpl incompatibility. > > - the aws-cli2-temp repo is based on upstream, not our awscli repo. I was > intentionally being sloppy to quickly get through a test. > > - aws-lc and s2n-tls may be hard to maintain. Both are complicated, security > critical crypto libraries. I forgot to mention one more issue: - this branch avoids the challenges with botocore by embedding a copy. This decision is defended by the author in the github conversation, and I'm convinced it's the best option right now. Still, it's not ideal. Ross
Bug#966573: progress packaging awscli v2
On Thu, Jun 17, 2021 at 09:56:10AM -0700, Noah Meyerhans wrote: > awscli v2 remains quite difficult to package, but it seems that upstream > is looking to address this. See > https://github.com/aws/aws-cli/issues/6186 for details and tracking. Using the source dist poc from https://github.com/aws/aws-cli/pull/6352 I've made enough progress to get a packaged aws-cli v2 working. There's a lot more that needs to be done, but idea of the above linked PR could work for us. I'm going to document my findings here. The branch is based on 2.2.1. All of its python dependencies except aws-crt-python are packaged (though the versions in sid don't match the requirements). I ignored this with no ill side effects so far to focus on aws-crt-python. aws-crt-python is the hard part. It depends on a bunch of C libraries which follow a more modern development style. They: - provide no abi/api stability guarantees. - have versioned releases, but no one cares about the versions. The intention is that everyone should be following the main branch. - only nominally support dynamic linking (it can be enabled, but is not used or tested by upstream). - seem to be mostly used via source inclusion. My first pass only produces -dev packages with headers and static libraries. To test them out, build the debian/sid branch from these repos, in this order: - https://salsa.debian.org/rvandegrift/aws-c-common - https://salsa.debian.org/rvandegrift/aws-lc - https://salsa.debian.org/rvandegrift/s2n-tls - https://salsa.debian.org/rvandegrift/aws-c-cal - https://salsa.debian.org/rvandegrift/aws-c-io - https://salsa.debian.org/rvandegrift/aws-c-compression - https://salsa.debian.org/rvandegrift/aws-checksums - https://salsa.debian.org/rvandegrift/aws-c-http - https://salsa.debian.org/rvandegrift/aws-c-mqtt - https://salsa.debian.org/rvandegrift/aws-c-event-stream - https://salsa.debian.org/rvandegrift/aws-c-auth - https://salsa.debian.org/rvandegrift/aws-c-s3 - https://salsa.debian.org/rvandegrift/aws-crt-python - https://salsa.debian.org/rvandegrift/aws-cli2-temp With gbp and sbuild, you should be able to build each with: gbp buildpackage --git-builder=sbuild -d unstable --extra-package=$PWD/../build-area/ A few known issues: - some repos have tests disabled due to failing during builds. So far, I don't know if these are real failures, or if upstream's build method. - copyright attribution for aws-lc is very hard. It's a fork of Google's BoringSSL, which is a fork of pre-3.0 OpenSSL. - That also means that aws-lc inherits the openssl gpl incompatibility. - the aws-cli2-temp repo is based on upstream, not our awscli repo. I was intentionally being sloppy to quickly get through a test. - aws-lc and s2n-tls may be hard to maintain. Both are complicated, security critical crypto libraries. Ross
Bug#993530: ddcutil version bump
Package: enlightenment Version: 0.24.2-8 - Forwarded message from Sanford Rockowitz - Date: Thu, 2 Sep 2021 01:11:11 -0400 From: Sanford Rockowitz To: pkg-e-de...@lists.alioth.debian.org Cc: Andrey Rahmatullin Subject: Fwd: ddcutil version bump User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 And, I neglected to mention, update Recommends: libddcutil3 to Recommends: libddcutil4 Forwarded Message Subject:ddcutil version bump Date: Wed, 1 Sep 2021 23:45:37 -0400 From: Sanford Rockowitz Organization: Minaret Software To: pkg-e-de...@lists.alioth.debian.org CC: Andrey Rahmatullin The latest ddcutil release (1.1.0) that's about to go into sid increments the shared library to libddcutil.so.4. I've reviewed the code in file e_system_ddc.c. There are no changes that affect your use of the API. All you need to do is check for libddcutil.so.4 before libddcutil.so.3 and libddcutil.so.2. Regards, Sanford Rockowitz ddcutil developer -- Pkg-e-devel mailing list pkg-e-de...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-e-devel - End forwarded message -
Bug#984849: dpkg-divert: too sensitive to order of command-line args
Hello, On Thu, Sep 02, 2021 at 04:16:36AM +0200, Guillem Jover wrote: > On Mon, 2021-03-08 at 22:35:49 -0800, Ross Vandegrift wrote: > > dpkg-divert is too sensitive to the order of the command line parameters. > > Since I only use it rarely, I almost always run into: > > > > # dpkg-divert --add /wooo --divert /yeah --rename > > dpkg-divert: warning: please specify --no-rename explicitly, the default > > will change to --rename in 1.20.x > > dpkg-divert: error: --add needs a single argument > > > > Use --help for help about diverting files. > > > > The fix is to move --add last. But neither the error nor the manpage makes > > that clear. > > Both the man page and the --help output mention that the usage is: > > dpkg-divert [...] > > And then go to list the commands and options on their respective > sections. While I guess I could add a hint or similar on the error > message (because modifying the way this is parsed would be a pain), > that seems it would be too specific for such a generic message. So > I'm inclined to leave it as is, TBH. If you have an alternative > suggestion I'm happy to consider, otherwise I'm afraid I'll just > going to close the report. I don't have any good suggestions - I think usage would be more obvious if the commands weren't prefixed with dashes, but that would cause much worse breakage. If the parsing is too hard to change, then leaving it as-is is sounds reasonable. Thanks for thinking about it, feel free to close. Ross
Bug#976235: enlightenment: e switches off screen|monitor
Hi enno, On Tue, Aug 24, 2021 at 11:02:24PM +0200, enno wrote: > NEW: If I do nothing, screen stays black for quite precisely 30 seconds, no > matter if on VT7 or VT1-6, then screen comes back. If in TTY1-6 it stays, if > in VT7 as soon as I press a key or click a mouse it turns black again. But > then sometimes also VT1-6 turn black again, apparently without my influence. > > And in .xsession-errors--where I redirect console output, there's: Sorry, I still don't think I have any idea what's going on. You're best off contacting upstream at enlightenment-us...@lists.sf.net or #e on libera.chat. Ross
Bug#992153: bullseye-pu: package cloud-init/20.4.1-2+deb11u1
On Fri, Aug 13, 2021 at 03:07:46PM -0600, Ross Vandegrift wrote:
> [ Checklist ]
> [X] *all* changes are documented in the d/changelog
> [X] I reviewed all changes and I approve them
> [X] attach debdiff against the package in (old)stable
Apologies - reportbug -r seems to have missed the attachment. Here it is.
Ross
diff -Nru cloud-init-20.4.1/debian/changelog cloud-init-20.4.1/debian/changelog
--- cloud-init-20.4.1/debian/changelog 2021-03-19 10:18:59.0 -0600
+++ cloud-init-20.4.1/debian/changelog 2021-08-12 18:47:26.0 -0600
@@ -1,3 +1,11 @@
+cloud-init (20.4.1-2+deb11u1) bullseye; urgency=high
+
+ * Team upload.
+ * cherry-pick upstream fix for duplicate includes in /etc/sudoers
+(Closes: #991629)
+
+ -- Ross Vandegrift Thu, 12 Aug 2021 18:47:26 -0600
+
cloud-init (20.4.1-2) unstable; urgency=high
* Avoid logging generated passwords to world-readable log files.
diff -Nru cloud-init-20.4.1/debian/patches/0009-includedir-in-suoders-can-be-prefixed-by-arroba-783.patch cloud-init-20.4.1/debian/patches/0009-includedir-in-suoders-can-be-prefixed-by-arroba-783.patch
--- cloud-init-20.4.1/debian/patches/0009-includedir-in-suoders-can-be-prefixed-by-arroba-783.patch 1969-12-31 17:00:00.0 -0700
+++ cloud-init-20.4.1/debian/patches/0009-includedir-in-suoders-can-be-prefixed-by-arroba-783.patch 2021-08-12 18:47:26.0 -0600
@@ -0,0 +1,64 @@
+From: Jordi Massaguer Pla
+Date: Fri, 29 Jan 2021 15:43:56 +0100
+Subject: includedir in suoders can be prefixed by "arroba" (#783)
+
+Since version 1.9.1, @includedir can be used in the sudoers files
+instead of #includedir:
+
+https://github.com/sudo-project/sudo/releases/tag/SUDO_1_9_1
+
+Actually "@includedir" is the modern syntax, and "#includedir" the historic
+syntax. It has been considered that "#includedir" was too puzzling because
+it started with a "#" that otherwise denotes comments.
+
+This happens to be the default in SUSE Linux enterprise sudoer package,
+so cloudinit should take this into account.
+
+Otherwise, cloudinit was adding an extra #includedir, which was
+resulting on the files under /etc/sudoers.d being included twice, one by
+@includedir from the SUSE package, one by the @includedir from
+cloudinit. The consequence of this, was that if you were defining an
+Cmnd_Alias inside any of those files, this was being defined twice and
+creating an error when using sudo.
+---
+ cloudinit/distros/__init__.py| 2 +-
+ tests/unittests/test_distros/test_generic.py | 13 +
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/cloudinit/distros/__init__.py b/cloudinit/distros/__init__.py
+index 1e11847..220bd11 100755
+--- a/cloudinit/distros/__init__.py
b/cloudinit/distros/__init__.py
+@@ -673,7 +673,7 @@ class Distro(persistence.CloudInitPickleMixin, metaclass=abc.ABCMeta):
+ found_include = False
+ for line in sudoers_contents.splitlines():
+ line = line.strip()
+-include_match = re.search(r"^#includedir\s+(.*)$", line)
++include_match = re.search(r"^[#|@]includedir\s+(.*)$", line)
+ if not include_match:
+ continue
+ included_dir = include_match.group(1).strip()
+diff --git a/tests/unittests/test_distros/test_generic.py b/tests/unittests/test_distros/test_generic.py
+index 4460748..336150b 100644
+--- a/tests/unittests/test_distros/test_generic.py
b/tests/unittests/test_distros/test_generic.py
+@@ -119,6 +119,19 @@ class TestGenericDistro(helpers.FilesystemMockingTestCase):
+ self.assertIn("josh", contents)
+ self.assertEqual(2, contents.count("josh"))
+
++def test_sudoers_ensure_only_one_includedir(self):
++cls = distros.fetch("ubuntu")
++d = cls("ubuntu", {}, None)
++self.patchOS(self.tmp)
++self.patchUtils(self.tmp)
++for char in ['#', '@']:
++util.write_file("/etc/sudoers", "{}includedir /b".format(char))
++d.ensure_sudo_dir("/b")
++contents = util.load_file("/etc/sudoers")
++self.assertIn("includedir /b", contents)
++self.assertTrue(os.path.isdir("/b"))
++self.assertEqual(1, contents.count("includedir /b"))
++
+ def test_arch_package_mirror_info_unknown(self):
+ """for an unknown arch, we should get back that with arch 'default'."""
+ arch_mirrors = gapmi(package_mirrors, arch="unknown")
diff -Nru cloud-init-20.4.1/debian/patches/series cloud-init-20.4.1/debian/patches/series
--- cloud-init-20.4.1/debian/patches/series 2021-03-19 10:02:44.0 -0600
+++ cloud-init-20.4.1/debian/patches/series 2021-08-12 18:47:26.0 -0600
@@ -6,3 +6,4 @@
0009-Drop-all-unused-extended-version-handling.patch
0012-Fix-message-when-a-local-is-missing.patch
dont_log_generated_passwords.patch
+0009-includedir-in-suoders-can-be-prefixed-by-arroba-783.patch
Bug#992153: bullseye-pu: package cloud-init/20.4.1-2+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: rvandegr...@debian.org, debian-cl...@lists.debian.org [ Reason ] The version of sudo in bullseye introduces a new syntax for includes, "@includedir". This is supported alongside the previous syntax "#includedir". cloud-init tries to ensure that /etc/sudoers.d is included. But the version in bullseye only looks for the old sudo syntax. Since the default contains the new syntax, this duplicates all of the config in /etc/sudoers.d. At least some sudo config cannot be duplicated - details are in #991629. The report+fix came too close to the bullseye release. The team considers it RC, but have a workaround in place to prevent immediate user impact: https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/263 This requires modifying one of sudo's config file during the image build, so we'd prefer a fixed cloud-init package. [ Impact ] Users may have previously working sudo configs break. [ Tests ] The upstream fix adds a unit test for this issue. This and the other tests pass during package build. [ Risks ] Very low, the patch is trivial. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Effectively, s/#includedir/[#@]includedir/ in the /etc/sudoers handling. Thanks, Ross, for the cloud team
Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers
Control: severity -1 serious On Wed, Aug 11, 2021 at 03:12:37PM -0700, Noah Meyerhans wrote: > On Wed, Aug 11, 2021 at 02:05:39PM -0700, Noah Meyerhans wrote: > > 2. I will implement a temporary change to our bullseye images to revert the > >sudoers file to use the old syntax that cloud-init will detect. > > This is implemented by > https://salsa.debian.org/cloud-team/debian-cloud-images/-/merge_requests/263 Great, thanks - adjusting severity per today's discussion. Ross
Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers
On Fri, Aug 06, 2021 at 09:07:02AM +0100, Chris Boot wrote: > On 06/08/2021 02:47, Ross Vandegrift wrote: > > On Thu, Jul 29, 2021 at 10:24:22AM +0100, Chris Boot wrote: > > > In the sudoers file there is a duplicate includedir > > > statement; at the end of the file you will find the following contents: > > > > > > """ > > > # See sudoers(5) for more information on "@include" directives: > > > > > > @includedir /etc/sudoers.d > > > > > > # Added by cloud-init v. 20.4.1 on Wed, 28 Jul 2021 20:40:05 + > > > #includedir /etc/sudoers.d > >^ > > > > Is this a copy/paste mistake? It looks commented out. > > It's isn't a copy/paste mistake, nor is it commented out. This was the > syntax used up to Buster, but from Bullseye the new @includedir syntax is > preferred (but sudo accepts both). That's presumably why it was changed in > sudo. , thanks. This is fixed upstream in 21.1, though many other changes are included. I didn't look through the list carefully. The fix for this particular bug is trivial, I staged it here: https://salsa.debian.org/rvandegrift/cloud-init/-/tree/debian/bullseye Either a targeted fix or a new upstream release will need to wait for a stable update at this point. Ross
Bug#991629: cloud.debian.org: Bullseye AWS AMI: cloud-init creates duplicate #includedir in /etc/sudoers
Hi Chris, On Thu, Jul 29, 2021 at 10:24:22AM +0100, Chris Boot wrote: > In the sudoers file there is a duplicate includedir > statement; at the end of the file you will find the following contents: > > """ > # See sudoers(5) for more information on "@include" directives: > > @includedir /etc/sudoers.d > > # Added by cloud-init v. 20.4.1 on Wed, 28 Jul 2021 20:40:05 + > #includedir /etc/sudoers.d ^ Is this a copy/paste mistake? It looks commented out. Ross
Bug#988968: unblock: e17/0.24.2-6
Control: tags -1 - moreinfo
On Tue, May 25, 2021 at 09:12:37AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
>
> On 2021-05-22 08:39:18 -0700, Ross Vandegrift wrote:
> > Control: tags -1 - moreinfo
> >
> > Hello,
> >
> > On Sat, May 22, 2021 at 09:53:26AM +0200, Sebastian Ramacher wrote:
> > > Control: tags -1 moreinfo
> > >
> > > On 2021-05-21 22:23:20 -0700, Ross Vandegrift wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: unblock
> > > > X-Debbugs-Cc: rvandegr...@debian.org
> > > >
> > > > Please unblock package e17
> > > >
> > > > [ Reason ]
> > > >
> > > > 0.24.2-6 recommends libddcutil2, which has been replaced by
> > > > libddcutil3.
> > > >
> > > > [ Impact ]
> > > >
> > > > A non-existant package will be recommended. Backlight controls for
> > > > external monitors won't work unless the user tries libddcutil3.
> > > >
> > > > [ Tests ]
> > > >
> > > > There are no automated tests. I have used libddcutil3 without
> > > > regression
> > > > since uploading the change.
> > >
> > > Are you sure?
> > >
> > > /tmp/e17-0.24.2%% rgrep ddcutil\.so
> > > src/bin/system/e_system_ddc.c: ddc_lib = dlopen("libddcutil.so.2",
> > > RTLD_NOW | RTLD_LOCAL);
> > >
> > > I don't see libddcutil.so.3 used anywhere.
> >
> > No, I'm not sure anymore - I must've messed up. Apologies!
> >
> > Upstream git after 0.24.2 has a patch to support libddcutil3. There may
> > not be
> > time for testing + migration before release. But if there were, would the
> > below patch be acceptable during freeze?
>
> Yes. Please remove the moreinfo tag once the version with that patch is
> available in unstable.
Thanks - I confirmed the fix works and 0.24.2-8 has been uploaded to unstable.
Thanks,
Ross
signature.asc
Description: PGP signature
Bug#988968: unblock: e17/0.24.2-6
Control: tags -1 - moreinfo
Hello,
On Sat, May 22, 2021 at 09:53:26AM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
>
> On 2021-05-21 22:23:20 -0700, Ross Vandegrift wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: rvandegr...@debian.org
> >
> > Please unblock package e17
> >
> > [ Reason ]
> >
> > 0.24.2-6 recommends libddcutil2, which has been replaced by libddcutil3.
> >
> > [ Impact ]
> >
> > A non-existant package will be recommended. Backlight controls for
> > external monitors won't work unless the user tries libddcutil3.
> >
> > [ Tests ]
> >
> > There are no automated tests. I have used libddcutil3 without regression
> > since uploading the change.
>
> Are you sure?
>
> /tmp/e17-0.24.2%% rgrep ddcutil\.so
> src/bin/system/e_system_ddc.c: ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW
> | RTLD_LOCAL);
>
> I don't see libddcutil.so.3 used anywhere.
No, I'm not sure anymore - I must've messed up. Apologies!
Upstream git after 0.24.2 has a patch to support libddcutil3. There may not be
time for testing + migration before release. But if there were, would the
below patch be acceptable during freeze?
Thanks,
Ross
commit ead43c40c36bb4f74426a8b1ca4418952e338ac1
Author: Carsten Haitzler
Date: Tue Aug 18 12:06:43 2020 +0100
ddc - add libddcutil.so.3 as supported as it is compatible for our uses
diff --git a/src/bin/system/e_system_ddc.c b/src/bin/system/e_system_ddc.c
index 2d57b3bac..74d48dd56 100644
--- a/src/bin/system/e_system_ddc.c
+++ b/src/bin/system/e_system_ddc.c
@@ -302,7 +302,11 @@ err:
static Eina_Bool
_ddc_init(void)
{
- ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW | RTLD_LOCAL);
+ // .so.3 is ABI compatible twith .so.2 for out uses - see
+ // https://www.ddcutil.com/c_api_99/ for changes between them
+ ddc_lib = dlopen("libddcutil.so.3", RTLD_NOW | RTLD_LOCAL);
+ if (!ddc_lib)
+ ddc_lib = dlopen("libddcutil.so.2", RTLD_NOW | RTLD_LOCAL);
if (!ddc_lib) return EINA_FALSE;
#define SYM(_x) \
do { \
signature.asc
Description: PGP signature
Bug#988968: unblock: e17/0.24.2-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: rvandegr...@debian.org Please unblock package e17 [ Reason ] 0.24.2-6 recommends libddcutil2, which has been replaced by libddcutil3. [ Impact ] A non-existant package will be recommended. Backlight controls for external monitors won't work unless the user tries libddcutil3. [ Tests ] There are no automated tests. I have used libddcutil3 without regression since uploading the change. [ Risks ] Low risk - e17 only builds leaf packages and the change is trivial. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock e17/0.24.2-7 diff -Nru e17-0.24.2/debian/changelog e17-0.24.2/debian/changelog --- e17-0.24.2/debian/changelog 2021-01-01 14:29:49.0 -0800 +++ e17-0.24.2/debian/changelog 2021-05-02 22:02:56.0 -0700 @@ -1,3 +1,10 @@ +e17 (0.24.2-7) unstable; urgency=medium + + * d/control: Recommend libddcutil3 instead of libddcutil2 which isn't in +bullseye + + -- Ross Vandegrift Sun, 02 May 2021 22:02:56 -0700 + e17 (0.24.2-6) unstable; urgency=medium * Recommend libddcutil2 and update NEWS with backlight control info diff -Nru e17-0.24.2/debian/control e17-0.24.2/debian/control --- e17-0.24.2/debian/control 2021-01-01 14:07:17.0 -0800 +++ e17-0.24.2/debian/control 2021-05-02 21:57:47.0 -0700 @@ -51,7 +51,7 @@ acpid, bc, bluez, - libddcutil2, + libddcutil3, libevas-loaders, packagekit, terminology | x-terminal-emulator,
Bug#868875: Your thoughts about #868875
On Wed, Apr 28, 2021 at 10:14:15PM +0200, Thomas Goirand wrote: > Could you guys read the patch, at: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868875#33 > > Do you think it should be merged ASAP, and then ask for cloud-utils to > be unblocked? > > Release is coming, we'd better fix this quickly if we need to, and I > don't feel like doing it without a 2nd opinion on this. Your thoughts? The patch looks right, and it matches the fixed version that's in bullseye. I didn't actually test a patched version of cloud-utils 0.29 though. It seems like a straightforwrd fix, if you think it's worth a stable update. Ross
Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.
Package: fwupd
Version: 1.5.7-3
Followup-For: Bug #943343
X-Debbugs-Cc: rvandegr...@debian.org
I have a pair of laptops, one where fwupd-refresh.service is broken and one
where it works. Both are running bullseye with the same versions of fwupd,
systemd, and dbus. No remote users, nfs, freeipa, etc.
I've run both with this config:
$ cat /etc/systemd/system/fwupd-refresh.service.d/override.conf
[Service]
StandardError=
StandardError=journal
ExecStart=
ExecStart=/usr/bin/strace -ff /usr/bin/fwupdmgr -v refresh
The results aren't too enlightening - the broken one cannot auth to dbus as
it's systemd dynamic user:
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7
fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(7, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"},
110) = 0
sendmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0",
iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=128515, uid=62803, gid=62803}}],
msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 1
sendto(7, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
recvfrom(7, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
sendto(7, "AUTH EXTERNAL 3632383033\r\n", 26, MSG_NOSIGNAL, NULL, 0) = 26
recvfrom(7, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
I don't know why that would fail. If I could provide more details or test
something, please let me know.
Ross
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (40, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fwupd depends on:
ii libc6 2.31-11
ii libcurl3-gnutls7.74.0-1.2
ii libefiboot137-6
ii libelf10.183-1
ii libflashrom1 1.2-5
ii libfwupd2 1.5.7-2
ii libfwupdplugin11.5.7-2
ii libglib2.0-0 2.66.8-1
ii libgnutls303.7.1-3
ii libgudev-1.0-0 234-1
ii libgusb2 0.3.5-1
ii libjcat1 0.1.3-2
ii libjson-glib-1.0-0 1.6.2-1
ii libpolkit-gobject-1-0 0.105-30
ii libsmbios-c2 2.4.3-1
ii libsqlite3-0 3.34.1-3
ii libsystemd0247.3-3
ii libtss2-esys-3.0.2-0 3.0.3-2
ii libxmlb1 0.1.15-2
ii shared-mime-info 2.0-1
Versions of packages fwupd recommends:
ii bolt 0.9.1-1
ii dbus 1.12.20-2
ii fwupd-amd64-signed [fwupd-signed] 1.5.7+3
ii python33.9.2-2
pn secureboot-db
ii udisks22.9.2-1
Versions of packages fwupd suggests:
pn gir1.2-fwupd-2.0
-- no debconf information
Bug#985613: unblock: terminology/1.9.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: rvandegr...@debian.org
Please unblock package terminology
[ Reason ]
terminology 1.9.0-1 is missing a dependency required for users on wayland.
1.9.0-2 fixes this. The package has non-trivial autopkgtests, but the test
suite doesn't work on all arches. Thus, it will not migrate automatically.
[ Impact ]
terminology won't start for wayland users that are missing
libevas1-engines-wayland
[ Tests ]
1.9.0-2 only contains packaging changes:
- add Depends on libevas1-engines-wayland
- remove unused cme files accidentally included in the 1.9.0-1 upload. This is
not in the changelog because I only just discovered the issue. I can do a
1.9.0-3 changelog-only release, if that's better.
[ Risks ]
terminology is a leaf package, so the risk is isolated.
[ Checklist ]
[ ] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
[ Other info ]
unblock terminology/1.9.0-2
diff -Nru terminology-1.9.0/debian/changelog terminology-1.9.0/debian/changelog
--- terminology-1.9.0/debian/changelog 2021-01-20 23:15:33.0 -0800
+++ terminology-1.9.0/debian/changelog 2021-03-14 22:46:23.0 -0700
@@ -1,3 +1,9 @@
+terminology (1.9.0-2) unstable; urgency=medium
+
+ * d/control: Depend on libevas1-engines-wayland (Closes: #985208)
+
+ -- Ross Vandegrift Sun, 14 Mar 2021 22:46:23 -0700
+
terminology (1.9.0-1) unstable; urgency=medium
* New upstream version
diff -Nru terminology-1.9.0/debian/control terminology-1.9.0/debian/control
--- terminology-1.9.0/debian/control2021-01-20 22:21:53.0 -0800
+++ terminology-1.9.0/debian/control2021-03-14 22:34:15.0 -0700
@@ -16,7 +16,7 @@
Package: terminology
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, terminology-data (=
${source:Version}), libevas1-engines-x
+Depends: ${shlibs:Depends}, ${misc:Depends}, terminology-data (=
${source:Version}), libevas1-engines-x, libevas1-engines-wayland
Suggests: libelementary-bin, libemotion-players
Provides: x-terminal-emulator
Description: Enlightenment efl based terminal emulator
diff -Nru terminology-1.9.0/debian/copyright-scan-patterns.yml
terminology-1.9.0/debian/copyright-scan-patterns.yml
--- terminology-1.9.0/debian/copyright-scan-patterns.yml2021-01-20
22:32:09.0 -0800
+++ terminology-1.9.0/debian/copyright-scan-patterns.yml1969-12-31
16:00:00.0 -0800
@@ -1,41 +0,0 @@
-check:
- suffixes:
-- "*"
-
-ignore:
- pattern:
-- afl/
-- data/themes/
-- data/fonts/TERMINUS.txt
-- data/fonts/XFONT.txt
- suffixes:
-# cme/licensecheck barfs up garbage if binaries aren't excluded
-- bmp
-- dds
-- edc
-- eet
-- eps
-- gif
-- j2k
-- jp2
-- jpg
-- jpeg
-- md2
-- mo
-- ogg
-- ply
-- png
-- psd
-- svg
-- svgz
-- tga
-- tgv
-- ttf
-- wav
-- wbmp
-- webp
-- x
-- xcf
-- xcf.gz
-- xpm
diff -Nru terminology-1.9.0/debian/fill.copyright.blanks.yml
terminology-1.9.0/debian/fill.copyright.blanks.yml
--- terminology-1.9.0/debian/fill.copyright.blanks.yml 2021-01-20
22:31:22.0 -0800
+++ terminology-1.9.0/debian/fill.copyright.blanks.yml 1969-12-31
16:00:00.0 -0800
@@ -1,23 +0,0 @@
-.*:
- copyright: 2012-2020 Carsten Haitzler and various contributors (see AUTHORS)
- license: BSD-2-clause
-
-po/*:
- 'override-copyright': 2012-2020 Carsten Haitzler and various contributors
(see AUTHORS)
- 'override-license': BSD-2-clause
-
-meson.build:
- copyright: 2012-2020 Carsten Haitzler and various contributors (see AUTHORS)
- 'override-license': BSD-2-clause
-
-data/fonts/*.pcf:
- license: public-domain
- copyright: none
-
-data/fonts/nexus.pcf:
- copyright: 1996-2002 Carsten Haitzler, Jonathan Perkin, Tom Gilbert and
Simon Horman
- license: BSD-2-clause
-
-data/fonts/terminus*:
- copyright: 2011 Dimitar Toshkov Zhekov, with Reserved Font Name "Terminus
Font"
- license: SIL-OFL-1.1
Bug#984849: dpkg-divert: too sensitive to order of command-line args
Package: dpkg Version: 1.20.7.1 Severity: wishlist X-Debbugs-Cc: rvandegr...@debian.org dpkg-divert is too sensitive to the order of the command line parameters. Since I only use it rarely, I almost always run into: # dpkg-divert --add /wooo --divert /yeah --rename dpkg-divert: warning: please specify --no-rename explicitly, the default will change to --rename in 1.20.x dpkg-divert: error: --add needs a single argument Use --help for help about diverting files. The fix is to move --add last. But neither the error nor the manpage makes that clear. Ross -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.8-4 ii libc62.31-9 ii liblzma5 5.2.5-1.0 ii libselinux1 3.1-3 ii tar 1.34+dfsg-1 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.2.0 pn debsig-verify -- no debconf information
Bug#984848: extrepo: default config uses broken url
Package: extrepo Version: 0.8 Severity: normal Hello, I tried extrepo, but ran into an error: $ sudo extrepo enable google_chrome Could not download index YAML file: 403 Forbidden file type or location at /usr/share/perl5/Debian/ExtRepo/Data.pm line 27. ...propagated at /usr/bin/extrepo line 123. After some troubleshooting, I found that the salsa pages url seems to require https. s/http/https in config.yaml gets things working. Ross -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages extrepo depends on: ii gpgv 2.2.27-1 ii libcryptx-perl0.069-1+b1 ii libdpkg-perl 1.20.7.1 ii libwww-perl 6.52-1 ii libyaml-libyaml-perl 0.82+repack-1+b1 ii perl 5.32.1-2 extrepo recommends no packages. extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed [not included] -- no debconf information
Bug#984537: libefl-all-dev should Recommend libeina-bin, libelementary-bin
On Fri, Mar 05, 2021 at 06:49:50AM +0100, Pierre Couderc wrote: > > On Thu, Mar 04, 2021 at 10:44:10AM -0800, Ross Vandegrift wrote: > > > On Thu, Mar 04, 2021 at 06:28:42PM +0100, Pierre Couderc wrote: > > > > But I think there should be some improvement in libefl-all-dev : > > > > libefl-all-dev is done for efl developers > > > > > > > > I need developers tools : at least eina_btlog and elemetary_test at > > > > least... > > > > > > > > Is it possible ? > > > Yes, you'll find them in libeina-bin and libelementary-bin. Probably, > > > libefl-all-dev should Recommend them. > > This would be a nice change for the next release. > > > > Ross > > Why not even include them ? It would be a temporary situation before merged packages come out. Moving those two binaries is more effort that I'd rather put into the permanent reorganization. But adding a Recommends is very simple. For more on how that might look, see this thread: https://alioth-lists.debian.net/pipermail/pkg-e-devel/2020-February/003674.html Ross
Bug#984537: libefl-all-dev should Recommend libeina-bin, libelementary-bin
Package: libefl-all-dev Version: 1.25.1-1 Severity: wishlist On Thu, Mar 04, 2021 at 10:44:10AM -0800, Ross Vandegrift wrote: > On Thu, Mar 04, 2021 at 06:28:42PM +0100, Pierre Couderc wrote: > > But I think there should be some improvement in libefl-all-dev : > > libefl-all-dev is done for efl developers > > > > I need developers tools : at least eina_btlog and elemetary_test at least... > > > > Is it possible ? > > Yes, you'll find them in libeina-bin and libelementary-bin. Probably, > libefl-all-dev should Recommend them. This would be a nice change for the next release. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Sun, Jan 03, 2021 at 12:09:09AM +0100, enno wrote: > I did a few updates on suspected potentially involved packages and the like: > [INSTALL] xorg-docs:i386 1:1.7.1-1.2 > [INSTALL] xserver-xorg-input-evdev:i386 1:2.10.6-2 > [REMOVE (PURGE)] xserver-xorg-input-all:i386 1:7.7+19 > [REMOVE (PURGE)] xserver-xorg-video-vmware:i386 1:13.3.0-2 > [UPGRADE] xorg-docs-core:i386 1:1.7.1-1 -> 1:1.7.1-1.2 > [UPGRADE] xterm:i386 361-1 -> 362-1 IMO none of these look related. If you're really still using linux 5.3, I'd suggest upgrading linux-image-amd64. > And BTW I've tried to present my problem on the phabricator, but there is no > reaction within 10 days or so by now. Yea, phab isn't very active for E, especially for user questions. You want to contact enlightenment-us...@lists.sourceforge.net. > Isn't there anybody who knows what these ~/.xsession-errors log lines say: > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 320 > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 312 > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 306 > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 302 > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 300 > BL: set > [/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0/card0-LVDS-1/radeon_bl0] > -> 299 This is E logging it's backlight changes - but so far, it seems like it's not a backlight control issue. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Tue, Dec 22, 2020 at 02:05:19AM +0100, enno wrote: > >>>>> "Ross" == Ross Vandegrift writes: > > Do your backlight keys work? E24 has introduced additional > > screen dimming, and it will dim the backlight fully. Maybe > > there's a strange interaction between your video card's > > brightness control and E's behavior. > [snip] > > BTW what do you mean by backlight keys? Most laptops have some keys for adjusting the brightness of the screen backlight. Try pressing the key to increase the brightness. E24 adjusts the backlights to improve dimming & fade effects. On my laptop, E's dimmer allows me to turn my backlight off. And on startup, E will now dim the backlight and fade it in. So I'm wondering if that's working, but getting stuck in the off position. Seems unlikely if disabling it in the config didn't help. You could also try shining a fairly bright light on the screen. If everything is running with the backlight off, you might be able to see some screen elements. At least on my laptop, I'm barely able to make things out if I shine my phone's light on it. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Sat, Dec 19, 2020 at 12:32:47AM +0100, enno wrote: > First thanks for hangin on. And no, it's definitely not in a suspend/resume > cycle--i cold boot into the system, and the problem is there. Still not > understood, especially the strange flicker between screen on and off. But as > I'm not a LCD technician I haven't a clue, if this is just backlight off or > whatever effect it may be. But as stated before, the LCD display is black, > but all standard 7 VTs are there and listening to my entries via > keyboard--well confirmed I have so far VT1 to VT3, but I don't suppose it > could be different on VT4 to 6. Presumably VT7 is working too, but that is a > wee bit difficult to test without seeing the mouse pointer. Do your backlight keys work? E24 has introduced additional screen dimming, and it will dim the backlight fully. Maybe there's a strange interaction between your video card's brightness control and E's behavior. It's possible to disable this, but it'll be hard without ever getting an E session going. To try disabling by hand: 1) apt install libeet-bin 2) vieet ~/.e/e/config/standard/e_comp.cfg config 3) Search for "nofade" 4) Change the value from 0 to 1. The line should be: value "nofade" uchar: 1; > In the past I had some difficulties with a certain release of i can't really > remember, i think it was aptitude back then, which after some package updates > stopped working properly. Some people from the debian response team said > they were surprised that my system was working at all, because of some very > old packages combined with a lot of the testing suite. They suggested to > upgrade the whole system. After that, aptitude worked. And yes, this might > be some sort of solution in this case as well. But I still doubt that this > Windows kind of solution is the ultimate debian way: Reinstall. According to the info included in your bug report, your apt prefers testing and has the expected versions of E & EFL from testing. That all seems pretty normal. So I don't expect reinstalling anything will help. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Mon, Dec 07, 2020 at 11:34:46PM +0100, enno wrote: > >>>>> "Ross" == Ross Vandegrift writes: > >> So all three cases use LVDS and know the precise measurements > >> of my display, just e seems to need something additional which > >> alas is not in the dependency list i suppose. > > > > Well, not quite - this output shows that X knows the > > measurements of your LVDS display, ie, your laptop's built-in > > panel. The external screen are not detected - that confirms > > this is not a problem in E. > > Uh, Ross, I had hoped to have made that clear, all this is just about my--as > you call it--built-in panel. I don't have any external screen. I'm sorry I > haven't been able to make that clear straight away. Oh sorry, I misunderstood your first message - apologies! Is there any chance that you only see this behavior after a suspend/resume cycle? If I suspend by closing my lid on bullseye, I get a cycle of suspend & unsuspend that takes ~20-30 seconds each time. I haven't really tried to track down a cause since I normally suspend using the menu anyhow. That's the only remote similar issue I've ever seen. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Mon, Dec 07, 2020 at 12:43:35AM +0100, enno wrote: > >>>>> "Ross" == Ross Vandegrift writes: > > [...] - it might be useful to run `xrandr` in > > flwm and a bare X session to compare with E's output regarding > > your displays. > > xrandr on flwm and on pure X diff -q 0: > LVDS connected primary 1600x900+0+0 (normal left inverted right x axis y > axis) 310mm x 174mm >1600x900 59.90*+ 39.93 >1440x900 59.99 >1280x854 59.95 >1280x800 59.96 >1280x720 59.97 >1152x768 59.95 >1024x768 59.95 >800x600 59.96 >848x480 59.94 >720x480 59.94 >640x480 59.94 > DisplayPort-0 disconnected (normal left inverted right x axis y axis) > DisplayPort-1 disconnected (normal left inverted right x axis y axis) > DisplayPort-2 disconnected (normal left inverted right x axis y axis) > VGA-0 disconnected (normal left inverted right x axis y axis) > > So all three cases use LVDS and know the precise measurements of my display, > just e seems to need something additional which alas is not in the dependency > list i suppose. Well, not quite - this output shows that X knows the measurements of your LVDS display, ie, your laptop's built-in panel. The external screen are not detected - that confirms this is not a problem in E. Since X doesn't detect a display connected to the other outputs, E is disabling them. I bet flwm doesn't have any knowledge of xrandr, and just runs on any X display it finds. I don't know why the connection would be misreported - probably a bug in the video driver. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Sat, Dec 05, 2020 at 12:45:42AM +0100, enno wrote: > No change so gvfs doesn't seem to be responsible BUT 1 new finding: I had > the meanwile usual procedure, starting enlightenment via my ~/.xsession, the > aforementioned switching off of the screen/monitor/display (I mean it just > turns BLACK), the blind switch to a console VT already being logged in, > waiting about 20 seconds, VT comes up again to life, further 20 seconds > without any interference by me, and the screen goes black again. Sorry, I haven't seen this and don't know what could be the case. You might get more ideas from upstream at enlightenment-us...@lists.sourceforge.net. > I'm just resistant to the idea it might be a hardware error, because with > flwm there's no problem at all! Yea, that is strange - it might be useful to run `xrandr` in flwm and a bare X session to compare with E's output regarding your displays. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Thu, Dec 03, 2020 at 09:44:38PM +0100, enno wrote: > This time after switching to blind VT2 it took several seconds, about 10, and > all of a sudden the VT switched back to live--my first trials to solve this > riddle included once waiting for more than 10 mins and nothing happened. Now > I tried Alt-F7 and had half a second of something looking very much like > enlightenment--and then the screen went black again, including all VTs. > > What is enlightenment_system and enlightenment_fm? They don't have manpages > and they don't accept -h or --help. _fm says: enlightenment_system implements privileged actions so enlightnement doesn't need root to e.g. shutdown the system. enlightenment_fm implements the file manager. > If it is of help, here's the .xsession-errors from the most recent "crashed" > e-launch: This is usually the most useful info. [snip] > ESTART: 1.98189 [0.2] - Screens Init > ESTART: 1.98190 [0.2] - screens: client > ESTART: 1.98196 [0.6] - E_Screensaver Init > ESTART: 1.98199 [0.2] - screens: client volume > ESTART: 1.98201 [0.2] - screens: win > ESTART: 2.05413 [0.07213] - Compositor Init > RRR: . info get! > RRR: out LVDS > RRR: .. lid_closed = 0 (1 && 0) > RRR: .. connected 1 > RRR: .. modes 0x230a8c0 > RRR: 'LVDS' 0 0 1600x900 > RRR: out DisplayPort-0 > RRR: .. lid_closed = 0 (0 && 0) > RRR: .. connected 0 > RRR: .. modes (nil) > RRR: out DisplayPort-1 > RRR: .. lid_closed = 0 (0 && 0) > RRR: .. connected 0 > RRR: .. modes (nil) > RRR: out DisplayPort-2 > RRR: .. lid_closed = 0 (0 && 0) > RRR: .. connected 0 > RRR: .. modes (nil) > RRR: out VGA-0 > RRR: .. lid_closed = 0 (0 && 0) > RRR: .. connected 0 > RRR: .. modes (nil) This output shows that X has detected five outputs, and only one (LVDS) is connected. Do you have the lid closed on your laptop? I wonder if it's running on the closed laptop screen. The later output about screen configuration only shows actions for LVDS. > BTW I'm writing this on flwm which works perfectly but just isn't e, > especially not MY e. Since other windows managers are able to start X normally, it might be useful to see if you can start one yourself: 1) From a VT run `startx xterm` (or whatever terminal you use). 2) Assuming X starts correctly, you should see a terminal in the top left. 3) Move the mouse in the term and run `enlightenment_start`. Ross
Bug#976235: enlightenment: e switches off screen|monitor
On Tue, Dec 01, 2020 at 11:49:54PM +0100, enno wrote: > Upgraded e, after that e on start complained in a window that I had no screen > configured to display on--but my 4 screens from prior .e were present. But > the complaint persisted, so finally I tried the suggested Settings->Screens-- > but that doesn't exist. However I remembered there was some Screen config > somewhere, found that, didn't find anything to configure. Complaint about > unconfigured persisted. So again into the configure-dialog, there is a lot of > options without explanation or tooltip, f.i. one checkbox choice with > 0 90 180 270 as choices. Checked 90 and haven't seen e again since that. Sounds like you found the right dialog - it is terse. The options correspond to xrandr config for your displays. Quick explanation: - The drop down in the upper left selects which output to configure. - The middle pane lists supported modes. - The upper right (0,90,180,270) sets screen rotation. - Below that, the On checkbox enables/disables the screen. - Below that are priority and layout controls. > Calling enlightenment_start since then just switches off the monitor (on a > laptop) and .xsession-errors contains some lines that google doesn't come up > with any solution: When you checked 90, you enabled 90 degree rotation for one screen. >From the error, it looks like X or your video driver doesn't like that: This should clear out all of your screen config, hopefully allowing you to start E again: rm ~/.e/e/config/standard/e_randr*.cfg Ross
Bug#975074: libefreet-bin has circular Depends on libeio1
Control: reassign 963881 src:efl Control: reassign -1 src:efl Control: merge 963881 -1 Control: retitle -1 efl binary packages should be reorganized to eliminate internal cycles EFL's various libraries have dependency cycles between them. We haven't been able to robustly eliminate them with split binary packages. The next step is to bundle them into a single binary package. Upstream is working on linking all of them into a single lib. I'd like to hold off on the bundling until that is ready or abandoned. Some discussion on the issue is at [1]. Ross [1] - https://alioth-lists.debian.net/pipermail/pkg-e-devel/2020-February/003674.html
Bug#971732: lintian: font-in-non-font-package triggers on non-font files
Hi Felix, On Tue, Oct 06, 2020 at 01:29:27AM -0700, Felix Lechner wrote: > On Mon, Oct 5, 2020 at 10:45 PM Ross Vandegrift > wrote: > > > > Lintian misidentifies the output of eolioan_gen as font files. > > I will look for other distinguishing factors---perhaps based on file > magic---but it may be easier to use a different extension, such as > *.eo. EOT files are Embedded OpenType. [1] I see - I assumed that lintian was already using some file magic. I think it's better for me to add overrides for now. eolian isn't really used outside of efl, so I think I'm the only one that would benefit from a fix. Ross
Bug#971732: lintian: font-in-non-font-package triggers on non-font files
Package: lintian
Version: 2.97.0
Severity: minor
Hello,
Lintian misidentifies the output of eolioan_gen as font files. This causes
font-in-non-font-package false positives. Example case from libefl-all-dev is
attached.
Thanks,
Ross
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lintian depends on:
ii binutils2.35.1-1
ii bzip2 1.0.8-4
ii diffstat1.63-1
ii dpkg1.20.5
ii dpkg-dev1.20.5
ii file1:5.38-5
ii gettext 0.19.8.1-10
ii gpg 2.2.20-1
ii intltool-debian 0.35.0+20060710.5
ii libapt-pkg-perl 0.1.36+b3
ii libarchive-zip-perl 1.68-1
ii libcapture-tiny-perl0.48-1
ii libclass-xsaccessor-perl1.19-3+b5
ii libclone-perl 0.45-1
ii libconfig-tiny-perl 2.24-1
ii libcpanel-json-xs-perl 4.23-1
ii libdata-dpath-perl 0.58-1
ii libdata-validate-domain-perl0.10-1
ii libdevel-size-perl 0.83-1+b1
ii libdpkg-perl1.20.5
ii libemail-address-xs-perl1.04-1+b2
ii libfile-basedir-perl0.08-1
ii libfile-find-rule-perl 0.34-1
ii libfont-ttf-perl1.06-1
ii libhtml-html5-entities-perl 0.004-1
ii libipc-run3-perl0.048-2
ii libjson-maybexs-perl1.004002-1
ii liblist-compare-perl0.55-1
ii liblist-moreutils-perl 0.416-1+b5
ii liblist-utilsby-perl0.11-1
ii libmoo-perl 2.004000-1
ii libmoox-aliases-perl0.001006-1
ii libnamespace-clean-perl 0.27-1
ii libpath-tiny-perl 0.114-1
ii libperlio-gzip-perl 0.19-1+b6
ii libproc-processtable-perl 0.59-2
ii libsereal-decoder-perl 4.018+ds-1
ii libsereal-encoder-perl 4.018+ds-1
ii libtext-glob-perl 0.11-1
ii libtext-levenshteinxs-perl 0.03-4+b7
ii libtext-markdown-discount-perl 0.12-1
ii libtext-xslate-perl 3.5.8-1
ii libtime-duration-perl 1.21-1
ii libtime-moment-perl 0.44-1+b2
ii libtimedate-perl2.3300-1
ii libtry-tiny-perl0.30-1
ii libtype-tiny-perl 1.010006-1
ii libunicode-utf8-perl0.62-1+b1
ii liburi-perl 1.76-2
ii libxml-libxml-perl 2.0134+dfsg-2
ii libyaml-libyaml-perl0.82+repack-1
ii lzip1.21-8
ii lzop1.04-1
ii man-db 2.9.3-2
ii patchutils 0.4.2-1
ii perl [libdigest-sha-perl] 5.30.3-4
ii t1utils 1.41-4
ii unzip 6.0-25
ii xz-utils5.2.4-1+b1
lintian recommends no packages.
Versions of packages lintian suggests:
ii binutils-multiarch 2.35.1-1
ii libtext-template-perl 1.59-1
-- no debconf information
struct @extern Efl.Time
{
[[This type is a alias for struct tm.
It is intended to be a standard way to reference
it in .eo files.
@since 1.22
]]
tm_sec: int; [[Seconds.[0-60] (1 leap second)]]
tm_min: int; [[Minutes.[0-59] ]]
tm_hour: int; [[Hours. [0-23] ]]
tm_mday: int; [[Day.[1-31] ]]
tm_mon: int; [[Month. [0-11] ]]
tm_year: int; [[Year- 1900.]]
tm_wday: int; [[Day of week.[0-6] ]]
tm_yday: int; [[Days in year.[0-365] ]]
tm_isdst: int; [[DST. [-1/0/1] ]]
}
struct Efl.Version
{
[[This type describes the version of EFL with an optional variant.
This may be used to query the current running version of EFL. Or it can
be passed by applications at startup time to inform EFL of the version
a certain application was built for.
@since 1.22
]]
major: int; [[Major component of the version (>= 1).]]
minor: int; [[Minor component of the version (>= 0).]]
micro: int; [[Micro component of the version (>= 0).]]
revision: int; [[Revision component of the version (>= 0).]]
flavor: string; [[Special version string for this build of EFL, $null for
vanilla (upstream) EFL. Contains $EFL_VERSION_FLAVOR.]]
build_id: string;
Bug#971545: cloud.debian.org: Provide AMI image ID that is always recent
On Thu, Oct 01, 2020 at 05:16:36PM +0200, tkoeck wrote:
> is there an AMI image ID that is always the recent one?
That's not how AWS works - every image is always a different ID, just
like every instance is always a different ID.
Instead of hardcoding an AMI somewhere, you can search to find the
current release. With awscli, try something like this:
$ aws ec2 describe-images \
--output text \
--owners 136693071363 \
--filters Name=name,Values="debian-10-amd64-*" \
--query 'Images[].[Name,ImageId]' \
| sort -rn \
| head -n 1 \
| awk '{print $2}'
If you're using terraform, the aws_ami data source works like this:
data "aws_ami" "debian10" {
most_recent = true
owners = ["136693071363"]
filter {
name = "name"
values = ["debian-10-amd64-*"]
}
}
Ross
Bug#970362: terminology prints backtrace on startup on ppc
Control: severity -1 minor Hi Efraim, On Tue, Sep 15, 2020 at 11:27:18AM +0300, Efraim Flashner wrote: > I tried rebuilding terminology from the salsa respository and installing > that version of terminology and terminology-data. I got the same > backtrace when I launched that version after installing it. Does terminology fail? Many EFL apps frequently print backtraces. If you capture the backtrace, it could be reported upstream. Follow the instructions for installing debug symbols at: https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols You'll also need to install libeina-bin. The backtrace output will include instructions on decoding it with eina_btlog. > I did not try rebuilding EFL to see if that made a difference. I wouldn't expect rebuilds to make a difference. Ross
Bug#968262: lintian: spare-manual-page misses .so targets
On Wed, Aug 12, 2020 at 07:45:22PM -0700, Felix Lechner wrote: > On Wed, Aug 12, 2020 at 7:17 PM Ross Vandegrift > wrote: > > > > Is that unusual or incorrect?'. > > I cannot answer that. From Lintian's perspective, there is no > executable for the manual page, and that is how the tag works. I see. It might be nice if the tag said "lintian cannot confirm this page is useful, since there's no binary with the same name. If no links point to it, it should probably be removed." But if I'm the only one to run into this this, it's not worth the change. I'll ignore or override. > As a side note, I am not sure how helpful terminology-helpers.1 is. > Why don't you just link to the main manual page terminology.1 and add > a section about the helpers there? I agree it's thin. I'd rather not combine it with terminology.1 - as a user, I often find combined manpages difficult to navigate. But I agree more details would be good. > Hope this was helpful. Very, and thanks for the feedback! Ross
Bug#968262: lintian: spare-manual-page misses .so targets
Hi Felix, On Tue, Aug 11, 2020 at 10:55:49PM -0700, Felix Lechner wrote: > On Tue, Aug 11, 2020 at 10:39 PM Ross Vandegrift > wrote: > > > > I: terminology-data: spare-manual-page > > usr/share/man/man1/terminology-helpers.1.gz > > The links are fine, but I could not find an executable named > terminology-helpers in your installation packages. Do you ship one? Nope, it's just the placeholder name that the binaries' manpages link to. Is that unusual or incorrect? I checked policy 12.1, but I didn't see anything relevant to this case. Ross
Bug#968262: lintian: spare-manual-page misses .so targets
Package: lintian Version: 2.89.0 Severity: normal terminology-data installs terminology-helpers.1 for a number of small binaries from terminology. Each helper binary has a corresponding man file consisting just of a .so line. But lintian reports: I: terminology-data: spare-manual-page usr/share/man/man1/terminology-helpers.1.gz N: N:Each manual page in /usr/share/man should have a reason to be there. N:This manual page does not appear to have a valid reason to be shipped. N: N:For manual pages in sections 1 and 8, an executable (or a link to one) N:should exist. This check currently considers all installation packages N:created by the same sources, as long as they are present. N: N:Refer to Debian Policy Manual section 12.1 (Manual pages) and N:https://bugs.debian.org/583125 for details. N: N:Severity: info N: N:Check: documentation/manual Thanks, Ross -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'testing'), (40, 'unstable'), (30, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.35-1 ii bzip2 1.0.8-4 ii diffstat 1.63-1 ii dpkg 1.20.5 ii dpkg-dev 1.20.5 ii file 1:5.38-5 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b5 ii libclone-perl 0.45-1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl4.19-1 ii libdata-dpath-perl0.58-1 ii libdata-validate-domain-perl 0.10-1 ii libdevel-size-perl0.83-1+b1 ii libdpkg-perl 1.20.5 ii libemail-address-xs-perl 1.04-1+b2 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.21-1 ii libio-async-perl 0.77-3 ii libipc-run3-perl 0.048-2 ii libjson-maybexs-perl 1.004002-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl0.416-1+b5 ii liblist-utilsby-perl 0.11-1 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b6 ii libsereal-decoder-perl4.018+ds-1 ii libsereal-encoder-perl4.018+ds-1 ii libtext-levenshteinxs-perl0.03-4+b7 ii libtext-xslate-perl 3.5.8-1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b2 ii libtimedate-perl 2.3300-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl 1.010002-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl2.0134+dfsg-2 ii libxml-writer-perl0.625-1 ii libyaml-libyaml-perl 0.82+repack-1 ii lzip 1.21-7 ii lzop 1.04-1 ii man-db2.9.3-2 ii patchutils0.4.2-1 ii perl [libdigest-sha-perl] 5.30.3-4 ii t1utils 1.41-4 ii unzip 6.0-25 ii xz-utils 5.2.4-1+b1 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35-1 ii libtext-template-perl 1.59-1 -- no debconf information
Bug#968030: e17: FTBFS during combined arch+indep build
On Fri, Aug 07, 2020 at 01:17:29AM +0200, Andreas Beckmann wrote: > e17/experimental FTBFS during a combined binary arch+indep build (i.e. the > default dpkg-buildpackage mode), while it succeeds during separate arch and > indep builds (dpkg-buildpackage -B, dpkg-buildpackage -A; as done by the > buildds). I know no other package having such a failure mode ;-) Hah, I swear I finally had all combinations working- but looks like I just moved the bump in the rug around. At least I got a totally unique failure out for my time! :) Ross
