Bug#1028602: transition: gnustep-base, gnustep-gui

[Yavor Doganov]

Sebastian Ramacher wrote:
> On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> > I realise we are already late and in all likelihood we've missed
> > the last bookworm train, which is rather unpleasant for us and
> > GNUstep users but entirely our fault.
> 
> I am not quite sure what you mean with unpleasant. What would be
> unpleasant for GNUstep users?

I meant that in case the transition is postponed to trixie, bookworm
will ship with old releases of core GNUstep.  It happened for bullseye
when I missed to inform upstream about Debian's freeze/release
schedule.  This time the upstream releases were made in time but we
failed to meet the deadline again.

Re: Uploading linux (6.1.8-1)

[Paul Gevers]

Hi Salvatore,

On 28-01-2023 17:48, Salvatore Bonaccorso wrote:

[On a related note, if you, release team can unblock an let 6.1.7-1
still migrate to testing earlier that that, that would be welcome so
we have several important fixes in already for testing. Though there
is a regressions for i386. Help from people interested in i386 would
be very welcome.]


I've added the hint, but are these regressions in cryptsetup and 
libguestfs tracked somewhere? As a bare minimum I've CC'd their 
maintainers in this message so that they are aware, and I've added our 
i386 porter explicitly too.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029918: marked as done (spring needs hinting into testing)

[Debian Bug Tracking System]

Your message dated Sun, 29 Jan 2023 08:01:29 +0100
with message-id <98fe5a9a-445c-62d0-1074-aa8904a91...@debian.org>
and subject line Re: Bug#1029918: spring needs hinting into testing
has caused the Debian Bug report #1029918,
regarding spring needs hinting into testing
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1029918: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029918
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal

Issues preventing migration:
∙ ∙ spring-javaai/arm64 has unsatisfiable dependency

Package: spring-javaai
Architecture: all
Depends:
...
 spring (>= ${source:Version}),

Package: spring
Architecture: amd64 i386

The package was removed from testing in October due to an RC bug
that is now fixed.

#563686 explains why this package is x86-only.
--- End Message ---
--- Begin Message ---

HI Adrian,

On 29-01-2023 01:02, Adrian Bunk wrote:

Issues preventing migration:
∙ ∙ spring-javaai/arm64 has unsatisfiable dependency


hint added.

Paul


OpenPGP_signature
Description: OpenPGP digital signature
--- End Message ---

Re: Upload of TeX Info 7.0.x to unstable?

[Anthony Fok]

Hi Hilmar and Sebastian,

On Thu, Jan 26, 2023 at 2:24 AM Sebastian Ramacher  wrote:
> On 2023-01-25 23:17:54 +0100, Hilmar Preuße wrote:
> > Am 25.01.2023 um 22:08 teilte Sebastian Ramacher mit:
> > > On 2023-01-24 09:23:26 +0100, Hilmar Preuße wrote:
> > > > TeX Info version 7.0 was released last year at beginning of November and
> > > > was uploaded to experimental. We got a few bug reports, which were
> > > > addressed by upstream authors promptly.
> > > > Since then two bugfix releases appeared (currently 7.0.2) and we could
> > > > think about uploading to unstable. According to [1] we are neither in
> > > > the tool chain nor would this be a transition. Nevertheless we know that
> > > > a few(?) packages use makeinfo and texi2* to convert documents, so
> > > > uploading could cause breakage and FTBFS bugs when building docs.
> > >
> > > Did you perform a test rebuild of the reverse build dependencies? That
> > > would make it every easy to answer the question whether its safe or not.
> > >
> > No, I did not. Could you trigger that or let me know how to do it?
>
> There's https://wiki.debian.org/MassRebuilds - best to talk to Lucas.

There is also the "ratt - Rebuild All The Things" tool written by
Michael Stapelberg, originally for the Debian Go Packaging Team, but
works on any other non-Go packages!  I am now trying it on libwebp
1.2.4-1 which I uploaded a while ago (which I didn't test with ratt
back then but thankfully didn't break anything), and it is running
great on my local machine!

"apt install ratt", and optionally "apt install dose-extra" too if it
didn't get installed, for better reverse-dependency checking (i.e.
more comprehensive list of packages to test rebuild).

Cheers,

Anthony

Bug#1029918: spring needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Issues preventing migration:
∙ ∙ spring-javaai/arm64 has unsatisfiable dependency

Package: spring-javaai
Architecture: all
Depends:
...
 spring (>= ${source:Version}),

Package: spring
Architecture: amd64 i386

The package was removed from testing in October due to an RC bug
that is now fixed.

#563686 explains why this package is x86-only.

Processed: Re: Bug#1029566: transition: shibboleth-sp

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1029566 [release.debian.org] transition: shibboleth-sp
Added tag(s) moreinfo.

-- 
1029566: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029566
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1029566: transition: shibboleth-sp

[Sebastian Ramacher]

control: tags -1 moreinfo

On 2023-01-24 17:17:36 +0100, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> When reporting #1028286 (transition: xml-security-c) I totally missed
> that one of the mentioned planned upper layer uploads is the
> shibboleth-sp 3.3 -> 3.4 upgrade, which, contrary to the xml-security-c
> transition, actually entails an SONAME change.  Since this wasn't
> explicit in the original bug, we decided to ask for your ACK again.
> As you can see in the autogenerated tracker at
> https://release.debian.org/transitions/html/auto-shibboleth-sp.html,
> there are only two reverse dependencies, both of which are internal to
> the Shibboleth ecosystem (thus maintained by us) and both build without
> changes against shibboleth-sp 3.4.1+dfsg-1.

What would be the consequences of postponing this transition to trixie?

Cheers

> 
> Ben file:
> 
> title = "shibboleth-sp";
> is_affected = .depends ~ "libshibsp10" | .depends ~ "libshibsp11";
> is_good = .depends ~ "libshibsp11";
> is_bad = .depends ~ "libshibsp10";
> 

-- 
Sebastian Ramacher

Bug#1028602: transition: gnustep-base, gnustep-gui

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
> Control: affects -1 + src:gnustep-base src:gnustep-gui
> 
> Dear Release team,
> 
> We would like your permission to carry out a GNUstep transition (two
> libraries simultaneously with one round of binNMUs):
> 
>   libgnustep-base1.28 -> 1.29
>   libgnustep-gui0.29  -> 0.30
> 
> I realise we are already late and in all likelihood we've missed the
> last bookworm train, which is rather unpleasant for us and GNUstep
> users but entirely our fault.

I am not quite sure what you mean with unpleasant. What would be
unpleasant for GNUstep users?

Cheers

> In case it's not possible to do it now
> (after tiff/poppler) then please have us in mind for the early stages
> of the trixie development cycle.
> 
> gnustep-base/1.29.0-1 is available in experimental, not yet built on
> mipsen, ppc64el and s390x.  But note that 1.28.1-2 was built in
> unstable on all release architectures; 1.29.0 is essentially the same
> except the version bump (the damage done was corrected; see #1028189).
> 
> gnustep-gui/0.30.0-1 is also available in experimental, not yet built
> on ppc64el and s390x but I do not expect any problems there.
> 
> While build-testing all rdeps on amd64, the following problems were
> observed:
> 
> agenda.app   #1028185  gnustep-gui bug, will be fixed with next upload
> gnustep-dl2  #1028577  fixed locally; needs a sourceful upload
> pantomime#1028578  likewise
> sope #1028579  patch sent to the BTS; needs a sourceful upload
> 
> In addition, gnustep-back will require a sourceful upload (that is
> always the case).
> 
> The automatic ben trackers at release.d.o look fine.
> 

-- 
Sebastian Ramacher

Processed: Re: Bug#1028602: transition: gnustep-base, gnustep-gui

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo
Bug #1028602 [release.debian.org] transition: gnustep-base, gnustep-gui
Added tag(s) moreinfo.

-- 
1028602: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028602
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1029849: hw-detect: storing firmware information specifically

[Cyril Brulebois]

Package: hw-detect
Severity: important
X-Debbugs-Cc: debian-release@lists.debian.org

Hi,

Quoting the text that was agreed to via the 2022 General Resolution
about non-free firmware:

When the installer/live system is running we will provide
information to the user about what firmware has been loaded (both
free and non-free), and we will also store that information on the
target system such that users will be able to find it later. 

During the initial brainstorming, I think it was suggested to maybe
include some kind of informational message at the end of the
installation process, like “we installed this and that” or “yay,
you're entirely free”.

That would mean extra work on the translation side, wouldn't add much
value, so that looks like something we should *not* implement.


Regarding the letter of the text, and given hw-detect's code, it's
probably easy enough to keep a file around during the installation
process, with both package name and the component it was found in.

hw-detect already has some finish-install hooks, so it would only need
to generate something like /var/log/installer/firmware-packages from
it, with “$package $component” on each line?

And maybe “# no firmware packages” (with a leading # to signal a
comment), so that people can easily iterate over it if they so wish?


I don't think that's a blocker for the next d-i release, that might be
considered a blocker for Bookworm though; debian-release@ in Cc can
comment and raise severity if that's desired.

If one wanted not to work on this at all, one could make the case that
/var/log/installer/syslog can be used to determine whether/which
firmware packages were installed; the presence of non-free-firmware in
sources.list would be another indication. (That's why I don't think
that's a short-term blocker at all.) But building a 2-column table out
of existing information shouldn't be much work anyway…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Uploading linux (6.1.8-1)

[Salvatore Bonaccorso]

Hi

I would like to upload linux version 6.1.8-1 to unstable.

[On a related note, if you, release team can unblock an let 6.1.7-1
still migrate to testing earlier that that, that would be welcome so
we have several important fixes in already for testing. Though there
is a regressions for i386. Help from people interested in i386 would
be very welcome.]

It consists of importing new 6.1.8 stable version. With that import
#1029816 get resolved.

An ABI bump is included.

Other changes on top in the packaging consist of:

  * d/t/main.control.in: Add Depends on python3-jinja2 for linux-support
packages
  * gpiolib-acpi: Don't set GPIOs for wakeup in S3 mode (Closes: #1029046)
  * drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count assignments
(Closes: #1028451)
  * drm/amdgpu/display/mst: limit payload to be updated one by one
(Closes: #1028451)
  * drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
(Closes: #1028451)
  * drm/display/dp_mst: Correct the kref of port. (Closes: #1028451)
  * Bump ABI to 3
  * d/rules.real: Remove executable bit from dtb files (Closes: #1028601)
  * Add patch to fix missing symbol versions for str{,n}{cat,cpy}
on alpha. Fixes FTBFS. (Closes: #1027974)
  * [amd64] drivers/platform/x86/intel/uncore-frequency: Enable
INTEL_UNCORE_FREQ_CONTROL as module (Intel Uncore frequency control)
(Closes: #1029484)
  * [amd64] arch/x86: Enable 5-level page tables support (X86_5LEVEL)
(Closes: #1029674)

Regards,
Salvatore


signature.asc
Description: PGP signature

Processed: affects 1029823

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 1029823 gitlab
Bug #1029823 [release.debian.org] bullseye-pu: package 
ruby-cfpropertylist/2.2.8-1.1+deb11u1
Added indication that 1029823 affects gitlab
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1029823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029823
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1029823: bullseye-pu: package ruby-cfpropertylist/2.2.8-1.1+deb11u1

[Jakob Haufe]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ruby-cfpropertyl...@packages.debian.org, su...@debian.org
Control: affects -1 + src:ruby-cfpropertylist

This update fixes #1029726 in bullseye.

This bug was introduced silently by updating ruby above 1.8.

The most visible impact is fixing displaying diffs in the fasttrack packaging
of gitlab.

The patch was tested manually by applying it to at least two gitlab instances.

The only other consumer of ruby-cfpropertylist in Debian, ruby-fission, still
builds fine and passes its build time tests with this update applied.

As this removes a namespace pollution, I see no risks involved with this
updated.

The change has been cherry-picked from upstream.

Debdiff attached.

-- 
ceterum censeo microsoftem esse delendam.


ruby-cfpropertylist_2.2.8-1.1_to_2.2.8-1.1+deb11u1.debdiff
Description: Binary data


pgprVdSqzv4GL.pgp
Description: OpenPGP digital signature

Processed: bullseye-pu: package ruby-cfpropertylist/2.2.8-1.1+deb11u1

[Debian Bug Tracking System]

Processing control commands:

> affects -1 + src:ruby-cfpropertylist
Bug #1029823 [release.debian.org] bullseye-pu: package 
ruby-cfpropertylist/2.2.8-1.1+deb11u1
Added indication that 1029823 affects src:ruby-cfpropertylist

-- 
1029823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029823
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems