Bug#1078689: [DRE-maint] Bug#1078689: schleuder: autopkgtest is flaky, fails most of the time
Hi Alexandre, Thanks for your report. On 24-08-14 12:44:57, Alexandre Detiste wrote: > The autopkgtest is flaky and hinders the update of systemd-cron and > likely anything else that needs a cron-daemon. This seems to have started recently, in May -- I'm debugging why is that. For now, I've uploaded 4.0.3-13 which increases verbosity of the failing test and marks it as 'flaky' -- ideally the later should help systemd-cron to migrate. Cheers, Georg
Bug#1070077: [Pkg-privacy-maintainers] Bug#1070077: ships files directly in /usr/onionprobe
Hi, Thanks for the report. On 24-04-29 16:19:21, Antoine Beaupre wrote: > Package: onionprobe > Version: 1.0.0+ds-2.1+deb12u1 > Severity: serious > > The Debian package shipped in bookworm right now changed the path to > the examples/ directory. It used to be: > > /usr/lib/python3/dist-packages/onionprobe/examples/tpo.py > > and now seems to be: > > /usr/onionprobe/examples/tpo.py > > Apart from the gratuitous change, this seems to be a violation of the > FHS policy, packages shouldn't ship their own stuff directly under > /usr like this... Indeed -- I wasn't aware, or probably forgot, that bookworm is affected. Given the severity, this might warrant a bookworm-pu, I guess? > I haven't checked in unstable to see if this is fixed. This was reported via #1025508 and fixed in unstable via 1.1.2+ds-1. Cheers, Georg
Bug#1056594: [Pkg-privacy-maintainers] Bug#1056594: mat2: test failure
Hi Paul, On 24-01-01 10:24:46, Paul Gevers wrote: > On 01-01-2024 09:50, Paul Gevers wrote: > > I'm going to NMU with this patch shortly. @gregor, any reason why > > you didn't the upload to DELAYED after you built it already? > > I have uploaded the attached changes. Thanks for the upload, although I would have appreciated communication about this upfront. Could you please push the relevant changes to git? Thanks & all the best, Georg
Bug#1038935: [DRE-maint] Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='
Hi, On 23-06-27 09:05:43, Georg Faerber wrote: > Regarding the test: I'll seek comments of the Ruby team before filling > the -pu; I believe the risk of regressions should be fairly low, as > arel, as described, has been part of activerecord since quite some > time. I'll test this especially in combination with schleuder, which > exposed this issue; to ease future maintenance and increase the > chances of spotting these issues earlier, ideally before release, I > added a "piuparts multi distro upgrade" test job to the Salsa CI [1]. I was on the road the last weeks, therefore I was only able to mail the team by now. Cheers, Georg
Bug#1040257: schleuder-cli does not work with Ruby >= 3.0.0
Hi, Thanks for your report. On 23-07-03 23:50:03, s3lph wrote: > [...] > > Upstream has fixed the issue on the main branch, but has not yet > created a new release containing the fix. The fix is quite small, > only two lines diff: > > https://0xacab.org/schleuder/schleuder-cli/-/commit/68754cf94cc2d9b2a400ff19d2e48a7ffa2ec1f2 > > With this patch applied manually, schleuder-cli works as expected: > > [...] Indeed, I forgot to pull this into Debian, apologies for that. That's fixed now via 0.1.0-5. bookworm-pu is tracked via #1040791. Cheers, Georg
Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='
Hi, On 23-06-26 10:27:37, Antoine Beaupré wrote: > Just to make sure, someone still is working on this to make sure it's > fixed in bookworm? I'll take care of it. > I guess the first step is to wait for the package to transition to > trixie and then do the -pu? I suspect it will be hard to test this in > trixie since you'd need to upgrade from buster to trixie, right? Right, it needs some more days. CI reported regressions, which I believe are unrelated to the issue and hand the fix. As of now it should migrate within five days. Regarding the test: I'll seek comments of the Ruby team before filling the -pu; I believe the risk of regressions should be fairly low, as arel, as described, has been part of activerecord since quite some time. I'll test this especially in combination with schleuder, which exposed this issue; to ease future maintenance and increase the chances of spotting these issues earlier, ideally before release, I added a "piuparts multi distro upgrade" test job to the Salsa CI [1]. I'll keep this bug updated. Cheers, Georg [1] https://salsa.debian.org/ruby-team/schleuder/-/commit/08fd9a91a938346f5cad3cf216f8225b6f6cdd0e
Bug#1036950: schleuder: fails to upgrade from 'buster': insufficient dependency on ruby-activerecord (>= 2:6)
Hi, On 23-06-23 20:14:59, Georg Faerber wrote: > Unfortunately, up until now, there wasn't a proposed update targeting > bullseye. > > Andreas, how do you want to proceed? Do you have any spare cycles to > handle this? This would be great -- but please don't hesitate to tell me > if that's not the case, if so, I'll take over. The pu targeting bullseye is now tracked via #1039020. Cheers, Georg
Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='
Hi, On 23-06-24 14:58:21, Andreas Beckmann wrote: > Shouldn't these conflicts rather be in ruby-activerecord? Yes, I agree, that's the correct place. > As I understand the history, arel has been merged into activerecord (5 years > ago, probably version 6.0.x) and the "old" arel 9 is no longer compatible > with current activerecord 6.1.x. This is probably unrelated to schleuder > (which only exposes the bug). That's my understanding as well. > Interestingly this didn't happen on buster->bullseye upgrades, but perhaps > arel 9 was still compatible with activerecord 6.0.x. Yeah, I wondered about this also, but I'm unsure why is that, so far. > Should ruby-arel be RM:ed? > Note: one reverse build dependency > # Broken Build-Depends: > ruby-premailer-rails: ruby-arel Yes -- I sent a mail about this to the Ruby team, see [1] for details. > I'll give it a try... yes, the conflict against ruby-arel fixes the > upgrade path. Great, thanks. So, given the above, I believe this bug should be reassigned to ruby-activerecord, and schleuder should be marked as affected? Also, I guess, as this issue is not specific to schleuder, probably more packages which rely on ruby-activerecord are affected. I'll prepare a ruby-activerecord proposed-update targeting bookworm. Cheers, Georg [1] https://lists.debian.org/debian-ruby/2023/06/msg4.html
Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='
Control: tag -1 + patch Hi, Thanks for the report! On 23-06-23 11:20:28, Andreas Beckmann wrote: > Package: schleuder > > during a test with piuparts I noticed your package fails to upgrade > from 'buster' to 'bullseye' to 'bookworm'. > It installed fine in 'buster', and upgraded to 'bullseye' > successfully, but then the upgrade to 'bookworm' failed. I believe that's caused by ruby-arel, the attached patches fix the issue in my tests. Andreas, are you able to test these in your environment? All the best, Georg >From 45bc5cfff9adbacef1174d6bb9cd49ba8a90d860 Mon Sep 17 00:00:00 2001 From: Georg Faerber Date: Sat, 24 Jun 2023 00:14:47 + Subject: [PATCH 1/2] debian/control: add Conflicts: ruby-arel --- debian/control | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control b/debian/control index 0f08e89..80a6f0c 100644 --- a/debian/control +++ b/debian/control @@ -32,6 +32,7 @@ Rules-Requires-Root: no Package: schleuder Architecture: all +Conflicts: ruby-arel, Depends: adduser, cron | cron-daemon, default-mta | postfix | mail-transport-agent, -- 2.30.2 >From 009d8af740408deccafd477bbbeaf8eaa6d54ec1 Mon Sep 17 00:00:00 2001 From: Georg Faerber Date: Sat, 24 Jun 2023 00:15:10 + Subject: [PATCH 2/2] debian/changelog: Debian release 4.0.3-8 --- debian/changelog | 9 + 1 file changed, 9 insertions(+) diff --git a/debian/changelog b/debian/changelog index edb2aa8..9bda664 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +schleuder (4.0.3-8) unstable; urgency=medium + + * debian/control: +- Declare that schleuder conflicts with ruby-arel. Before, database + migration failed during an upgrade, if ruby-arel was installed. + (Closes: #1038935) + + -- Georg Faerber Sat, 24 Jun 2023 00:05:14 + + schleuder (4.0.3-7) unstable; urgency=medium * Team upload -- 2.30.2
Bug#1036950: schleuder: fails to upgrade from 'buster': insufficient dependency on ruby-activerecord (>= 2:6)
Control: tag -1 + confirmed bullseye Control: X-Debbugs-CC: gitcom...@henk.geekmail.org Hi, Thanks for reporting this, and sorry for my delay in answering: On 23-06-23 09:34:13, Andreas Beckmann wrote: > Followup-For: Bug #1036950 > Control: tag -1 patch > Control: retitle -1 schleuder: fails to upgrade from 'buster': insufficient > dependency on ruby-activerecord (>= 2:6) > > I'm currently testing the attached patch ... This makes sense -- thanks a lot. Actually, Hendrik Jäger (Cc:ed) reported this issue and provided a patch [1], which was uploaded to unstable on 2022/12/26 via 4.0.3-7. After a review of the patch, I also noticed this only targeted Build-Depends, but not Depends. Unfortunately, up until now, there wasn't a proposed update targeting bullseye. Andreas, how do you want to proceed? Do you have any spare cycles to handle this? This would be great -- but please don't hesitate to tell me if that's not the case, if so, I'll take over. Also, another, related question, looking at #1038935, which will require an update targeting bookworm: I assume, as Debian, qua definition, only supports upgrades from one release to the next, fixing the ruby-activerecord issue in bullseye is sufficient? All the best, Georg [1] https://salsa.debian.org/ruby-team/schleuder/-/commit/307f8f5e4125dec9d3a9b2bce5a721394c9657fa
Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...
Hi nodens, On 22-10-25 09:16:29, Clément Hermann wrote: > Do you mind if I cherry-pick the upstream fix and upload today ? > This is blocking the perl 5.36 transition. I do not, please do, and thanks in advance. Please push your changes, including the tag. Cheers, Georg
Bug#1019682: [DRE-maint] Bug#1019682: Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty
Hi, After further debugging, I've now got the following backtrace: a bounce message is received :85:in `require': cannot load such file -- charlock_holmes (LoadError) from :85:in `require' from /<>/lib/schleuder/cli.rb:4:in `' from :85:in `require' from :85:in `require' from bin/schleuder:12:in `' from bounce example However, the following works as expected # ruby -v -e "require 'charlock_holmes'; puts CharlockHolmes::VERSION" ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux-gnu] 0.7.7 so I'm still at loss. Cheers, Georg
Bug#1019682: [DRE-maint] Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty
Control: tags -1 + help Hi Antonio, all, Thanks for your report. I had a look, and I'm able to reproduce locally if building the package, although so far I haven't been able to find out what is causing this. I would be happy if someone is able to support me in debugging this. Looking at [1], which fails in the same way, I noticed: Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine bcrypt --version 3.1.17 Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem pristine charlock_holmes --version 0.7.7 Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine debug --version 1.4.0 Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs --version 2.1.0 Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine sdbm --version 1.0.0 Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine thin --version 1.8.0 Ignoring bcrypt-3.1.17 because its extensions are not built. Try: gem pristine bcrypt --version 3.1.17 Ignoring charlock_holmes-0.7.7 because its extensions are not built. Try: gem pristine charlock_holmes --version 0.7.7 Ignoring debug-1.4.0 because its extensions are not built. Try: gem pristine debug --version 1.4.0 Ignoring rbs-2.1.0 because its extensions are not built. Try: gem pristine rbs --version 2.1.0 Ignoring sdbm-1.0.0 because its extensions are not built. Try: gem pristine sdbm --version 1.0.0 Ignoring thin-1.8.0 because its extensions are not built. Try: gem pristine thin --version 1.8.0 Some of these are direct dependencies of Schleuder. I'm mentioning this, because some days ago, [2] reported different errors: Failure/Error: require 'thin' LoadError: cannot load such file -- thin To make all of this even more interesting: [3] reports no errors. I'm wondering if different build environments are of relevance here. Any clue, anyone? Thanks in advance, all the best, Georg [1] https://buildd.debian.org/status/fetch.php?pkg=schleuder&arch=all&ver=4.0.3-4.1&stamp=1666457954&raw=0 [2] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/schleuder.html [3] https://ci.debian.net/data/autopkgtest/unstable/amd64/s/schleuder/27432900/log.gz
Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...
Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/178 Control: tags -1 + fixed-upstream upstream Hi Paul, On 22-10-13 19:52:35, Paul Gevers wrote: > With a recent upload of libimage-exiftool-perl the autopkgtest of mat2 > fails in testing when that autopkgtest is run with the binary packages > of libimage-exiftool-perl from unstable. Thanks for your report. Cheers, Georg
Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})
Hi Utkarsh, Thanks for your upload. Could you please push the changes you did to the git repo? Thanks, cheers, Georg
Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: marked as done (mat2: FTBFS: AssertionError: 'TransparentColor' not found in {})
Hi Utkarsh, Thanks for your upload. Could you please push the changes you did to the git repo? Thanks, cheers, Georg
Bug#1002622: schleuder: ActiveRecord >= 6.0 changes boolean serialization, makes existing mailing lists fail
Package: schleuder Version: 3.6.0-3 Severity: grave Justification: renders package unusable Forwarded: https://0xacab.org/schleuder/schleuder/-/issues/505 Tags: fixed-upstream Since ActiveRecord >= 6.0, the SQLite3 connection adapter relies on boolean serialization to use 1 and 0, but does not natively recognize 't' and 'f' as booleans were previously serialized. This change made existing mailing lists fail, after people upgraded buster to bullseye, due to the involved ActiveRecord version bump, as Schleuder isn't able anymore to fetch correct values from the database. Unfortunately, we missed this breaking change when bumping ActiveRecord to >= 6.0 recently. This caused quite some work upstream, but also in downstream environments and, last but not least, at the side of users. We should extend our CI to explicitly test, and ensure things work as expected, if running a Schleuder setup in real world. As of now, we don't ensure data provided by a user in Schleuder version x still works after upgrading to version y.
Bug#1002418: [Pkg-privacy-maintainers] Bug#1002418: mat2: FTBFS: AssertionError: 'TransparentColor' not found in {}
Control: affects -1 libimage-exiftool-perl Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/162 -- Hi Lucas, On 21-12-22 09:13:25, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Thanks for reporting, the error is caused by libimage-exiftool-perl >= 12.37+dfsg-1. I've forwarded this upstream. Cheers, Georg
Bug#980194: [Pkg-privacy-maintainers] Bug#980194: Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised
Hi Paul, On 21-01-15 22:57:54, Georg Faerber wrote: > I'm wondering if this is related to the recent upload of media-types > [1]. > > This test [2], which installed media-types 1.0.1, was successful, > whereas the test [3], which installed media-types 1.1.0, wasn't. I've requested a test [1] in testing with media-types from unstable, which was successful. The problem seems a regression in media-types, which is fixed in media-types >= 3.0.0. Given this, is there anything else required from my side? Cheers, Georg [1] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9735398/log.gz
Bug#980194: [Pkg-privacy-maintainers] Bug#980194: mat2: autopkgtest regression in testing: AssertionError: ValueError not raised
Hi Paul, Thanks for telling! On 21-01-15 22:09:18, Paul Gevers wrote: > With a very recent change in testing the autopkgtest of your package > started to fail. I copied some of the output at the bottom of this > report. Can you please investigate the situation and fix it? I'm wondering if this is related to the recent upload of media-types [1]. This test [2], which installed media-types 1.0.1, was successful, whereas the test [3], which installed media-types 1.1.0, wasn't. Cheers, Georg [1] https://tracker.debian.org/news/1208854/accepted-media-types-110-source-into-unstable/ [2] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9452897/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/9663226/log.gz
Bug#976270: [Pkg-puppet-devel] Bug#976270: Bug#976270: ruby-puppet-forge: autopkgtest/ftbfs with ruby-faraday-middleware 1.x
Hi, On 20-12-03 14:19:00, Pirate Praveen wrote: > Added Breaks, but we may need to request removal from testing to allow > ruby-faraday to migrate. I would like to keep it in testing, as it's a dependency of r10k. Cheers, Georg
Bug#975533: [Pkg-privacy-maintainers] Bug#975533: mat2's autopkg tests fail with Python 3.9
Hi nicoo, On 20-12-14 15:57:10, nicoo wrote: > There doesn't seem to be anyone else handling the mat2 RC bug (FTBFS & > autopkgtest failure) so I will do it. I'm well aware and will handle this accordingly once there is a new upstream release, which should happen soon. Cheers, Georg
Bug#951225: marked as pending in schleuder
Control: tag -1 pending Hello, Bug #951225 in schleuder reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/ruby-team/schleuder/commit/033760b58aa9d2e8f6121fa5609a393e308c5aa4 debian/patches: Relax dependency on sqlite3 in gemspec Closes: #951225 (this message was generated automatically) -- Greetings https://bugs.debian.org/951225
Bug#949824: [DRE-maint] Bug#949824: schleuder: tests fail with ruby-sqlite 1.4.2-1
Control: Tags -1 + confirmed upstream Control: Forwarded -1 https://0xacab.org/schleuder/schleuder/issues/453 Hi, On 20-01-25 09:58:22, Antonio Terceiro wrote: > I'm about upload ruby-sqlite3 1.4.2-1, and schleuder now fails its > tests on the dependency resolution step. > > [...] > > I tried hacking it locally, and just changing ~> to >= makes it work, > and all the tests pass. Please consider making the dependency check > less strict. Thanks for reporting -- confirmed, will be fixed upstream. Cheers, Georg
Bug#949252: [Pkg-privacy-maintainers] Bug#949252: mat2: autopkgtest needs update for new version of libimage-exiftool-perl
Control: tags -1 + confirmed upstream Control: Forwarded -1 https://0xacab.org/jvoisin/mat2/issues/136 Hi Paul, On 20-01-18 22:09:54, Paul Gevers wrote: > With a recent upload of libimage-exiftool-perl the autopkgtest of mat2 > fails in testing when that autopkgtest is run with the binary packages > of libimage-exiftool-perl from unstable. > > [...] Thanks for reporting, confirmed. We'll fix this upstream. Cheers, Georg
Bug#939630: [DRE-maint] Bug#939630: schleuder: breaks testbed?
control: tags -1 confirmed pending Hi Gianfranco, Thanks for your report. On 19-09-07 08:16:22, Gianfranco Costamagna wrote: > looks like you are playing with /dev/random removing and symlinking it > again. > > This might break the test environment, so I would say we should > > 1) declare the test as breaks-testbed [1] > > or > > 2) stop doing that. > > I tried to remove that if statement in Ubuntu, and the testsuite ran > successfully everywhere, including armhf. > > I discovered that issue, because in armhf the rm was failing because > of "dev/random" busy issues. > > you can see my "ubuntu3" upload, and the various test results if you > want more information > http://autopkgtest.ubuntu.com/packages/s/schleuder/eoan/armhf Agreed -- I've just uploaded 3.4.0-4 which drops this workaround. Lets see how this goes, I'll update this bug soonish once there are some tests made. Cheers, Georg
Bug#921637: [DRE-maint] Bug#921637: FTBFS: /usr/lib/ruby/vendor_ruby/ronn/roff.rb:165:in `block_filter': undefined method
Control: tags + confirmed pending On 19-02-23 20:24:15, brian m. carlson wrote: > It would be great if we could get this patch into buster. [...] Upload, including the patch, upcoming in the next days. Cheers, Georg signature.asc Description: Digital signature
Bug#919072: schleuder: FTBFS in both buster and sid
Control: reopen -1 Control: found -1 3.3.0-7 Hi, I've just uploaded 3.3.0-7, which, three times in a row, built fine on my local machine prior to the upload. On 19-01-12 13:26:16, Santiago Vila wrote: > Failures: > > 1) user sends a plain text message from thunderbird being signed-inline > Failure/Error: expect(error).to be_empty >expected `"Error: A serious, unhandleable error happened. Please > contact the administrators of this system or service and provide them with > the following information:\n\ninvalid byte sequence in US-ASCII\n".empty?` to > return true, got false > # ./spec/schleuder/integration/send_plain_spec.rb:18:in `block (3 > levels) in ' > # ./spec/spec_helper.rb:47:in `block (3 levels) in ' > # ./spec/spec_helper.rb:46:in `block (2 levels) in ' > > [...] However, it seems, this error still happens (sometimes?) [1]. In any case: two done, one more to go.. :) Cheers, Georg [1] https://salsa.debian.org/ruby-team/schleuder/pipelines/35065 signature.asc Description: Digital signature
Bug#918569: Could not find 'activerecord' (~> 4.2) - did find: [activerecord-5.2.0]
Hi Pirate, On 19-01-07 19:13:39, Pirate Praveen wrote: > Currently rails 5.2 is in unstable and schleuder autopkgtest is > failing (it is causing a delay in rails 5 migration to buster). Please > fix it so we can get rails 5 into buster. I'm back from traveling, and just uploaded 3.3.0-7 containing a fix. Sorry that this took so long.. :( Cheers, Georg signature.asc Description: Digital signature
Bug#913843: [DRE-maint] Bug#913843: ruby-mail-gpg FTBFS with gpgme 1.12.0
Control: severity -1 important Will take care of this (non-critical) bug at the end of January; I'm currently on travel. Up until then, downgrading the severity to prevent autoremoval. Cheers, Georg signature.asc Description: Digital signature
Bug#910376: mat2: Incomplete debian/copyright?
Hi all, On 18-10-07 16:00:06, intrigeri wrote: > Georg Faerber: > > Currently, we don't ship the logo, but I'm unsure if this matters? > > We do ship the logo in the source package so it does matter :) Alright -- I'll fix this once the current state is clarified upstream, see the corresponding issue over there. Cheers, Georg signature.asc Description: Digital signature
Bug#910376: mat2: Incomplete debian/copyright?
Hi Chris, Thanks for reporting. On 18-10-05 17:31:50, Chris Lamb wrote: > I just ACCEPTed mat2 from NEW but noticed it was missing attribution > in debian/copyright for at least a certain "Marie Rose". > > This is in no way exhaustive so please check over the entire package > carefully and address these on your next upload. Currently, we don't ship the logo, but I'm unsure if this matters? Cheers, Georg signature.asc Description: Digital signature
Bug#890751: rake FTBFS with Ruby 2.5: cannot load such file -- ubygems (LoadError)
I'll work on this today. Cheers, Georg signature.asc Description: Digital signature
Bug#892507: [DRE-maint] Bug#892507: ruby-sequel FTBFS with Ruby 2.5
On 18-03-09 23:13:27, Adrian Bunk wrote: > Source: ruby-sequel > Version: 4.37.0-1 > Severity: serious > Tags: buster sid I'll work on this today. Cheers, Georg signature.asc Description: Digital signature
Bug#888189: [DRE-maint] Bug#888189: ruby-innertube: FTBFS on ruby2.5: undefined method mock
On 18-01-23 20:31:56, Chris West (Faux) wrote: > This package fails to build against ruby2.5. Soon, there will be a > transition to ruby2.5, and this package will FTBFS in sid. Upstream seems rather dead, popcon lists 11 installations. @Héctor: You've tagged this help: Are you using it personally, or DSA? Cheers, Georg signature.asc Description: Digital signature
Bug#890954: closed by Michael Gilbert (Bug#890954: fixed in chromium-browser 65.0.3325.146-2)
Hi, I can confirm this works now. Thanks for the work, Michael! Cheers, Georg signature.asc Description: Digital signature
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Hi Roger, Not the maintainer here, but: On 17-08-31 20:10:35, Roger Shimizu wrote: > Is it time to upload backports of 0.2.7-3 to stretch? No: Packages need to be first in testing, before going into -backports. > I'm also wondering why it didn't hit testing yet. Read this bug report for some reasons. Cheers, Georg signature.asc Description: Digital signature
Bug#867031: marked as pending
tag 867031 pending thanks Hello, Bug #867031 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-ruby-extras/schleuder.git/commit/?id=08774fe --- commit 08774fe9924e4f8d5339702adfbd424231fef10a Author: Georg Faerber Date: Thu Jul 13 13:45:49 2017 +0200 debian/changelog: Debian release 3.1.2-1 diff --git a/debian/changelog b/debian/changelog index 2c7708e..1513498 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,21 @@ +schleuder (3.1.2-1) unstable; urgency=medium + + * New upstream release. + * debian/copyright: +- Bump years to include 2017. +- Fix upstream source location. + * debian/control: Bump required rake version to >= 12~. + * debian/schleuder.preinst: +- Check for existing schleuder < 3.0 data first, before doing the backup. +(Closes: #867031) +- Don't use 'echo' to inform the user about the data migration process, +but instead via a proper NEWS file. + * debian/NEWS: Add said file with notes on how to migrate schleuder < 3.0 +data. + * debian/patches/0003-bin-fix-require.patch: Refresh for 3.1.2-1. + + -- Georg Faerber Thu, 13 Jul 2017 13:40:47 +0200 + schleuder (3.1.1-1) unstable; urgency=medium * New upstream release.
Bug#849308: wireguard: Wireguard should not transition to stable yet
Hi, I would like to see wireguard right now in buster. Even if the on-wire format should change in the future, it would be still worth it, IMHO. Buster is the 'testing' suite - so let's just do that: let's test and get this into testing. Sometimes testing breaks, which is expected, but most of the time it works. I doubt that there would be a major difference in this case. Thanks for consideration and your work, cheers, Georg signature.asc Description: Digital signature
Bug#867643: [DRE-maint] Bug#867643: schleuder: FTBFS: ERROR: Test "ruby2.3" failed: Failure/Error: expect(output).to include("98769E8A1091F36BD88403ECF71A3F8412D83889 was fetched (new key)")
On 17-07-08 21:05:36, Lucas Nussbaum wrote: > On 08/07/17 at 19:37 +0200, Georg Faerber wrote: > > Unfortunately, I can't reproduce this locally. Besides the sbuild > > options used which are shown in the log file, is there a .sbuildrc in > > place, with non-default options? If so, could you share it? > > Have you tried diffing your log with mine? Not yet, but all the tests work for me. I strongly suspect gnupg2 / dirmngr to cause trouble, I'm however unsure, how to reproduce that. > > Additionally, I've got a question regarding the network configuration of > > the VM on which the build was run: At the moment of the build, were the > > only configured network interfaces localhost and / or loopback? > > no. Hm, alright. I've suspected [1] to apply here as well, but it seems there has to be a different problem. > Also, I've just tried on another machine (that has Internet access). In > that case the test suite hangs at: > > user sends a plain text message > from thunderbird > > Schleuder::ListBuilder That sounds like low entropy: Ensure that haveged is running or that the entropy pool is filled via some other technique / method. Cheers, Georg [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856152 signature.asc Description: Digital signature
Bug#867643: [DRE-maint] Bug#867643: schleuder: FTBFS: ERROR: Test "ruby2.3" failed: Failure/Error: expect(output).to include("98769E8A1091F36BD88403ECF71A3F8412D83889 was fetched (new key)")
Hi, Unfortunately, I can't reproduce this locally. Besides the sbuild options used which are shown in the log file, is there a .sbuildrc in place, with non-default options? If so, could you share it? Additionally, I've got a question regarding the network configuration of the VM on which the build was run: At the moment of the build, were the only configured network interfaces localhost and / or loopback? Thanks, Georg signature.asc Description: Digital signature
Bug#867643: [DRE-maint] Bug#867643: schleuder: FTBFS: ERROR: Test "ruby2.3" failed: Failure/Error: expect(output).to include("98769E8A1091F36BD88403ECF71A3F8412D83889 was fetched (new key)")
Hi Lucas, Thanks for the report: On 17-07-08 08:28:30, Lucas Nussbaum wrote: > > [...] > > About the archive rebuild: The rebuild was done on EC2 VM instances > from Amazon Web Services, using a clean, minimal and up-to-date > chroot. Every failed build was retried once to eliminate random > failures. Was a wrapper used, like pbuilder or sbuild? Thanks, Georg signature.asc Description: Digital signature
