Alexander Larsson writes:
$ cat /run/host/font-dirs.xml
>
>
>
> /run/host/fonts
> /run/host/user-fonts
>
>
> Is this format acceptable? Its mostly about naming the nodes and the
> attributes, so its basically trivial. If you want i can rename things
> or change orders, but I'd really
Akira TAGOH writes:
> Hm, to deal with more complicated cases, I guess we may need to have
> one global salt to affect everything and a path-specific salt for
> remapped path.
Or, more likely, no salt at all for the outermost layer as it doesn't
really add anything here.
> for flatpak case,
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
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
Alexander Larsson writes:
> As I said in an earlier email, it needs to be in the individual dir
> elements, because a global salt is not right.
Do you want it in the elements directly? That would be more
straightforward in many ways and could avoid troubles with separate salt
declarations that
Alexander Larsson writes:
> We don't want a global salt for everything in the container.
I guess I wonder why not? Salt + dir inside the container will always be
unique. The place where you want to have different salt is for
directories mapped from the host; I think those will always be in
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
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
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
Adrian Bunk writes:
> Source: libnewlib-nano
> Version: 2.11.2-1
> Severity: serious
> Tags: ftbfs bullseye sid
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnewlib-nano.html
The correct fix is to get picolibc out of the new queue so I can finish
removing this
"Chris Lamb" writes:
> Dear Maintainer,
>
>> Source: nickle
>> Version: 2.77-1
>> Tags: patch
>
> There hasn't seem to be any update on this bug in 135 days, in which
> time the Reproducible Builds effort has come on a long way.
>
> Would you consider applying this patch and uploading?
So sorry
Nick Morrott writes:
> There is a bug report asking for 1.1.alpha to be packaged [1], so I
> think a sensible plan might be to get a mildly-patched 1.0.3 into
> unstable and then consider uploading the current alpha into
> experimental?
I had packaged 1.1.alpha, which has a number of useful
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 tha
Paul Gevers writes:
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15,
Lucas Nussbaum writes:
> There was a texlive update in the meantime. Here are the versions of
> packages that differ.
I explored this a bit today -- there's something quite amiss with the
docbook toolchain. I'm seeing a lot of this error:
! Undefined control sequence.
Adrian Bunk writes:
> On Sun, Nov 08, 2020 at 07:06:52PM -0500, Ryan Armstrong wrote:
>>...
>> I have been researching old terminal and X games recently, and realized
>> that much of the code from 'xmille' orignated from the terminal game
>> 'mille', which is part of bsdgames.
>>
>>
Ryan Armstrong writes:
> I just did a bit of digging, since I previously had a 2.11 BSD VM set up
> in SIMH (fun!). It looks like the version of mille in that release was
> indeed from about the 1985/1986 time frame, and the copyright headers
> were not yet added. So that makes much more
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
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 from 'upstream'
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
signature.asc
Description:
Simon McVittie writes:
> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?
I think that and a transition plan are both key to this project. I
recently installed
Matthias Klose writes:
> This blocks migration of gcc-defaults, there is no aarch64 cross
> target on armhf.
Suggestions on how to work around this welcome; I really don't know what
to do. I want to continue providing the generated binaries on all
architectures, but we appear to need to
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)
{
Joel Stanley writes:
> Package: gcc-riscv64-unknown-elf
> Version: 8.3.0.2019.08+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> I am trying to use the riscv toolchain to build a bare metal
> application. It appears to have a broken stdint.h:
You might try using picolibc instead of newlib;
Package: ftp.debian.org
Severity: normal
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
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
I looked for exactly this bug as I fixed the same issue in
binutils-riscv-unknown-elf today, but somehow I missed it.
This should be fixed in version 18 by using dpkg-query instead of
hand-hacked shell bits:
upstream_version := $(shell dpkg-query -W -f="\$${source:Upstream-Version}\n"
> One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
> exclude the LTO flags specifically so that they don't leak into the target
> builds. Another thought I had was to use the dpkg-buildflags for armhf as a
> target architecture, since there could be other per-arch flags
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 just noticed
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 for your to NMU
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
301 - 332 of 332 matches
Mail list logo
