Bug#969792: Incorrect target triple

and FreeRTOS. So, I'm not sure 'none' is right either? -- -keith signature.asc Description: PGP signature

Bug#1086462: RM: gcc-riscv64-unknown-elf [mips64el] -- ROM; mips64el gcc crashes while building this package

m the mips64el arch. I'm assuming this will unblock migration to testing, at least once gcc-14 14.2.0-9 manages to migrate. -- -keith signature.asc Description: PGP signature

Bug#1086462: Status of gcc-riscv64-unknown-elf migration to testing

From: Johannes Schauer Marin Rodrigues Date: Thu, 28 Nov 2024 08:12:43 +0100 > 1. Keith files a bug with ftp.debian.org to remove the mips64el package of > gcc-riscv64-unknown-elf from testing, thus declaring that the removal > of mips64el from the package was indeed intention

Bug#1087676: RM: gcc-riscv64-unknown-elf [mips64el] -- ROM; mips64el gcc crashes while building this package

Package: ftp.debian.org Severity: normal X-Debbugs-Cc: gcc-riscv64-unknown-...@packages.debian.org Control: affects -1 + src:gcc-riscv64-unknown-elf User: ftp.debian@packages.debian.org Usertags: remove The mips64el build for gcc-riscv64-unknown-elf crashes in the link phase for the compiler.

Bug#1086188: nickle: please make the build reproducible

#x27;t root-cause the issue as it seems "impossible" unless different hardware is producing different results for the same code. -- -keith signature.asc Description: PGP signature

Bug#1086319: snek: FTBFS: /usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: snek-duemilanove-1.9.elf section `.text' will not fit in region `text'

I've submitted an MR to the gcc-avr repository on salsa: https://salsa.debian.org/debian/gcc-avr/-/merge_requests/4 -- -keith signature.asc Description: PGP signature

Bug#1086188: nickle: please make the build reproducible

d then, taking that binary, run it on another? To reproduce the original issue, it would probably be best to also build the file on each of the targets without using -static and see what that does. -- -keith signature.asc Description: PGP signature

Bug#1086188: nickle: please make the build reproducible

ompiler or hardware bug here; I'll continue using bc for nickle, but we can extract the program which generates that data from the repository and use it for testing along with the shorter possible reproducer I wrote here. Finding another x86 FPU bug would be notable. -- -keith signature.asc Description: PGP signature

Bug#1086319: snek: FTBFS: /usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: snek-duemilanove-1.9.elf section `.text' will not fit in region `text'

+ 1.0; + else if (a > 16.0) +return a - 3.0; + else if (a < 300.0) +return a - 30.0; + else +return a; +} + +/* { dg-final { scan-rtl-dump-not "memory is more profitable" "ira" } } */ -- 2.45.2 -- -keith signature.asc Description: PGP signature

Bug#1086319: snek: FTBFS: /usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: snek-duemilanove-1.9.elf section `.text' will not fit in region `text'

r avr has been fixed there. I'll see if there's a single commit which could be applied to our existing compiler or whether we just need to wait until gcc-avr is updated. -- -keith signature.asc Description: PGP signature

Bug#1086319: snek: FTBFS: /usr/lib/gcc/avr/14.2.0/../../../avr/bin/ld: snek-duemilanove-1.9.elf section `.text' will not fit in region `text'

41,r24 std Y+42,r25 ldd r22,Y+39 ldd r23,Y+40 ldd r24,Y+41 ldd r25,Y+42 On the surface, this looks like a completely unnecessary sequence of 8 instructions. There are multiple instances of this behavior in just this one file. -- -keith signature.asc Description: PGP signature

Bug#1086188: nickle: please make the build reproducible

id) { volatile double s = sin(v); int ret = 0; printf("value: ( %.18g %a ) sin(value): ( %.18g %a )\n", v, v, s, s); if (s != sinv) { printf("Error: expected ( %.18g %a ) got ( %.18g %a )\n", sinv, sinv, s, s); ret = 1; } return ret; } $ cc -static -O2 bug-1086188.c -lm -- -keith signature.asc Description: PGP signature

Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104

From: Johannes Schauer Marin Rodrigues Date: Tue, 10 Sep 2024 19:26:28 +0200 > In an upstream github issue that Keith responded to a week or more ago he did > say he couldn't do anything immediately as he was "off flying rockets" - I > took that to mean he is likely enj

Bug#1072233: mosh: use wtmpdb to write wtmp entries

I think Mosh would be happy to support this transition, but Mosh doesn't write to utmp/wtmp itself or with a PAM module; Mosh uses libutempter for this. If libutempter is going to be updated to use wtmpdb, I don't think Mosh itself has to change. Sincerely, Keith On Thu, May 30, 2024 a

Bug#1052674: ITS: mu-editor

Package: mu-editor Version: 1.2.1-1 Severity: important X-Debbugs-Cc: ni...@debian.org I'd like to get an updated version of this application into the archive; it's been a year since the last upload and upstream has moved from version 1.0 to version 1.2 with significant improvements and bug fixes.

Bug#815539: typecatcher: Still the same in Bookworm

Package: typecatcher Version: 0.3-1.2 Followup-For: Bug #815539 The package in Bookworm has exactly the same problem. Disappointing that this bug remains seven years after being reported. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (990, 'testing'), (500, 'tes

Bug#1034041: Should firmware-amd-graphics be automatically installed?

I must have sent 1/2 a dozen requests to unscript to this email address. debian-boot-requ...@lists.debian.org This address was in the email headers. Why am I not being removed? > On May 22, 2023, at 12:57 PM, Ferenc Wágner wrote: > > Cyril Bruleb

Bug#1036446: Please enable udhcpc6

How do I get off this list? Regards, Keith > On May 20, 2023, at 7:11 PM, Ben Hutchings wrote: > > Package: udhcpc > Version: 1:1.35.0-4+b2 > Severity: wishlist > Tags: ipv6 > > Busybox has a DHCPv6 client (udhcpc6) but this is not included > in the Debian p

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

Package: installation-reports Severity: important Boot method: CD Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso (2023-04-24 23:09) Machine: UTM QEMU VM Base System Installation Checklist: [O] = OK, [E] = Error (pl

Bug#1034401: clementine: No tray icon under bookworm + Cinnamon

Package: clementine Version: 1.4.0~rc1+git867-g9ef681b0e+dfsg-1 Severity: minor Dear Maintainer, After upgrade to bookworm, Cinnamon DE, the Clementine icon no longer appears in the system tray (it is enabled in Preferences, Behaviour). This may be related to bug #1029650 - it's not clear from

Bug#1034339: libpam-mount: 'sudo -i' gives 'HXproc_run_async: pmvarrun: No such file or directory'

Package: libpam-mount Version: 2.19-1 Severity: minor Tags: patch Dear Maintainer, * What led up to the situation? Running 'sudo -i' causes 'HXproc_run_async: pmvarrun: No such file or directory' to be printed. The sudo call works without problem. * What exactly did you do (or not do) th

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > On Wed, 30 Nov 2022, Keith Packard wrote: > >> Scott Talbert writes: >> >>> @Keith, do you have time to upload this patch? Unfortunately, this is >>> blocking a large number of packages from migrating to testing. >>> Alternat

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > @Keith, do you have time to upload this patch? Unfortunately, this is > blocking a large number of packages from migrating to testing. > Alternatively, any objections to an NMU? Thanks for the NMU! Did you happen to create a git repo with this change? I jus

Bug#1023020: cmark-gfm: FTBFS on s390x

Scott Talbert writes: > @Keith, do you have time to upload this patch? Unfortunately, this is > blocking a large number of packages from migrating to testing. > Alternatively, any objections to an NMU? I didn't get to this today, and might not until thursday or friday. Happy f

Bug#1021193:

binutils-source) -- -keith signature.asc Description: PGP signature

Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

-fno-exceptions" CXXFLAGS="$(CXXFLAGS) -g -Os -ffunction-sections -fdata-sections -fno-exceptions" LDFLAGS="$(LDFLAGS)" BUILDFLAGS_PICOLIBC=CFLAGS="--specs=picolibc.specs $(CFLAGS) -g -Os -ffunction-sections -fdata-sections" CXXFLAGS="--specs=picolibcpp

Bug#1010368: Maybe marshal nondeterminism?

that it might be shared with who knows what else. I'm assuming this stops reproducing when you change it to a unique name since no one else will share the reference and you'll just deterministically get no FLAG_REF. Just my best guesses. Keith [1] https://github.com/python/cpython/blob/main/Python/marshal.c

Bug#1010175: ITP: ruby-prawn-templates -- Prawn::Templates allows using PDFs as templates in Prawn

Package: wnpp Severity: wishlist Owner: Keith Packard X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Ruby Extras Maintainers * Package name: ruby-prawn-templates Version : 0.1.2 Upstream Author : Gregory Brown * URL : https://github.com/prawnpdf/prawn

Bug#1007178: Incorrect dependency from libghc-curl-dev?

dency is actually against the GNUTLS flavor of libcurl, so it seems like the dependency on libcurl4-openssl-dev may be in error. Found this working with Debian 11/bullseye. --Keith

Bug#1005718: mosh: FTBFS with OpenSSL 3.0

forwarded 1005718 https://github.com/mobile-shell/mosh/issues/1174 thankyou On Sun, Feb 13, 2022 at 1:03 PM Sebastian Andrzej Siewior wrote: > > Source: mosh > Version: 1.3.2-2.1 > Severity: important > Tags: bookworm sid > User: pkg-openssl-de...@lists.alioth.debian.org > Usertags: ftbfs-3.0 >

Bug#1004440: libgtk-3-0: File selection dialog filters incorrectly on NFS mounted directories

Package: libgtk-3-0 Version: 3.24.24-4 Severity: normal Dear Maintainer, When using the GTK file selection dialog - for example, from mouse pad - it's possible to start typing a filename and the dialog progressively filters out files that don't match. That works fine on a locally mounted direct

Bug#1004058: RM: libnewlib-nano -- ROM; Obsoleted by picolibc. Has numerous open security and RC issues.

Package: ftp.debian.org Severity: normal

Bug#989103: Fix

Downgrading the deb-multimedia package libasound2-plugins from 1.2.2-dmo2 to 1.2.2-2 fixed this for me. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991337#30

Bug#989103: pulseaudio crashes on startup

Caution: naivety ahead. I'm seeing similar behaviour, but I'm not sure it's identical. I don't have "load-module module-alsa-sink" uncommented in /etc/pulse/default.pa. I've also rebuild pulseaudio with the patches but my problem persists. With no USB audio devices connected, pulseaudio works fin

Bug#990733: xfwm4: Resolution drops from 3840x2160 to 2560x1440 on power save

Package: xfwm4 Version: 4.16.1-1 Severity: normal Dear Maintainer, Occasionally - maybe once a week - after re-waking a sleeping monitor, the screen resolution changes as per subject. Settings, Display then shows a maximum available resolution of 2560x1440. Logging out and in keeps the lower r

Bug#989548: light-locker: Username field has focus when unlocking

> Did you maybe change something in the default lightdm configuration (like > having the userlist displayed?). No, the lightdm config is out of the box unmodifed. > Is accountsservice installed on your box? No. Should it be? -- Great music, chat and even some wit. Join me every Friday eveni

Bug#989548: light-locker: Username field has focus when unlocking

Package: light-locker Version: 1.8.0-3 Severity: normal Dear Maintainer, New installation of Bullseye with XFCE and light-locker. When the screen is locked, the username is not populated and it also has focus. Previous versions of light-locker would fill in the username and put the focus on the

Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h

colibc instead of newlib; that's the library I maintain. It's a fork of newlib with changes for embedded systems. $ sudo apt install picolibc-riscv64-unknown-elf $ riscv64-unknown-elf-gcc -specs=picolibc.specs -march=rv32i -mabi=ilp32 -c test.c -- -keith signature.asc Description: PGP signature

Bug#981220: gcc-xtensa-lx106: libgcc doesn't contain soft float functions

Package: gcc-xtensa-lx106 Version: 10.2.1-3+8 Severity: normal X-Debbugs-Cc: kei...@keithp.com It seems that libgcc built for this toolchain is missing the soft float emulation functions? This program fails to link: cat > test.c << EOF #include #include #include int main(void) { char

Bug#978636: move to merged-usr-only?

hould be clear about what we're > resolving. I think you've added helpful clarification to the conversation, thanks! -- -keith signature.asc Description: PGP signature

Bug#980086: broken autopkg test, no aarch64 cross targets on armhf.

to need to restrict which architectures are allowed to attempt to build them. Is there some reason the aarch64 cross compiler is *not* available on armhf? -- -keith signature.asc Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

Adrian Bunk writes: > I am just a normal user enjoying the game, and looking at the number of > uploads in the past decade two maintainers might be sufficient to handle > the load. ;-) I've uploaded 'kgames' to the new queue :-) Thanks for playing. -- -keith s

Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries

e-only upload to DELAYED/15, closing this > bug. Please let me know if I should delay or cancel that upload. Oh, thanks so much for doing this upload -- I totally spaced doing a source upload after 1.4.7 required a binary upload to go through the new queue again for the added aarch64 binary packag

Bug#974011: xmille: Incorrect license/copyright for xmille

Steven Robbins writes: > On Saturday, December 26, 2020 12:50:58 A.M. CST Keith Packard wrote: > >> I've tagged version '1.0' of this repository and created some (not >> finished) debian packaging for it. This version has imported the mille >> sources

Bug#974011: xmille: Incorrect license/copyright for xmille

Keith Packard writes: > This package includes a bunch of games using a shared widget library, > including a raft of solitaire, another (not terribly good) reversi > implementation and even a version of dominoes. Having this build only > xmille would be fairly easy. If that

Bug#977958: dbus: Some ir-keytable remote control buttons don't work unless dbus is restarted

Package: dbus Version: 1.12.20-0+deb10u1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Configuring an IR remote control (for MythTV) and noticing some keys don't work. Example: the "play" butto

Bug#974011: xmille: Incorrect license/copyright for xmille

Adrian Bunk writes: > On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote: >> Adrian Bunk writes: >> > >> > Keith, do you remember the copyright history of this code? >> >> I may have copied the underlying mille sources *before* copyrights wer

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

its packages to have, I'm happy to comply and have no quibbles with your patch. Cheers, Keith On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian < vagr...@reproducible-builds.org> wrote: > On 2020-12-18, Keith Winstein wrote: > > Thank you for tracking this down! Hap

Bug#977684: mahimahi: reproducible builds: Embeds paths to iptables and ip in binaries

Thank you for tracking this down! Happy to take the patch -- would you mind filing this as an upstream pull request at https://github.com/ravinet/mahimahi ? That way we will have this in one place when we next have cycles to upload a new mahimahi package. Sincerely, Keith On Fri, Dec 18, 2020 at

Bug#974011: xmille: Incorrect license/copyright for xmille

lle code into xmille, along with copyrights. This has the advantage of fixing a number of crashes on 64- bit architectures. When I finish, I'll create a new upstream version, at which point we can package that for debian and resolve the copyright and license issues. -- -keith signature.asc Description: PGP signature

Bug#974011: xmille: Incorrect license/copyright for xmille

n stripped out of all code in the xmille distribution. >> Also, none of the included materials give credit to the original author, >> Ken Arnold. >> >> I'm not sure what the best solution is, exactly. Extensively patch the >> source until it complies with the

Bug#976405: Bug#976535: Bug#976495: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6

d the resulting PDF has a lot of artifacts in the TOC. Each TOC label and page number are prefixed with 'black'. I'd be happy to help fix things, but I'm afraid I'm way out of my docbook depth here. -- -keith signature.asc Description: PGP signature

Bug#969436: Fixing wrong changelog entry

se to correct the changelog also in the actual package, not just in the source repo? Thanks,Keith

Bug#958110: nickle: please make the build reproducible

consider applying this patch and uploading? So sorry -- I had applied the fixes but hadn't uploaded. Vagrant caught me on IRC and encouraged me to finish the next release. -- -keith signature.asc Description: PGP signature

Bug#956253: mu-editor 1.0.3 packaged (with bonus features)

27;t had as much review or testing in this version. > I wonder if there are there any other standalone commits post 1.0.3 > that might also be worthwhile patching in? Let me look into this this > week. Thanks. -- -keith signature.asc Description: PGP signature

Bug#960866: libnewlib-nano FTBFS with meson 0.54.2-1

nish removing this package from the archive. Picolibc is just a rename of this library to avoid conflicting with existing uses of the name 'newlib-nano'. -- -keith signature.asc Description: PGP signature

Bug#952637: Close bug 952637

Pirate Praveen writes: > On Mon, 09 Mar 2020 12:41:41 -0700 kei...@keithp.com ("Keith Packard") wrote: >> >> Source: ruby-asciidoctor-pdf >> Version: 1.5.3-1 >> >> Updated gemspec dependency on concurrent-ruby to ~> 1.1.0 which matches

Bug#951306: snek: unsatisfiable b-d on picolibc-arm-none-eabi

Ralf Treinen writes: > snek build-depends on picolibc-arm-none-eabi which does not exist (yet) > in sid. Yup. It's been stuck in the 'new' queue for several months now. -- -keith signature.asc Description: PGP signature

Bug#951068: xinetd: daytime service gives incorrect format

uggests no packages. -- Configuration Files: /etc/xinetd.d/daytime changed [not included] -- no debconf information -- Keith Blow

Bug#930764: Still present in 3.0.13-1

ew version, rendering it unusable. Since this package regularly gets upstream upgrades and is (going to be) part of several transitions, more broken packages are expected if this is not fixed. Is it possible to incorporate the supplied patch? Regards, Keith

Bug#946419: samba-vfs-modules: Resource forks are truncated when written to fruit-enabled share

Package: samba-vfs-modules Version: 2:4.11.1+dfsg-3 Severity: important I use vfs_fruit with a Samba share serving various older versions of Mac OS X, from 10.6 up through 10.11, archiving classic Mac files dating back to the mid 80s. With the latest Samba 4.11.1 in Debian testing, writing one o

Bug#930764: cyrus-common 3.0.8-6 fails to configure package due to "unknown type of DB: BACKUP" on upgrade-db

roken packages are expected if this is not fixed. Is it possible to incorporate the supplied patch? Regards, Keith

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

Yes, that's one possible fix. But if you grab a newer version from upstream, pointer_deref_comparison.patch isn't necessary at all. The change from '\0' to NULL was already made 2018-09-19 as I described above in message #5 on this report. I suppose grabbing the newer version make sense in the lo

Bug#675299: Hello,

I sent this letter to you a month ago, but I'm not sure if you got it, I did not hear from you, and this is the reason I repeat it. Can we talk now please? Thanks, Campion Keith.

Bug#933057: Reproducing the bug

To reproduce the bug: $ bsd-csh -f -c 'eval date' Segmentation fault $

Bug#933057: csh: bsd-csh eval command always dies with segmentation fault

Package: csh Version: 20110502-4 Severity: important Tags: upstream -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8

Bug#929515: smokeping: CSS and js files not found

eping-screen.css net::ERR_ABORTED 404 (Not Found) ...and more, similar. The file exists: $ ls -l $(locate smokeping-screen.css) -rw-r--r-- 1 root root 4596 Feb 24 00:54 /usr/share/smokeping/www/css/smokeping-screen.css So, this appears to be some kind of path issue. Keith -- System Information: D

Bug#925202: Keep calypso out of testing/buster

hanges there. Please feel free to hack on the code if you like. For instance, getting Guido's autopkgtest bits re-integrated would be awesome. There are also a couple of bug reports against 1.5 and it would be good to check and see if they're still valid against 2.0. -- -keith signature.asc Description: PGP signature

Bug#836691: Note#836690: ryan

K On Sep 4, 2016 6:21 PM, "#WalPromos" wrote: > CongratsThis __is your__1,OOO.OO_Walmart___GiftCard >

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Alexander Larsson writes: > Yeah, assuming there is no global default salt that messes this up. It sounds like having 'salt' values in dir and remap-dir elements is what we want then -- no need for separate salt elements. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

that case, we'll need to enumerate all flatpak visible font directories separately. I think we need a complete enumeration of the cases; I keep seeing more options... -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

u need to be able to inherit the 'salt' value from the host (if set)? If so, we could have: /run/host/fonts -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Yep, that looks good to me. I don't time this week to hack on the code, and it looks like you're doing great anyways; let me know if you need help in any way with the implementation work. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

use to discover the relevant fontconfig information seems like a useful improvement; as I recall, flatpak is currently assuming /usr/share/fonts and ~/.fonts are used on the host. -- -keith signature.asc Description: PGP signature

Bug#920956: ITP: fonts-recommended -- set of recommended fonts

Adam Borowski writes: > Fonts people: as the first stab, I'll upload my picks with Fabian's input, > then let's have a flamewar. Can you point us at the proposed list? -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

mapped paths? Alternatively, we could just assume that only flatpak will use the salt mechanism and leave this for a future enhancement? -- -keith signature.asc Description: PGP signature

Bug#920698: mosh-server not found

directory, and give the location when starting mosh (e.g. "mosh --server=/home/kaction/bin/mosh-server"). There are some instructions at https://mosh.org you may find helpful. Best regards, Keith On Mon, Jan 28, 2019 at 4:39 AM Dmitry Bogatov wrote: > > Package: mosh > Version: 1.3.

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Sure. I started to implement it based on Keith's branch. Awesome. I'll be back home "tomorrow" and able to spend some time on this next week. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

the file system path as the contents of the element and the cache path as the property, but perhaps the property name could be 'cache-path' instead? -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

Akira TAGOH writes: > Keith, > > I'm fine with it. do you have a time to work on it? or already started > working? > If not, please let me know. I've been at a conference all week, but hope to have time next week. Would be happy to see others get this started, or col

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

ific directory trees. Let's figure out how we should handle the stale flatpak fonts cache issue. Once we've settled that, we can go implement the whole mess and get a new fontconfig release made in time for debian freeze. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

rwise, this looks good to me. If we can convince you to mount the host font paths inside the runtime where they had been in the host, then we don't even need that part. But I can easily see where you'd end up with a pile of magic conditionals to avoid having some critical part of the flatpak file system smashed by fonts. Plus, we've already got that part of the solution mostly implemented, and we all know how horrible it is to throw away code (just kidding). -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

With this, and my path->key mapping series, we would be able to access the existing cache files for external fonts (via the mapping mechanism), as well as avoid collisions between internal and external font paths within the cache. And we wouldn't have .uuid files (see above). I still don't understand how UUID files help with the missing mtime issue though; if you could explain that in a bit more detail, that would help me, and perhaps expose a weakness with my alternative proposal. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

nother sandbox *inside* this sandbox, you'd have another level of indirection: /run/host/fonts sandbox-depth-1/usr/share/fonts / sandbox-depth-1/ (assuming that the sandbox didn't manage to mount the "real" system fonts inside the sandbox somewhere). This configuration file would be generated by flatpak at runtime. -- -keith signature.asc Description: PGP signature

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

this point are a collection of dead ends. (Also, if I've missed or forgotten something relevant, please let me know; I've re-read a lot of stuff while writing this, but surely something escaped my notice). -- -keith signature.asc Description: PGP signature

Bug#855025: I'm also seeing the reported issue

ricky thing is if you connect to the VNC server fast enough, while the session is still doing its reload attempts, you also end up getting the panel. In any case, I'll try Sebastian's patch. --Keith Bare

Bug#911120: espeakup fails to install

On 15/10/18 22:02, Samuel Thibault wrote: Hello, Keith Barrett, le dim. 14 oct. 2018 16:50:08 +0100, a ecrit: I removed the package with a view to reinstalling but invoke-rc.d: initscript espeakup, action "start" failed. Mmm, perhaps you just need to have the speakup_soft mod

Bug#911120: espeakup: Does not fully install

Package: espeakup Version: 1:0.80-10 Severity: grave Tags: a11y Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Frequent loss of speech in the console, particularly when swi

Bug#908545: postfix: upgrade queries about replacing /etc/postfix/makedefs.out, when it really should always do so

Package: postfix Version: 3.3.0-1ubuntu0.1 Severity: minor As you can tell from the version, I'm actually encountering this problem on Ubuntu, but this is merely a packaging matter so filing this upstream seemed valid! When upgrading Postfix, I was surprised to be asked Configuration file '/etc/

Bug#908453: Also checked 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10

like it's using a newer upstream version, I wanted to check whether it also ignores type = 'pvh'. I could imagine maybe some of the comet changes were merged in... But, even with the deb9u10 package, I'm still seeing that DomUs will boot in PV mode when their configuration specifies type = 'pvh'. --Keith Bare

Bug#908453: xen-utils-common: README.comet seems to no longer apply to the current Xen packages

de (and we've continued doing so since then). I was interested in exploring PVH mode though, since it looked like it was more similar to PV mode in some ways that would make it work better with various tooling (e.g., xen-tools). The fact it didn't work with the Debian packages the w

Bug#906785: version warping patch is overly aggressive

he tool should exit with an error status rather than silently corrupting the build process. We spent a couple of days tracking down this issue, which would have been obvious had the package build simply failed when it used -target 1.4. -- -keith signature.asc Description: PGP signature

Bug#864082: fontconfig: please make the cache files reproducible

ing for an upstream release with this patch; it looks like that shouldn't be more than a month or two from now. Any particular reason for urgency here? -- -keith signature.asc Description: PGP signature

Bug#882444: xrandr doesn't select DoubleScan modes by name without refresh rate

This bug is caused by a change made in 2009 where xrandr ignores DoubleScan modes unless the user has specified a refresh rate. I don't know what this wanted to fix, so I'm hesitant to fix it. However, a reasonable workaround for the user is to simply specify a non-zero refresh rate.

Bug#899300: mosh: apt-get install error in jessie-backports

Thank you for the bug report. I believe this is a duplicate of bug 803253, which was fixed in mosh 1.2.5-1.1. 2018-05-22 1:08 GMT-07:00 ikar.us : > Package: mosh > Version: 1.2.5-1~bpo8+1 > Severity: important > > > root@:~# apt-get -t jessie-backports install mosh > Paketlisten werden gelesen...

Bug#864082: fontconfig: please make the cache files reproducible

Chris Lamb writes: > Hi Keith, > >> > +source_date_epoch = getenv("SOURCE_DATE_EPOCH"); >> >> Could this work as a build-time value in the library instead of a >> run-time environment variable? > > Unfortunately not. Imagine the situation wh

Bug#864082: fontconfig: please make the cache files reproducible

Chris Lamb writes: > +source_date_epoch = getenv("SOURCE_DATE_EPOCH"); Could this work as a build-time value in the library instead of a run-time environment variable? -- -keith signature.asc Description: PGP signature

Bug#894271: ITP: cmark-gfm -- GitHub enhanced version of cmark, the common markdown parser

Package: wnpp Severity: wishlist Owner: Keith Packard * Package name: cmark-gfm Version : 0.28.3.gfm.12 Upstream Author : John MacFarlane * URL : https://ithub.com/github/cmark * License : BSD, MIT/X Programming Lang: C Description : GitHub enhanced

Bug#892929: gambas3: Crashes upon start. [20] Bad Argument. Settings.WriteWindow.388

Package: gambas3 Version: 3.9.2-2 Severity: important Dear Maintainer, Upon starting Gambas3, a message window immediately pops up claiming "[20] Bad Argument. Settings.WriteWindow.388", with only an ok button to acknowledge. Upon acknowledgement, the application closes. At this point in time,

Bug#890973: ITP: xorgproto -- X11 extension protocols and auxiliary headers

s a note to the curious; we're merging all of the protocol headers into a single repository to reduce our development work. Future changes to any of these headers will only be released in this combined format; the separate repositories will be frozen. -- -keith signature.asc Description: PGP signature

  1   2   3   4   5   6   7   >