Re: please give back sollya on amd64
Hi Jerome, On Sat, Apr 23, 2022 at 11:45:00AM +0200, Jerome BENOIT wrote: > Sollya 8.0+ds-1 is actually prevented from migration because > it was not built on buildd for arch 64. I have to submit first > this package to the NEW queue. > > gb sollya_8.0+ds-1 . amd64 "gb" is the wrong command, that's only used for failed builds. You'd need a full binNMU instead. Either way, that would be useless, because then you'd still be stuck with the maintainer uploaded arc:all binary. So you need to do a full sourceful upload instead, just upload a -2. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#1003814: dpkg-repack: build profile with a slash breaks dose-builddebcheck
Control: severity -1 critical
On Sun, Jan 16, 2022 at 06:45:06AM +0100, Helmut Grohne wrote:
> As a consequence, rebootstrap and debcheck
> (https://qa.debian.org/dose/debcheck/src_unstable_main/) are broken.
> Given that the autobuilder is stuck on 1.48, I guess it also broke
> buildd.d.o.
Mostly because of buildd.d.o, I'm bumping the severity quite a bit.
aurel32 hammered w-b so that it skips dpkg-repack in the meantime.
https://salsa.debian.org/wb-team/wanna-build/-/commit/f737db3
> $Something will have to change. Either we revert the build profile or we
> fix dose to handle this situation. This bug can be reassigned to the
> proper place if necessary, but it tracks the need for change.
I'd say a revert is the best first step in this case, until dose in
stable (or at least stable-backports I guess. And oldstable since
plenty of d.o infra is still not updated) supports this notation.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: "all"packages not identified as needs-build
On Sun, Jan 16, 2022 at 04:15:28AM +, Scott Kitterman wrote: > I uploaded a new postfix (3.6.4-1) and while the packages for the > architecture specific packages are built and installed, the arch all > build hasn't even registered that there's a build needed. I checked > and I didn't see any needs-build packages for "all", so I'm wondering > if I screwed something up or if there's a more general issue? That's probably due to https://bugs.debian.org/1003814 that appears to have broken dose and therefore wanna-build. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Please give back acl2 on armhf
Done!
On Sun, Oct 10, 2021 at 4:37 PM Camm Maguire wrote:
>
> Greetings, and thank you so much for your reply! Most happy to wait on
> salsa-admin. In the meantime, I have committed a fix in gcl for this
> issue -- would you please mind hitting the giveback button for me again
> once gcl-2.6.12-104 is installed?
>
> Take care,
>
> Mattia Rizzolo writes:
>
> > On Sun, Oct 03, 2021 at 07:12:19PM -0400, Camm Maguire wrote:
> >> Mattia Rizzolo writes:
> >> > On Sun, Oct 03, 2021 at 01:49:04PM -0400, Camm Maguire wrote:
> >> >> Greetings, and thanks for your reply! When I do, I am asked for salsa
> >> >> login credentials. Apparently my automatically created account was
> >> >> disabled due to non-use a year ago. I've requested activation on #salsa
> >> >> and salsa-ad...@debian.org to no effect. Just tried registering fresh
> >> >> with a new username and email address, and am awaiting administrator
> >> >> confirmation. Am I overlooking anything?
> >> >
> >> > AFAIK it would anyway require to be a DD, so it wouldn't work.
> >>
> >> I am a DD, but it does not appear I have a working salsa login. I would
> >> like to get that working so I could give back packages without bothering
> >> anyone. Might you be able to advise me on that?
> >
> > Oh, sorry. I did a lookup on your email address, but didn't yield any
> > result because that address is not in a uid of your gpg key, nor was it
> > used "recently" in any upload.
> >
> > Anyway, salsa accounts of DDs have been disabled for all those DDs that
> > didn't activate theirs within 2 years after salsa was created.
> > Only the salsa admins can re-enable those accounts, and ttbomk, the way
> > is to mail salsa-ad...@debian.org like you said you already did.
> > Registering a new account won't probably help anyway, since your @d.o
> > address is tied to the deactivated one, and moving the address still
> > require admin intervention which then leads to the same situation of
> > waiting on them (furthermore the "DD status" of a salsa account actually
> > comes from nm.debian.org and their linking. re-linking your nm.d.o
> > account to a new salsa account has some rought edges that can also
> > require a nm.d.o admin ("Front Desk") to manually set it up; so you'll
> > then still have to nudge plenty of people to get it done).
> >
> >
> > I see you asked in #salsa on IRC 3 days ago, and I have to suppose you
> > mailed them around the same time. Since you have been without salsa for
> > more than 3 years already perhaps you can give the salsa admins more
> > time to react?
>
> --
> Camm Maguirec...@maguirefamily.org
> ==
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
--
regards,
Mattia Rizzolo
GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
Re: Please give back acl2 on armhf
On Sun, Oct 03, 2021 at 07:12:19PM -0400, Camm Maguire wrote:
> Mattia Rizzolo writes:
> > On Sun, Oct 03, 2021 at 01:49:04PM -0400, Camm Maguire wrote:
> >> Greetings, and thanks for your reply! When I do, I am asked for salsa
> >> login credentials. Apparently my automatically created account was
> >> disabled due to non-use a year ago. I've requested activation on #salsa
> >> and salsa-ad...@debian.org to no effect. Just tried registering fresh
> >> with a new username and email address, and am awaiting administrator
> >> confirmation. Am I overlooking anything?
> >
> > AFAIK it would anyway require to be a DD, so it wouldn't work.
>
> I am a DD, but it does not appear I have a working salsa login. I would
> like to get that working so I could give back packages without bothering
> anyone. Might you be able to advise me on that?
Oh, sorry. I did a lookup on your email address, but didn't yield any
result because that address is not in a uid of your gpg key, nor was it
used "recently" in any upload.
Anyway, salsa accounts of DDs have been disabled for all those DDs that
didn't activate theirs within 2 years after salsa was created.
Only the salsa admins can re-enable those accounts, and ttbomk, the way
is to mail salsa-ad...@debian.org like you said you already did.
Registering a new account won't probably help anyway, since your @d.o
address is tied to the deactivated one, and moving the address still
require admin intervention which then leads to the same situation of
waiting on them (furthermore the "DD status" of a salsa account actually
comes from nm.debian.org and their linking. re-linking your nm.d.o
account to a new salsa account has some rought edges that can also
require a nm.d.o admin ("Front Desk") to manually set it up; so you'll
then still have to nudge plenty of people to get it done).
I see you asked in #salsa on IRC 3 days ago, and I have to suppose you
mailed them around the same time. Since you have been without salsa for
more than 3 years already perhaps you can give the salsa admins more
time to react?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Please give back acl2 on armhf
On Sun, Oct 03, 2021 at 01:49:04PM -0400, Camm Maguire wrote:
> Greetings, and thanks for your reply! When I do, I am asked for salsa
> login credentials. Apparently my automatically created account was
> disabled due to non-use a year ago. I've requested activation on #salsa
> and salsa-ad...@debian.org to no effect. Just tried registering fresh
> with a new username and email address, and am awaiting administrator
> confirmation. Am I overlooking anything?
AFAIK it would anyway require to be a DD, so it wouldn't work.
At any rate, I gave it back 4 hours ago, and the second build already
completed and failed, is that enough for you?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Build failure for Yoshimi soft synth
Hi!
On Mon, Mar 22, 2021 at 09:38:43PM +, Will Godfrey wrote:
> I hope I've come to the right place for this. If not please redirect.
It's not, but nevermind in this one case.
> For kfreebsd Yoshimi has been marked as unistallable for some time due to a
> claimed dependency on libboost-dev.
>
> This is not correct. We removed all reference to boost 2017-9-27 as reported
> in
> our changelog.
The build-dependency comes from the package itself, which means the
proper place to report this would have been a bug report against the
package.
Anyway, I'm part of the team that maintains it, so I went ahead and
removed the build-dep (after confirming that the build was the same
after removing it).
https://salsa.debian.org/multimedia-team/yoshimi/-/commit/d792d6352519fec34bc0d031793be420fc325661
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Fwd: Build Timeouts for bazel-bootstrap on mips64el and riscv64
On Thu, Jan 28, 2021 at 09:22:49PM -0500, Olek Wojnar wrote: > Apologies if my previous email to the mips64el and riscv64 @buildd.d.o > lists went to the wrong group. They probably weren't, tbh. > On Sun, Jan 24, 2021 at 2:06 PM Olek Wojnar wrote: > > > Greetings, > > > > The bazel-bootstrap package seems to build very slowly on these two > > architectures and is timing out on the buildds. I've tested in Docker > > locally and the build can take 5-7 hours, and there's one point where there > > is no screen output for a few hours (but the build continues normally after > > that). You'll need to fix this. gcc somewhere has one thing that makes it output something (a dot IIRC) every few minutes in the steps where it might get stuck for a while. However, if you do that do make very very sure you don't make it deadlock in that part… > > Could you please increase the timeout value for this package on both of > > these architectures? 4 hours should be safe. I believe it will build > > correctly with that change. AFAIK there are no per-package timeouts (it's a buildd-level setting), so it's not possible. TBH, i'd just consider excluding these archs from the package if they don't carry any special value to you. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Build failure because python3 isn't found
You don't have a build-depends on python3, so where is your surprise?.. It seems to me that a makefile from that package is using python3 directly. Probably something else before was pulling it in (same in your chroot...) And now it isn't anymore. That's a RC bug waiting to be filed. On Sat, 19 Sep 2020, 8:33 pm Julien Puydt, wrote: > Hi, > > I was surprised to see my recent upload of giac fail on most > architectures: >https://buildd.debian.org/status/package.php?p=giac > > It turned out that the common issue was: >python3: No such file or directory > > This is especially strange since : > > - I use a schroot build to check for missing b-deps (but perhaps my > schroot isn't that clean?) : worked. > > - I since tried to build my package in schroot on two porterbox > machines (barriere for amd64 and abel for armhf) : worked. > > So I'm wondering if for some reason my package was built at a crucial > moment when something was amiss (in which case re-triggering the build > will solve the issue) or if there's really something fishy I should > investigate and solve? > > Cheers, > > JP > >
Re: build status of pyhst2
On Wed, Sep 16, 2020 at 04:13:31PM +0200, picca wrote:
> Hello, I have some difficulties to understand why the pyhst2 package does
> not build on buildd
>
> https://buildd.debian.org/status/package.php?p=pyhst2
>
> It seems that nvidia-cuda-toolkit is missing, but
The non-free component is not available in the buildds (for legal
reasons; non-free licenses might include clauses preventing, for
example, to link against them or re-distribute the resulting linked
binaries, etc etc).
You'll need to manually build that package and upload the resulting
binary.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: liboauth2 buildd error on almost all architectures
Hi, On Sun, Sep 13, 2020 at 10:57:35AM -0400, Nicolas Mora wrote: > I believe this is a false positive due to the timeout issue in the > dh_auto_test step. I'm bemused you believe it's a timeout. From the amd64 log: 86%: Checks: 74, Failures: 8, Errors: 2 ... test/check_jose.c:367:F:core:test_jwks_resolve_uri:0: Assertion 'list != ((void *)0)' failed: list == 0, ((void *)0) == 0 ... test/check_http.c:623:F:core:test_http_get:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 test/check_http.c:655:F:core:test_http_post_form:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 ... test/check_proto.c:287:F:core:test_proto_ropc:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 ... test/check_oauth2.c:606:F:core:test_oauth2_verify_jwks_uri:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 test/check_oauth2.c:645:F:core:test_oauth2_verify_eckey_uri:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 test/check_oauth2.c:674:F:core:test_oauth2_verify_token_introspection:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 ... test/check_oauth2.c:891:F:core:test_oauth2_verify_token_metadata:0: Assertion 'rc == 1' failed: rc == 0, 1 == 1 ... test/check_openidc.c:664:E:core:test_openidc_handle_cookie:0: (after this point) Test timeout expired test/check_openidc.c:664:E:core:test_openidc_handle_cache:0: (after this point) Test timeout expired ... So it's 8 actual failures and only 2 timeouts. And looking at the debugging bits before that summary doesn't look at all like a timeout to me. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: [p-a-s/sid] Allow fdflush to build on amd64
Hi, I can't help bug ask, but… > aboot: alpha # alpha > boot loader > %arcboot: mips # > mips boot loader > -fdflush: alpha i386 # > i386/alpha specific > +fdflush: alpha amd64 i386 # > amd64/i386/alpha specific > %gpart: i386 hurd-i386 ia64 alpha arm armel mipsel amd64 # little > endian specific > %libgcr410: i386 amd64 # > [ANAIS] > %linux-wlan-ng: amd64 i386 powerpc arm armel armhf alpha hppa lpia # > ANAIS [?] why not just use the proper Architecture: line in those packages, instead of keeping this (for many newer people little known) list? I can barely understand the negative entries (like the !s390x for xorg-*), but for everything else it makes little sense to me. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#940144: developers-reference: document self-service givebacks in wanna-build section
On Tue, Jan 21, 2020 at 09:20:54PM +0100, Philipp Kern wrote:
> That being said, tracker, nm and contributors already moved to request
> client certificates on the main host.
In their case it didn't really change anything, since they had the
client certificate bit in their section.
> And yes, the correct approach would be something like OAuth2. Or use
> client certificates with some sort of CLI. :/
Then get the sso.d.o team to do that, in a sane way. We are still
waiting for an interface to register guest accounts, that has been ready
for more than a year now but apparently has trouble being deployed.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Please remove extra Dep-Wait on mipsel
>
> because of the update of libglvnd/mesa/qt5, some packages failed to
> build, and were given a Dep-Wait on the newer qtbase-opensource-src.
> The fixed version was already built and installed yesterday, however
> the packages are still stuck with the Dep-Wait. Can you please remove
> it for the following packages:
> - trace-cmd
> - gmic
> - kate
> - sigil
> - vtk-dicom
> - seafile-client
FWIW, this is because the dep-wait was added against the source package
(qtbase-opensource-src) instead of a binary package (such as
qtbase5-dev)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: please give back nqp on mipsel
On Sun, Oct 20, 2019 at 02:19:07PM +0200, Robert Lemmen wrote: > thanks for the give-back, but I didn't see any change. I also tried the > self-service interface you helpfully pointed out, which seems to have > worked (it says "Successfully given back the package"), yet I don't see > any change on e.g. > https://buildd.debian.org/status/architecture.php?a=mipsel&suite=experimental. > I was expecting it to go back to "needs build", am I mistaken there? So are you looking to give-back the experimental build? You never said so, and even the version you specified in the first email is the one in sid. Indeed the version in unstable has been retried 7 times now: https://buildd.debian.org/status/logs.php?pkg=nqp&ver=2019.07.1%2Bdfsg-2&arch=mipsel I've now given back the version in experimental as well, though it doesn't make sense since it's older than the one in unstable… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: please give back nqp on mipsel
On Fri, Oct 18, 2019 at 07:54:29PM +0200, Robert Lemmen wrote:
> Could you please
>
> gb nqp_2019.07.1+dfsg-1 . mipsel
done
(https://lists.debian.org/debian-devel-announce/2019/08/msg3.html)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Please give back rlottie on mipsel and powerpc
On Wed, Sep 25, 2019 at 05:36:25PM +0300, Коля Гурьев wrote:
> I discovered that if rlottie in the current state is build against
> recent glibc (= 2.29-2), the rlottie package passes all its auto-tests.
Interesting.
> Please rebuild rlottie on mipsel and powerpc again.
>
> gb rlottie_0~git20190721.24346d0+dfsg-2 . mipsel powerpc
✓
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: multi-arch:same failures when bin-nmus changelog dates are not the same
On Thu, Mar 29, 2018 at 04:41:50PM +0100, Wookey wrote: > On 2018-03-29 14:41 +0200, Jean-Michel Vourgère wrote: > > The problem is that pod2man uses the changelog date to generate the man > > footer, and that date is no longer the same on all architectures ! > > Don't do that. It's a reproducibility failure as well as breaking > multi-arch co-installability. > > > Please advise how to proceed! > > I'm surprised the reproducibility people have not nobbled pod2man to > stop this behaviour already. Is there a bg about it somewhere? We met a lot of push backs when originally we were trying to *remove* as many datetimes as possible. Since then we found it was much easier to ask people to programatically set those datetimes to the value of SOURCE_DATE_EPOCH, which in Debian we set to the time in the topmost pargraph of d/changelog. pod2man has been patched exactly to that goal, and it does make rrdtools reproducible indeed. I don't have an opinion on how to best approach this issue. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: mariadb-10.1 (10.1.28-2) stuck in Uploaded status on amd64, mips, mipsel, s390x & powerpc
On Wed, Nov 15, 2017 at 06:18:55PM +0100, Sebastiaan Couwenberg wrote:
> The recent upload of mariadb-10.1 (10.1.28-2) is stuck in Uploaded
> status for over two days now on amd64, mips, mipsel, s390x & powerpc.
>
> Please help this package get installed. This upload is required to
> unblock various packages from migrating to testing.
There is nothing to help with, the binary uploads got rejected by dak
because they tried to upload binaries with a lower version than ones
already installed (and built by mariadb-10.2).
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Please give back ruby-redis-rails on all
On Thu, Aug 24, 2017 at 06:14:15PM +0530, Pirate Praveen wrote: > As per the failed build log, > https://buildd.debian.org/status/fetch.php?pkg=ruby-redis-rails&arch=all&ver=5.0.2-1&stamp=1500605275&raw=0 > > Unable to activate redis-rack-1.5.0, because redis-store-1.3.0 conflicts > with redis-store (~> 1.1.0) (Gem::ConflictError) > > but ruby-redis-rack is 2.0.2 in experimental. Except that nothing is pulling ruby-redis-rack from experimental. Probably some package (ruby-redis-store?) is missing a versioned dependency. Check the build log: Get:94 http://debian.csail.mit.edu/debian unstable/main amd64 ruby-redis-rack all 1.5.0-7 [4440 B] > Attaching my successful build log. Probably your chroot is misconfigured, or anyway configured differently from the buildds, where they prefer unstable packages over anything else unless a versioned dependency "forces" an experimental version. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#867104: wanna-build issue with src:perl versioned Provides
On Thu, Jul 27, 2017 at 03:15:14PM +0200, Aurelien Jarno wrote: > > 1. upload to stretch, upgrade wuiet to stretch > > I plan to upgrade wuiet to stretch during debconf, but not before. Note > anyway that going through stretch means waiting for the next point > release. I don't believe waiting for the next point release would be so bad anyway. It probably means less than 2 months, this change waited for quite longer… Also, couldn't you install it from stretch-pu? > > 3. upload to stretch-bpo, upgrade wuiet to stretch > > That also works and might be faster. It means we need to try to keep as > much as possible the interface unchanged to not get any breakage. That, and it would need be kept up to date in backports to comply with backport's rules. Overall I think that 1 is the best choice for everything, but then it comes down to Ralf's willingness to take out the fixing commit and to a stable update (and RM acceptance of it), and pkg-perl's willingness to wait for the next point release. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#867104: wanna-build issue with src:perl versioned Provides
On Thu, Jul 20, 2017 at 09:04:34PM +0300, Niko Tyni wrote:
> Given Kurt's earlier answer above, I expect they need a jessie backport.
I was involved in the dose3 backports, and as of now the version in.
jessie-backports is completely up to date with stable, and wuiet.d.o is
using it.
Now, I see that #867104 and #864906 have been closed yesterday in
unstable.
https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/dose3.git/commit/?id=42aa4c43aac0357aa59d2a1b2d9d640cd5f10dc1
Now I'm unsure what's the best way to get that fix in wuiet.d.o.
The options here are probably:
1. upload to stretch, upgrade wuiet to stretch
2. upload to stretch, then to jessie-bpo
3. upload to stretch-bpo, upgrade wuiet to stretch
4. asking for exception to the backports' rules and backport the fix
to jessie-bpo without fixing stretch
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
gb python-gitdb_2.0.0-2 . mips
I don't get the what that error is about, and trying one I could not
reproduce it, would you please
wb gb python-gitdb_2.0.0-2 . mips
please?
tia
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: misleading timestamps in binnmus
On Wed, Nov 09, 2016 at 10:04:28AM +0100, Sven Joachim wrote:
> I'm afraid I don't really have a good suggestion. Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.
Why would that break reproducibility? reproducible builds is about
reproducing a given build, in the case of a binNMU all the data neede
for that is registered in .buildinfo, including the date of the binNMU
and the full changelog entry of it.
Just using `date -R` is good, imho.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: please gb yi and haskell-http-client
On Mon, Aug 15, 2016 at 08:13:26AM +, Mattia Rizzolo wrote:
> These 2 packages failed to build on buildds, but can be successfully
> built now.
Thanks to whoever did it, though I forgot of:
wb gb yi_0.12.6-1 . all
:)
even if… now everything is stuck due to haskell foo, but oh, well, it'll
unblock itself ^^ (I hope, at least)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
please gb yi and haskell-http-client
Dear wb team, These 2 packages failed to build on buildds, but can be successfully built now. wb gb yi_0.12.6-1 . ANY wb gb haskell-http-client_0.4.31-1 . kfreebsd-amd64 wb gb haskell-http-client_0.4.31-1+b1 . kfreebsd-i386 (hoping I got the syntax right) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 08:17:22PM +0200, Ralf Treinen wrote: > well, the source-only upload to jessie-backports was rejected, claiming > that architecture-independent packages have to be included. Great surprise, > that wasn't the case before. source only uploads (without arch:all binaries) to anything != (unstable, sid, experimental) have never been a thing. > I am leaving for vacation tomorrow and don't have > access to a jessie chroot now, so I cannot fix this now. If you want 5.0-3 > in backports please pick it up at > > https://anonscm.debian.org/git/pkg-ocaml-maint/packages/dose3.git > branch jessie-backports/master I'll build and upload it! Thanks :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Unsattisfied dependency python-cffi-backend-api-min (<= 9729)
On Thu, Jul 21, 2016 at 07:17:03PM +0200, Ralf Treinen wrote:
> Fixed package is in sid (5.0-3) since Fri, 15 Jul, should migrate to
> testing soon. I just uploaded to jessie-backports.
It migrated to testing this morning.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
