bug#70456: Request for merging "core-updates" branch

Hey, I've spent a bunch of time in the last few days trying to see if I can get the bordeaux build farm moving on core-updates and I think things are moving at pace now. Builds are happening for 6 systems, with the only major omission being i586-gnu, I think there are existing issues with the gui

bug#70456: Request for merging "core-updates" branch

Christopher Baines writes: > I've spent a bunch of time in the last few days trying to see if I can > get the bordeaux build farm moving on core-updates and I think things > are moving at pace now. Following on from this, builds have mostly paused for the last few days as man

bug#72239: libfaketime (still) broken on i686-linux

Ludovic Courtès writes: > Ludovic Courtès skribis: > >> So the easiest short-term solution seems to be using datefudge to run >> the ‘nss’ tests on 32-bit platforms, as Chris already suggested before >> (patch below; it’s being built right now, I’ll see tomorrow if it >> worked…). > > It failed:

bug#72239: libfaketime (still) broken on i686-linux

Ludovic Courtès writes: > Hi! > > Christopher Baines skribis: > >> When running without datefudge, the tests work and the cd in gtests.sh >> seems to fail: >> >> Running tests for gtests >> TIMESTAMP gtests BEGIN: Mon Jul 22 10:09:27 UTC 2024 >>

bug#70456: Request for merging "core-updates" branch

Christopher Baines writes: > Christopher Baines writes: > >> I've spent a bunch of time in the last few days trying to see if I can >> get the bordeaux build farm moving on core-updates and I think things >> are moving at pace now. ... > Some good progress was

bug#71494: data.guix.gnu.org statistics page broken

Antero Mejr writes: > The page at: > https://data.guix.gnu.org/statistics > > appears broken, it is displaying placeholder text relating to the > count-guix-revisions procedure instead of the results themselves. Thanks for reporting this, even when the page was working there were some performanc

bug#73193: /var/lib/certbot/renew-certificates may exist but not be up to date

/var/lib/certbot/renew-certificates was previosuly kept up to date, but as of is no longer kept up to date. The script still exists though and may "work" if run, potentially renewing the certificates but based on a older system configuration. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?

bug#61879: Powerpc on core-updates

best to apply this patch, or how describe it, but at least this is a step forward. From 382862fc06085ba80380977caf2a1f9c3203a12d Mon Sep 17 00:00:00 2001 From: Christopher Baines Date: Thu, 13 Apr 2023 14:45:14 +0100 Subject: [PATCH] WIP --- gnu/packages/gcc.scm | 108 +++

bug#61879: Patch

Andreas Enge writes: > Am Thu, Apr 13, 2023 at 06:57:41PM +0200 schrieb Andreas Enge: >> attached is a new commit in old syntax, mixing both our commits. >> I have confirmed that it does not change the gcc-11 build on x86_64 and i686. >> But do we need "--force" for patching? >> Could you maybe

bug#61879: Patch

Andreas Enge writes: > Am Fri, Apr 14, 2023 at 09:20:03AM +0100 schrieb Christopher Baines: >> I haven't tried this yet, but I've had a quick look. I'm not sure >> search-patches will work where it is, since that'll be running in the >> build environm

bug#62943: Locale issue when rebooting from installation system

root@gnu ~# reboot warning: failed to delete /mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny.pem: No such file or directory warning: failed to delete /mnt/tmp/guix-inst/rna7vp3yi1qj8jzcgcfm2641335nwgk1-profile/etc/ssl/certs

bug#56625: [core-updates] libaio test fails on powerpc64le-linux due to kernel bug

Thiago Jung Bauermann via Bug reports for GNU Guix writes: > On the core-updates branch, libaio has been updated to version 0.3.113. > This version contains a new test which fails on guixp9 (one of the > powerpc64le-linux builders) due to a bug present in the kernel it is > running: ... > So l

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Since the recent core-updates merge, I've seen the build coordinator using less memory, but it's also been crashing in a new way, up to 10 times a day. In the log, you see something like: 2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051 2023-05-07 09:15:42 Signals delivery f

bug#63331: Guile-GnuTLS/Git circular dependency

Simon Josefsson via Bug reports for GNU Guix writes: > [[PGP Signed Part:Undecided]] > Ludovic Courtès writes: > >> We need to solve that. For now, the only fix I can think of is having >> ‘guile-gnutls’ built from a “make dist”-provided tarballs. Apparently >> we can add assets at

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Christopher Baines writes: > Since the recent core-updates merge, I've seen the build coordinator > using less memory, but it's also been crashing in a new way, up to 10 > times a day. > > In the log, you see something like: > > 2023-05-07 09:15:42 Signals

bug#63331: Guile-GnuTLS/Git circular dependency

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> It seems to build for me, but I'm having problems cross building. There >> were warnings before about protocol/ssl3 being undefined, but now this >> seems to result in an error when bu

bug#63445: guix-build-coordinator guile-gnutls segfault

I've seen the build coordinator on bayfront crash a couple of times, and it seems to be segfaulting, maybe in gnutls? May 11 14:31:39 localhost vmunix: [15795370.287670] build-submitted[6013]: segfault at 0 ip 7f1e2e796415 sp 7f1b86ffd640 error 4 in guile-gnutls-v-2.so.0.0.0[7f1e2e79

bug#63414: Evaluation comparison on cuirass

Josselin Poiret via Bug reports for GNU Guix writes: > Hi Andreas, > > Andreas Enge writes: > >> When working on a branch and deciding whether to merge it, we need a way >> of comparing its status with that of the master branch. As far as I can see, >> there is currently no way in cuirass to co

bug#63445: guix-build-coordinator guile-gnutls segfault

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> I've seen the build coordinator on bayfront crash a couple of times, and >> it seems to be segfaulting, maybe in gnutls? >> >> May 11 14:31:39 localhost vmunix: [15795370.287670] &

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

Ludovic Courtès writes: > So it seems ‘guix substitute’ picked /nar/zstd, even though > bordeaux.guix is not advertising that. > > Or is it? > > $ sudo cat > /var/guix/substitute/cache/kzwjeblndsbkjzmjailrt4bnhguil7tqjmewzcyw22hgajbhfy3q/apw1y9nf8rqgxvjnlr1isbhpd502bcs5 > (narinfo (version 2) (

bug#63634: nar 404 leads to hard ‘guix substitute’ crash

Ludovic Courtès writes: > Simon Tournier skribis: > >> 2. &message: > "https://bordeaux.guix.gnu.org/nar/zstd/sx6sr6cs1x8sf5jhgb65rcr1yxk1q75x-rust-base64-0.13.1.tar.xz: > HTTP download failed: 404 (\"Not Found\")" > > Look: > > $ wget -qO- > https://bordeaux.guix.gnu.org/sx6sr6cs1x8sf5jhgb65r

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

Hey! On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't reboot or halt. root@hamal ~# halt Service root is not running. 1: /gnu/store/y6w0xix15cq08qasmq75f04yzgbl98jx-shepherd-0.9.3 signature.asc Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't >> reboot or halt. >> >> root@hamal ~# halt >> Service root is not running. > > Hey, why halt

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Ludovic Courtès writes: > Christopher Baines skribis: > >> Since the recent core-updates merge, I've seen the build coordinator >> using less memory, but it's also been crashing in a new way, up to 10 >> times a day. >> >> In the log, you see somet

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and >> (defined? (quote transient?)) (map (# ?) ?)). >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression &g

bug#63794:

"N. Y." writes: > Are there any workarounds, for an inexperienced user who does not know much > about guix? I am getting 404's for > > - > https://bordeaux.guix.gnu.org/nar/zstd/arnx6fnjq85wscmr894d64cj3529r3h1-wxPython-4.2.0.tar.xz > - > https://bordeaux.guix.gnu.org/nar/zstd/26q8viimh3r7354

bug#63794: Bad error reporting in case of 404 during downloading

Maxime Devos writes: > Problems: > * The server not having a file is not an exceptional situation; > it should just skip this server or just report that there > is no available location for this resource instead of > a backtrace. > > * It claims ‘corrupt input while restoring ...

bug#63794: Acknowledgement (Bad error reporting in case of 404 during downloading)

Maxime Devos writes: > From: Christopher Baines >> I think the key bits here might be a duplicate of #63634 > > Looks like I need to upgrade my Guix system to fix substitution > ... but "guix system build" is currently failing, which needs > [cycle!]. > > Th

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Christopher Baines writes: > Ludovic Courtès writes: > >> Christopher Baines skribis: >> >>> Since the recent core-updates merge, I've seen the build coordinator >>> using less memory, but it's also been crashing in a new way, up to 10 >>

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

Ludovic Courtès writes: > Christopher Baines skribis: > >> I've seen this happen with the build coordinator agent now (on >> milano-guix-1): >> >> 2023-06-02 18:59:55 2023-06-02 18:59:55 (DEBUG): >> fb9f06cf-cc1d-4493-88b8-3eac9437f5d4: checking the

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> Ludovic Courtès writes: >> >>> Hi, >>> >>> Christopher Baines skribis: >>> >>>> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and

bug#64197: Segmentation fault while building ‘guix-cli-core.drv’

Ludovic Courtès writes: > I’ve seen this “failure to process the revision” on qa.guix due to a > segfault while building Guix (from > , commit > f3ec19edf3c3bb902a06ac597e5954b35ee41bce): > > loading... 89.7% of 39 files[ 36/ 78] loading... 92.3% of

bug#64297: [Cuirass] Remote server not picking up job, losing workers

Ludovic Courtès writes: > Ludovic Courtès skribis: > >> The problem is most likely with the connection-to-port caching in >> squee’s ‘connection-socket-port’, as can be seen in this other trace >> where I added ‘pk’ calls in ‘connection-socket-port’: > > Confirmed, with a fix! > > https://not

bug#64609: Failure to "guix pull" at ddbfef2 on aarch64-linux

Michael Ford writes: > This morning when attempting to guix pull, on arch64-linux machines: > > guix pull > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > Authenticating channel 'guix', commits 9edb3f6 to ddbfef2 (32 new commits)... > Building f

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

Hey, I spotted this issue a few days ago, but I'm still pretty confused by it. Both instances of the data service have sometimes been reporting only a small number of package derivations for i686-linux and armhf-linux. I think the first revisions to exhibit this on the master branch for the two d

bug#64762: Guix sometimes doesn't support most packages for i686-linux and armhf-linux

Christopher Baines writes: > To confirm that this is an issue with the supported systems as reported > by Guix, I had the data service print out the transitive supported > systems for the guix package: > > debug: Starting getting derivations for (i686-linux . #f) > looki

bug#64872: guix pull: po4a: build failed

Artyom Poptsov writes: > Hello, Guixers. > > Recently I started to see this error on "guix pull" -- please see > the logs attached. Are you able to share the end of the build log for /gnu/store/qcjl6wfiy662s9knwvkb24vkrviw3jdn-po4a-0.68.drv ? It has been built at least, so you should be able t

bug#64872: guix pull: po4a: build failed

Artyom Poptsov writes: > Huh, it seems that the problem not in "po4a" itself but in > "texlive-hyphen-complete". > > When I try to access > > https://www.tug.org/texlive/tags/texlive-2023.0/Master/texmf-dist//doc/generic/elhyphen > I get 404 error. Ok, well maybe try building /gnu/store/g9xf

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Hello Christopher, > > I tried to build "texlive-hyphen-complete" using a local Guix clone > with the following commands: > > $ cd guix > $ guix shell -D guix > $ ./bootstrap > $ make -j$(nproc) > $ guix build -K texlive-hyphen-complete > > Also I tried to build the deri

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Besides, I run GNU Guix on Ubuntu 22.04.2 LTS. > Please find my SystemD Guix service attached. > > As you can see, I'm using a substitution service through Yggdrasil > network: http://ci.guix.ygg.trop.in > Also there's a proxy server configured. The downloading of the n

bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

Artyom Poptsov writes: > Hello, > > Sorry for the late reply! > > I removed > http_proxy=http://127.0.0.1:9080 https_proxy=http://127.0.0.1:9080 > from my "Environment" variable in "guix-daemon.service" and after I restarted > the Guix daemon "guix pull" and "guix upgrade" went flawlessly. > >

bug#65434: https://data.guix.gnu.org/statistics is bogus

Maxime Devos writes: > That page contains: > > Guix revisions > # > Derivations > # > > I think some code forgot to actually call these procedures. Haha, that's a werid issue. I haven't looked at that page for a long while as I don't think it was performing well when you have any more than a f

bug#62240: Exception within (guix store) process-stderr when using suspendable ports

Christopher Baines writes: > Christopher Baines writes: > >> Christopher Baines writes: >> >>> I'm seeing this in the build coordinator agent, but it can be reproduced >>> by tweaking the guix build script as below. The build coordinator uses >>

bug#63445: guix-build-coordinator guile-gnutls segfault

Christopher Baines writes: > Ludovic Courtès writes: > >> Hi, >> >> Christopher Baines skribis: >> >>> I've seen the build coordinator on bayfront crash a couple of times, and >>> it seems to be segfaulting, maybe in gnutls? >&

bug#65858: mumi crashes

Maxim Cournoyer writes: > Hi, > > Maxim Cournoyer writes: > >> Hi Arun, >> >> Arun Isaac writes: >> >>> Hi Maxim, >>> >>> I have made a number of changes to mumi and reconfigured berlin with the >>> latest mumi. Here is a quick summary of the main changes to mumi. >>> >>> - We now log the comp

bug#65858: mumi crashes

Maxim Cournoyer writes: > Hi Christopher, > > Christopher Baines writes: > > [...] > >>> Here's a fresh crash (on berlin): >>> >>> 2023-10-24 06:22:58 GET >>> /graphql?query=query%20%7B%0A%20%20issue%28number%3A%2065806%29%20%7B%0A%20%

bug#63414: Evaluation comparison on cuirass

Ludovic Courtès writes: > Hello, > > Andreas Enge skribis: > >> When working on a branch and deciding whether to merge it, we need a way >> of comparing its status with that of the master branch. As far as I can see, >> there is currently no way in cuirass to compare arbitrary evaluations and >

bug#65720: [bug#66650] [PATCH] git: Shell out to ‘git gc’ when necessary.

Ludovic Courtès writes: > Fixes . > > This fixes a bug whereby libgit2-managed checkouts would keep growing as > we fetch. > > * guix/git.scm (packs-in-git-repository, maybe-run-git-gc): New > procedures. > (update-cached-checkout): Use it. > --- > guix/git.sc

bug#22304: Julia

Just checking this, looks like 1.8.3 is still not reproducible, just one file differs though: → guix challenge --diff=simple julia /gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3 contents differ: no local build for '/gnu/store/h5mgc7ar7a05f9rwrd1makhzays5wd3s-julia-1.8.3' https://ci.g

bug#39310: MariaDB reproducibility issue

Ludovic Courtès writes: > Hi! > > Marius Bakke skribis: > >> Josh writes: >> >>> Hi Guix, >>> >>> I ran into this issue when building mariadb 10.1.38. I've attached the >>> last 300 lines of the log. Thanks >> >> I can reproduce this failure by checking out Guix 1.0.1 in a "time >> machine" an

bug#66997: nar-herder uses 10 GiB of resident memory, 100% CPU on hydra-guix-129

Maxim Cournoyer writes: > I was looking at top on the hydra-guix-129 node, which runs nar-herder, > and saw this: > > 4772 nar-her+ 20 0 28.9g 11.5g 100.0 6.1 55,55 S .nar-herder-rea > > 11.5 GiB of memory seems a bit excessive, no? Its cumulated processing > time is also at the top

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

The bordeaux build farm depends on computing the derivations on one machine, then potentially building them on a different machine. Some of the build machines don't have a new enough guix-daemon that understands builtin:git-download, so derivations that use this are sometimes failing (e.g. [1]) 1

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Simon Tournier writes: > Hi Chris, > > On Fri, 17 Nov 2023 at 21:39, Christopher Baines wrote: > >> The bordeaux build farm depends on computing the derivations on one >> machine, then potentially building them on a different machine. >> >> Some of the bu

bug#67305: Build bffe.x86_64-linux on master is broken.

Maxim Cournoyer writes: > Hi, > > cuir...@gnu.org (Cuirass) writes: > >> The build bffe.x86_64-linux for specification master is >> broken. You can find the detailed information about this build > href="https://ci.guix.gnu.org/build/2664791/details";>here. >> >> https://ci.guix.gnu.org/build/26

bug#67250: builtin:git-download capability detection not working for the bordeaux build farm

Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> The bordeaux build farm depends on computing the derivations on one >> machine, then potentially building them on a different machine. >> >> Some of the build machines don't have a n

bug#68561: Guix wrongfully claims there is no space left

Lars Rustand writes: > Guix is claiming that there is no space left on the device when none of > my devices are in fact full. As you can see from the output of df -h > there is more than enough space on all filesystems: > > > Filesystem Size Used Avail Use% Mounted on > none7.8

bug#68439: [bug#69793] [PATCH] gnu: icewm: Update to 3.4.6

Andy Tai writes: > * gnu/packages/wm.scm (icewm): Update to 3.4.6 > > Change-Id: Ieff1fc5417cfe164fa7886774e8855fd95248c8f > --- > gnu/packages/wm.scm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks both, I've pushed this to master as 8cc450e59a4c83fa39097964f62c2b2c84e0aee3

bug#70284: @ancronym not recognized as valid Texinfo in description

Maxim Cournoyer writes: > Hi, > > Using an acrynym such as @acronym(SNES, Super Nintendo Entertainment > System) currently throws an "invalid Texinfo markup" error at build > time. I think I've used acronyms in descriptions, seems like diffr in rust-apps uses one for example. The brackets are d

bug#70456: Request for merging "core-updates" branch

Hey, Thanks for raising this issue Steve, given the branch has been going for around 9 months (since [1]) now, I think it's well overdue to start looking at building and merging it. 1: https://lists.gnu.org/archive/html/guix-commits/2023-07/msg00332.html I pushed a single commit plus a merge fro

bug#70456: Request for merging "core-updates" branch

Christopher Baines writes: > I'm also really confused by what commits appear to be on the branch, > take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to be one > core-updates, but it's a duplicate of > e2a7c227dea5b361e2ebdbba24b923d1922a79d0 which was pushed

bug#70456: Status of ‘core-updates’

Ludovic Courtès writes: > What’s the status of ‘core-updates’? What are the areas where help is > needed? > > I know a lot has happened since the last update¹, which is roughly when > I dropped the ball due to other commitments, but I’m not sure where we > are now. I haven't really been followi

bug#70456: Request for merging "core-updates" branch

Maxim Cournoyer writes: > Hi, > > Christopher Baines writes: > >> Christopher Baines writes: >> >>> I'm also really confused by what commits appear to be on the branch, >>> take 12b15585a75062f3fba09d82861c6fae9a7743b2 which appears to b

bug#69466: Wrong colours for QA

Andreas Enge writes: > it looks like the dark green colour is wrongly chosen in QA, > for instance here: >https://qa.guix.gnu.org/issue/69441 > The issue has been reviewed, but "Comparison unavailable > Yet to process revision". > > I think dark green should only appear when the package is re

bug#69466: Wrong colours for QA

Andreas Enge writes: > Am Mon, Apr 22, 2024 at 05:27:58PM +0100 schrieb Christopher Baines: >> When implementing this I chose to have the review trump any other status >> since hopefully any failing builds will have been taken in to account by >> the reviewer. > > My

bug#70662: Problems building nss@3.98.0

nss@3.98.0 seems really difficult to build, currently on the bordeaux build farm it's failed all attempts to build it on all architectures except riscv64-linux and aarch64-linux [1]. 1: https://data.guix.gnu.org/revision/9593750698394b6fecd73e7fca00409ea1ffa2e3/package/nss/3.98.0?locale=en_US.UTF

bug#70663: nss@3.99 is really hard to build

nss@3.99 is really hard to build, it's so hard and so important that data.guix.gnu.org is still after two days trying to process [1]. I say so important because you have to build nss@3.99 to compute the channel instance derivations for Guix. 1: https://data.guix.gnu.org/revision/72308f262c910977e4

bug#70663: nss@3.99 is really hard to build

Christopher Baines writes: > nss@3.99 is really hard to build, it's so hard and so important that > data.guix.gnu.org is still after two days trying to process [1]. I say > so important because you have to build nss@3.99 to compute the channel > instance derivations for G

bug#70663: nss@3.99 is really hard to build

Maxim Cournoyer writes: > Hi Chris, > > Christopher Baines writes: > >> nss@3.99 is really hard to build, it's so hard and so important that >> data.guix.gnu.org is still after two days trying to process [1]. I say >> so important because you have to bu

bug#70456: Process gnome-team before core-updates

block 70456 by 70766 thanks I think being able to merge core-updates is still a few weeks away, so I think there's time to build and merge gnome-team without delaying core-updates. If it does become a problem, we can always switch approach and wait until after core-updates is merged to look at gn

bug#70838: guix pull fails

Simon Tournier writes: > I think ’nss’ is substitutable, so I guess you are rebuilding from > source, right? > > Well, the build of ’nss’ works for me. > > --8<---cut here---start->8--- > $ guix build /gnu/store/8379qa0y6s7ssjr8gplm5fyw9r5pnxhn-nss-3.99.0.drv

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

I've seen this when updating systems, but it seems like something is wrong with the handling of nss-certs. I'm on a guix revision with nss-certs by default, and when I add nss-certs to my system packages (to simulate not removing it when upgrading), it breaks certificates (e.g. wget https://guix.g

bug#70663: nss@3.99 is really hard to build

Christopher Baines writes: > nss@3.99 is really hard to build, it's so hard and so important that > data.guix.gnu.org is still after two days trying to process [1]. I say > so important because you have to build nss@3.99 to compute the channel > instance derivations for G

bug#70932: FAIL tests/guix-shell.sh

When attempting to update the guix package, I got this failure. The test log makes no sense though, as it's trying to test for errors, so I have no idea where to start in working out what is wrong. I thought maybe the issue was here: guix shell: error: package intelmetool@4.7 does not support a

bug#70663: nss@3.99 is really hard to build

Maxim Cournoyer writes: >> Before closing this bug, it would be good to understand more about how >> this happened and from that try to think if anything can be done to >> prevent similar issues in the future? >> >> At least from what I can see on the issues, the problem was introduced >> with th

bug#70663: nss@3.99 is really hard to build

"pelzflorian (Florian Pelz)" writes: > Hello Christopher. > > Christopher Baines writes: >> Had the changes waited for longer, then these failures should have been >> spotted by QA, I would guess that the revision might have failed to be >> processed, and

<    1   2   3