Re: Error when running dh_dwz (actually an error when running dwz(1))

[Matthias Klose]

On 09.07.19 21:54, Boyuan Yang wrote:
> Dear -devel list,
> 
> Looks like dh_dwz was recently added into debhelper and it is causing some
> FTBFS on one of my packages. It could be a bug of dwz itself but I'm looking
> for some help inside Debian first.
> 
> Please try to build package marisa from its git packaging repo
> ( 
> https://salsa.debian.org/input-method-team/marisa/commit/f5ff598466266b230d68c9db9f8e31281604b7a6
> ). The following error will pop up when dwz is called:
> 
> =
> [...]
>dh_dwz
> dwz: debian/ruby-marisa/usr/lib/x86_64-linux-gnu/ruby/2.5.0/marisa.so: Found
> compressed .debug_aranges section, not attempting dwz compression
> dh_dwz: dwz -q -- debian/ruby-marisa/usr/lib/x86_64-linux-
> gnu/ruby/2.5.0/marisa.so returned exit code 1
> make: *** [debian/rules:30: binary] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned
> exit status 2
> =
> 
> I don't have much experience of dealing with debugging symbols so any hints
> would be appreciated.

dwz currently doesn't handle compressed debug sections.  There is some
discussion, if dwz should decompress, do it's work and compress it again.
However until then, don't use compressed debug sections. Apparently these are
turned on by the upstream build system.   debhelper maybe could warn about
compressed debug sections in general. Would would you want to have those anyway?
 The packages are compressed, and you shouldn't care about the on-disk space
when debugging.

There's also discussion, about errors:
https://sourceware.org/bugzilla/show_bug.cgi?id=24766
Apparently the RPM based helpers ignore the return value of dwz, and leave the
debug symbols unhandled.  Again, debhelper could warn about such packages when
built in compat12 mode.

Matthias

Re: Dropping Release and Release.gpg support from APT

[Julian Andres Klode]

On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> 
> > Timeline suggestion
> > ---
> > now add a warning to apt 1.9.x for repositories w/o InRelease, but 
> > Release{,.gpg}
> > Aug/Sep turn the warning into an error, overridable with an option (?)
> > Q1 2020 remove the code
> 
> I think this timeline is missing a few items:
> 
> File bugs/patches on dak, launchpad, reprepro and other repository
> creation tools to drop producing Release{,.gpg} (including all the
> ones used by derivatives and by prominent external apt repositories
> and apt repository services).
> 
> Wait for all of those to be fixed.

We don't need them to do that. Repositories can still ship the old
files :)

We do need them to ship InRelease files. I just filed an issue for OBS
to do that. Given how long we had InRelease file, and how confusing it
is to not provide InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.

Also like we've been talking about dropping Release.gpg support
and listing the InRelease file as mandatory in the repository format
spec for ages, so this should hardly come as a surprise to anyone.

> 
> Add the warnings.
> 
> Wait one Debian release cycle.

I don't think it provides a significant benefit - we'll have plenty
of other breakage in 2 years time. Like we started APT 2.0 development,
there is probably quite some more stuff that's going to break. Like
package names might suddenly have a different meaning when we get
patterns or stuff like that (something we do really have to fix, currently
apt install g++7 would install a ton of packages involving gs and a
7 somewhere in their name if there is no g++7). I think InRelease is
the least of our worries.

Basically we have three types of users:

1. The average user, using the debian repo and a bunch of popular
   third-party ones (e.g. spotify, chrome)
2. The power user who builds their own repository
3. Organizations building their own repositories

Let's see how this affects them when they upgrade to bullseye:

1. The average user mostly uses the same third-party repositories
   as an Ubuntu user. Those will be fixed because they've already
   been causing warnings/errors in an Ubuntu stable release.
2. The power user will likely be running testing/unstable and have
   already fixed their repository, or at the very least do so now.
3. The organization will run upgrade tests prior to upgrading, note
   their repositories stopped working, and fix them before rolling
   out the update.

In summary, I do not expect Debian users to be really negatively
impacted by that change. 

In any case, we'll see what breaks when we add that in 1.9.x, and
if there's still significant damage left we can potentially extend
the grace period for periods of 3 months or so, but I definitely want
this to be over when bullseye releases.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

git & Debian packaging sprint report

[Sean Whitton]

Hello,

Over the weekend, Ian Jackson and I met in Cambridge, U.K. to work on
the design and implementation of tools and processes relating to git &
Debian packaging.

Main achievement


We designed and implemented a system to make it possible for DDs to
upload new versions of packages by simply pushing a specially formatted
git tag to salsa.

Please see this blog post to learn about how it works:
https://spwhitton.name/blog/entry/tag2upload/

While the cloud service part of this system has not yet been deployed,
and so you can't just tag to upload yet, the blog post explains how you
can run the cloud service in an ad-hoc mode on your laptop, and thereby
get a feel for how it works.

You can also read git-debpush(1) in sid.[1]

Other achivements
-

1. In-depth design discussions for:

   - git-ffqrebase, a tool for Debian users and downstreams to rebase
 delta queues on top of Debian's source code; and

   - better git-merge support for git-debrebase.  Confirmed the
 resolution UX/workflow, so implementation is now unblocked.  Some
 notes are in #931552.

2. Improved the git packaging survey[2] by setting up inner pages,
   deciding on a template for those, and filling some of them in.

3. Made some plans to improve the layout of dgit's documentation.  Thank
   you to Colin Watson for the feedback which prompted this.

4. Triage of bugs filed against src:dgit.

5. Various smaller fixes/improvements to dgit.

6. Wrote up some requirements as input to an upcoming BoF.[3]

7. Produced blog post linked above.

Reimbursement
-

There will be one travel reimbursement request, for an amount less than
$100.

Acknowledgements


Thank you to donators to Debian for travel funding, and the people who
live at Ian Jackson's place (including Ian) for hosting.

[1]  https://manpages.debian.org/git-debpush
[2]  https://wiki.debian.org/GitPackagingSurvey
[3]  
https://debconf19.debconf.org/talks/68-one-git-to-package-them-all-and-on-the-salsa-find-them/

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Dropping Release and Release.gpg support from APT

[Julian Andres Klode]

On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> On 2019-07-10 10:04, Julian Andres Klode wrote:
> > On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> > > On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
> > > 
> > > > Timeline suggestion
> > > > ---
> > > > now add a warning to apt 1.9.x for repositories w/o InRelease, 
> > > > but Release{,.gpg}
> > > > Aug/Sep turn the warning into an error, overridable with an option 
> > > > (?)
> > > > Q1 2020 remove the code
> [...]
> > We do need them to ship InRelease files. I just filed an issue for OBS
> > to do that. Given how long we had InRelease file, and how confusing it
> > is to not provide InRelease files (not to mention that it doubles the
> > traffic for no-change cases), I'm surprised they aren't using InRelease
> > files yet.
> 
> Given the timeline, shouldn't we also get oldstable to ship an InRelease
> file?

What's the use case for having oldstable in your sources.list on
unstable/testing machines?

But yes, I think it would make sense to ship an InRelease file
with 9.10 now that we are capable of having those.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: Dropping Release and Release.gpg support from APT

[Philipp Kern]

On 2019-07-10 10:04, Julian Andres Klode wrote:

On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:

On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:

> Timeline suggestion
> ---
> now add a warning to apt 1.9.x for repositories w/o InRelease, but 
Release{,.gpg}
> Aug/Sep turn the warning into an error, overridable with an option (?)
> Q1 2020 remove the code

[...]

We do need them to ship InRelease files. I just filed an issue for OBS
to do that. Given how long we had InRelease file, and how confusing it
is to not provide InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.


Given the timeline, shouldn't we also get oldstable to ship an InRelease 
file?


Kind regards
Philipp Kern

Re: Dropping Release and Release.gpg support from APT

[Paul Wise]

On Wed, Jul 10, 2019 at 4:18 PM Julian Andres Klode wrote:

> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

I have it in a chdist so that I can look up package versions in old releases.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Dropping Release and Release.gpg support from APT

[Johannes Schauer]

Quoting Julian Andres Klode (2019-07-10 10:17:51)
> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?

If apt in unstable cannot understand oldstable repos anymore, then this will
also mean that unstable systems cannot create oldstable chroots using
multistrap or mmdebstrap anymore.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Using dh causes configure to be run twice?

[Simon McVittie]

On Wed, 10 Jul 2019 at 01:16:03 -0400, Theodore Ts'o wrote:
> In my attempt to convert e2fsprfogs's debian/rules to use dh, I'm
> running into yet another frustration with dh, which is that it insists
> on running the configure script twice.

This has not been my experience with other Autotools packages. dbus is
my usual example of a relatively complicated Autotools build, and it
only enters 'debian/rules override_dh_auto_configure' once (which as it
happens runs configure three times - for normal, debug and udeb builds -
but that's deliberate and dbus-specific).

  % dh build --no-act
   dh_testdir
   dh_update_autotools_config
   debian/rules override_dh_autoreconf
   debian/rules override_dh_auto_configure
   debian/rules override_dh_auto_build
   debian/rules override_dh_auto_test-arch
   debian/rules override_dh_auto_test-indep
   create-stamp debian/debhelper-build-stamp

I don't think we had that problem with glib2.0 either, although glib2.0
in stretch is old enough that it's still using cdbs, while glib2.0 in
buster is new enough that it has switched from Autotools to Meson, so I
don't have any buildd logs to provide evidence of that.

Perhaps you could share your latest version of d/rules somewhere?

> The problem is that dh is trying to use build-arch and build-indep:
> 
> % dh build --no-act
>debian/rules build-arch
>debian/rules build-indep

dbus doesn't explicitly define build, build-arch or build-indep targets,
it leaves that to dh's "%" rule. Does e2fsprogs perhaps explicitly define
those targets?

smcv

buster backports question/status

[olivier sallou]

Hi,
it may be a silly question, but doing some tests on a Debian buster, I got
errors trying to install a package from buster-backports.

I added to sources.list.d info to set buster-backports but i get this error:

E: The value 'buster-backports' is invalid for APT::Default-Release as such
a release is not available in the sources

Looking at https://backports.debian.org, I only see stretch info/links.

As buster is really new, I expect there is no package yet in
buster-backports, but I should not get errors trying to access it. And I am
surprise to not find any reference to it.

So, am I doing something wrong?

Thanks

Olivier

Re: buster backports question/status

[Andrey Rahmatullin]

On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> So, am I doing something wrong?
You tried to install a package (what package? they don't exist) from a
repo that doesn't exist.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: buster backports question/status

[olivier sallou]

Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin  a
écrit :

> On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> > So, am I doing something wrong?
> You tried to install a package (what package? they don't exist) from a
> repo that doesn't exist.
>

I tried a package that is not in backports, it was just for test (for an
automation tool I use)
It should fail with a *package not found* , but should not fail about
buster-backports being non available.

Is the problem linked to buster-backports not existing yet ? Is backports
repo not created automatically on new releases?


> --
> WBR, wRAR
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: buster backports question/status

[Kyle Robbertze]

On 2019/07/10 11:29, olivier sallou wrote:
> 
> 
> Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin  > a écrit :
> 
> On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> > So, am I doing something wrong?
> You tried to install a package (what package? they don't exist) from a
> repo that doesn't exist.
> 
>  
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> buster-backports being non available.

buster-backports is not yet available.
> 
> Is the problem linked to buster-backports not existing yet ? Is
> backports repo not created automatically on new releases?

It is created a little while after the release, not automatically

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Re: Using dh causes configure to be run twice?

[Colin Watson]

On Wed, Jul 10, 2019 at 01:16:03AM -0400, Theodore Ts'o wrote:
> I tried to see how other packages work around this misfeature, and I
> see that openssh just hacks things to make the second
> dh_auto_configure a no-op:
> 
> override_dh_auto_configure-arch:
>   dh_auto_configure -Bdebian/build-deb -- $(confflags)
> ifeq ($(filter noudeb,$(DEB_BUILD_PROFILES)),)
>   dh_auto_configure -Bdebian/build-udeb -- $(confflags_udeb)
>   # Avoid libnsl linkage. Ugh.
>   perl -pi -e 's/ +-lnsl//' debian/build-udeb/config.status
>   cd debian/build-udeb && ./config.status
> endif
> 
> override_dh_auto_configure-indep:
> 
> RLY?

You've misread this, I'm afraid.  The point of the *-indep overrides in
openssh is to avoid doing unnecessary work in
architecture-independent-only builds, not to avoid duplicate configure
steps.  openssh has some Architecture: all binary packages, which
Debian's autobuilders build on separate builders that do the rough
equivalent of "sbuild --arch-all --no-arch-any", so a small amount of
time optimising this was worthwhile.

This is unrelated to the problem you're running into.

Proof: I introduced this change in
https://salsa.debian.org/ssh-team/openssh/commit/c1f965684b54bed51e8cb1e7a2f3d2003d64d341.
Aside from its commit message, you can also look at build logs from
before and after this change:

  
https://buildd.debian.org/status/fetch.php?pkg=openssh&arch=i386&ver=1%3A6.9p1-2&stamp=1441886711&raw=0
  
https://buildd.debian.org/status/fetch.php?pkg=openssh&arch=i386&ver=1%3A6.9p1-3&stamp=1448408594&raw=0

Both before and after this change, you can see that there's only one
dh_auto_configure pass (two actual configure runs, but that's because
there's one for deb and one for udeb).  I only started doing source-only
uploads with 1:6.9p1-3, so you can't easily see what it would have
looked like beforehand, but you can see that
https://buildd.debian.org/status/fetch.php?pkg=openssh&arch=all&ver=1%3A6.9p1-3&stamp=1448408071&raw=0
is nice and short once it gets past installing build-dependencies.

-- 
Colin Watson   [cjwat...@debian.org]

Re: buster backports question/status

[Andrey Rahmatullin]

On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote:
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> buster-backports being non available.
I don't think the failing command was apt install, but rather apt update?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: buster backports question/status

[olivier sallou]

Le mer. 10 juil. 2019 à 11:35, Andrey Rahmatullin  a
écrit :

> On Wed, Jul 10, 2019 at 11:29:01AM +0200, olivier sallou wrote:
> > I tried a package that is not in backports, it was just for test (for an
> > automation tool I use)
> > It should fail with a *package not found* , but should not fail about
> > buster-backports being non available.
> I don't think the failing command was apt install, but rather apt update?
>

Nope, only at install time, update succeeded.
I though that backport was immediately available with new releases, even if
empty. I understand that is not the case.
I will update my scripts to manage the backports *not available* case.

Anyway, thanks for your anssers.

>
> --
> WBR, wRAR
>


-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Re: buster backports question/status

[Julien Cristau]

On Wed, Jul 10, 2019 at 11:29:01 +0200, olivier sallou wrote:

> Le mer. 10 juil. 2019 à 11:08, Andrey Rahmatullin  a
> écrit :
> 
> > On Wed, Jul 10, 2019 at 10:54:21AM +0200, olivier sallou wrote:
> > > So, am I doing something wrong?
> > You tried to install a package (what package? they don't exist) from a
> > repo that doesn't exist.
> >
> 
> I tried a package that is not in backports, it was just for test (for an
> automation tool I use)
> It should fail with a *package not found* , but should not fail about
> buster-backports being non available.
> 
> Is the problem linked to buster-backports not existing yet ? Is backports
> repo not created automatically on new releases?
> 
buster-backports exists.  AIUI this is an apt bug when dealing with
empty repos.  (Although why are you setting default-release to
buster-backports?)

Cheers,
Julien

Re: buster backports question/status

[David Kalnischkies]

On Wed, Jul 10, 2019 at 11:42:40AM +0200, Julien Cristau wrote:
> buster-backports exists.  AIUI this is an apt bug when dealing with
> empty repos.  (Although why are you setting default-release to
> buster-backports?)

JFTR: Yes it is an apt "bug" in that empty repositories do not create
the structures apt is checking later on if a given target-release is
sensible – that is a feature since 0.8.15.3 (2011) btw → #407511.

I think we will end up creating the structures again for other reasons
so that error will disappear for this edgecase – but I have to second
the question as that seems wrong (and why I put "bug" in quotes).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Apt-secure and upgrading to bullseye

[Julian Gilbey]

Hooray, buster's released!  Congrats to all!

So I tried upgrading my machine to bullseye today, and
aptitude/apt-get update don't like this, giving me errors such as:

E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its 
'Codename' value from 'buster' to 'bullseye'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.

So I read apt-secure(8), which gives no indication of how to "accept
this explicitly", and neither do any of the linked wiki pages.

Any suggestions?

(And obviously something needs changing so that people aren't stung
when bullseye is released.)

Best wishes,

   Julian

Re: Apt-secure and upgrading to bullseye

[Julian Gilbey]

On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
> Hooray, buster's released!  Congrats to all!
> 
> So I tried upgrading my machine to bullseye today, and
> aptitude/apt-get update don't like this, giving me errors such as:
> 
> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its 
> 'Codename' value from 'buster' to 'bullseye'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
> 
> So I read apt-secure(8), which gives no indication of how to "accept
> this explicitly", and neither do any of the linked wiki pages.
> 
> Any suggestions?
> 
> (And obviously something needs changing so that people aren't stung
> when bullseye is released.)

Ah, turns out it's a known bug with aptitude.  The solution is to run
"apt update", which interactively asks what to do with these changes.

Best wishes,

   Julian

Re: Apt-secure and upgrading to bullseye

[Paul Wise]

On Wed, Jul 10, 2019 at 7:59 PM Julian Gilbey wrote:

> So I read apt-secure(8), which gives no indication of how to "accept
> this explicitly", and neither do any of the linked wiki pages.
>
> Any suggestions?

There are two options:

# apt update


# apt-get --allow-releaseinfo-change update

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
https://bonedaddy.net/pabs3/

Re: Apt-secure and upgrading to bullseye

[David Kalnischkies]

Hi,

On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
> Hooray, buster's released!  Congrats to all!

Indeed! ☺

> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its 
> 'Codename' value from 'buster' to 'bullseye'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.

There are various reports about that against apt/aptitude, so I am not
feeling like adding lots of duplicated content now, but the gist is:

Either use "apt update" (it will ask an interactive question) or
"apt-get update --allow-releaseinfo-change" (see apt-get manpage) or
[least preferred option] set the config option
Acquire::AllowReleaseInfoChange for basically any apt-based client.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Apt-secure and upgrading to bullseye

[Mechtilde Stehmann]

Hello,

Am 10.07.19 um 14:30 schrieb Julian Gilbey:
> On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
>> Hooray, buster's released!  Congrats to all!
>>
>> So I tried upgrading my machine to bullseye today, and
>> aptitude/apt-get update don't like this, giving me errors such as:
>>
>> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed 
>> its 'Codename' value from 'buster' to 'bullseye'
>> N: This must be accepted explicitly before updates for this repository can 
>> be applied. See apt-secure(8) manpage for details.
>>
>> So I read apt-secure(8), which gives no indication of how to "accept
>> this explicitly", and neither do any of the linked wiki pages.
>>
>> Any suggestions?
>>
>> (And obviously something needs changing so that people aren't stung
>> when bullseye is released.)
> 
> Ah, turns out it's a known bug with aptitude.  The solution is to run
> "apt update", which interactively asks what to do with these changes.

that is the reason, why I didn't have this problem. I use apt-get / apt
all the time.

> 
> Best wishes,
> 
>Julian
> 

Kind regards

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Re: Apt-secure and upgrading to bullseye

[Osamu Aoki]

On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
> Hooray, buster's released!  Congrats to all!
> 
> So I tried upgrading my machine to bullseye today, and
> aptitude/apt-get update don't like this, giving me errors such as:
> 
> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed its 
> 'Codename' value from 'buster' to 'bullseye'
> N: This must be accepted explicitly before updates for this repository can be 
> applied. See apt-secure(8) manpage for details.
> 
> So I read apt-secure(8), which gives no indication of how to "accept
> this explicitly", and neither do any of the linked wiki pages.
> 
> Any suggestions?
> 
> (And obviously something needs changing so that people aren't stung
> when bullseye is released.)

Slightly different but ...
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879786
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929248

I guess it may be worth to try along:

 $ sudo apt-get --allow-releaseinfo-change update

Osamu

Re: Apt-secure and upgrading to bullseye

[Bjørn Mork]

Julian Gilbey  writes:
> On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
>> Hooray, buster's released!  Congrats to all!
>> 
>> So I tried upgrading my machine to bullseye today, and
>> aptitude/apt-get update don't like this, giving me errors such as:
>> 
>> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed 
>> its 'Codename' value from 'buster' to 'bullseye'
>> N: This must be accepted explicitly before updates for this repository can 
>> be applied. See apt-secure(8) manpage for details.
>> 
>> So I read apt-secure(8), which gives no indication of how to "accept
>> this explicitly", and neither do any of the linked wiki pages.
>> 
>> Any suggestions?
>> 
>> (And obviously something needs changing so that people aren't stung
>> when bullseye is released.)
>
> Ah, turns out it's a known bug with aptitude.  The solution is to run
> "apt update", which interactively asks what to do with these changes.

If it's any comfort, I had the exact same problem.

It would be nice if the warning either pointed to the apt-get(8) man
page, where the solution can be found, or some hint was added to the
apt-secure(8) man page.

I found this section of the apt-secure(8) man page particularily
unhelpful:

  Since version 1.5 the user must therefore explicitly confirm changes
  to signal that the user is sufficiently prepared e.g. for the new
  major release of the distribution shipped in the repository (as
  e.g. indicated by the codename).


Those who cares which version this was added will read the changelog.
Those reading the man page are more likely looking for instructions, not
background info.


Bjørn

Bug#931796: ITP: live-clone -- GUI to clone and manage Live-Build USB sticks

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: live-clone
  Version : 1.0-1
  Upstream Author : Georges Khaznadar 
* URL : https://usb.freeduc.org/jbart-en.html
* License : GPL-3
  Programming Lang: Python3
  Description : GUI to clone and manage Live-Build USB sticks

 The main use case for `live-clone` should be for people who
 use a USB live stick to boot a GNU-Linux system anywhere, on
 whatever machine which allows them to boot from such a support.

 It can be summarized as "nomadic IT usage". I use it as a valuable
 educational tool for my students: so, they can find exactly the
 same computer environment at school and for their homework,
 provided they know how to boot a machine with their own
 Debian-Live flash disk.

 This application allows one to make bootable USB sticks from an
 iso-hybrid image issued by Live-Build. It adapts additionally a
 persistence partition to use the free space on the USB stick.
 .
 It features also management tools for live USB sticks: when such
 USB disks are used daily, they happen to have inconsistencies in their
 persistence area which can render them unusable. Tools are provided to
 save persistence data when necessary, and to blank the persistence area,
 so the USB disk can be used again.
 .
 The application detects when it is run from a Debian-Live environment,
 thus featuring seamless auto-cloning.

The package is currently stored at https://salsa.debian.org/georgesk/live-clone
and I aim to maintain it in the next years.

wanted: recommendation for webhook queueing library/thing

[Ian Jackson]

Sean Whitton writes ("git & Debian packaging sprint report"):
> Main achievement
> 
> 
> We designed and implemented a system to make it possible for DDs to
> upload new versions of packages by simply pushing a specially formatted
> git tag to salsa.
> 
> Please see this blog post to learn about how it works:
> https://spwhitton.name/blog/entry/tag2upload/
> 
> While the cloud service part of this system has not yet been deployed,
> and so you can't just tag to upload yet, the blog post explains how you
> can run the cloud service in an ad-hoc mode on your laptop, and thereby
> get a feel for how it works.
> 
> You can also read git-debpush(1) in sid.[1]

The one technical piece missing for deployment is webhook queue /
dispatcher.  Can someone familiar with this space recommend one ?

In more detail, here is what I think the problem is:

 * The webhook client expects a quick response. But the bot's
   processing for a tag addressed to the bot takes some time (because
   it needs to fetch a fair amount of data and build a source
   package).  So webhook calls must be queued.

 * Sometimes it will be necessary to retry a failed bot invocation.
   (The bot already knows whether a particular invocation should be
   retried, and can feed this back to the queue.)  The retry interval
   and number of retries must be limited.

 * The bot expects to be forked/exec'd.

 * Significant protection against DoS is not needed because the
   web hook receiver's webserver will have a firewall protecting it
   from anything other than salsa.

 * The webserver and web hook receiver/queue (including the JSON
   parser which will be needed) must be high quality software, because
   we really want to avoid any vulnerabilities.

 * I can easily change the bot's fork/exec API to make it conveniently
   fit into whatever queue system.

If necessary I can write my own but it seems like this is a problem
that there should already be a good solution to.

Thanks,
Ian.

Re: The noudeb build profile and dh-only rules files

[Ian Jackson]

Theodore Ts'o writes ("Re: The noudeb build profile and dh-only rules files"):
> Thanks, that's really helpful.  One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:
...
> # See?   dh is easy-peasy!
...
> Sure, there are few a examples using one or two override declarations,
> but trying to use dh on a non-trivial package is non-obvious,
> given the current documentation.  Some more advanced tutorials, or
> some links to good examplars of how to use dh in "real world",
> non-trivial packaging setups, would be really good.  It looks like
> openssh is a good example, but I'm sure they must be others.

Here's an example from a package I converted to dh in the last year or
so:
  https://browse.dgit.debian.org/xen.git/tree/debian/rules

I'm not sure where I should send this so that the next person with
your question finds it (other than just posting it to -devel when it
seems relevant).

I highly recommend the approach of writing a comment next to each
override etc., explaining what it's there for.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#883393: ITP: jool -- Open Source SIIT and NAT64 Translator for Linux

[Vincent Bernat]

Package: wnpp
Followup-For: Bug #883393

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Any progress on this? Do you need help packaging?

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl0mDQYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5SVQP/2rf1gCpD3aw71BxPFf7xAzwQLaMezWG
0uuJVw6ZLp6bBcYWaOzQsAeit4Je/NkILsCkltKXCVOa2OSr82BMIbeW2tVUnENI
ZXP6sXy0EuTh1Eb+WhutLjIkialCtRgmmgzZWHqyFLWBtsnd+430G8G+/lUso+SX
D3clxPPcPFWhbp8rwoNaaXU7C25pTHfqxUDcdywuBV6pj7LAkxtwuzbkPrWdRR5n
PkAZHYzrABKCFKSM8HnOyW328cOUZ7SkPB5XtwkcO191O/onnrm/XaVEVMXUQR0k
jb6qZ/c0sfEtkn50BiFA/MkEOaFb9xpBZ/3S2pwXLQK7zWNKxCnVSxKO8ig7aS6e
r2aJ25E5/mDai2nzJYSXOSw2TIfvRkEnt4plD4dPF21OzNGs5M3hkytCGuDqUR11
yl9JSdVq+bjq3xiWkQ4TrgyKvBKnHv/VxIsr292lnSUayvkzFY+HS3ATISUdbVCo
pvEpNh7ykxwQzQhAplOVnoppeXA2xNIDzgrHWA/EEqGG8MI6wp1MlJiYunBaKd9C
VG9A5OYeOPGHGZ6pUVbsBdJSshYD3ZcGwqA8gOBoKQRPRN2Lz6O8w4JfwXsp2MTs
ZyZsISTZrdO+A1AHeGb+DcVLOzTHQroBkAzYUDE1HKmUeu7mblyAFzbz0yZZltGm
qGTrTJaInWpa
=fm8W
-END PGP SIGNATURE-

Re: The noudeb build profile and dh-only rules files

[Andreas Metzler]

Theodore Ts'o  wrote:
[...]
> Thanks, that's really helpful.  One of the really frustrating things
> I've found about trying to use dh is that there is a real lack of
> examples which are more complicated than:

> #!/usr/bin/make -f
> #
> # See?   dh is easy-peasy!

> %:
> dh $@

> Sure, there are few a examples using one or two override declarations,
> but trying to use dh on a non-trivial package is non-obvious,
> given the current documentation. 
[...]

Hello,

FWIW my personal experience with converting was that I had to stop
treating debian/rules as a makefile with a dependency tree of
targets. It is just list of dh_auto_*. If you want to change the
buildprocess, override dh_auto_build, etc.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Apt-secure and upgrading to bullseye

[Julian Gilbey]

On Wed, Jul 10, 2019 at 02:30:24PM +0200, David Kalnischkies wrote:
> Hi,
> 
> On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
> > Hooray, buster's released!  Congrats to all!
> 
> Indeed! ☺
> 
> > E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed 
> > its 'Codename' value from 'buster' to 'bullseye'
> > N: This must be accepted explicitly before updates for this repository can 
> > be applied. See apt-secure(8) manpage for details.
> 
> There are various reports about that against apt/aptitude, so I am not
> feeling like adding lots of duplicated content now, but the gist is:
> 
> Either use "apt update" (it will ask an interactive question) or
> "apt-get update --allow-releaseinfo-change" (see apt-get manpage) or
> [least preferred option] set the config option
> Acquire::AllowReleaseInfoChange for basically any apt-based client.

Thanks to everyone for suggestions; I discovered "apt update" through
a Google search.

But I realised later that this is going to bite all users when they
come to upgrade from buster.  Perhaps some aptitude and apt-get
patches can go into a stable (buster) point release, so that fewer
users are hurt by this in 2-3 years' time?  It is quite a showstopper!

Best wishes,

   Julian

Re: Apt-secure and upgrading to bullseye

[Neil McGovern]

On Wed, Jul 10, 2019 at 07:51:18PM +0100, Julian Gilbey wrote:
> Thanks to everyone for suggestions; I discovered "apt update" through
> a Google search.
> 

I've submitted a patch against the release notes to explicitly mention
this:
https://salsa.debian.org/ddp-team/release-notes/merge_requests/50

> But I realised later that this is going to bite all users when they
> come to upgrade from buster.  Perhaps some aptitude and apt-get
> patches can go into a stable (buster) point release, so that fewer
> users are hurt by this in 2-3 years' time?  It is quite a showstopper!
> 

Given the release notes tell people to use "apt update", I'd be
interested to know if there was any documentation you read or followed
during the upgrade. If you didn't use the release notes, is there a
reason why? Could a tl;dr version make you more likely to read them?

Neil
-- 


signature.asc
Description: PGP signature

Re: wanted: recommendation for webhook queueing library/thing

[Antonio Terceiro]

On Wed, Jul 10, 2019 at 04:09:11PM +0100, Ian Jackson wrote:
> Sean Whitton writes ("git & Debian packaging sprint report"):
> > Main achievement
> > 
> > 
> > We designed and implemented a system to make it possible for DDs to
> > upload new versions of packages by simply pushing a specially formatted
> > git tag to salsa.
> > 
> > Please see this blog post to learn about how it works:
> > https://spwhitton.name/blog/entry/tag2upload/
> > 
> > While the cloud service part of this system has not yet been deployed,
> > and so you can't just tag to upload yet, the blog post explains how you
> > can run the cloud service in an ad-hoc mode on your laptop, and thereby
> > get a feel for how it works.
> > 
> > You can also read git-debpush(1) in sid.[1]
> 
> The one technical piece missing for deployment is webhook queue /
> dispatcher.  Can someone familiar with this space recommend one ?
> 
> In more detail, here is what I think the problem is:
> 
>  * The webhook client expects a quick response. But the bot's
>processing for a tag addressed to the bot takes some time (because
>it needs to fetch a fair amount of data and build a source
>package).  So webhook calls must be queued.
> 
>  * Sometimes it will be necessary to retry a failed bot invocation.
>(The bot already knows whether a particular invocation should be
>retried, and can feed this back to the queue.)  The retry interval
>and number of retries must be limited.
> 
>  * The bot expects to be forked/exec'd.
> 
>  * Significant protection against DoS is not needed because the
>web hook receiver's webserver will have a firewall protecting it
>from anything other than salsa.
> 
>  * The webserver and web hook receiver/queue (including the JSON
>parser which will be needed) must be high quality software, because
>we really want to avoid any vulnerabilities.
> 
>  * I can easily change the bot's fork/exec API to make it conveniently
>fit into whatever queue system.
> 
> If necessary I can write my own but it seems like this is a problem
> that there should already be a good solution to.

Enrico has been producing some content that is related:

https://www.enricozini.org/blog/2018/debian/automatic-deploy-from-gitlab-salsa-ci/
https://debconf18.debconf.org/talks/71-autodeploy-from-salsa/

It's based on systemd .path units. the advantage is that you don't need
a new component, you only put the config in place and systemd takes care
of it for you.

another option is rabbitmq; that's what debci uses. and it has clients
for several languages. one advantage is that you can have multiple
worker processes consuming from the queue in parallel, but OTOH you have
do manage those extra daemons, care about not exposing it to the
internet, etc.


signature.asc
Description: PGP signature

Re: wanted: recommendation for webhook queueing library/thing

[Sam Hartman]

I also use systemd.path units for this.
Since it was Ian asking I didn't really feel that was worth suggesting
though.

Re: wanted: recommendation for webhook queueing library/thing

[Antonio Terceiro]

On Wed, Jul 10, 2019 at 05:05:53PM -0400, Sam Hartman wrote:
> I also use systemd.path units for this.
> Since it was Ian asking I didn't really feel that was worth suggesting
> though.

yes, I also though about that but decided to cite prior art anyway. one
can always use inotify to achieve the same effect.


signature.asc
Description: PGP signature

Re: Apt-secure and upgrading to bullseye

[The Wanderer]

On 2019-07-10 at 15:03, Neil McGovern wrote:

> On Wed, Jul 10, 2019 at 07:51:18PM +0100, Julian Gilbey wrote:

>> But I realised later that this is going to bite all users when they
>> come to upgrade from buster.  Perhaps some aptitude and apt-get
>> patches can go into a stable (buster) point release, so that fewer
>> users are hurt by this in 2-3 years' time?  It is quite a
>> showstopper!
> 
> Given the release notes tell people to use "apt update", I'd be
> interested to know if there was any documentation you read or
> followed during the upgrade. If you didn't use the release notes, is
> there a reason why? Could a tl;dr version make you more likely to
> read them?

For myself, no, a shorter/simplified version of the release notes
probably wouldn't have made me more likely to read them.

I track testing by that name (and have done so for well over a decade),
and dist-upgrade on at least a weekly basis, so I never actually upgrade
to a new release; I just start pulling from the new testing when the old
one moves out from under my feet to become stable.

Since I'm not upgrading to a new release, but just sticking with testing
as I've been doing all along, I wouldn't think to check release notes.
That's especially true just after the release of a new stable; at that
point, it's intuitively obvious that testing can't have release notes,
because until new package versions migrate from unstable the new testing
is *empty*. (Whether this intuition is accurate or not.)

As Julian apparently did, I only found the solution for this by a Google
search for the error message I was seeing - in my case, in what I recall
as being a months-old bug report, since it it hadn't been brought up
post-release on e.g. debian-user yet by then.

The release notes might be a valid place to document this for people
upgrading from oldstable-buster to stable-bullseye after the release of
bullseye, or even (if this would be applicable) switching from stable to
testing-bullseye midway through the release cycle; it's considerably
more reasonable to expect people to think to check release notes before
upgrading at those stages. But for people who are merely sticking with
testing, after the buster release just as after previous releases, the
release notes are IMO not an appropriate answer.


Also: I would have tried to reject a "just use 'apt update'" solution,
as you say the release notes propose, and kept searching for a way to do
it using apt-get - since that's my preferred client, and the idea of
switching clients just for a single task like this strikes me as
intuitively wrong somehow. In fact, it's possible that I *did* do that;
I remember skipping multiple search results which suggested only that
solution, and it's even possible that the release notes were one of them.

I'd have given in eventually if no "native" solution were to be found,
but since in this case one *does* exist, IMO it's not appropriate to
present only the solution which would require me to temporarily switch
clients.

David Kalnischkies presented three different solutions, suitable for
different clients, earlier in this thread. IMO, if the release notes
need to document any of them, they should document all - or, if it's
considered more reasonable to restrict the release notes to discussing
one single recommended client, there should be another document
somewhere which lists not only all of these solutions but (for
discoverability's sake) as many of the client-specific error messages as
may be practical. (For those clients which don't present the solution
themselves, of course.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Apt-secure and upgrading to bullseye

[Andrei POPESCU]

On Mi, 10 iul 19, 23:47:28, The Wanderer wrote:
> 
> The release notes might be a valid place to document this for people
> upgrading from oldstable-buster to stable-bullseye after the release of
> bullseye, or even (if this would be applicable) switching from stable to
> testing-bullseye midway through the release cycle; 

In my understanding of the issue it only affects users that already have 
a source in their lists, but the source changes.

It shouldn't have any impact on buster users that upgrade to bullseye 
*after* the release, because they are adding a new source.

The biggest impact at bullseye's release will be on buster users, 
because buster will change from stable to oldstable.

It might also have some impact to buster users upgrading to bullseye 
before the release, however, by then most package managers should be 
updated to deal with this correctly.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature