Re: armhf regressions in a few packages
Bus error tends to be about unaligned memory access. I personally don't fix such issues, but I do report them upstream and then disable that architecture for building. For bioinformatics, there is no reason to support armhf. -- Michael R. Crusoe On Sat, Nov 21, 2020, 22:11 Nilesh Patra wrote: > Hi, > > I've seen some packages failing _only_ on armhf when I added autopkgtests > to them. Murasaki[1] and lighter[2] for example. > They seem to fail with this common error message: Bus Error -- > > > Could it be because of lack of RAM/memory issue there? > > Couple of days ago, Praveen (in CC) reported to me an error with > golang-github-honnef-tools[3] > But on running in an armhf porter box, it works just fine as I'm told. > > I've also noticed that the tests in these packages need a _relatively_ > higher computation power. > I'm unsure if this is a fault in the tests, or a limitation at CI's end. > Please let me know what you'd think about this and plausible solutions to > this. > > [1]: > https://ci.debian.net/data/autopkgtest/testing/armhf/m/murasaki/8213738/log.gz > [2]: > https://ci.debian.net/data/autopkgtest/testing/armhf/l/lighter/8203401/log.gz > [3]: > https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-honnef-go-tools/8213705/log.gz > > Regards, > Nilesh > >
Re: [RFS] plasmidseeker
On Sun, 22 Nov 2020 at 02:47, tony mancill wrote: > On Sun, Nov 22, 2020 at 02:21:47AM +0530, Nilesh Patra wrote: > > Hi, > > > > On Sun, 22 Nov, 2020, 12:58 am tony mancill, > wrote: > > > > > On Sun, Nov 22, 2020 at 12:54:28AM +0530, Nilesh Patra wrote: > > > > dcut dm --uid npatra...@gmail.com --allow plasmidseeker > > > > > > Done. > > > > > > > Thanks, but I've not yet received the permissions. Could you please > re-run? > > This was on the processing side. I never resubmitted but recently > received a confirmation that the command finally took effect. Here is > the command I issued: > > $ dcut dm --uid npatra...@gmail.com --allow plasmidseeker > Uploading commands file to ftp.upload.debian.org (incoming: > /pub/UploadQueue/) > Picking DM Nilesh Patra with fingerprint > 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 > Uploading tony-1605986826.dak-commands to ftp-master > > You can see the timestamp in the commands file that was uploaded: > > $ date --utc -d @1605986826 > Sat 21 Nov 2020 07:27:06 PM UTC > > But the email confirmation is > Sat 21 Nov 2020 08:55:06 PM UTC > > So dak took nearly 90 minutes to process the commands. > I see, apologies for the impatience, and thanks for the explanation :-)
Re: gsort_0.1.4-1_amd64.changes REJECTED
Hi Steffen,
This package has probably been accepted and this dak errors occurs due to
"Built-Using" field in d/control which I forgot to remove earlier.
Could you please $git pull from salsa and upload to NEW again? In principle
it'd get accepted just in some time. (minutes?)
We also faced this earlier in vcfanno and seqkit and vcfanno which were
fixed after a re-upload with "Built-Using" removed.[1][2][3][4]
[1]
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-October/085330.html
[2]:
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-October/085353.html
[2]:
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-October/085331.html
[4]:
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-October/085356.html
Regards
Nilesh
On Sun, 22 Nov 2020 at 02:40, Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:
>
> An exception was raised while processing the package:
> Traceback (most recent call last):
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 109,
> in wrapper
> function(upload, srcqueue, comments, transaction)
> File "/srv/ftp-master.debian.org/dak/dak/process_policy.py", line 236,
> in comment_accept
> extra_archives=[upload.target_suite.archive],
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 450, in
> copy_binary
> self._ensure_extra_source_exists(filename, db_source, archive,
> extra_archives=extra_archives)
> File "/srv/ftp-master.debian.org/dak/daklib/archive.py", line 244, in
> _ensure_extra_source_exists
> raise ArchiveException('{0}: Built-Using refers to package {1} (= {2})
> not in target archive {3}.'.format(filename, source.source, source.version,
> archive.archive_name))
> daklib.archive.ArchiveException: g/gsort/gsort_0.1.4-1_amd64.deb:
> Built-Using refers to package golang-github-alexflint-go-scalar (=
> 1.0.0+ds-1) not in target archive ftp-master.
>
> Original comments:
>
>
>
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
>
>
Re: [RFS] plasmidseeker
On Sun, Nov 22, 2020 at 02:21:47AM +0530, Nilesh Patra wrote: > Hi, > > On Sun, 22 Nov, 2020, 12:58 am tony mancill, wrote: > > > On Sun, Nov 22, 2020 at 12:54:28AM +0530, Nilesh Patra wrote: > > > dcut dm --uid npatra...@gmail.com --allow plasmidseeker > > > > Done. > > > > Thanks, but I've not yet received the permissions. Could you please re-run? This was on the processing side. I never resubmitted but recently received a confirmation that the command finally took effect. Here is the command I issued: $ dcut dm --uid npatra...@gmail.com --allow plasmidseeker Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Picking DM Nilesh Patra with fingerprint 3E99A526F5DCC0CBBF1CEEA600BAE74B343369F1 Uploading tony-1605986826.dak-commands to ftp-master You can see the timestamp in the commands file that was uploaded: $ date --utc -d @1605986826 Sat 21 Nov 2020 07:27:06 PM UTC But the email confirmation is Sat 21 Nov 2020 08:55:06 PM UTC So dak took nearly 90 minutes to process the commands. Cheers, tony signature.asc Description: PGP signature
armhf regressions in a few packages
Hi, I've seen some packages failing _only_ on armhf when I added autopkgtests to them. Murasaki[1] and lighter[2] for example. They seem to fail with this common error message: Bus Error -- Could it be because of lack of RAM/memory issue there? Couple of days ago, Praveen (in CC) reported to me an error with golang-github-honnef-tools[3] But on running in an armhf porter box, it works just fine as I'm told. I've also noticed that the tests in these packages need a _relatively_ higher computation power. I'm unsure if this is a fault in the tests, or a limitation at CI's end. Please let me know what you'd think about this and plausible solutions to this. [1]: https://ci.debian.net/data/autopkgtest/testing/armhf/m/murasaki/8213738/log.gz [2]: https://ci.debian.net/data/autopkgtest/testing/armhf/l/lighter/8203401/log.gz [3]: https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-honnef-go-tools/8213705/log.gz Regards, Nilesh
Re: [RFS] plasmidseeker
Hi, On Sun, 22 Nov, 2020, 12:58 am tony mancill, wrote: > On Sun, Nov 22, 2020 at 12:54:28AM +0530, Nilesh Patra wrote: > > dcut dm --uid npatra...@gmail.com --allow plasmidseeker > > Done. > Thanks, but I've not yet received the permissions. Could you please re-run? Regards Nilesh >
Re: [RFS] plasmidseeker
On Sun, Nov 22, 2020 at 12:54:28AM +0530, Nilesh Patra wrote: > dcut dm --uid npatra...@gmail.com --allow plasmidseeker Done.
[RFS] plasmidseeker
dcut dm --uid npatra...@gmail.com --allow plasmidseeker Nilesh
