Bug#1071181: Removing packages from rollback distributions fails

[Stephan Sürken]

On Wed, 2024-05-15 at 15:53 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Version: 2.0.15~bpo12+1
> 
> Sorry if I should have discussed this elsewhere before reporting a bug, but 
> there is no mailing list for mini-buildd, is there? It seems like it has to 
> be 
> a bug, although it's surprising that nobody has reported it yet. Sorry if 
> it's 
> been fixed in 2.2 already, but I can't find anything relevant in the 
> changelog.

yes, there is no mailing list. Bug report is prefectly fine...

> Anyway, I'm getting 400 Bad Request (No such source: Source 'package_version' 
> not found in 'repo-dist-suite-rollback4' distribution) when trying to remove a

ups, good find. Seems that feature is hardly ever used ;)


This was actually introduced in 2.0.x, and is still in 2.2.x.

Will add test case and fix asap.

Thx!

S


signature.asc
Description: This is a digitally signed message part

Bug#906747: reprepro does not accept built files on includedsc

[Stephan Sürken]

On Sat, 25 Aug 2018 13:25:24 +0200 Marc Haber  
wrote:
> severity #906747 normal
> thanks
> 
> I now think that this is actually a reprepro issue, and it only applies

(...)

> My beef against mini-buildd is therefore reduced to the fact that it
> once more hides the actual error message in the logs, and that I
> cannot access the built packages for manual testing since they're killed
> off as soon as the error happens.

fwiw: This went to control@ only, pasting here again for 
convenience/explanation:

retitle 906747 Please keep build data (even if installation finally fails)
fixed 906747 2.0.0
thanks

Since 2.0.0, all build data is kept in a resp. builds directory (including 
potentially built
binary packages), and can be downloaded via HTTP.

Builds data expires after 5 days (or, for 2.2.x, by default after 5 days).

For expert debugging, m-b-debug-build may be used to help analyze faild builds 
(while the
build data is still there).

Hth,

S


signature.asc
Description: This is a digitally signed message part

Bug#1070111: mini-buildd wishlist: configurable periodic jobs (or: don't keep complete build results for a full year)

[Stephan Sürken]

Hi Magnus,

On Tue, 2024-04-30 at 11:40 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Severity: wishlist

> coded. Perhaps you've already planned to add some configurability in the 
> future, but more specifically I'd like to talk about the "Expire

no imminent plans to make cron jobs configurable, however expire times for
event and build directories are configurable in upcoming 2.2.x.

Hth!

S


signature.asc
Description: This is a digitally signed message part

Bug#1052822: mini-buildd: FTBFS: make[1]: *** [debian/rules:11: override_dh_auto_build] Error 25

[Stephan Sürken]

Hi Lucas,

On Tue, 2023-09-26 at 14:43 +0200, Lucas Nussbaum wrote:
> Source: mini-buildd
> Version: 2.0.8
> Severity: serious
(..)
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
(..)
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
(..)
> > hostname: Name or service not known

is ``hostname [-f]`` not working in the build environment?

I see that ``m-b-self-signed-cerificate --help`` fails, which would add
up. Also, 2.0.8 was a source-only upload and already 'got thru' previously.

Hth!

Stephan


signature.asc
Description: This is a digitally signed message part

Bug#1052459: mini-buildd: Problems with unnecessarily doubled slashes

[Stephan Sürken]

Hi Magnus,

On Fri, 2023-09-22 at 15:37 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Version: 2.0.7~bpo12+1
> 
> mini-buildd requires (in Archive.clean) that all archive URLs end in
> a slash. 
> Yet it (always?) adds another slash before 'dists' (e.g. 
> Archive.ReleaseFile(f"{archive.url}/dists/{self.codename}/") in 
> Source.mbd_check). With behaving servers, this shouldn't be a 

hmm yes, that's indeed unnecessary ;). Fix pending.

Thx!

Stephan




signature.asc
Description: This is a digitally signed message part

Bug#1033519: debootstrap: Fails to bootstrap wheezy (please symlink script as 'archived', like squeeze)

[Stephan Sürken]

Package: debootstrap
Version: 1.0.128+nmu2
Severity: wishlist

Dear Maintainer,

wheezy is archived, but script (unlike, f.e. squeeze) still links to sid:

---
ls -l /usr/share/debootstrap/scripts/wheezy 
/usr/share/debootstrap/scripts/squeeze
lrwxrwxrwx 1 root root 4 Oct 19 00:49 /usr/share/debootstrap/scripts/squeeze -> 
etch
lrwxrwxrwx 1 root root 3 Oct 19 00:49 /usr/share/debootstrap/scripts/wheezy -> 
sid
---

[i.e., bootstrap w/o special parameters for mirror (archived) and key file 
(removed) will fail.]

Please symlink wheezy like squeeze.

Thx!

Stephan

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debootstrap depends on:
ii  wget  1.21.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.20-1
ii  debian-archive-keyring  2023.2
ii  gnupg   2.2.40-1

Versions of packages debootstrap suggests:
ii  binutils 2.40-2
pn  squid-deb-proxy-client   
ii  ubuntu-keyring [ubuntu-archive-keyring]  2020.06.17.1-1
ii  xz-utils 5.4.1-0.2
ii  zstd 1.5.4+dfsg2-5

-- no debconf information

Bug#1026843: Not suitable for testing yet (due to outstanding migration tests)

[Stephan Sürken]

Package: mini-buildd
Version: 1.9.112
Severity: serious

While working quite well already on a new setup, some crucial testing
has not yet been fully done yet -- especially

* migration tests (i.e., upgrading an existing installation from 1.0.x->2.0.x)
* new 'setup' system's maintenance facilities

I.e., I don't recommend upgrading production systems just yet, please
wait for a proper 2.0.x release.

Thanks!

Stephan
-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages mini-buildd depends on:
ii  adduser3.129
ii  debconf [debconf-2.0]  1.5.80
ii  debootstrap1.0.128+nmu2
ii  devscripts 2.22.2
ii  dirmngr2.2.40-1
ii  dpkg-dev   1.21.13
ii  gnupg  2.2.40-1
ii  init-system-helpers1.65.2
ii  python33.10.6-3
ii  python3-mini-buildd1.9.112
ii  python3-pyftpdlib  1.5.7-2
ii  reprepro   5.3.1-1
ii  sbuild 0.84.2
ii  schroot1.6.13-3+b1
ii  sudo   1.9.11p3-2
ii  sysvinit-utils [lsb-base]  3.06-2
ii  zstd   1.5.2+dfsg-1

Versions of packages mini-buildd recommends:
ii  arch-test0.19-1
ii  autopkgtest  5.27
ii  lintian  2.115.3
ii  mini-buildd-doc  1.9.112
ii  piuparts 1.1.5
ii  python3-apt  2.5.0

Versions of packages mini-buildd suggests:
ii  binfmt-support  2.2.2-2
ii  btrfs-progs 6.0.2-1
ii  debian-archive-keyring  2021.1.1
ii  haveged 1.9.14-1+b1
ii  lvm22.03.16-2
ii  openssl 3.0.7-1
ii  qemu-user-static1:7.2+dfsg-1
ii  ubuntu-keyring  2020.06.17.1-1

-- Configuration Files:
/etc/default/mini-buildd changed [not included]
/etc/sudoers.d/mini-buildd-sudoers [Errno 13] Permission denied: 
'/etc/sudoers.d/mini-buildd-sudoers'

-- debconf information excluded

Bug#1026215: python3-openssl: Fails using deprecated SSL_CTX_set_ecdh_auto which ultimately has been removed w/ p-cryptography 38

[Stephan Sürken]

Package: python3-openssl
Version: 21.0.0-1
Severity: important

Dear Maintainer,

since p-cryptography 38 hit unstable, this fails somewhere here

  File "/usr/lib/python3/dist-packages/OpenSSL/SSL.py", line 674, in __init__

using SSL_CTX_set_ecdh_auto, which is deprecated w/ at least openssl3 afaiu, and
python3-cryptography 38 seem to to have that binding now removed for good.

Newest release versions of pyopenssl have this depcrecated call just removed, 
so maybe
updating upstream is the way to go here.

Hth, and thanks!

Stephan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-openssl depends on:
ii  python3   3.10.6-3
ii  python3-cryptography  38.0.4-1
ii  python3-six   1.16.0-4

python3-openssl recommends no packages.

Versions of packages python3-openssl suggests:
pn  python-openssl-doc   
pn  python3-openssl-dbg  

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/OpenSSL/SSL.py (from 
python3-openssl package)

Bug#937049: mini-buildd: Python2 removal in sid/bullseye

[Stephan Sürken]

Hi Bastian,

On Tue, 2022-11-29 at 21:09 +0100, Bastian Germann wrote:
> Why don't you move the experimental to unstable now?

well, some crucial tests (especially on upgrading) are unfortunately
still pending.

Uploading to unstable always marked "ok to use" in that respect, however...

> The unstable mini.buildd version is not usable but is now the last reverse 
> dependency of python-setuptools
> (sphinx and nuitka only have it as optional alternatives).

as it seems to cause big pain elsewhere, I will prepare the next upload
(within "days" ;) for unstable (with a blocking RC bug if need be).

Hth!

S


signature.asc
Description: This is a digitally signed message part

Bug#937049: mini-buildd: Python2 removal in sid/bullseye

[Stephan Sürken]

Hi Moritz,

On Fri, 2022-10-28 at 00:12 +0200, Moritz Mühlenhoff wrote:
> Am Fri, Aug 30, 2019 at 07:26:40AM + schrieb Matthias Klose:
> > Package: src:mini-buildd
> > Version: 1.0.41
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> > 
> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> How close is the 2.x branch in experimental from being a replacement?
> python2 will be dropped in bookworm and also removed from the archive.

it's taking way too long already ;), but I am still quite confident to be
able to upload to unstable this year, i.e., before Debian freeze/bookworm.

Hth!

S

Bug#1007101: libjs-jquery-datatables: jquery.dataTables[.min].js files missing

[Stephan Sürken]

Package: libjs-jquery-datatables
Version: 1.11.5+dfsg-1
Severity: important

Dear Maintainer,

in 1.11.4+dfsg-1:
---
? dpkg -L libjs-jquery-datatables | grep jquery.dataTables
/usr/share/javascript/jquery-datatables/css/jquery.dataTables.css
/usr/share/javascript/jquery-datatables/css/jquery.dataTables.min.css
/usr/share/javascript/jquery-datatables/jquery.dataTables.js
/usr/share/javascript/jquery-datatables/jquery.dataTables.min.js
---

in current 1.11.5+dfsg-1:
---
dpkg -L libjs-jquery-datatables | grep jquery.dataTables
/usr/share/javascript/jquery-datatables/css/jquery.dataTables.css
/usr/share/javascript/jquery-datatables/css/jquery.dataTables.min.css
---

So these file(s) clearly are missing.

Marking important as these files are also documented as 1st basic
example upstream, see https://www.datatables.net/.

Or is there another include scheme now?

Thx!

Stephan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-0.bpo.3-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libjs-jquery-datatables depends on:
ii  libjs-jquery  3.6.0+dfsg+~3.5.13-1

Versions of packages libjs-jquery-datatables recommends:
pn  javascript-common  

libjs-jquery-datatables suggests no packages.

-- no debconf information

Bug#998068: debconf values not populated on initial install (like debootstrap) since 1.5.78

[Stephan Sürken]

Package: debconf
Version: 1.5.78
Severity: important

Dear Maintainer,

on initial install (for example via deboostrap), debconf values are not 
populated, i.e.,

debconf-show debconf

is empty.

Maybe due to fix for #989567, which seems to actually remove postinst
for good w/o actually producing debhelper's default postinst?

Thx!

Stephan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-0.bpo.2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages debconf depends on:
ii  perl-base  5.32.1-6

Versions of packages debconf recommends:
ii  apt-utils 2.3.11
ii  debconf-i18n  1.5.78

Versions of packages debconf suggests:
ii  debconf-doc1.5.78
pn  debconf-kde-helper 
pn  debconf-utils  
pn  libgtk3-perl   
pn  libnet-ldap-perl   
pn  libterm-readline-gnu-perl  
ii  perl   5.32.1-6
ii  whiptail   0.52.21-5

-- debconf information excluded

Bug#981213: debrepro: fusermount -u fails in chroots

[Stephan Sürken]

Rehi,

On Wed, 27 Jan 2021 19:29:00 +0100 =?utf-8?q?Stephan_S=C3=BCrken?= <
abs...@debian.org> wrote:
> Package: devscripts
> Version: 2.20.5
> Severity: normal
> 
> Dear Maintainer,
> 
> any chrooted run debrepro fails on cleanup with s.th. like:
> ---
> rm: cannot remove '/tmp/debrepro.WdTfiXpiIP/second/source': Device or
resource busy
> ---

some more info: The behaviour is as described under (at least) linux
5.9.15.

Running with our current kernel (5.10.9) however, everything seems
fine.

If this really is gone for good with 5.10, I will just close this
eventually.

Hth,

S

Bug#981213: debrepro: fusermount -u fails in chroots

[Stephan Sürken]

Package: devscripts
Version: 2.20.5
Severity: normal

Dear Maintainer,

any chrooted run debrepro fails on cleanup with s.th. like:
---
rm: cannot remove '/tmp/debrepro.WdTfiXpiIP/second/source': Device or resource 
busy
---

This is due to fusermount -u failing w/
---
fusermount: failed to mark mounts private: Invalid argument
---

fusermount in a check prior to the umount runs
---
res = mount("", "/", "", MS_PRIVATE | MS_REC, NULL);
---
This *seems* to fail in chroots "since some kernel versions";
i.e., definitely fails w/ linux 5.* (bullseye), definitely used
to work with linux 4.19.* (buster).

A simple "umount" otoh still works for me like a charm -- "working for me"-style
patch attached, but there is no real wisdom in it ;).

It really seems to be a generic problem, but I'd still love someone to re-test
this in case it's a PP after all...

Thanks!

Stephan

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBCLEAN_CLEANDEBS=yes
DEBUILD_PREPEND_PATH=/usr/lib/ccache

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.7.1
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.31-9
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.0-6
ii  python3   3.9.1-1
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.18
ii  curl7.74.0-1
pn  dctrl-tools 
ii  debian-keyring  2020.12.24
ii  dput-ng [dput]  1.32
ii  equivs  2.3.1
ii  libdistro-info-perl 0.24
ii  libdpkg-perl1.20.7.1
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-2
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
pn  libsoap-lite-perl   
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.06-1
pn  licensecheck
ii  lintian 2.104.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.1.7
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.20-3
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
pn  strace  
ii  unzip   6.0-26
ii  wget1.21-1+b1
ii  xz-utils5.2.5-1.0

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.3.1
pn  devscripts-el
ii  diffoscope   165
ii  disorderfs   0.5.11-1
pn  dose-extra   
pn  duck 
ii  faketime 0.9.7-3.1
pn  gnuplot  
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-1
pn  libyaml-syck-perl
pn  mmdebstrap   
ii  mozilla-devscripts   0.54.2
pn  mutt 
ii  openssh-client [ssh-client]  1:8.4p1-3
pn  piuparts 
pn  postgresql-client
pn  quilt
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.7
pn  w3m  

-- no debconf information
>From 1e0d29944cc36aa1e5e67d8ae3b3cf0648f635f4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stephan=20S=C3=BCrken?= 
Date: Wed, 27 Jan 2021 18:58:47 +0100
Subject: [PATCH] debrepro.sh: Use 'umount', not 'fusermount -u' (fixes umount
 in 

Bug#981043: git-buildpackage: dch: Please support --distribution for snapshots (or at least properly document --distribution)

[Stephan Sürken]

Package: git-buildpackage
Version: 0.9.21
Severity: minor

Dear Maintainer, Guido,

in snapshot mode, header options --distribution (and --urgency) are deliberately
not honored in-code (scripts/dch.py):

---
# This must not be done for snapshots or snapshots changelog entries
# will not be concatenated
if not options.snapshot:
...
---

Afaiu, this comment means when doing a second 'dch --snapshot' (with a custom, 
not
UNRELEASED distribution), it would create another CL rather than combining with 
the
latter.

I.e., with the restriction in place, the valid use case to set the distribution 
is
denied -- however, *without* the restriction, the old behaviour can be achieved 
(just
don't specify --distribution), and those who want to set a distribution are 
also happy.

(Documentation may be updated that 'dch --snapshot' behaves slightly different 
when not using dist=UNRELEASED.)

I am using it locally here with that restriction removed, and not seen any
odd behaviour. But may be I do not get the full picture here?

Thx!

Stephan

> Package: git-buildpackage

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages git-buildpackage depends on:
ii  devscripts 2.20.5
ii  git1:2.30.0-1
ii  man-db 2.9.3-2
ii  python33.9.1-1
ii  python3-dateutil   2.8.1-5
ii  python3-pkg-resources  51.3.3-1
ii  sensible-utils 0.0.14

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2
ii  sbuild0.80.1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.5p1-1
ii  unzip6.0-26

-- no debconf information

Bug#981013: git-buildpackage: dch: Please don't capture stderr on debchange run

[Stephan Sürken]

(...)
> debchange may be non-interactive, showing some warning to stderr end

rather "interactive" not "non-interactive"...
 
Sorry ;),

S


signature.asc
Description: This is a digitally signed message part

Bug#981013: git-buildpackage: dch: Please don't capture stderr on debchange run

[Stephan Sürken]

Package: git-buildpackage
Version: 0.9.21
Severity: minor
Tags: patch

Dear Maintainer, Guido,

debchange may be non-interactive, showing some warning to stderr end expecting
[RETURN] on stdin to continue.

Capturing stderr leads to stopping without showing any clue why or what to do.
For example:

  gbp dch --release --distribution=my-unknown-dist

Unless there is any known ill effect, I'd suggest to just show
debchange's stderr output.

Hth!

Stephan
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages git-buildpackage depends on:
ii  devscripts 2.20.5
ii  git1:2.30.0-1
ii  man-db 2.9.3-2
ii  python33.9.1-1
ii  python3-dateutil   2.8.1-5
ii  python3-pkg-resources  51.3.3-1
ii  sensible-utils 0.0.14

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2
ii  sbuild0.80.1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.5p1-1
ii  unzip6.0-26

-- no debconf information
>From d7017801c63a9d0c395b662fb45aa19ad0e64538 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stephan=20S=C3=BCrken?= 
Date: Mon, 25 Jan 2021 16:34:09 +0100
Subject: [PATCH] gbp/deb/changelog.py (ChangeLog.spawn_dch): Don't capture
 stderr on debchange run.

debchange may be non-interactive, showing some warning to stderr end expecting
[RETURN] on stdin to continue.

Capturing stderr leads to stopping without showing any clue why or what to do 
-- for example:

  gbp dch --release --distribution=my-unknown-dist
---
 gbp/deb/changelog.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gbp/deb/changelog.py b/gbp/deb/changelog.py
index dda9b75..ccd2e60 100644
--- a/gbp/deb/changelog.py
+++ b/gbp/deb/changelog.py
@@ -285,7 +285,7 @@ class ChangeLog(object):
 args.append('[[[insert-git-dch-commit-message-here]]]')
 else:
 args.append('')
-dch = Command('debchange', args, extra_env=env, capture_stderr=True)
+dch = Command('debchange', args, extra_env=env)
 dch.run_error = Command._f("Dch failed: {stderr_or_reason}")
 dch([], quiet=True)
 if msg:
-- 
2.30.0

Bug#980735: dput-ng: Please add ftps (RFC 4217, not sftp) support

[Stephan Sürken]

Package: dput-ng
Version: 1.31
Severity: wishlist
Tags: patch

Dear Maintainer(s),

this adds a new method "ftps" following RFC 4217 with ftplib.FTP_TLS (py 
standard library).

Patch is in this salsa merge request:

https://salsa.debian.org/debian/dput-ng/-/merge_requests/14

Thanks for considering!

Stephan

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages dput-ng depends on:
ii  python3   3.9.1-1
ii  python3-dput  1.31

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#980468: dput: Please add ftps (RFC 4217, not sftp) support

[Stephan Sürken]

Package: dput
Version: 1.1.0
Severity: wishlist
Tags: patch

Dear Maintainer, Ben,

this adds a new method "ftps" following RFC 4217 with ftplib.FTP_TLS (py 
standard library).

Patch is in this salsa merge request:

https://salsa.debian.org/debian/dput/-/merge_requests/4

Thanks for considering!

Stephan

Bug#955277: buster-pu: package mini-buildd/1.0.36

[Stephan Sürken]

Hi Adam,

On Sun, 2020-11-22 at 18:30 +, Adam D. Barratt wrote:
> Control: tags -1 -moreinfo +confirmed
> 
> Hi,
> 
> Apologies for having somehow missed your earlier reply.
> 
> On Tue, 2020-04-28 at 08:51 +0200, Stephan Sürken wrote:
(...)
> Please go ahead.

thx, uploaded now.

I guess my new year's resolution now is to skip all mail filters, as I
also failed to see your reply for ~2 month ;).

Hth,

S


signature.asc
Description: This is a digitally signed message part

Bug#955277: buster-pu: package mini-buildd/1.0.36

[Stephan Sürken]

Hi Adam,

thanks for yor answer.

On Sun, 2020-04-26 at 15:34 +0100, Adam D. Barratt wrote:
(...)

> We'd need to see diffs for a proposed upload before OKing anything
> here.

Sure; just was somewhat confused how to proceed in the 1st place ;).

I have now (correctly) flagged the bug as fixed in 1.0.37.

The proposed update will only address this

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951641

very bug (see attached diff). 

Fwiw, there is also more verbose description of the problem in this

https://salsa.debian.org/debian/mini-buildd/-/commit/3e267eafd66f70deedd9b90c4752130cdac0c8f7

commit message.

I hope I may proceed uploading this to buster?

Thx!

Stephan
diff -Nru mini-buildd-1.0.36/debian/changelog mini-buildd-1.0.36+deb10u1/debian/changelog
--- mini-buildd-1.0.36/debian/changelog	2018-06-22 16:30:15.0 +0200
+++ mini-buildd-1.0.36+deb10u1/debian/changelog	2020-04-28 08:18:54.0 +0200
@@ -1,3 +1,12 @@
+mini-buildd (1.0.36+deb10u1) buster; urgency=medium
+
+  * [36d75e1] debian/gbp.conf: Update debian branch.
+  * [85bd4e0] builder.py: sbuild call: set '--no-arch-all' explicitly
+(Fixes "false" reprepro errors after successful builds w/ sbuild >=
+0.77) (Fixes: #951641)
+
+ -- Stephan Sürken   Tue, 28 Apr 2020 08:18:54 +0200
+
 mini-buildd (1.0.36) unstable; urgency=medium
 
   * [9a29242] source.py: wizards: Update signing keys for unstable +
diff -Nru mini-buildd-1.0.36/debian/gbp.conf mini-buildd-1.0.36+deb10u1/debian/gbp.conf
--- mini-buildd-1.0.36/debian/gbp.conf	2018-06-22 14:51:53.0 +0200
+++ mini-buildd-1.0.36+deb10u1/debian/gbp.conf	2020-04-28 08:18:25.0 +0200
@@ -1,3 +1,3 @@
 [DEFAULT]
-debian-branch = 1.0.x
+debian-branch = buster-proposed-updates
 snapshot-number = os.popen("date --utc +'%Y%m%d%H%M%S'").readlines()[0]
diff -Nru mini-buildd-1.0.36/src/mini_buildd/builder.py mini-buildd-1.0.36+deb10u1/src/mini_buildd/builder.py
--- mini-buildd-1.0.36/src/mini_buildd/builder.py	2018-06-22 14:51:53.0 +0200
+++ mini-buildd-1.0.36+deb10u1/src/mini_buildd/builder.py	2020-04-28 08:18:25.0 +0200
@@ -213,6 +213,8 @@
 
 if "Arch-All" in self._breq:
 sbuild_cmd += ["--arch-all"]
+else:
+sbuild_cmd += ["--no-arch-all"]  # Be sure to set explicitly: sbuild >= 0.77 does not seem to use this as default any more?
 
 if "Run-Lintian" in self._breq:
 sbuild_cmd += ["--run-lintian"]
diff -Nru mini-buildd-1.0.36/src/mini_buildd/__init__.py mini-buildd-1.0.36+deb10u1/src/mini_buildd/__init__.py
--- mini-buildd-1.0.36/src/mini_buildd/__init__.py	2018-06-22 16:30:15.0 +0200
+++ mini-buildd-1.0.36+deb10u1/src/mini_buildd/__init__.py	2020-04-28 08:18:54.0 +0200
@@ -2,4 +2,4 @@
 from __future__ import unicode_literals
 from __future__ import absolute_import
 
-__version__ = "1.0.36"
+__version__ = "1.0.36+deb10u1"

Bug#951641: mini-buildd: MD5 conflict with doc packages when compiling "any" arch

[Stephan Sürken]

Hi Marc,

On Wed, 2020-03-18 at 14:42 +0100, Marc Leeman wrote:
(...)
> Thanks for the pointer. 
> 
> I've applied the patch and restarted the service. I could recompile
> openjdk-8 without problem; it seems that this was the problem.

great!

Fwiw, afaik all packages failing to build (their 'all' binary packages)
unreprodicibly should be affected by this on a plain buster install.

As this imho is a more serious problem, I am trying to get some advice
if/how I can do updates via proposed-updates:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955277

Hth,

S

Bug#951641: mini-buildd: MD5 conflict with doc packages when compiling "any" arch

[Stephan Sürken]

Hi Marc,

On Thu, 2020-03-12 at 11:15 +0100, Marc Leeman wrote:
> This is the status of the openjdk-8 build: as the log confirms, the
> i386 packages got inserted, while the amd64 not due to the md5
> conflict since both are creating the same openjdk-8-source_8u242-b04-
> 2~company10+6_all.deb
> 
> In my setup, the error seems consistent for "any" source packages 

can't go into that all into detail now, but I just remebered

https://salsa.debian.org/debian/mini-buildd/-/commit/3e267eafd66f70deedd9b90c4752130cdac0c8f7

Seems you are you using 1.0.36 or lower? -- sounds just like your problem.

Unfortunately, I cannot provide support for updates in Debian (i.e., 
testing->bpo) atm:

http://mini-buildd.installiert.net/articles/10x-maintenance-moved-to-hellfield-archive.html

Please get stable updates for mini-buildd from hellfield for now (or port from 
unstable or build from git).

Hope that is your problem,

Thx

S

Bug#951641: mini-buildd: MD5 conflict with doc packages when compiling "any" arch

[Stephan Sürken]

Hi Marc,

On Fri, 2020-02-21 at 11:54 +0100, Marc Leeman wrote:
> 
> Could it be that there is some config option that is still wreaking
> havoc after having been disabled.

Fwiw, there is this 'inconvenience' bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838393

So just be sure to restart the Daemon after configuration changes.

> The initial setup might have had amd64/i386 build architecture all
> enabled. 
> 
> I then disabled i386 to get something working quickly only to enable
> it again a couple of months later, this time with the build
> architecture all disabled for i386.

Hmm, ok. Seems suspicious, but would still not explain the behaviour
you are seeing, imho.

Could you, before doing the failing portext, check the repo status for
the package? I.e., s.th. like

---
su - mini-buildd
cd ~/repositories//
reprepro listmatched stretch--experimental '*gstreamer*'
---

Thx!

S

Bug#951641: mini-buildd: MD5 conflict with doc packages when compiling "any" arch

[Stephan Sürken]

Hi Marc,

On Wed, 2020-02-19 at 12:17 +0100, Marc Leeman wrote:

(...)

> older platforms) and amd64 (current). I've come accross the following
> while backporting GStreamer 1.14.4 from buster to stretch.

just tried it here with no issues.

Ftr, I did a portext to stretch with

https://deb.debian.org/debian/pool/main/g/gstreamer1.0/gstreamer1.0_1.14.4-1.dsc

Could it be that in your stretch distribution, you have

'BUILD ARCHITECTURE ALL'

checked for both, amd64 and i386? 

Hth!

S

Bug#934978: mini-buildd: Does not function behind a NAT router

[Stephan Sürken]

Hi Daniel,

On Fri, 2019-08-23 at 22:07 +0200, Stephan Sürken wrote:
> On Mon, 2019-08-19 at 23:06 -0700, Daniel Schepler wrote:
> > On Mon, Aug 19, 2019 at 12:25 PM Stephan Sürken 
(...)
> Fwiw, I did all the tests with 1.0.x. I now see that you are testing
> 1.1.x ;) -- but the same might still apply.

For 1.1.x development, please try to run 'dpkg-reconfigure mini-buildd'
and change/add this endpoint argument:

--httpd-endpoint=tcp6:port=8066:interface=localhost

I guess this might solve the problem at hand.

Hth!

S

Bug#934978: mini-buildd: Does not function behind a NAT router

[Stephan Sürken]

On Mon, 2019-08-19 at 23:06 -0700, Daniel Schepler wrote:
> On Mon, Aug 19, 2019 at 12:25 PM Stephan Sürken 
> wrote:
> > I am not quite getting it ;), I guess I need more information here.
> > 
> > What's the 'Hostname' entry of the 'Daemon' instance?
> 
> localhost
> 
> > Do you have remotes configured (not needed if you are building on
> > that
> > host only)?
> 
> No, no remotes configured.

Hmm, checked a standard setup + hostname in Daemon set to "localhost",
and this worked fine. Also, there does not seem to be a stupid mistake
in the source not noticed until now (i.e., it uses the hostname set in
Daemon for the internal remote).

> Also, on further investigation, it appears that
> "a23-195-69-106.deploy.static.akamaitechnologies.com" is actually the
> FQDN of the host my ISP's broken DNS redirects me to for nonexistent
> host names :( , rather than the external IP address of the NAT
> router.

a23-195-69-106.deploy.static.akamaitechnologies.com really should not
show up. Sure you set the hostname to "localhost" in the Daemon
instance (i.e., not via --httpd-bind in the command line)?

Fwiw, I did all the tests with 1.0.x. I now see that you are testing
1.1.x ;) -- but the same might still apply.

Hth,

S

Bug#934978: mini-buildd: Does not function behind a NAT router

[Stephan Sürken]

Hi Daniel,

On Sat, 2019-08-17 at 08:53 -0700, Daniel Schepler wrote:
> Package: mini-buildd
> Version: 1.1.18
> Severity: wishlist
> 
> I think I've gotten my local mini-buildd instance mostly set up.  But
> now, when I try to upload to it to do a test build, I get a failure
> along the lines of:
> 
> Host: a23-195-69-106.deploy.static.akamaitechnologies.com
> Build request failed: 100 (upload-failed): Failed to update status
> for
> remote via URL '
> http://a23-195-69-106.deploy.static.akamaitechnologies.com:8066/mini_buildd/api?command=status=python'
> :
> 
> 
> I've verified by direct search through config.sqlite that no
> instances
> of that external host name are left in the configuration; yet it
> still
> seems to be getting that from somewhere as the address to connect
> builders to.  My intent is to use it only locally, and not to expose
> it to the internet.

I am not quite getting it ;), I guess I need more information here.

What's the 'Hostname' entry of the 'Daemon' instance?

Do you have remotes configured (not needed if you are building on that
host only)?

Thx!

S

Bug#933751: mini-buildd (build-)depends on cruft package.

[Stephan Sürken]

Hi Peter,

On Fri, 2019-08-02 at 22:11 +0100, Peter Michael Green wrote:
> Package: mini-buildd
> Version: 1.0.41
> Severity: serious
> 
> python-mini-buildd depends on and the mini-buildd source package 
> build-depends on the python-django-registration binary package which
> is 
> no longer built by the python-django-registration source package.

yes, or 'python2 django', for that matter ;). I guess it will be
removed from testing soon:

http://mini-buildd.installiert.net/articles/10x-maintenance-moved-to-hellfield-archive.html

> I notice this already seems to be fixed in experimental, are there
> any 
> blockers for uploading the experimental version to unstable?

The branch uploaded to experimental is development, and should not be
used for production.

I am pressing for a release asap (~months), then everything will be
fine again ;).

Hth!

S

Bug#924077: mini-buildd: sbuild-update has no option --keygen

[Stephan Sürken]

Hi "itd",

On Sat, 2019-03-09 at 12:31 +0100, i...@firemail.cc wrote:
> Package: mini-buildd
> Version: 1.0.36
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> sbuild (>= 0.77.0) no longer supports `sbuild-update` option `
> --keygen` 

ups yes - thx for the hint.

It's really time to go for that old compatibility workaround ;).

Will remove this in dev, ignore the error in stable.

Thx!

S

Bug#922614: mini-buildd: Doesn't actually call sbuild with --jobs option

[Stephan Sürken]

Hi Magnus,

On Mon, 2019-02-18 at 13:59 +0100, Magnus Holmgren wrote:
> Package: python-mini-buildd
> Version: 1.0.36~bpo9+1
> 
> The Change daemon page states about the Sbuild jobs option: "Degree of 
> parallelism per build (via sbuild's '--jobs' option)." but the option is only 
> passed via the DEB_BUILD_OPTIONS variable, not --jobs, meaning that no -j 
> option will be added to the dpkg-buildpackage command line nor MAKEFLAGS. 
> Packages using dh with --parallel or compat >= 10 will automatically use the 
> parallel option in DEB_BUILD_OPTIONS, but not other packages that don't parse 
> DEB_BUILD_OPTIONS by hand.
> 
> Perhaps it's actually not desirable to always set -j in MAKEFLAGS but in that 
> case the documentation should be changed to match reality.

hmm yes, you are completely right. And also I think --jobs is the
better choice here.

I did some research ;), and it seems I changed it from --jobs to env
back in 2013 due to <=etch compatibility issues:

commit 355893eb0202f507246569a0b922e89474f27369
Author: Stephan Sürken 
Date:   Thu Jan 3 17:02:26 2013 +0100

builder: Use env. DEB_BUILD_OPTIONS='parallel=N' instead of 'd-p -jN' 
(Fixes: Builds for <= etch).

Will fix the doc in stable (1.0.x), and switch to '--jobs' again in current 
development.

Thanks!

Stephan

Bug#922675: segfault on dir chroot prepare (in sqlite)

[Stephan Sürken]

Hi Marc,

On Tue, 2019-02-19 at 11:34 +0100, Marc Haber wrote:
> Package: mini-buildd
> Version: 1.0.36
> Severity: important
> 
> Hi,
> 
> I log in to my mini-buildd instance, start configuring, call up the
> Dir
> chroots, mark one, click on "prepare". The browser immediately
> returns a
> "connection reset", no mini-buildd process is there any more, and the
> syslog shows:
> 
> Feb 19 11:27:10 spinturn kernel: mini-buildd[1368]: segfault at 8 ip
> 7f25f375ef91 sp 7f25daff88f0 error 4 in
> libsqlite3.so.0.8.6[7f25f36f8000+da000]

I just ran the whole testsuite (and also did some manual chroot
prepares) on the 1.0.x branch with current sid/amd64 -- could not
produce the problem.

Same libsqlite afaics (/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6).

However, I hope this

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923038

is the same issue; then it might have been fixed in sqlite3 3.27.2-1
(w/o updating the so version)...

Could you recheck?

Thx!

S

Bug#898850: ui-utilcpp: FTBFS: syntax error in configure script

[Stephan Sürken]

Hi Sven,

On Wed, 2018-05-16 at 17:26 +0200, Sven Joachim wrote:
> Source: ui-utilcpp
> Version: 1.8.5-2
> Severity: serious
> 
> Your package FTBFS everywhere[1], the reason being that the configure

Ups yes, thanks for the hint ;).

I did not thoroughly check on this after the hasty post-salsa upload...

Thx!

S

Bug#858988: python-cherrypy3: https request error An unexpected TLS packet was recieved

[Stephan Sürken]

Hi Gerald,

On Wed, 29 Mar 2017 12:58:21 +0200 Gerald Hansen 
 wrote:
> Package: python-cherrypy3
> Version: 3.5.0-2build1
> Severity: normal
> 
> Dear Maintainer,
> 
> I try to use salt-api with cherrypi and ssl encryption.
> But the Debian version of cherrypy3 contains some bugs https://github
.com/saltstack/salt/issues/37783
> A installation with pip works fine and I also saw that the upstream
version is already at 10.x

could you check if that's still an issue with 8.9.1?

Thx!

S

Bug#855321: ui-auto: please deprecate or remove ui-auto-rsign and option to use debrsign

[Stephan Sürken]

On Tue, 2018-01-02 at 11:48 -0500, Daniel Kahn Gillmor wrote:
> The places you mention sound reasonable to me, though.

1.2.10-1 is now underway. Fwiw, relevant change is visible here:

https://sourceforge.net/p/ui-auto/ui-auto/ci/b656b4778c8a7b8b7b2212ba43b3f6a2f79ebc73/

(...)

> Finally, if you aren't actually maintaining the software, sometimes 

Sure -- however, I fear I brought that daemon upon myself ;), and I
will still 'maintain' upstream (via stable/bug fix point releases) as
long as needed. So it's doomed to be superfluous eventually, but not
just yet...

I hope this solves this, and, if that helps ;), I also have no
objections to removing debrsign from devscripts.

Have a nice day!

Stephan

Bug#886126: mini-buildd: using alt.files as keyring backend is highly impractical

[Stephan Sürken]

Hi "ydirson",

On Tue, 2018-01-02 at 16:09 +0100, ydir...@free.fr wrote:
> Package: mini-buildd
> Version: 1.0.29
> 
> With no external keyring software installed, python-keyring defaults
> to alt.files, and the impact
> on scripting (eg. launching auto-setup for a test) is quite high:
> 
> * have to enter keyring password for each keyring access
> * a single error in one of those numerous prompts stops the whole
> process:

to change the default of python-keyring, add a file
'~/.local/share/python_keyring/keyringrc.cfg':

--
[backend]
default-keyring=keyrings.alt.file.PlaintextKeyring
--

This will (not be very secure) but ok for a auto-setup test drive. I
definitely would not change the default keyring backend of python-
keyring in mini-buildd code.

auto-setup is currently a bash script, repeatedly calling m-b-t
(python), which adds to the "problem". For the future, auto-setup will
be integrated into mini-buildd itself; for now, the only option is to
properly configure python-keyring for the calling user...

Hth!

S

Bug#855321: ui-auto: please deprecate or remove ui-auto-rsign and option to use debrsign

[Stephan Sürken]

Hi Daniel,

On Thu, 2017-02-16 at 13:54 -0500, Daniel Kahn Gillmor wrote:
> Package: ui-auto
> Version: 1.2.9

(...)

> the debrsign workflow isn't a particularly safe one (see discussion
> on
> https://bugs.debian.org/855282 and https://bugs.debian.org/855320).
> 
> ui-auto should not encourage its use, and should probably either
> explicitly deprecate or just drop support for the debrsign option.
> 
> Additionally, ui-auto-rsign seems to encourage the same dubious
> workflow of making ssh connections from untrusted machines to trusted
> machines.  It should probably be deprecated or removed as well.

thx for the note :).

ui-auto is not actively developed any more, it's basically 'compat-
maintained' for projects still using it -- i.e., I do not much like
dropping functionality.

Would it be sufficient to add appropriate warnings

- in the example user.conf (*_rsign and *_debrsign options)
- when *_rsign resp. *_debrsign are called (as warning log)
- when ui-auto-rsign is called (as warning log)

?

Fwiw, both options (rsign or debrsign) are disabled by default and need
explicit configuration by the user.

Thx!

Stephan

Bug#867592: mini-buildd: "500 Internal Server Error" when trying to add an uploader's gpg pubkey

[Stephan Sürken]

Hi Frank,

On Mon, 2017-09-11 at 16:30 +0200, Frank Doepper wrote:
> Am 11.09.17 um 15:09 schrieb Stephan Sürken:
> 
> > commit a37e69c2bc8371b57531f4e65e0b271bc3b20617 (HEAD -> master)
> > However, I don't know if or how the other logs/findings you posted
> > here
> > relate to this. Maybe there is still another bug?
> > 
> > Could you retest with that patch applied?
> 
> The patch fixes the save-daemon bug, thanks for that.
> 
> But the "NOT NULL constraint failed: mini_buildd_uploader.user_id"
> when
> trying to add a new uploader's key is still there.

are you trying to *add* an actual Uploader instance?

If so, that is not possible. An Uploader instance is created
automatically for any new User (one-to-one relation). The only thing
you need to do as admin is to *change* Uploader instances that are
already there.

That's why in mini-buildd's custom config overview, the "add" button is
deliberately missing. It's not feasible afaik to phase out any adding
of instances via django's generic admin interface, so admittingly, it
sort of offers something that does not work ;).

So do you also have a problem *changing* an uploader instances with a
new public key?

Thx!

S

Bug#867592: mini-buildd: "500 Internal Server Error" when trying to add an uploader's gpg pubkey

[Stephan Sürken]

Hi Frank,

On Fri, 2017-09-01 at 17:57 +0200, Frank Doepper wrote:
> Am 23.08.17 um 12:06 schrieb Stephan Sürken:
> 
> > If the problem persists, could you enable "debug logging"
> 
> Yeah, I have sent you some backtraces yesterday.

actually, there is/was a code regression:

---
commit a37e69c2bc8371b57531f4e65e0b271bc3b20617 (HEAD -> master)
Author: Stephan Sürken <abs...@olurdix.de>
Date:   Mon Sep 11 14:46:50 2017 +0200

daemon.py: Fix broken 'save' of Daemon instances (regression in 1.1 only).

In 3370ecd8a0bdbd3d90deb0e77790180da7c227f9, code in daemon.py was cleaned
up, and update_to_model() method removed. However code in model/daemon.py,
using that very method, was overlooked, and hence broken.

This brings back update_to_model() in a somewhat modified form.

Closes: 867592
Thanks: Frank Doepper
---

-- thanks for detecting this!

So I am using this bug now to track that very regression.

However, I don't know if or how the other logs/findings you posted here
relate to this. Maybe there is still another bug?

Could you retest with that patch applied?

Thx!

Stephan

Bug#867592: mini-buildd: "500 Internal Server Error" when trying to add an uploader's gpg pubkey

[Stephan Sürken]

Hi Frank,

On Tue, 2017-08-22 at 13:33 +0200, Frank Doepper wrote:
> Am 16.08.17 um 17:09 schrieb Stephan Sürken:
> 
> > Just to be clear: We are talking about "Manage Account/Manage
> > Profile/Set New Key" via the web interface?
> 
> I'm talking about
> http://mini-buildd:8066/admin/mini_buildd/uploader/add/

I also tried that here, but can't produce that error.

> > Do you have the resp. log lines from daemon.log?
> 
> It's only one line:
> 
> 2017-08-22 13:32:34,127 [CP Server Thread-10] ERROR   : 500 Internal
> Server Error: Sorry, something went wrong [views:55]
> [mini_buildd.views:76]

Hmm, strange. That hilarious exception is from cherrypy ;).

Could you double-check you have an up-to-date sid system?

If the problem persists, could you enable "debug logging" [1], somewhat
like so:

# dpkg-reconfigure mini-buildd  # Use options: "--verbose --verbose 
--debug=exception,http,webapp"

Thx!

S

[1] 
http://mini-buildd.installiert.net/extra/mini-buildd/documentation/admin.html#logging-and-debugging

Bug#867592: mini-buildd: "500 Internal Server Error" when trying to add an uploader's gpg pubkey

[Stephan Sürken]

On Mon, 2017-08-14 at 18:06 +0200, Frank Doepper wrote:
> Am 25.07.17 um 14:16 schrieb Stephan Sürken:
> 
> > thx for testing experimental ;).
> > 
> > However, I could not produce this (with the current master branch).
> > 
> > Could you try if 1.1.4 fixes this?
> 
> 1.1.4 does not fix this.
> 
> maybe it is related to my deactivated "test" repository or other
> custom
> configuration.

sounds imaginable -- however, it still works here when I deactivate one
repo.

Just to be clear: We are talking about "Manage Account/Manage
Profile/Set New Key" via the web interface?

Do you have the resp. log lines from daemon.log?

Thx!

S

Bug#867592: mini-buildd: "500 Internal Server Error" when trying to add an uploader's gpg pubkey

[Stephan Sürken]

Hi Frank,

On Fri, 2017-07-07 at 18:09 +0200, Frank Doepper wrote:
> Package: mini-buildd
> Version: 1.1.3
> Severity: normal
> 
> When trying to add a new uploader's gpg key via web admin, "500
> Internal
> Server Error: Sorry, something went wrong" is the result. I would
> expect
> the key to be inserted into the uploaders' list.
> 
> It worked in former versions, this is experimental.

thx for testing experimental ;).

However, I could not produce this (with the current master branch).

Could you try if 1.1.4 fixes this?

Thx!

S

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

On Mi, 2017-02-08 at 15:33 +0200, Konstantinos Margaritis wrote:
> Στις 08-02-2017, ημέρα Τετ, και ώρα 14:14 +0100, ο/η Stephan Sürken
> έγραψε:

(...)

> > It seems it's just a "correctly failing build" -- please check your
> > build log ;)
> Argh, hate it when this happens :)
> 
> Thanks, imported the missing deps and it was built. However, would it
> be possible to add the possible reason as an extra explanation in the
> status? (ie, "possible missing build-deps"). I know I should have the
> read the log closer but maybe even a hint, would be nice to have as a
> wishlist.

we depend on sbuild here. For your case, Build status "given-back"
(instead of "attempted") could hint you to a b-d problem on the mini-
buildd page right away (yes, you need to hover on the build result to
see that).

Generally, I would love to have better "error perusal" for sbuild
runs/failed builds, but sbuild doesn't offer much here yet.

Hth,

S

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

Hi Konstantinos,

On Mi, 2017-02-08 at 14:27 +0200, Konstantinos Margaritis wrote:
> Στις 08-02-2017, ημέρα Τετ, και ώρα 11:51 +0100, ο/η Stephan Sürken

(...)

> > ) might be helpful, too.
> Ok, I stripped all but the debian directory and renamed the relevant
> name variables, the package still fails to build with the same
> message.
> Attaching the source package and the log.

ok, thx.

However, could it be that your are simply having incorrect build-deps?

At first, the build just plainly fails:

--
The following packages have unmet dependencies:
 sbuild-build-depends-test-sample-framework-dummy : Depends: libtest-se-blm1 
which is a virtual package and is not provided by any available package

Depends: 
python-networkmanager (>= 0.9.10-1+test1) but it is not going to be installed
Depends: 
python-requests-ntlm which is a virtual package and is not provided by any 
available package

Depends: python-xrandr 
which is a virtual package and is not provided by any available package
--

Removing these dependendies from control make the package build fine.

It seems it's just a "correctly failing build" -- please check your
build log ;)

Hth!

S

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

On Mi, 2017-02-08 at 11:51 +0100, Stephan Sürken wrote:
> Hi Konstantinos,

(...)

> ) might be helpful, too.

Also, it would be (easy and) helpful if you can just build the test
packages, and report whether test package 'mbd-test-archall' also fails
on your setup.

Thx!

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

Hi Konstantinos,


On Di, 2017-02-07 at 16:32 +0200, Konstantinos Margaritis wrote:
(...)

> I am attaching a sample dsc (I hope you only need the dsc and not the
> rest of the files, because it's an internal debian package and I had 

hmm ic.

I fear only a complete Debian Source Package would be of any help.

Alternatively, an excerpt of mini-buildd's log (with mini-buildd put
to debug (--verbose --verbose --debug=exception)

http://mini-buildd.installiert.net/extra/mini-buildd/documentation/admin.html#logging-and-debugging

) might be helpful, too.

Thx!

S

Bug#854480: reprepro && detached upstream signatures

[Stephan Sürken]

Hi Frank, all,

fwiw, a colleague of mine just debugged this (with patch), and added a
bug report on reprepro:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854480

Fwiw2, this feature came in with

---
dpkg (1.18.5) unstable; urgency=medium

  (...)
  * Perl modules:
  (...)
- Allow detached upstream orig tarball signatures when extracting
  version 1.0 non-native source packages.
- Include upstream orig tarball signatures in source packages.
  See #759478.
---

and here's the link to the Bug report discussing it in length:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759478

Hth!

S

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

Hi Konstantinos,

On Di, 2017-02-07 at 12:57 +0200, Konstantinos Margaritis wrote:
> Hello,
> 
> I just wanted to say that I was able to reproduce this bug on a
> stretch
> based system (mini-buildd 1.0.29), building 2 arches, i386/amd64,
> where
>  i386 is optional and amd64 builder builds arch:all packages. I
> uploaded a python package in both source and binary form (ie,
> source.changes, amd64.changes) and in both cases I'm getting the
> FAILED
> status, message:
> 
> 1 mandatory architecture(s) missing: amd64

thanks for the report.

However, what really would help me is an URL to such a failing DSC, so
I can try to reproduce and debug the behavior.

Thx!

S

Bug#849551: spurious "internal error building" related to gpg

[Stephan Sürken]

Hi Marc,

On Fr, 2016-12-30 at 13:57 +0100, Marc Haber wrote:
> On Fri, Dec 30, 2016 at 01:26:09PM +0100, Stephan Sürken wrote:

(...)

> That would be:
> > 
> > Dec 28 13:44:29 spinturn mini_buildd.call (0114):
> > WARNING : ? gpg.. (stderr): gpg: can't connect to the agent: IPC
> > connect call failed
> I don't have a solution for that other than to retry at least once.
> Maybe too many operations in too short time confusing the agent?

coincidentally doing some testing on another platform, I also
experienced this behaviour (again), so I tried to do some debugging.

Bottom line 1st: I could not definitely pin it down. However, at least
on the system I experience this, a "just try again after some time"-
style workaround seems to work. This workaround will be in 1.0.29 (now
in current snapshots from hellfield).

With this workaround being applied, look for "Retrying" in the log to
actually still see the bug.

On the system where this is happening, this is currently the simplest
way for me to reproduce this:

1. Run attached ./signtest as user mini-buildd.
2. Rebuild any package.

"signtest" will then eventually error out with the described error, at
least most of the times. Without any building action, signtest will
just run successfully forever.

I am guessing this might be some sort of race condition with the gpg
stuff sbuild is doing; however, it could also be some esoteric/kernel
thing, as I cannot for the life of me get the bug occur on any other
systems yet.

[The system I actually can reproduce the bug is container-based
(openvz), with the host using some older patched kernel.]

Hth,

S

signtest
Description: application/shellscript

Bug#849551: spurious "internal error building" related to gpg

[Stephan Sürken]

On Do, 2016-12-29 at 19:48 +0100, Marc Haber wrote:
> On Thu, Dec 29, 2016 at 07:40:27PM +0100, Stephan Sürken wrote:
> > 
> > On Do, 2016-12-29 at 18:41 +0100, Marc Haber wrote:
> > > 
> > > i can grep for "0041" to find the complete log for this process,
> > > right?
> > No, that would be the line number in code ;).
> Then I can only say that the line just before the error message in
> the
> log is just "Queueing incoming changes file" and not gnupg2 output.

fwiw, you would need to check more previous lines, looking for
something like

--
WARNING   : ? gpg.. (stderr): gpg:
--

As mini-buildd is multi-threaded, you can't tell for sure what other
logs are in between, or what logs belong to what context.

However, thinking about this ;), I have patched up threading/logging
for 1.0.28 (including making all logs from one build grep-able).

Preliminary snapshot would be available from here:

http://mini-buildd.installiert.net/extra/mini-buildd/changes/mini-buildd_1.0.27snap20161230120659~ab~SID+0_source.changes
deb http://debian.installiert.net/hellfield-ab/ sid-ab-snapshot main contrib 
non-free

Hth,

S

Bug#849551: spurious "internal error building" related to gpg

[Stephan Sürken]

On Do, 2016-12-29 at 18:41 +0100, Marc Haber wrote:

(...)

> If I have the error message:
> 
> Dec 28 14:35:22 spinturn mini_buildd.builder  (0041):
> ERROR   : Internal error building: Call failed with retval 2: 'gpg --
> homedir /var/lib/mini-buildd/.gnupg --display-charset UTF-8 --batch 

(...)

> i can grep for "0041" to find the complete log for this process,
> right?

No, that would be the line number in code ;).

MfG,

S

Bug#849544: bind mount for home directory needed if not on root fs

[Stephan Sürken]

On Mi, 2016-12-28 at 13:13 +0100, Marc Haber wrote:
> Package: mini-buildd
> Version: 1.0.27
> Severity: normal

(...)

> My current fix is not a real fix since /etc/schroot/mini-buildd/fstab
> is likely to be overwritten with the next mini-buildd update.
> 
> How would a local admin make mini-buildd work in this environment? 

Local admins should do changes if needed in "fstab-generic" (also see
comments in that file). You will get standard conffile handling for
that file (while 'fstab' is auto-generated only).

This should at least partly help (unless there are any order issues ;).

Hth,

S

Bug#849547: clicking retry on a failed build will result in an immediate reject

[Stephan Sürken]

On Do, 2016-12-29 at 18:36 +0100, Marc Haber wrote:
> On Thu, Dec 29, 2016 at 06:09:25PM +0100, Stephan Sürken wrote:
> > 
> > Could it be you are running with reprepro < 5? (#843402)
> No, I pulled the version from experimental.

I am out of guesses, then ;).

Fwiw, I have just retestet locally that the "Retry now" button
(correctly) does not appear in case one optional arch failed
(status=INSTALLED).

What was the status of the package that delivered the log page with the
retry button? I.e., INSTALLED or FAILED, and if FAILED, what was the
error message?

MfG,

S

Bug#849551: spurious "internal error building" related to gpg

[Stephan Sürken]

Hi,

On Mi, 2016-12-28 at 14:22 +0100, Marc Haber wrote:

(...)

> again and uploaded again. This time the build went through just fine.

I have previously seen similar behavior too, but not any more for quite
some time.

I had the impression this was a temporary behavior of some version of
the gnupg2 package. Not sure what's going on there, really, atm ;).

> If the gpg call had produced any output, where would I have been able
> to see it?

Yes, the command's output, if any, should precede the exception log
line you pasted here.

Hth!

S

Bug#849547: clicking retry on a failed build will result in an immediate reject

[Stephan Sürken]

Hi,

On Do, 2016-12-29 at 17:24 +0100, Marc Haber wrote:

(...)

> > > packages being built correctly with the armhf build failing.
> > with armhf being set up as optional arch?
> Probably not. It is not really optional, I didn't notice that armhf
> was offline.

it rather should be; else mini-buildd should not have tried to install
the package at all (and I would be confused).

> > taint the version).
> I mean "retry now", yes.

hmm then ;).

Could it be you are running with reprepro < 5? (#843402)

mini-buildd does not handle that bug/missing feature in reprepro well;
it installs the source package, but reprepro fails on the first binary
package installation. This would actually lead to a "log page"
including the non-working "retry" button.

Hth,

S

Bug#849547: clicking retry on a failed build will result in an immediate reject

[Stephan Sürken]

Hi Marc,

On Mi, 2016-12-28 at 13:35 +0100, Marc Haber wrote:
(...)
> When I uploaded a package to mini-buildd, I didn't notice that my
> armhf builder was being offline. This resulted in the i386 and amd64
> packages being built correctly with the armhf build failing.

with armhf being set up as optional arch?

> After reparing the armhf builder, I clicked on "rebuild" in the

I guess you mean the "Retry now" button on the "log page" instead?

"retry now" should only be available for failed (not installed)
packages, "rebuild" (via "show") is for installed versions (and would
taint the version).

Thx!

S

Bug#843402: Fwd: reprepro_5.0.0-1_amd64.changes ACCEPTED into experimental

[Stephan Sürken]

Hi Bernhard,

On Do, 2016-12-22 at 10:28 +0100, Bernhard R. Link wrote:
> I'd appreciate if those invovled could test the version of reprepro
> currently in experimental. I plan to upload 5.0.1 to unstable with
> some additional smaller things to unstable tomorrow (Friday) evening
> (UTC).

great!

Fwiw, 5.0.0 works fine "for me", i.e. in a setup w/o any tracking.

I have actually tested this under sid/experimental as well as under
jessie and wheezy (one may find preliminary jessie/wheezy ports here

 http://debian.installiert.net/hellfield-ab/pool/main/r/reprepro/

if that helps).

MfG,

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

On Di, 2016-11-22 at 11:33 +0100, Patrick Matthäi wrote:

(...)

> Thanks for your effort! I have just uploaded 1.0.3-3.
> 
> Would you (Stephan) be so kindly and upload it to jessie-bpo, if
> there
> are no new problems with it? I will be on vacation before it may ent

fwiw, I did just port this.

Fwiw2 ;): I have also created an upstream ticket for this:

https://github.com/DE-IBH/apt-dater/issues/124

Hth!

S

Bug#802689: please consider allowing to switch off lintian for architectures

[Stephan Sürken]

Hi Marc,

On Do, 2015-10-22 at 18:27 +0200, Marc Haber wrote:
> Source: mini-buildd
> Version: 1.0.7
> Severity: wishlist

(...)

> Please consider implementing a possibility to say "don't run lintian
> on this architecture" or "dont run lintian on builds done by this
> builder".

fwiw, 1.0.26 now has a "per-upload option" that can do this:

http://mini-buildd.installiert.net/extra/mini-buildd/documentation/user.html?#upload-options

There is no way yet to configure this to do it by default, though.

Hth!

S

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Stephan Sürken]

On Tue, 22 Nov 2016 19:08:06 +0100 =?utf-8?q?Sl=C3=A1vek_Banko?= 
 wrote:
> Dne út 22. listopadu 2016 Stephan Sürken napsal(a):

(...)

> without "Tracking", buildinfo files are not processed - "reprepro include" 
> ignores them.
> 
> With "Tracking: minimal" (without "includebuildinfos") and with "Permit: 
> unused_files" (see workaround from message 10), buildinfo files are not 
> processed - "reprepro processincoming" ignores them.

thx, that's what I thought. Seems the patch still has some issues when
tracking is configured.

> However, I thought that the purpose of the patch was to add support for 
> processing buildinfos.

Imho, the main purpose should be to make such new changes installable
at all again, with or without actually processing buildinfo files.

But I guess you are right, Guillem's patch also seems to try to process
them.

Let's keep him in good mood by more excellent feedback so he might
improve it ;).

Hth,

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi Patrick,

On Di, 2016-11-22 at 11:33 +0100, Patrick Matthäi wrote:

(...)

> > S
> Thanks for your effort! I have just uploaded 1.0.3-3.

ok, thx!

> Would you (Stephan) be so kindly and upload it to jessie-bpo, if
> there
> are no new problems with it? I will be on vacation before it may
> enter
> testing.

ok, I will do that if I don't forget ;).

@evgeni: Would be nice if you could retest this.

Fwiw, to properly test matches, I emulated some "error logs" on hosts
using s.th. like this

---
DPkg::Pre-Install-Pkgs {"/usr/bin/printf 'E: apt-dater\n'";};
DPkg::Pre-Install-Pkgs {"/usr/bin/printf 'apt-dater ERROR\n'";};
DPkg::Pre-Install-Pkgs {"/usr/bin/printf 'W: apt-dater\n'";};
---

as extra apt.conf (this still needs an actual package upgrade to take
place to see these logs).

Hth!

S

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Stephan Sürken]

Hi Slavek,

On Tue, 22 Nov 2016 00:31:47 +0100 =?utf-8?q?Sl=C3=A1vek_Banko?= 
 wrote:

(...)

> When I use "reprepro include", I got:

(...)

> Aborted
> 
> Buildinfo files are generated by dpkg 1.18.15 (already included in 
> Stretch). Tracking is set to: minimal includebuildinfos
> 
> Please, is there something else that I should have set up?

only a guess: Does "include" work w/o any tracking configured?

On mbd, there is no tracking at all atm, and "include" seems to work
just fine.

Hth,

S

Bug#843608: mini-buildd: reprepro not recognizing .buildinfo file, causing upload failure

[Stephan Sürken]

Hi Boyuan!

On Di, 2016-11-08 at 22:38 +0800, Boyuan Yang wrote:
> 在 2016年11月8日星期二 CST 下午3:31:49，您写道：

(...)

> The only truth is that mini-buildd with dpkg >= 1.18.11 will stop
> working, and 
> it should be fixed *somehow* *somewhere* before this bug gets closed.

Fwiw, there is now a patch available for reprepro by Guillem:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843402#25

This seems to work fine for mini-buildd, but it's still being tested
afaiu.

However, "preliminary convenience" packages with that patch are
available to ease the pain from here:

http://mini-buildd.installiert.net/pages/the-hellfield-archive.html

Look for apt sources for wheezy-ab-stable, jessie-ab-stable or sid-ab-
unstable, resp. (others have done packages, too, see bug report).

Hth!

S

Bug#843402: reprepro cannot handle .changes files that reference .buildinfo files

[Stephan Sürken]

Hi Guillem, all,

On Fri, 18 Nov 2016 14:21:08 +0100 Guillem Jover  wrote:

(..)

> Ok, Michael Prokop deployed it on jenkins.grml.org and retriggered at
> least the dpkg jobs and they seem to work now. I've fixed an
inversion
> logic error in the previous patch and I'm including the good one
here.
> Review and more testing would be very appreciated.

thanks for the patch!

Fwiw, I have done ports with your patch for sid/jessie/wheezy [1], and
retested via mini-buildd and experienced no issues, i.e.:

* 'reprepro include' no longer fails.
* Packages get installed as before.

So it seems to be fine at least how mini-buildd calls reprepro.

Hth, and thx!

S

[1] http://mini-buildd.installiert.net/pages/the-hellfield-archive.html
    http://debian.installiert.net/hellfield-ab/pool/main/r/reprepro/

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi Patrick,

On Mo, 2016-11-21 at 10:12 +0100, Patrick Matthäi wrote:

(...)

> > S
> Ok so adding patch
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827339#34 and drop
> current patch 01-grep-syntax-error ?

sure, that would be my suggestion.

For your Debian patch, you should maybe only use the "entity fixes" of
my patch (not the additions to the regex of my personal liking which
are also in there ;).

@Thomas:

Of course upstream should fix this too, eventually.

Thx!

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi,

On Fr, 2016-11-18 at 17:01 +0100, Patrick Matthäi wrote:
> Am 17.11.2016 um 18:52 schrieb Stephan Sürken:
> > 
> > Hi Patrick,
> > 
> > On Do, 2016-11-17 at 15:40 +0100, Patrick Matthäi wrote:
> > (...)
> > > 
> > > Then the question is, why it does not work on Jessies grep?
> > did you overlook my comment? Or are my findings wrong?
> > 
> > Thx!
> > 
> > S
> Ah now I get it. You have adjusted the C code of apt-dater, to detect
> errors without using HTML.

not quite. I rather fixed the default pattern being used when the user
does not configure one.

> But we have got still the problem, that the default grep syntax (also
> your fixed grep syntax) from "typescript" produces a more or less
> silent
> "syntax error", like from the beginning of this report.

afaict, my patch just fixes each and every aspect of this bug report
;).

Hth,

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi Patrick,

On Do, 2016-11-17 at 15:40 +0100, Patrick Matthäi wrote:
(...)
> Then the question is, why it does not work on Jessies grep?

did you overlook my comment? Or are my findings wrong?

Thx!

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi all,

On Do, 2016-11-10 at 22:09 +0100, Thomas Liske wrote:

(...)

> this is a negative lookbehind assertion - quoting from perlre(1):

(...)

Afaics, the hardcoded default value for err-pattern falsely uses HTML
entities. These are needed in the XML config obviously, but not in
getXPropStr() default value argument.

With this patch, the default "err-pattern" works for me:

---
$ absurd? cat debian/patches/02-fix-default-err-pattern.patch 
diff --git a/src/keyfiles.c b/src/keyfiles.c
index affdb2b..2e04a6b 100644
--- a/src/keyfiles.c
+++ b/src/keyfiles.c
@@ -401,7 +401,8 @@ gboolean loadConfig(const gchar *filename, CfgFile *lcfg) {
 
 #ifdef FEAT_HISTORY
 lcfg->record_history = getXPropBool(s_history, "record", TRUE);
-lcfg->history_errpattern = getXPropStr(s_history, "err-pattern", 
"((?!no )error|(?!insserv: )warning|fail(ed)?)");
+/* lcfg->history_errpattern = getXPropStr(s_history, "err-pattern", 
"((?!no )error|(?!insserv: )warning|fail(ed)?)"); */
+lcfg->history_errpattern = getXPropStr(s_history, "err-pattern", "((?history_dir = getXPropStr(s_path, "history-dir", 
g_strdup_printf("%s/%s/history", g_get_user_data_dir(), PACKAGE));
 #endif
---

This patch also adds patterns for "E: foo" "W: bar"-types of logs
(which I think are useful).

Hth!

S

Bug#843608: mini-buildd: reprepro not recognizing .buildinfo file, causing upload failure

[Stephan Sürken]

Hi Boyuan,

On Di, 2016-11-08 at 13:51 +0800, Boyuan Yang wrote:
> Source: mini-buildd
> Severity: important
> Tags: upstream
> 
> Upstream bug #843402.

I have tagged that reprepro bug as "affecting mini-buildd".

mini-buildd can't do anything about that, really. Do you have any
reasons to have an extra bug here, or can I close this?

Thx!

S

Bug#832643: mini-buildd: Please provide options for repository structure similar to official repo

[Stephan Sürken]

Hi Boyuan again,

On So, 2016-10-23 at 20:50 +0200, Stephan Sürken wrote:
> Hi Boyuan,
> 
> On So, 2016-10-23 at 15:53 +0800, Boyuan Yang wrote:
> (...)
> > 
> > Several months have passed since last update. Still I think this is
> > something

(...)

> No, I don't think so. From your description I would think that this
> is
> just a bug in mini-buildd that has crept in at some time for that
> special configuration -- given that I don't use that anywhere myself
> in
> production instances, nor in my "big wheel testing" ;(.

the Meta-Distribution handling was in fact broken, so I have chosen a
better title for this bug.

So, 1.0.25...

* Fixes this, so these uploads actually build ;).
* Adds error handling against ambiguity in Meta-Distributions.
* Adds "debdev" repository wizard (and some extra test builds) to my personal 
testing gear.
* Adds some more doc about this special feature in the "Online" manual:
   
http://mini-buildd.installiert.net/extra/mini-buildd/documentation/admin.html#meta-distributions

Hope this makes work what you aim to achieve.

Fwiw, your initial bug title speaks of "repository structure similar to
official repo". This is not what the "Meta-Distributions" feature does,
it's not really more than a mapping of incoming changes distributions
to actual mini-buildd (x-y-z) distributions.

This also means there is currently no way to access a meta distribution
like "unstable" (i.e., by that very naming) via sources.lists. I guess
that might be feasable however (we would need to check what reprepro
offers here?); if you need that, too, it would be nice to open a new
wishlist bug for that.

Hth!

S

Bug#827339: Please revert patch for cmd, and fix default pattern

[Stephan Sürken]

Hi Evgeni, Patrick,

fwiw (probably this is already worked on), i have fixed up my system by

* reverting 01-grep-syntax-error.diff

This actually totally breaks things, as this now uses "P" as pattern,
practically matching always:

--
grep -aiqseP "$AD_HIST_ERRPATTERN" "$AD_HIST_PATH/typescript"
--

I would actually like to see call grep (in the cmd script) called like so

--
grep -a -q -i -s -P -e "$AD_HIST_ERRPATTERN" "$AD_HIST_PATH/typescript"
--

(however, '-aiqsPe' should work as well).

* Use custom err-pattern

I don't really know what's wrong with the default perl regex (should
the '' stuff be actually be in the final string?), I am just using
a simpler one now that works. On a shell you can see the error via

--
grep -P -e '((?!no )error|(?!insserv: )warning|fail(ed)?)'
--

(That's the same string you also see in the "meta" debug file, using
all defaults for err-pattern).

So for me it seems:

* With the default pattern in place (and pre-patch), the grep would
always fail, meaning it would never detect an actual error in
typescript.
* With the broken patch, it always wrongly finds errors (while showing
an empty log via less).

So please remove 01-grep-syntax-error.diff, and somehow fix the default
pattern ;).

Hth!

S

Bug#832643: mini-buildd: Please provide options for repository structure similar to official repo

[Stephan Sürken]

Hi Boyuan,

On So, 2016-10-23 at 15:53 +0800, Boyuan Yang wrote:
(...)
> Several months have passed since last update. Still I think this is
> something
(...)
> Just as the log says in the previous email (20160731), we would meet 
> 
> Package 'cutegram_2.9.5-1aseman-xenial+git20161022.0.2373dd32-1'
> REJECTED: Malformed distribution 'unstable': Must be
> '--[-rollback]'
> 2016-10-23 13:33:24,139 mini_buildd.views(0078):
> INFO:
> API call 'logcat' by user 'admin' [views:206]

my apologies, I did not have time to look at this at all until now ;).

> FYI, this mini-buildd instance is set on "https://b.hosiet.me;.

Ah nice ;).

> I grep-ed through your source code and found the class called
> mini_buildd.misc.Distribution is causing problems. Appearantly it is
(...)
> So why would things bother like this? Well, I still want to upload a
> package
(...)
> now because such packages would be REJECTED due to the
> Malformed-Distribution problem as I stated above.
> 
> It would be great if we could finish that goal before Stretch freeze.

Yes. I am actually currently trying to bring any bug/wishlist fixes or
roadmap features "anyhow feasable for 1.0.x" in before switching to
1.2.x development (which somehow coincidences with the stretch
release).

No promises ;), but I think I will look into that for 1.0.25.

> If there
> is anything wrong, please point it out for me :)

No, I don't think so. From your description I would think that this is
just a bug in mini-buildd that has crept in at some time for that
special configuration -- given that I don't use that anywhere myself in
production instances, nor in my "big wheel testing" ;(.

Hth!

S

Bug#838393: PCA on a repository insufficient to update uploaders

[Stephan Sürken]

Hi Sam,

On Mi, 2016-09-21 at 13:05 -0400, Sam Hartman wrote:
> So, I can see a couple of easy fixes:
> 
> 1) have _uploaders be a class variable rather than an instance
> variable
> 
> or
> 
> 2) store a list ofweakrefs to extant demon objects
> 
> then provide a class method to invalidate all the uploaders caches.

thx, I will eventually look into the options.

However, and for documentation's sake: This is not just an issue with
the uploaders keyring, also any values you change in the Daemon
instance -- and maybe others, I haven't looked at that specific code
for some time ;).

So I have updated the title accordingly...

Hth,

S

Bug#809127: links to still-building package log broken

[Stephan Sürken]

Hi Marc,

On So, 2015-12-27 at 13:43 +0100, Marc Haber wrote:
(...)
> When a package is still building, it shows up directly on the
> mini-buildd web page without having to unfold the packager's package
> list (by clicking on "Last packages: 100 (show)".
> 
> In this state, build logs for already-finished builds are not
> accessible. The link pointed to by the architecture name all point to
> the builder's host name port 8066, no path.
>
> In the list that can be unfolded by clicking on "Show", the
> architecture name points to the full build log. This should be the
> case for still building packages at least for the architecture that
> has already finished building. Otherwise one has to wait for the
> slowest arch to finish before one can see the log of an arch that has
> already failed.

sorry for the late reply, but I basically always agreed here. However,
I took the liberty to update this bug's title to what I guess your
intention is :).

Fwiw: The Link is not "broken", it just intentionally directs to the
builder host the package is currently building on. I.e., you can at
least hop to the builder host to see the build status there.

However, the builder's build stati do not include the build logs at all
currently, they are only visible later on the packager after it has
collected all build results.

So I would think mini-buildd needs some support to view live build logs
on builder hosts, along with some caching/persistence so that this is
still available after the buildresult has been uploaded.

Another option would be to improve the packager to already show results
before all build results have arrived. That would change much more
logic though, and would not give us live build logs.

Hth!

S

Bug#831750: mini-buildd: Poor support for reverse proxy when working with apache

[Stephan Sürken]

Hi Boyuan,

On Di, 2016-07-19 at 09:55 +0800, Boyuan Yang wrote:
> Source: mini-buildd
> Version: 1.0.12
> Severity: normal

(...)

> However, someone may want to setup using reverse proxy. For example,
> let
> "https://mywebsite.com/debian/buildd/; proxy_pass to
> "http://localhost:8066/;.
> For apache, `mod_proxy` and `mod_rewrite` may be used to fix URLs in
> the HTML
> file.

fwiw, there is an example in mini-buildd

/usr/share/doc/mini-buildd/examples/apache-ssl-proxy.conf

which does "work for me" (albeit a somewhat different use case, afaiu).

> The problem is there are *always* some resource files failing with
> 404. The
(...)
> something else, and failed to be converted by mod_rewrite.

That's a little over my head for now ;).

I guess I need some more details about your configuration, and what
resources actually fail.

> May consider setting up an option for such situation, just as what
> gogs and
> some other web applications do.

What do you mean exactly here? Is there some django option to do just
that?

Thanks!

S

Bug#836193: Improper handling of arch all only package

[Stephan Sürken]

Hi Sam!

On Mi, 2016-08-31 at 06:50 -0400, Sam Hartman wrote:
> package: mini-buildd
> version: 1.0.12
> severity: normal
> 
> I uploaded  the source of an arch all package (no arch any in the
> resulting build) and got:
> 
> 2016-08-30 22:06:57,398 mini_buildd.packager (0039):(...) 

(...)

> issing_mandatory_archs), a=" ".join(missing_mandatory_archs)))
> Exception: 1 mandatory architecture(s) missing: amd64

Hmm -- there is the internal test package "mbd-test-archall"; this one
works fine for me.

> I'll admit that sbuild isn't great with that situation either; I've
> filed some bugs there too.

I assume this is #836154?

Could you be any means provide an URL to that failing DSC, so I can
check myself?

Thanks!

S

Bug#837537: "Mkdir: file exists" error if any debootstrap file download failed

[Stephan Sürken]

Hi Boyuan!

On Mi, 2016-09-14 at 10:43 +0800, Boyuan Yang wrote:

(...)

> to download *once*. The dir-chroot creating process should either
> fail
> immediately or re-run the debootstrap process again with a warning
> sent to the logger,
> but it just continued as if everything is fine *until* the mkdir
> error
> happens (which is due to the unclean exit of debootstrap, maybe?)

Hmm don't know. I tested around quite a lot lately, and did not
experience such a behavior.

Could you try to reproduce this with 1.0.21? This may have some nicer
logging for these calls, and maybe an excerpt of this log might shed
some light ;).

Thx!

P.S.: Ah: <= 1.0.21 has a little bug in the service file (mini-buildd
might not use the default log level), so you might want to apply this
first (or wait for 1.0.22):

diff --git a/debian/mini-buildd.service b/debian/mini-buildd.service
index 6809dda..0a184f2 100644
--- a/debian/mini-buildd.service
+++ b/debian/mini-buildd.service
@@ -4,6 +4,7 @@ Documentation=man:mini-buildd(8)
 After=remote-fs.target
 
 [Service]
+Environment=MINI_BUILDD_OPTIONS="--verbose"
 EnvironmentFile=-/etc/default/mini-buildd
 User=mini-buildd
 ExecStart=/usr/sbin/mini-buildd $MINI_BUILDD_OPTIONS

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Stephan Sürken]

Hi Ansgar,

On Mi, 2016-09-21 at 00:18 +0200, Ansgar Burchardt wrote:

(...)

> Ansgar Burchardt writes:

(...)

> > Only adding -k for newer distributions (i.e. the ones that merged-
> > /usr
> > supports) should work around the problem.
> I pushed a patch implementing this to my debootstrap
> repository[2].  It

great, thanks!

> worked for Squeeze (w/o merged-/usr) and Stretch (w/ merged-/usr).

While i am at it anyway, I did bulk-test this for

stretch,sid,jessie,wheezy,squeeze,lenny,etch X i368,amd64:

1.0.83 vanilla:

* All work except squeeze (i386+amd64). 

1.0.83+5bb1da69596828821fe43b3ee63f733e4b8672e7(your patch):

* All work fine.

So I really think your patch is fine ;).

Hth,

S

Bug#838393: PCA on a repository insufficient to update uploaders

[Stephan Sürken]

Hi Sam,

On Di, 2016-09-20 at 15:40 -0400, Sam Hartman wrote:
(...)

> I've found that I need to restart the demon (I used systemctl,
> although
> perhaps starting/stopping the daemon in the web interface would have
> been sufficient).
> 
> 
> It looks like what's happening is that the cache mapping repository
> identities to uploader keyrings is stored on the demon object in the
> _uploaders field and this isn't being refreshed when a repository is
> reconfiged.
> 
> You could argue that cache is a demon thing, and so it is proper
> behavior, but it's very confusing.
> I think it would be worth having repository reactivation trigger
> refreshing that cache.

no, I actually explicitly agree here, it's confusing. There is actually
an item for that lingering on my TODO list for some time ;):

http://mini-buildd.installiert.net/articles/raw-development-todo-sep-2016.html

The way the code is designed prevents an easy fix currently, but I will
definitely try to improve that eventually.

Hth,

S

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Stephan Sürken]

Hi Julien,

On Di, 2016-09-20 at 21:09 +0200, Julien Cristau wrote:

(...)

> > It always exits here with exit code 2, without any further error
> > message (not even when using --verbose).
> > 
> There should be a log inside the target directory.

ah, sure ;).

debootstrap/debootstrap.log says:

---
gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
gpgv:using RSA key AED4B06F473041FA
gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
"
gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
gpgv:using RSA key 64481591B98321F9
gpgv: Good signature from "Squeeze Stable Release Key 
"
tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File 
exists
tar: ./bin/sh: Cannot create symlink to 'dash': File exists
tar: Exiting with failure status due to previous errors
gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
gpgv:using RSA key AED4B06F473041FA
gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
"
gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
gpgv:using RSA key 64481591B98321F9
gpgv: Good signature from "Squeeze Stable Release Key 
"
tar: ./lib/libacl.so.1.1.0: Cannot open: File exists
tar: ./usr/share/doc/libacl1/copyright: Cannot open: File exists
tar: ./usr/share/doc/libacl1/changelog.Debian.gz: Cannot open: File exists
tar: ./usr/share/doc/libacl1/changelog.gz: Cannot open: File exists
tar: ./lib/libacl.so.1: Cannot create symlink to 'libacl.so.1.1.0': File exists
tar: Exiting with failure status due to previous errors
---

Hth!

S

Bug#836156: improper handling of source+binary changes triggering binary builds

[Stephan Sürken]

Hi Sam,

On Di, 2016-09-06 at 08:27 -0400, Sam Hartman wrote:

(...)

> I don't know.  We normally do source only uploads.
> Actually, it may be arch all handling.  The package in question only
> produced an arch all binary.
> So, the most direct thing to test would be a binary+source upload of
> a
> package producing only an arch all deb.

sorry for the delay. I did debug this today, and I can reproduce it.

What I think is happening:

* Binary+source upload is happening.
* Build requests are uploaded to the builders (including debs).
* sbuild is triggered.

Now, sbuild (newly?) fails to overwrite (existing) debs in the builddir
for some reason (and will also state so in the build log via an error
log), but otherwise happily continues as "successful" build.

mini-buildd now (also very happy) mixes the new changes with the old
(not overwritten) deb in the build result.

The first thing were this crashes is when trying to install the binary
via the wrong changes file into the repository via reprepro. This
usually leads to only the source package being installed, and
misleading errors.

It's maybe noteworthy that reproducible builds (i.e., current builds
for sid) often masquerade this bug as the resulting debs may actually
be identical ;).

I am now going towards not adding any *.deb-Files to the build requests
in the first place, which (is some improvement in its own) and should
fix the issue, no matter how sbuild actually behaves.

So this should hopefully be fixed with the next upload.

Thx for spotting this!

S

Bug#820699: possible upcoming incompatibility with schroot 1.7

[Stephan Sürken]

Hi Marc,

On Mo, 2016-04-11 at 15:54 +0200, Marc Haber wrote:
(...)
> So please be advised to check compatiblity with schroot 1.7.

thx. I checked, and it's indeed not compatible ;).

However, I will not try to fix this right now, rather avoid it for the
moment:

control: Dep: Avoid schroot >= 1.7 for now (atm, we are not compatible with 
schroot 1.7).

1.7 is a development release. We rather postbone trying to be compatible
until 1.8 is released (or it hits unstable). In the meantime, avoid
people accidentially updating to it.

> It would also be a good idea to give a clear error message if sbuild
> does not find the spool directory mounted in the chroot. I have found
> this to be an extremely common error which is a hell to debug.

Different issue, however: Is there an easy way to detect that specific
error (or does this need monkey-parsing the build log)?

Thx,

S

Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17

[Stephan Sürken]

Hi Santiago,

On Mo, 2016-09-12 at 21:34 +0100, Santiago Vila wrote:
(...)
> > Lastly, one other option for gnupg at least is to patch upstream to
> > use
> > --debug-quick-random in the build-time test.
> > 
> > do any of these options sound more appealing than the others?
> I didn't know about --debug-quick-random, it seems perfect to me.
> 
> Stephan, do you think it would be possible to patch mini-buildd so
> that --debug-quick-random is added to gnupg command line, but only
> when the package is doing the tests following the build?

fwiw, I quickly tested '--debug-quick-random', and it does the trick,
albeit for 2.1 only. So I unfortunately cannot use it (needing to
support 1.4 still as well).

I am now doing the doctest with pre-built keys, so this is will
hopefully finally settle this issue with the next upload.

Btw, it's only now that I actually grasp your initial problem was about
entropy all along ;). I just blatantly assumed your initial bug report
was about the doctest failing due to GPG 2.1 (which it did at the time,
entropy or not).

Thx,

S

Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17

[Stephan Sürken]

Rehi,

On Mo, 2016-09-12 at 21:34 +0100, Santiago Vila wrote:
> On Mon, Sep 12, 2016 at 07:34:09PM +0200, Daniel Kahn Gillmor wrote:
> 
> > 
> > An even easier approach might be to do the following within the
> > build:
> > 
> >   * ln -sf /dev/urandom /dev/random
> > 
> > why would we need the blocking kernel RNG in the buildd anyway?
> Either that, or maybe a build-depends on a package specifically
> created to do that (as I'm not sure we could really ask all buildd
> operators to make the symlink permanently).
> 
> A good solution should be automatic and not need manual intervention,
> and should be independent of the machine on which the build is done.

Exactly ;).

> > Lastly, one other option for gnupg at least is to patch upstream to
> > use
> > --debug-quick-random in the build-time test.
> > 
> > do any of these options sound more appealing than the others?
> I didn't know about --debug-quick-random, it seems perfect to me.
> 
> Stephan, do you think it would be possible to patch mini-buildd so
> that --debug-quick-random is added to gnupg command line, but only
> when the package is doing the tests following the build?

Yeah, I will check this out (though it's not an option to gpg directly,
afair). Or maybe going with a pre-generated key.

Thx,

S

Bug#834683: [pkg-gnupg-maint] Bug#834683: fixed in mini-buildd 1.0.17

[Stephan Sürken]

Hi Daniel, Santiago,

thx for the answer; I am not 100% satisfied, though ;).

For me, it actually boils down to what notion we have:

(1) The builder hosts must provide reasonable entropy.
(2) Software testsuites generally must work fine even with low entropy.

In the past, I tended to go with (1) (which is one of the reasons mini-
buildd recommends haveged).

So I guess just going for both for now ;), so I will check how I can
improve that specific doctest in mini-buildd.

I am still sort of wondering how other testsuites behave in this
respect (like gnupg, gcrypt)?

Thx!

S
                 

Bug#837537: "Mkdir: file exists" error if any debootstrap file download failed

[Stephan Sürken]

Hi Boyuan,

On Mo, 2016-09-12 at 18:08 +0800, Boyuan Yang wrote:
> Package: python-mini-buildd
> Version: 1.0.18
> Severity: normal
> 
> I upgraded my Debian build machine to sid for latest 1.0.18 and found
> it
> impossible to create any dir chroots.
(...)

do I understand you correctly that the rollback mechanism can bring
mini-buildd into that state in case debootstrap fails to work properly
due to network problems?

Thanks!

S

Bug#834683: fixed in mini-buildd 1.0.17

[Stephan Sürken]

Hi Santiago,

On So, 2016-09-11 at 11:37 +0200, Santiago Vila wrote:
(...)
> This is the changelog entry you wrote:
> 
> >    * [8ee94bc] gnupg.py: Add extra method to get sec user id. Fixes
> doctest
> >  for GPG 2.1. Thanks to Santiago Vila (Closes: 834683)
> 
> If this is only intended to work with gnupg 2, please add
> Build-Depends: gnupg (>= 2) so that autobuilders testing packages in
> stretch do not even try to build it with gnupg version 1.

no, this should work for both, 1.4 and 2.1.

> OTOH, if this is intended to work with both gnupg 1 and gnupg 2
> (for example, if you intend this to be backported to jessie),
> then the problem is still here.

Yes, I do ;). And I did test it under jessie, and also the package
build under stretch.

> The error message:
(...)
> suggests to me that there is not enough entropy to generate a key.

If entropy actually is the problem, it should have always been there
for all 1.0.x versions (having that doctest).

> (I don't know how to fix that, sorry, maybe an additional
> build-depends on some package which wraps accesses to /dev/random to
> make them faster, if such package exists).
> 
> The full build log is attached.
> 
> This time I only tried to build it once, but since the problem was
> not
> supposed to always happen, it is probably correct to say that the
> FTBFS-randomness has not been eliminated.

Ok, agree, this does add some randomness [which I usually mitigate
running something like haveged on the builder host]. I guess this
generally means automated tests depending on some entropy must be
avoided?

Anyway, I don't have a good solution either right now; maybe someone
already has? Will look around eventually ;)

Thx,

S

Bug#836737: [buildd-tools-devel] Bug#836737: libsbuild-perl: aptitude resolver fails for non-multiarch chroots

[Stephan Sürken]

On Mo, 2016-09-05 at 13:22 +0200, Johannes Schauer wrote:
> Control: tag -1 + pending

(...)

> > Hoping for review && consideration...
> supporting unsupported old releases is no problem if I get patches
> which are as
> simple and without negative side effects as this one.
> 
> Applied locally and thanks!

ah great! Thanks, Josch!

S

Bug#834329: gpg key handling with sbuild 0.70 broken

[Stephan Sürken]

Hi Marc,

On So, 2016-08-14 at 16:07 +0200, Marc Haber wrote:
> Source: mini-buildd
> Version: 1.0.14
> Severity: normal

(...)

> I am not sure whether this is a bug in mini-buildd or in sbuild.
> Hence, the "normal" severity.
> 
> Building packages fails starting with the second build of an
> installation when sbuild 0.70 is used. This is caused by the code
> starting in line 1217 of /usr/share/perl5/Sbuild/ResolverBase.pm
> where
> gpg keys are imported into the sbuild keyring. This fails, because
> the
> key is already there, causing an "Failed to import public key" and an
> aborted build.

afaiu, 'sbuild-update --gen-key' was broken since GPG 2.1 became GPG;
also 0.70 changed to ASCII keyrings in an attempt to fix breakage for
builds in chroots with GPG being GPG 2.1 (>= stretch).

Fortunately, the latter has been reverted in 0.71, and everything seems
fine again. mini-buildd will now depend on that sbuild version to get
stretch/sid builds going again, and also nothing needs to be changed in
mini-buildd's "sbuild keys workaround" at this point.

As mini-buildd must be supporting squeeze still for quite some time,
just going w/o the sbuild keys is unfortunately not yet an option.
Added as wishlist for 1.2.x though ;).

Thx!

S

Bug#833340: mini-buildd: please make the build reproducible

[Stephan Sürken]

Chris, Boyang,

On Fr, 2016-08-05 at 17:09 +0200, Stephan Sürken wrote:
(...)
> > > 
> > > (Did you see my patch?)
> > Really sorry I overlook the last several lines. It is a good
> > solution.
> hmm thanks ;). However, I already did a patch (actually before the
> bug
> popped up). It's already pushed (1.0.x branch), so maybe someone may
> check if that still has a flaw ;).

fwiw, which would have been

https://anonscm.debian.org/git/collab-maint/mini-buildd.git/commit/?h=1.0.x=b513a9e398f2c05ec9265a627171eb2281c4d974

This does work alright, but I actually like Chris' patch better, so I
have swapped them.

Still pending, so hopefully the next upload will actually be
reproducible ;).

Thx,

S

Bug#833340: mini-buildd: please make the build reproducible

[Stephan Sürken]

Hi guys,

On Mi, 2016-08-03 at 23:46 +0800, Boyuan Yang wrote:
> 2016-08-03 23:34 GMT+08:00 Chris Lamb :
> > 
> > I deliberately expand it immediately after command-line parsing to
> > avoid this.
> > 
> > (Did you see my patch?)
> Really sorry I overlook the last several lines. It is a good
> solution.

hmm thanks ;). However, I already did a patch (actually before the bug
popped up). It's already pushed (1.0.x branch), so maybe someone may
check if that still has a flaw ;).

Thx!

S

Bug#832643: mini-buildd: Please provide options for repository structure similar to official repo

[Stephan Sürken]

Hi Boyuan,

On Do, 2016-07-28 at 09:47 +0800, Boyuan Yang wrote:
> Source: mini-buildd
> Version: 1.0.14
> Severity: wishlist
> 
> I got a little bit confused when first heard of the CODENAME-ID-
> SUITE[-ROLLBACK] distuibution name. That is weird. I understand that
> there may
> be multiple instances and packages may conflict. But this requires
> adjustments
> of d/changelog, which is painful. I cannot download a dsc package and
> upload
> without any modification.

fwiw, there is also the "portext" command, letting you do "no changes
ports" just from a DSC-URL to any mini-buildd distribution.

> I suggest that we provide a series of template similar to official
> Debian repo.

(...)

Iiuuc ;), there actually is such a thing via the Layout (see extra
options). There is also the per-wizard-predefined Layout "Debian
Developer" which already comes with aliases for sid afair:

---
Supported extra options
Meta-Distributions: META=CODENAME-SUITE[ META=CODENAME-SUITE[...:
Support METAs alone as distribution identifier.

Meta distribution identifiers should be unique across all repositories;
usually, a layout with meta distributions should only be used by at
most one repository.

Example: Meta-Distributions: unstable=sid-unstable experimental=sid-
experimental (see standard layout 'Debian Developer'), to allow
upload/testing of packages (to unstable,experimental,..) aimed for
Debian.
---

I hope that is what you are looking for?

Thx,

S

Bug#831749: mini-buildd: Unable to build any package due to missing gnupg in chroot environment of sid/stretch

[Stephan Sürken]

Hi Boyuan,

On Di, 2016-07-19 at 09:44 +0800, Boyuan Yang wrote:
> Source: mini-buildd
> Version: 1.0.12
> Severity: important
> Tags: upstream
> 
> On newly deployed mini-buildd, the default chroot environment for
> stretch/sid
> lacks gpg/gpg2.
> As a result, `apt-key` cannot run and causes every package to fail to
> be built.

yes you are right. Fwiw, obviously triggered by this

https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=87d468fe355c87325c943c40043a0bb236b2407f

change.

Thanks for the hint!

S

Bug#824385: debian/initramfs-tools.bash-completion: Wrong path after 56dfe39 (breaks completion)

[Stephan Sürken]

Hi Ben,

On So, 2016-05-15 at 11:02 +0100, Ben Hutchings wrote:

(...)

> > (not sure why 'dh_bash-completion' eats this in the 1st place,
> > though;):
> It actually installs debian/initramfs-tools.bash-completion rather
> than
> the files listed there.  This is... not very helpful.  It's sort-of
> documented, though there seems to be no validation of what is a
> 'proper
> completion snippet'.

ok, I see... And I also just found Bug #785271 on exactly that ;).

(...)
> > -bash_completion.d/initramfs-tools
> > +bash_completion.d/update-initramfs
> Applied, thanks.

Thanks Ben!

S

Bug#820692: please document how to activate skip_if_keep_in_debug

[Stephan Sürken]

Hi Marc,

On Mo, 2016-04-11 at 15:18 +0200, Marc Haber wrote:
> Package: mini-buildd
> Version: 1.0.11
> Severity: wishlist
> 
> Hi,
> 
> changes.py says:
> 
(...)
> mini_buildd.misc.skip_if_keep_in_debug(os.remove, f_abs)
> 
> When debugging (which is unfortunately the case way too often), I'd
> like to take a look at a file called
> zg2-rebootscript_20110521a-1~zgSID+1+rebuilt20160411105624_mini-buildd-buildrequest_armhf.changes.tar
> which looks like it is deleted by the last line quoted. The code looks
> like there is a possibility to have the code not zap the file.
> 
> How do I activate that?

'mini-buildd --help' has documentation on this ('--debug=keep'); just
put this to /etc/default/mini-buildd (preferably by 'dpkg-reconfiguring'
mini-buildd).

Maybe some explicit

http://mini-buildd.installiert.net/extra/mini-buildd/documentation/admin.html#logging-and-debugging

mentioning here is what you are after?

Hth,

S

Bug#808554: Patch

[Stephan Sürken]

Rehi,

On Mo, 2016-02-15 at 18:13 +0100, Stephan Sürken wrote:
> Hi Maintainers/Reporter,
> 
> please consider the attached patch, which fixes the bug for me.
> 
> [Not sure if it's correct to fix up the profile like that though, so
> please check this.]

please use this revised patch -- now also working with the test suite.

Hth!

S
From fa216270692e1e2234dbc5dce479decbfc0643c1 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stephan=20S=C3=BCrken?= <abs...@olurdix.de>
Date: Mon, 15 Feb 2016 18:00:07 +0100
Subject: [PATCH] dput/uploader.py: Make -u/--unchecked switch work.

---
 dput/uploader.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/dput/uploader.py b/dput/uploader.py
index 4589f48..19cb7f1 100644
--- a/dput/uploader.py
+++ b/dput/uploader.py
@@ -287,6 +287,9 @@ def invoke_dput(changes, args):
 full_upload_log = args.full_upload_log
 _write_upload_log(tmp_logfile.name, full_upload_log)
 
+if "unchecked" in args and args.unchecked:
+profile['allow_unsigned_uploads'] = True
+
 if args.delayed:
 make_delayed_upload(profile, args.delayed)
 
-- 
2.7.0

Bug#808554: Patch

[Stephan Sürken]

Hi Maintainers/Reporter,

please consider the attached patch, which fixes the bug for me.

[Not sure if it's correct to fix up the profile like that though, so
please check this.]

Hth!

Stephan
From 0842876bfaec827b6b2e7131633eb7c54711d6a0 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Stephan=20S=C3=BCrken?= 
Date: Mon, 15 Feb 2016 18:00:07 +0100
Subject: [PATCH] dput/uploader.py: Make -u/--unchecked switch work.

---
 dput/uploader.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/dput/uploader.py b/dput/uploader.py
index 4589f48..21aa7d9 100644
--- a/dput/uploader.py
+++ b/dput/uploader.py
@@ -287,6 +287,9 @@ def invoke_dput(changes, args):
 full_upload_log = args.full_upload_log
 _write_upload_log(tmp_logfile.name, full_upload_log)
 
+if args.unchecked:
+profile['allow_unsigned_uploads'] = True
+
 if args.delayed:
 make_delayed_upload(profile, args.delayed)
 
-- 
2.7.0

Bug#673443: Please add option to use btrfs snapshots instead of LVM snapshots [patch]

[Stephan Sürken]

Hi Katsuhiko,

On Mi, 2015-12-16 at 00:18 -1000, Katsuhiko Nishimra wrote:
> Tags: patch
> 
> Hi,
> 
> I've wrote a patch to implement this feature and am attaching it.
> I haven't find any fault through test deployment,
> but would you please review this closely?

just a short heads up: Thanks for the patch -- it looked fine to me on a
short glance, and I will eventually test and include it.

However, as this will change the SQL scheme, this should go to the 1.2.x
development tree -- not sure when exactly I find time to actually kick
this off ;).

Thanks!

S

Bug#785785: mini-buildd: fails to upgrade: “Unable to change process owner ([Errno 1] Operation not permitted)”

[Stephan Sürken]

Hi Ben,

thanks for the additional information...

On Mi, 2016-01-20 at 15:10 +1100, Ben Finney wrote:
> Control: found -1 mini-buildd/1.0.9
> Control: retitle -1 mini-buildd: fails to upgrade: Unable to change process 
> owner ([Errno 1] Operation not permitted)

...but I am still puzzled by this ;). Fwiw, I just sandboxed a
jessie/strech upgrade without any such problems.

Do you have any security (selinux,...?) hardening going on?

(...)

> Jan 20 15:02:29 lavender systemd[1]: Starting LSB: Start mini-buildd daemon...
> Jan 20 15:02:29 lavender mini-buildd[26769]: Starting custom Debian build 
> daemon: mini-builddmini-buildd FAILED: Unable to change process owner ([Errno 
> 1] Operation not permitted)
> Jan 20 15:02:29 lavender mini-buildd[26769]: failed!

Could you try what

--
# start-stop-daemon --start --chuid mini-buildd --exec /usr/bin/id
--

(as user 'root') says an that system?

If that does work fine, could you please try

--
? /usr/sbin/mini-buildd --foreground --verbose --verbose --debug=exception
--
(as user 'mini-buildd')?

Thanks!

Stephan

Bug#797592: is aptitude intentionally not installed in build chroots?

[Stephan Sürken]

Hi Marc,

On Mo, 2015-08-31 at 21:09 +0200, Marc Haber wrote:
> Source: mini-buildd
> Severity: wishlist
> 
> Hi,
> 
> I have just noticed that a build chroot does not have aptitude
> installed. If the aptitude resolver is used, this results in aptitude
> being installed over and over for every build process.
> 
> Is this intentional? If not, aptitude should be part of a build chroot
> that is intended to be used with the aptitude resolver.

that actually is sort of "intentional"; more precisely, all chroots are
generic, and may potentially be used by any mini-buildd repository --
only the build requests determine what resolver to be used.

Maybe just having aptitude pre-installed generally actually brings more
benefits than harm -- in that case, however, I would like to see
'debootstrap --varinat=buildd' bringing this in.

What mini-buildd *could* do is some instance-global
"chroot_extra_packages" option, so the administrator may override
debootstrap if he wants to.

Keep this open for that?

HtH!

S