Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?
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 just like an Ack on something. Format looks OK. I think we might bike-shed on the names here a bit -- 'real-path' is pretty ambiguous as both paths are 'real', one is just the file system path and the other is the cache path. I like using 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: > 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, they want to have a global salt to > change a salt in sandbox (for /usr/share/fonts in sandbox etc) and set > salt from host in 'remap-dir' to build cache filenames on host (for > /run/host/fonts and so on). We may want a command line tool that extracts data from the config for use by flatpak in building the dynamic configuration, including things like salt values per directory. Yeah, that might be made to work with flatpak essentially manually overriding the salt configuration so that it uses the flatpak-relative names. > This would avoid collision between one and origins. and assuming that > flatpaks can load config from host too, we could have: > > 10-salt.conf (from host): > I'd leave this out and not have salt in the host. > 50-flatpak.conf (sandbox specific): > /run/host/fonts > > /usr/share/fonts The salt here would need to have CDATA for the target directories, and I think flatpack wants to split the dynamic from static config bits. Dynamic (built at runtime): /run/host/fonts Static (built in the flatpak): /usr/share/fonts > > First salt element affects to 'remap-dir' and second one overrides it > for paths and change a salt in sandbox. I think we can put that into the remap-dir element as both of those are built at runtime? > To make things easier, we may also want to export all of dir elements > from fonts.conf to the separate file. flatpak can replace it with > 50-flatpak.conf in this case. or the file operation isn't desirable, > let's implement dir-reset element or something like that. I think a dir-reset makes a lot of sense so that the flatpak can control the set of font paths used. Building a command-line tool that flatpak can 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?
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?
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 take effect more broadly than one directory. So, one file (generated at flatpak creation time) with /usr/share/fonts /run/host/fonts and another (generated at runtime) with /run/host/fonts Presumably you will mask all host configured font paths somehow? Maybe you 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?
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 remap-dir clauses, if we have salt there, that should work? > In > reality things are more complicated than that. For example, an app may > bundle fonts, which will be in like /app/share/fonts, in addition to > the runtime fonts in /usr/share/fonts. These come from different > places and may individually be different in a different (or updated) > app, so the directories need to have different salts. If building the flatpak generates the font caches, then per-flatpak salt would make those correct. > Also, it is quite possible that some host font directory is *not* > remapped, but still visible to the app. For example /opt/fonts for an > app that has filesystem access. If for whatever reason fontconfig > looks at this directory it should not apply any salt for it. Oh, so some host directories may be visible unmapped and unknown to the flatpak? In 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?
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#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#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 1.1.6
>
> ~> 1.1 should be enough, see
> https://github.com/asciidoctor/asciidoctor-pdf/pull/1601
Thanks. I'll update the patch here and expect to delete it when
asciidoctor-pdf gets a new release.
--
-keith
signature.asc
Description: PGP signature
Bug#960866: libnewlib-nano FTBFS with meson 0.54.2-1
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 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#958110: nickle: please make the build reproducible
"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 -- 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)
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 additions (including built-in reformatting), but then went and looked at the Debian packaging and noticed that you had fixed a number of DFSG issues. It would probably be easier to merge changes from upstream to a 1.1.alpha experimental release than on top of 1.0.3, so it might make sense to publish a 'pure' 1.0.3 to unstable and then add a fancy 1.1.alpha to experimental. Are you keeping a patch-queue branch anywhere to help with evaluating which fixes to include? I've pushed my branch to https://salsa.debian.org/keithp/mu-editor/-/tree/patch-queue/debian/master That's got the three additions I'm using in class: 1. add snek mode (needed for my snek-based class) 2. close repl/plotter when serial port disappears (helps when unplugging USB) 3. scale button bar icons (helps on small screens) I had to back-port these to 1.0.3, so they haven'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#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 seems like a reasonable way > forward, I'll go ahead and create a release of that package. 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' which include copyright information for the BSD-sourced files. How would you like to go about getting these 'xmille' bits into the archive as a replacement for the ancient bits now living there? It's not a direct replacement as it includes a bunch of additional applications. They're all 'classic' X apps, although now 'modernized' (if code circa 1990 can be considered 'modern') as they're Xt/Xaw based, instead of being raw X based. And the colors now work too, plus fewer crashes. -- -keith signature.asc Description: PGP signature
Bug#978412: src:picolibc: fails to migrate to testing for too long: maintainer built arch:all binaries
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, 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 package. -- -keith signature.asc Description: PGP signature
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
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.
\close@pdflink ->\Hy@endcolorlink
\Hy@VerboseLinkStop \pdfendlink
l.585 ...-mode}}History\endNode{}\endSeq{}\endLink
{}\Seq%
The result is that pdfjadetex exits with status 1 and 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#974011: xmille: Incorrect license/copyright for xmille
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. >> >> Specifically, the following files are notably similar between the two >> games: >> comp.c >> end.c >> extern.c >> init.c >> mille.c & mille.h >> misc.c >> move.c >> types.h >> varpush.c >> >> Many of these even contain telltale BSD version/date comments, even a >> few not listed above that are common but extensively re-written. >> However, all of the original source files contain the 3-term BSD >> license, as follows: >>... >> This has been 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 BSD license again? >> >> Presumably, the copyright file needs to change at the very least. >>... > > Keith, do you remember the copyright history of this code? I may have copied the underlying mille sources *before* copyrights were added to each file; I started work on the X10 version of xmille around 1985 or 1986. I guess I could have mistakenly removed them? Thanks for discovering this error; I can fix these "upstream" and publish a new version? -- -keith signature.asc Description: PGP signature
Bug#974011: xmille: Incorrect license/copyright for xmille
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 sense then removing them. > > I guess the question becomes, would they still require a change in > copyright status, or is the previous status correct? > > Also, should a credit for Ken Arnold be added? I'm about half way through updating the code by copying the mille 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
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 were >> added to each file; I started work on the X10 version of xmille around >> 1985 or 1986. I guess I could have mistakenly removed them? Thanks for >> discovering this error; I can fix these "upstream" and publish a new >> version? > > I am just a user who would like to see this package also in bullseye. > > A new upstream version would be good, but it is not obvious to me > whether you or Steve M. Robbins or anyone else is considered upstream > or should become upstream (again). It looks like the version in the archive is *very* old (I mean, "new" xmille is still old, but there is a more modern port that uses Xt at least). I've got the newer version working, even on 64-bit systems, and have applied suitable copyright messages. https://keithp.com/cgit/games.git/ 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 seems like a reasonable way forward, I'll go ahead and create a release of that package. -- -keith signature.asc Description: PGP signature
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 from 'upstream' which include copyright information for the >> BSD-sourced files. >> >> How would you like to go about getting these 'xmille' bits into the >> archive as a replacement for the ancient bits now living there? > > Personally speaking: if you're already working on debian packaging, my > preference is to just step aside and let you carry on. If you're willing, > then I think it mainly becomes a problem of what to name the source package > as > the new sources are more than just xmille. The upstream name is 'games', which is a bit generic, I suspect. I've tentatively named the package 'kgames'. > I don't mind co-maintaining but, realistically, I won't be much help. Would be good to have more than one person able to upload, just in case. > If you are NOT interested in maintaining the package, then I can continue. > Unless Adrian wants to do it? ;-) I'm easy; three is even better than two? I've packaged everything in one bundle, even though there are 14 games and a shared library. There are few man pages; not even the rules for each game. I do have text for that from my palm pilot 'patience' application; I can see about putting that into a man page for each game. Just so you know, I've got my original 1990 edition of the 'X Window System Toolkit' book sitting on my desk at present. It's getting surprisingly yellowed with age, but the technical content remains as accurate as ever. Talk about 'legacy software' :-) -- -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 signature.asc Description: PGP signature
Bug#978636: move to merged-usr-only?
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 Debian from scratch on my HiFive unmatched board and it got merged / and /usr. When I built packages on this device, they created invalid packages as the shared library dependencies all listed /lib instead of /usr/lib. That seems like a non-starter to me. Any plan where a transitioning system cannot be used for ongoing Debian development seems unworkable to me -- it leaves all active Debian developers working on un-transitioned systems, which greatly reduces test coverage from people in the best position to help fix things. I do use a separate cowbuilder when creating packages to upload, and that could be configured in un-transitioned mode, but I also regularly debug packages on my native system as that offers much faster development times. > Guillem considers layout 1 to be broken and a mess. I don't agree, > but I'm not a dpkg maintainer. We should be aware that mandating this > implementation is likely to require some overruling. From an architectural purity perspective, layout 1 'looks nicer'. As that also matches what other distros are doing, it would make us more consistent across the Linux ecosystem (I believe that's a good thing). However, I believe only layout 2a would make it possible to build Debian packages on transitioned systems. That seems necessary to me. We could, in future, then transition from layout 2a to layout 1 once /lib (and /bin?) were no longer in the default search paths to cause invalid packages to be created. I don't understand the value of 2b; it's functionally similar to layout 1, but makes for additional work to create the shadow links, along with consuming space for them. It also doesn't resolve the problem of building packages. > Sorry to derail this but I think we should 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.
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 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#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 foo[50];
double q;
strcpy(foo, "3.1415");
sscanf(foo, "%lf", );
return (int) (sin(q) * 100);
}
EOF
xtensa-lx106-elf-gcc --specs=picolibc.specs test.c -lm
-- System Information:
Debian Release: bullseye/sid
APT prefers oldoldstable
APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, i386
Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, 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 gcc-xtensa-lx106 depends on:
ii binutils-xtensa-lx106 2.35.1-7+3+b1
ii libc6 2.31-9
ii libgcc-s1 10.2.1-6
ii libgmp10 2:6.2.1+dfsg-1
ii libmpc31.2.0-1
ii libmpfr6 4.1.0-3
ii libstdc++6 10.2.1-6
ii zlib1g 1:1.2.11.dfsg-2
gcc-xtensa-lx106 recommends no packages.
gcc-xtensa-lx106 suggests no packages.
-- no debconf information
Bug#979542: gcc-riscv64-unknown-elf: Unable to use stdint.h
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; 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#1004058: RM: libnewlib-nano -- ROM; Obsoleted by picolibc. Has numerous open security and RC issues.
Package: ftp.debian.org Severity: normal
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. I've got a new version ready for upload in my salsa repo here: https://salsa.debian.org/keithp/mu-editor I'm happy to either adopt this package or become a co-maintainer, whichever works for the team. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_WARN 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 mu-editor depends on: ii black 23.7.0-1 ii fonts-inconsolata 001.010-6 ii libjs-skeleton 2.0.4-2 ii node-normalize.css 8.0.1-5 ii python3 3.11.4-5+b1 ii python3-click 8.1.6-1 ii python3-flake8 5.0.4-4 ii python3-guizero 1.4.0+dfsg-1 ii python3-ipykernel 6.24.0-3 ii python3-ipython-genutils0.2.0-5 ii python3-jupyter-client 7.4.9-2 ii python3-matplotlib 3.6.3-1+b1 ii python3-nudatus 0.0.5-2 ii python3-pil 10.0.0-1 ii python3-platformdirs3.10.0-1 ii python3-pyqt5 5.15.9+dfsg-2 ii python3-pyqt5.qsci 2.14.1+dfsg-1 ii python3-pyqt5.qtchart 5.15.6+dfsg-1 ii python3-pyqt5.qtserialport 5.15.9+dfsg-2 ii python3-qtconsole 5.4.3-2 ii python3-requests2.31.0+dfsg-1 ii python3-semver 2.10.2-3 ii python3-serial 3.5-1.1 ii python3-uflash 1.2.4+dfsg-10 mu-editor recommends no packages. Versions of packages mu-editor suggests: ii mu-editor-doc 1.2.0-1 ii python3-gpiozero 1.6.2-1+b1 ii python3-pigpio1.78-1 -- no debconf information
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-templates * License : Ruby or GPL-2 or GPL-3 Programming Lang: Ruby Description : Prawn::Templates allows using PDFs as templates in Prawn A extension to prawn that allows one to include other pdfs either as background to write upon or to combine several pdf documents into one. This package is required to implement pdf import in ruby-asciidoctor-pdf which was left out because of a bug in pdf-core. There is a patch for the pdf-core bug which is upstream and will be released eventually; it would be good to have this package ready in debian for when the pdf-core bug is fixed so that a new version of ruby-asciidoctor-pdf can be released that enables this feature.
Bug#1021193:
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"
binutils-source)
--
-keith
signature.asc
Description: PGP signature
Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build
> 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 in the future
> that cause further problems. I've tried the latter approach in the attached
> patch, which fixes the problem of lto being incorrectly used for the
> arm-none-eabi target. I've verified that the resulting libstdc++ is usable
> again with this change.
Yeah, neither of these is really appropriate; we're not building Debian
code here. As 'rules' already sets the complete CFLAGS and CXXFLAGS
values save the necessary flags for a reproducible build, how about I
just add `-ffile-prefix-map=$(TOP_DIR)=.` manually and stop using
/usr/share/dpkg/buildflags.mk?
@@ -10,7 +10,6 @@ MULTILIB_LIST="--with-multilib-list=rmprofile"
GCC_PACKAGE=gcc-arm-none-eabi
include /usr/share/dpkg/pkg-info.mk
-include /usr/share/dpkg/buildflags.mk
SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
DVERSION := $(SVERSION)+$(DEB_VERSION)
@@ -29,6 +28,9 @@
BUILD_PICOLIBC_RELEASE_DIR=$(TOP_DIR)/build_picolibc_release/libstdc++
PNEWLIB=libstdc\+\+-arm-none-eabi-newlib
PPICOLIBC=libstdc\+\+-arm-none-eabi-picolibc
+CFLAGS := -ffile-prefix-map=$(TOP_DIR)=. -Wformat -Werror=format-security
+CXXFLAGS := $(CFLAGS)
+
BUILDFLAGS=CFLAGS="$(CFLAGS) -g -O2 -ffunction-sections -fdata-sections"
CXXFLAGS="$(CXXFLAGS) -g -O2 -ffunction-sections -fdata-sections"
LDFLAGS="$(LDFLAGS)"
BUILDFLAGS_NANO=CFLAGS="$(CFLAGS) -g -Os -ffunction-sections -fdata-sections
-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.specs
$(CXXFLAGS) -g -Os -ffunction-sections -fdata-sections"
LDFLAGS="--specs=picolibc.specs $(LDFLAGS)"
--
-keith
signature.asc
Description: PGP signature
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 just noticed that the salsa repo is in my private space. g...@salsa.debian.org:keithp/cmark-gfm.git -- -keith signature.asc Description: PGP signature
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 for your to NMU if you like. -- -keith signature.asc Description: PGP signature
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. >>> Alternatively, any objections to an NMU? >> >> Thanks for the NMU! Did you happen to create a git repo with this >> change? I just noticed that the salsa repo is in my private space. >> >>g...@salsa.debian.org:keithp/cmark-gfm.git > > No, I didn't, since I wasn't aware you were using a Vcs for packaging (no > Vcs listed in d/control). > > I can send you a merge request with the changes, if you'd like? That would be great. I'll see about moving this out of my personal salsa area and do a new upload with control pointing at the vcs. -- -keith signature.asc Description: PGP signature
