Re: Any hint how to fix python 3.11 pth files errors? (Was, First Noble Numbat test rebuild)

[Sebastien Bacher]

Hey Graham, sorry copy fail, the email was meant to include a bug reference

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

so libpwquality

vut also system-config-printer
https://launchpadlibrarian.net/706849625/buildlog_ubuntu-noble-amd64.system-config-printer_1.5.18-1ubuntu3_BUILDING.txt.gz

is another example

Cheers,
Sébastien

Le 11/01/2024 à 18:04, Graham Inggs a écrit :

Hi Sébastien

On Thu, 11 Jan 2024 at 15:59, Sebastien Bacher  wrote:

I noticed that a bunch of the desktop failures are python 3.11 problems
similar to the one discussed in

Would you name some of those packages please?

Regards
Graham



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Any hint how to fix python 3.11 pth files errors? (Was, First Noble Numbat test rebuild)

[Sebastien Bacher]

Hey there,

I noticed that a bunch of the desktop failures are python 3.11 problems 
similar to the one discussed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033353


> TEST FAILED: 
/<>/debian/tmp/usr/local/lib/python3.11/dist-packages/ does 
NOT support .pth files



Is there any standard fix/suggestion for those cases (to avoid having 
for everyone to figure out the same thing again)?


Cheers,
Sébastien

Le 02/01/2024 à 12:20, Graham Inggs a écrit :

The first test rebuild of Noble Numbat was started on December 15,
2023 for all architectures, all components. The rebuild is finished
for all architectures for the main component and still running for
universe and multiverse on s390x and riscv64.

There were some buildd issues with s390x, but we hope they will catch up soon.

Results (please also look at the superseded builds) can be found at:

https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20231215-noble-noble.html

Additional build failures for packages in noble-proposed (not yet in
noble) can be found at:

http://qa.ubuntuwire.com/ftbfs/

Please help with fixing the build failures.

Another test rebuild using a glibc snapshot from December 2023 can be found at:

https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20231215-noble-glibc-noble.html

Still running for universe and multiverse on s390x and riscv64.  The
glibc snapshot can be found in:

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/glibc

Yet another test rebuild using GCC 14 can be found at:

https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20231215-noble-gcc-noble.html

Still running for universe and multiverse on s390x and riscv64. This
is in preparation for GCC 14 for the 24.10 release.  GCC test packages
can be found in:

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test

Happy New Year and bug fixing!
Graham



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu-studio-devel] "Support Plan" request challenge (WAS: Ubuntu Studio LTS Re-Qualification)

[Sebastien Bacher]

Hey Erich,

I'm a relatively new member of the TB and not familiar with how flavors 
were granted LTS status in the past but let me share my perspective on 
what you wrote.


Le 24/11/2023 à 07:02, Erich Eickmeyer a écrit :


That said, this seems way too detailed for a repeated LTS. I will 
certainly follow this for Edubuntu since it's returning after 10 
years, but for Ubuntu Studio, and any other flavor with a prior LTS in 
the past two years, this should be a much lower bar.


Checking 
https://lists.ubuntu.com/archives/technical-board/2016-April/002213.html 
what I see in this example is 7 bullet points and less than 20 lines of 
text (wrapped at 80chars), that doesn't seem a long or unachievable task 
to me. Could you be a specifics on what exactly is making the bar too 
high in your opinion?
To me it feels like it would have taken you less time to write those 
details than those emails...


That said, I'm not standing-down from this challenge, but revising it: 
I challenge the Technical Board to revisit and more clearly define 
exactly what "Flavor's support plan presented to Tech Board and 
approved; support planshould indicate period of time if beyond 18 
months (3yrs or 5yr), keycontacts, and setting expectations as to 
level of support." means with specifics, as the wording is too vague. 
Furthermore, the policy wording is clearly outdated ("18 months"), has 
been around too long without revision (2011) and the policy itself 
should probably be reworked in collaboration with the Flavor Leads as 
is the spirit of Ubuntu.


The page could be probably be a bit more specific on what is asked 
indeed. I think it's a fair ask for the TB to review the current wording 
and policy and see if we believe changes are needed. We do review 
mailing list activity and open questions during our IRC meetings so we 
should be able to pick it up next time


Cheers,
Sébastien Bacher
-- 
ubuntu-studio-devel mailing list
ubuntu-studio-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel

Re: Flutter Installer and CUPS Frustrations

[Sebastien Bacher]

Hey there,

Le 11/08/2023 à 03:58, eeickme...@ubuntu.com a écrit :
Furthermore, the switch to the CUPS snap is also affecting the 
flavors, as this was done without any notification via proper channels 
(any channel, really) before it was implemented. 


As you pointed out we did wrote about it on discourse, but yes it could 
probably have been communicated better/more directly to flavors before 
landing.


FYI we reverted the change now for mantic since we are past feature 
freeze and the UI was still not ready (in addition to the problem it 
created for flavors)


Cheers,
Sébastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: git-ubuntu MP workflows in Launchpad

[Sebastien Bacher]

Hey Bryce,

Le 29/06/2023 à 20:12, Bryce Harrington a écrit :

I do love automation, however I think we shouldn't rule out letting this
be somewhat manual.  I.e. we already tell non-git-ubuntu sponsorees to
manually sub ubuntu-sponsors:

   https://wiki.ubuntu.com/MOTU/Contributing
   "Set the bug to Status "Confirmed". Assign to "Nobody". Subscribe the
   ubuntu-sponsors team to add your bug to the Sponsorship Queue."

So we could just have the docs direct them to add both ~ubuntu-sponsors
*and*  ~ubuntu-sponsors-reporter, and it wouldn't be inconsistent with
established procedures.


The fact that it matches the existing situation doesn't make it the 
right outcome though...


In practice we often have bugs where the contributor did what was asked 
to address the reviewers feedback but forgot to subscribe back the 
sponsors. With the current workflow we have very little visibility on 
those cases and they often end up lost in the launchpad noise.
It would be nice if we had a way to at least query for those bugs so we 
could review recent activity and see if there are cases were sponsors 
should be subscribed back and hadn't...


Cheers,
Sébastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Symbols files for C++ libraries for Ubuntu main

[Sebastien Bacher]

And I just noticed that Lunar SRU
https://launchpad.net/ubuntu/+source/libcupsfilters/2.0~rc1-0ubuntu1.2

Which is another variant of the problems described before. gcc 12.3 is 
being SRUed o Lunar and according to the report linked to that update


> The added symbols don't belong to the ABI, however the build fails 
because dh_makeshlibs is called with -c4, and two more template 
instantiations show up on riscv64.


So we end up in a situation where issuing a minor gcc update is leading 
to build failures for our packages...


Cheers,
Sébastien


Le 09/06/2023 à 14:27, Sebastien Bacher a écrit :


Hey there,

We had been struggling with a few of those cases recently in desktop 
and I was going to send an email about the topic then checking the 
archive I found back that discussion that I had forgotten about.


I would like to ask if there is any chance the MIR team would 
reconsider their position on the topic (at least until the day we have 
a somewhat working solution we can use)?



Here is why. Taking  a recent example from desktop and describing the 
experience on one package where we basically had to go through those steps


1. We added a symbols to libcupsfilters as part of the MIR promotion
https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel=c5821fe0

The build failed on armhf because dh_makeshlibs report symbols on 
armhf which do not existing on amd64

https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz

which also included those types of changes

- _Znam@Base 2.0~b2-0ubuntu3
+ _Znaj@Base 2.0~b2-0ubuntu4
+#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3

I personally don't understand why we have those symbols existing on 
armhf which don't exist on amd64. Nor why _Znam@Base is becoming 
_Znaj@Base nor how we are supposed to handle such cases


2. I tried to help getting that resolved with that upload
http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz

Which basically add the symbols showing a new on the armhf as 
'(optional)' and also listed those that changes as optional in their 
different variants


3. similar round for riscv64

http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz

4. doing those tweaks need to be done manually since it's not only 
applying the diff but also adding optional keyword at places, I got 
one wrong and it failed to build again


add one more symbol specific to risvc
http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz

5. still failed, I had to add another bunch of symbols from the 
previous build log


http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz

Which finally got us a working build.


I understand the motivation for wanting a symbol file but I agree with 
what Robie, what's the benefit. In that case we spent a few hours to 
end up with a .symbols which as over 150 '(optional)' entries, that 
doesn't protect us much better than just not having a .symbols or 
using -c0 but still has a high cost.
And from experience it is likely that following the next toolchain 
update the .symbols will not match anymore and that those of us who 
will end up having to fix the package build will not understand why 
and just end up applying the diff proposed by dpkg-gensymbols.


Checking on the Debian side, https://wiki.debian.org/UsingSymbolsFiles 
has a 'C++ libraries' section which start by this statement written in 
bold style


> For C++ libraries it is often better not to ship symbols files.

Which means we will often fail at upstreaming such improvements to 
Debian and will have to increase our delta. And I don't blame them, 
I'm not even sure how to deal with the 'the symbols change between 
architectures' out of throwing builds to a ppa to get results and 
iterate and Debian doesn't have the ppa option...


Cheers,
Sebastien Bacher

Le 22/05/2018 à 18:25, Robie Basak a écrit :

On Fri, May 18, 2018 at 08:29:13PM +0200, Matthias Klose wrote:

I completely disagree.  Replacing a somehow suboptimal check with no
check is not an option.

On Fri, May 18, 2018 at 08:22:55PM +0100, Dimitri John Ledkov wrote:

IMHO symbols files should be mandatory for any new libraries
introduced in the archive.

And we should assert symbols files for everything in main, and fix all
the things.

It's 2018, and we really ought to have sensible and strict symbols
files.

Both of these statements on their own state that we must do this work
but don't explain why this is of benefit to Ubuntu. I feel that you need
to justify your position rather than just stating it.

Can you provide examples of where maintaining this delta has actually
helped make Ubuntu better, in the specific case that C++ symbols are
being maintained by Ubuntu in a delta that Debian and upstream have
declined to

debcheckout -a behavior in Ubuntu?

[Sebastien Bacher]

Hey Steve,

Le 08/06/2023 à 22:10, Steve Langasek a écrit :

Now the reason I think this needs discussion before I just run off and
implement it is that I know some teams use ubuntu branches on
salsa.debian.org today for their work.  But those repositories would be
unsuitable for the above workflow, because the ubuntu branch on salsa
doesn't know about Launchpad ~ubuntu-dev ACLs.


The issue isn't specific to salsa and ~ubuntu-dev though, we have 
packages maintained on launchpad but owned by teams which don't include 
~ubuntu-dev (I've often hit that problem trying to fix installer bugs) 
or in github, and in reverse we have Ubuntu uploaders who do have access 
to the salsa branches.


The question is rather 'has the person doing the checkout write access 
to the target repository'



Do folks who use non-Launchpad repositories as the primary vehicle for their
packaging work mind if 'debcheckout -a' stops pointing at those
repositories?


I've an issue with that yes. For me as a package maintainer the ideal 
outcome for the cases where the uploader doesn't have write access to 
the Vcs would be to receive a merge request targeting the Vcs where the 
package is maintained. That's less work for the contributor (it gives 
them a chance to base the changes on the current state of the package 
vcs which might be different from the archive one, it might even 
potentially already include a fix for their problem) and less work for 
the maintainer (no need to rebase, possibility to merge from the webUI 
directly, ...).


Ideally we would guide them in doing the right thing (get an account if 
needed/push to personal space/mp).


For practical reasons it might be that the only reasonable action we can 
do in a consistant way from the debcheckout is to clone the git-ubuntu 
vcs but if go that way I would like for the tools to start by displaying 
a warning that the package is as actually maintained at 
 and that it is recommended/suggested to try to submit 
the fix there even if the tool is about to give a checkout from an 
import instead.


Cheers,
Sébastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Symbols files for C++ libraries for Ubuntu main

[Sebastien Bacher]

Le 17/06/2023 à 04:09, Seth Arnold a écrit :

On Thu, Jun 15, 2023 at 04:07:54PM +1000, Christopher James Halse Rogers wrote:

abi-compliance-checker and abigail. None of those experiments have ended up
sticking, though, for reasons which I'm not fully aware of. Alan Griffiths
and Michał Sawicz did most of that investigation; I'll see if they can help
shed light on problems we encountered.

If we *can* get (one of) the ABI checking tools working they'll be more
valuable than a symbols file anyway, as they actually check that ABI didn't
change rather than just that the symbol strings in the DSO match.

I'm not actually close enough to package updates to see how exactly these
different tools report symbols problems. I've tried reading the Debian
Wiki page, the KDE symbols page, etc, but without having these problems
myself, first-hand, it's hard for me to come to terms with the issues.

How do the default symbols files "failures" appear when building packages?
Are the results "actionable"? Or is the usual outcome to pave over the old
file and use a new file?


One typical example, that's a libcamera build that worked in Debian, was 
synced in Ubuntu and failed to build

https://launchpadlibrarian.net/486620598/buildlog_ubuntu-groovy-amd64.libcamera_0~git20200629+e7aa92a-3_BUILDING.txt.gz

Search for dpkg-gensymbols in the log

$ diffstat symbols.patch
 dpkg-gensymbols5sl4ol |  691 


 1 file changed, 501 insertions(+), 190 deletions(-)


What's the ratio of false positives to true positives?
If the library is well maintained we should have true positives, my 
experience on desktop packages from the past years is that we only get 
false positives like in the example there where the package is identical 
between Debian and Ubuntu and yet we get that stack of changes in the 
symbols.

There's more to ABI compatibility than keeping the types of parameters and
return values lined up. Do any of the ABI tracking tools provide help
looking into the types, or the functions, etc?
I think abi-compliance-checker is doing at some of that, from the 
website, https://lvc.github.io/abi-compliance-checker/


> The tool can create and compare ABI dumps for header files and shared 
objects of a library.



Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: SRU bug subscription for sponsors

[Sebastien Bacher]

Le 14/06/2023 à 22:32, Robie Basak a écrit :


If sponsors aren't prepared to do this, I question whether what they are
doing is actually useful. The harm is that they are leaving
non-uploaders in the cold, and review teams are spending unnecessary
effort that could be diverted to doing the reviews that only they can
do.


The issue is not really 'to be prepared to do this'. I do agree with you 
that the sponsors should be engaged in the process, especially when 
sponsoring work from someone who isn't familiar with all the details of 
the system. It is especially true for SRU uploads which often need 
follow-ups to deal with the issues you mentioned. Subscribing to the 
corresponding launchpad bug makes sense in that context and that's 
something I would recommend doing.


Where I disagree is that it should be forced on us this way, without 
even letting us the change to have a public discussion here before 
having the change in action.


A few concerns I have

1. I've noticed that people (even in our teams at Canonical) don't keep 
up with bug emails and some end up just ignoring anything coming from 
launchpad. The issue isn't new and isn't due to the new bot, but the bot 
is adding to the problem.


2. You argue that we should expect that the people asking for sponsoring 
aren't familiar with the processes or they wouldn't ask for sponsoring 
such they need guidance and involvement from their sponsors. While 
that's true for a class of contributors it's often not the case. I'm 
regularly sponsoring work for people in my team who are perfectly able 
to follow up on their changes and know the process, it just happens that 
sometime they need to upload a fix outside of the packagesets they have 
access to


3. You say "sponsors will follow through on uploads until they land", 
could the script be made to be smart enough to unsubscribe the sponsor 
at that point? Launchpad bugs are often noisy (users sometime comment on 
unrelated closed issues which seem similar to what they face, they ask 
for guidance on how to install an SRU updates, ...) which adds to 
problem 1. Yes I can go to unsubscribe manually if I'm bothered enough 
but that's just one more annoyance and manual action needed which 
contributes to the 'it's easier to just filter launchpad emails in a 
folder and ignore those'.


Cheers,
Sébastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Symbols files for C++ libraries for Ubuntu main

[Sebastien Bacher]

Hey there,

We had been struggling with a few of those cases recently in desktop and 
I was going to send an email about the topic then checking the archive I 
found back that discussion that I had forgotten about.


I would like to ask if there is any chance the MIR team would reconsider 
their position on the topic (at least until the day we have a somewhat 
working solution we can use)?



Here is why. Taking  a recent example from desktop and describing the 
experience on one package where we basically had to go through those steps


1. We added a symbols to libcupsfilters as part of the MIR promotion
https://git.launchpad.net/ubuntu/+source/libcupsfilters/commit/debian/libcupsfilters2.symbols?h=applied/ubuntu/devel=c5821fe0

The build failed on armhf because dh_makeshlibs report symbols on armhf 
which do not existing on amd64

https://launchpadlibrarian.net/647850924/buildlog_ubuntu-lunar-armhf.libcupsfilters_2.0~b2-0ubuntu4_BUILDING.txt.gz

which also included those types of changes

- _Znam@Base 2.0~b2-0ubuntu3
+ _Znaj@Base 2.0~b2-0ubuntu4
+#MISSING: 2.0~b2-0ubuntu4# _Znam@Base 2.0~b2-0ubuntu3

I personally don't understand why we have those symbols existing on 
armhf which don't exist on amd64. Nor why _Znam@Base is becoming 
_Znaj@Base nor how we are supposed to handle such cases


2. I tried to help getting that resolved with that upload
http://launchpadlibrarian.net/647856580/libcupsfilters_2.0~b2-0ubuntu4_2.0~b2-0ubuntu5.diff.gz

Which basically add the symbols showing a new on the armhf as 
'(optional)' and also listed those that changes as optional in their 
different variants


3. similar round for riscv64

http://launchpadlibrarian.net/647865001/libcupsfilters_2.0~b2-0ubuntu5_2.0~b2-0ubuntu6.diff.gz

4. doing those tweaks need to be done manually since it's not only 
applying the diff but also adding optional keyword at places, I got one 
wrong and it failed to build again


add one more symbol specific to risvc
http://launchpadlibrarian.net/647875197/libcupsfilters_2.0~b2-0ubuntu6_2.0~b2-0ubuntu7.diff.gz

5. still failed, I had to add another bunch of symbols from the previous 
build log


http://launchpadlibrarian.net/647896999/libcupsfilters_2.0~b2-0ubuntu7_2.0~b2-0ubuntu8.diff.gz

Which finally got us a working build.


I understand the motivation for wanting a symbol file but I agree with 
what Robie, what's the benefit. In that case we spent a few hours to end 
up with a .symbols which as over 150 '(optional)' entries, that doesn't 
protect us much better than just not having a .symbols or using -c0 but 
still has a high cost.
And from experience it is likely that following the next toolchain 
update the .symbols will not match anymore and that those of us who will 
end up having to fix the package build will not understand why and just 
end up applying the diff proposed by dpkg-gensymbols.


Checking on the Debian side, https://wiki.debian.org/UsingSymbolsFiles 
has a 'C++ libraries' section which start by this statement written in 
bold style


> For C++ libraries it is often better not to ship symbols files.

Which means we will often fail at upstreaming such improvements to 
Debian and will have to increase our delta. And I don't blame them, I'm 
not even sure how to deal with the 'the symbols change between 
architectures' out of throwing builds to a ppa to get results and 
iterate and Debian doesn't have the ppa option...


Cheers,
Sebastien Bacher

Le 22/05/2018 à 18:25, Robie Basak a écrit :

On Fri, May 18, 2018 at 08:29:13PM +0200, Matthias Klose wrote:

I completely disagree.  Replacing a somehow suboptimal check with no
check is not an option.

On Fri, May 18, 2018 at 08:22:55PM +0100, Dimitri John Ledkov wrote:

IMHO symbols files should be mandatory for any new libraries
introduced in the archive.

And we should assert symbols files for everything in main, and fix all
the things.

It's 2018, and we really ought to have sensible and strict symbols
files.

Both of these statements on their own state that we must do this work
but don't explain why this is of benefit to Ubuntu. I feel that you need
to justify your position rather than just stating it.

Can you provide examples of where maintaining this delta has actually
helped make Ubuntu better, in the specific case that C++ symbols are
being maintained by Ubuntu in a delta that Debian and upstream have
declined to adopt or postponed adopting? Without examples, we're not
really in a position to assess the trade-off of extra work vs. benefit
to Ubuntu. I don't think we should be maintaining delta unless the
benefit can be articulated and justified.

Separately, I question whether it's in the interest of our project to
spend time on maintaining a quality improvement indefinitely if Debian
and/or upstream decline to take it, and if that particular improvement
is not a high level goal of our project.

Thanks,

Robie
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
ht

Re: SRU bug subscription for sponsors

[Sebastien Bacher]

Hey Robie,

While I understand the rational, that's putting the annoyance on the 
sponsors and might decrease their motivation to help with the uploads. 
The annoyance being that by helping reviewing/uploading some change we 
will now end up being email nagged for every action/user follow up on 
the issues until you manual go to launchpad to unsubscribe.


Did the SRU team consider trying to identify the situations where the 
sponsors actual need to be subscribed and try to add them back only in 
those cases? Or to encourage the sponsoree to reach out to the sponsor 
again if needed? Or to have the SRU team subscribe back the sponsor only 
in case where an action is actually needed?


Cheers,
Sébastien Bacher

Le 01/06/2023 à 18:59, Robie Basak a écrit :

Dear Ubuntu Developers,

If you sponsor an SRU, please subscribe to its bugs so that you can
respond to any enquiries from the SRU team, and step in as necessary.

We're now also subscribing SRU sponsors automatically, but the initial
implementation is racy, so this might not always occur if SRU unapproved
processing is too quick (ha!). Hopefully it'll help in most cases, so
this should be much better than nothing. Incremental improvements!

We find that sometimes the sponsoree doesn't understand the process,
which is of course to be expected - that's what the sponsorship process
is for! But it seemed that sometimes sponsors weren't getting the
message, and the SRU would stall - hence this request, and the
autosubscription to help.

Robie



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Contributing Developer application: Amin Bandali

[Sebastien Bacher]

The DMB voted today in favor of Amin's application as Ubuntu Contributin 
Developer and he was added to ~ubuntu-developer-members


Congratulations Amin!

Le 27/02/2023 à 18:07, Amin Bandali a écrit :

Dear DMB,

I hereby apply to become an Ubuntu Contributing Developer.

You can find my application at:
   https://wiki.ubuntu.com/bandali/contributing-developer-application

I updated my reservation date on the agenda for the next meeting,
scheduled on 2022-03-06, with Seb's approval.

Thank you,
-a



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: DKMS upload rights application

[Sebastien Bacher]

The DMB voted today in favor of Andrea's application for the DKMS set, 
he has been added to ~ubuntu-kernel-dkms-uploaders team now


Congratulations Andrea!

Le 11/02/2023 à 13:55, Andrea Righi a écrit :

I would like to announce my application for membership in the DKMS
package set uploader team. My application can be found at:

https://wiki.ubuntu.com/AndreaRighi/DkmsUploadApplication

I have added myself to the agenda for the DMB meeting at:

https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda

Thanks,
-Andrea



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Replacing the telegram-desktop deb by a snap installer in stable series?

[Sebastien Bacher]

Hey Robie,

Le 23/02/2023 à 14:59, Robie Basak a écrit :

Nobody else seems to have an opinion on this? It's feature freeze today,
so as there doesn't seem to be anyone maintaining this delta, I propose
to remove the deb and I'll file a bug accordingly. Users who upgrade to
Lunar will be able to switch to the (non-Ubuntu-published) snap
manually.


In that scenario is anything going to take care to remove the deb from 
the system of users upgrading or warning them that they are left on an 
old and buggy version which isn't going to get updates?


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Run Focal i386 autopkgtests locally

[Sebastien Bacher]

Hey Steve, Julian,

I was reading again those steps Christian shared a while ago and noticed 
the current archive autopkgtest version still doesn't implement the '-a' 
option.
It seems 
https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development/+merge/376169 
got an ack 3 years ago, is there anything blocking the merge?


I've added the notes on 
https://wiki.ubuntu.com/ProposedMigration#How_do_we_debug_i386_issues 
because it's not the first time I have to figure that again and it's 
probably the same for others. It would be nice it things working with 
the archive version of autopkgtest


Cheers,
Sebastien

Le 06/02/2020 à 16:37, Christian Ehrhardt a écrit :

Hi,
The i386 removal works great and after the dust settled it comes 
mostly down to adding a few more hints in recent weeks. But sometimes 
there are i386 tests that are valid to run, but fail and need debugging.


If you happen to face such a case the old common pattern won't work 
anymore:


$ sudo autopkgtest-buildvm-ubuntu-cloud -a i386 -r bionic -s 15G
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest .dsc \
  -- qemu ~/work/autopkgtest-focal-amd64.img

The above was fine in the past, but with Focal you that won't work due to:
$ sudo autopkgtest-buildvm-ubuntu-cloud -a i386 -r focal -s 15G
Downloading 
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-i386.img...

No image exists for this release/architecture

Steve was so kind to help me with the case I was facing and after a 
bit I learned how to locally run my i386 tests in a VM and wanted to 
share that with you.


First of all, you probably need a more recent autopkgtest to get the 
features you need.

So you need to clone git and run it from there.

$ git clone 
git+ssh://pael...@git.launchpad.net/~ubuntu-release/autopkgtest/+git/development 


[for me that is in ~/work/autopkgtest/autopkgtest]

And then - since you only have amd64 images - to run it you have to add
# to select the architecture for the test
  -a i386
# to get the arch available in the test env before the testing starts
  --setup-commands="dpkg --add-architecture i386; apt-get update"

Overall for me it then worked like:
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest .dsc \
  --setup-commands="dpkg --add-architecture i386; apt-get update" -a 
i386 \

  -- qemu ~/work/autopkgtest-focal-amd64.img

I hope this helps some other people as well.
And if anyone knows more tweaks to get this local i386 test to run 
even better please reply and let us all know.


P.S. of course my commandline never is that simple, the above is just 
for illustration.

In reality it was more like:
$ sudo ~/work/autopkgtest/autopkgtest/runner/autopkgtest 
--no-built-binaries --apt-upgrade --apt-pocket=proposed=src:re2c 
--setup-commands="dpkg --add-architecture i386; apt-get update" 
--shell-fail -a i386 re2c_1.3-1.dsc -- qemu --qemu-options='-cpu host' 
--ram-size=2048 --cpus 2 ~/work/autopkgtest-focal-amd64.img


--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report

[Sebastien Bacher]

Hey Robie, your email was interesting to read, I've one question bellow

Le 05/12/2022 à 18:04, Robie Basak a écrit :

  I thought I recalled a
colleague mentioning something about this in ubuntu-helpers


Could you share a reference to ubuntu-helpers? I don't know about that 
project and neither apt search, launchpad.net/ubuntu-helpers nor google 
leaded me to the right place...


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Extended call for Ubuntu Technical Board candidates

[Sebastien Bacher]

Hey there!

I'm Sebastien Bacher, member of the Ubuntu Desktop Team and working for 
Canonical since 2004. I'm also an Ubuntu Archive members since 2007 and 
joined the DMB this year.
I do care about Ubuntu as a project, and not only the desktop part, 
which is why I try to help things moving by being active on the dev 
channels (IRC, lists, discourse), sponsor uploads (to Ubuntu and to 
Debian),  keep an eye on launchpad reports to direct reporters to the 
right place and toward a resolution of the issues if possible, try to 
lower our packages delta with Debian, etc. I'm also trying to push for 
us to communicate better and it a way which is accessible to everyone.


I've been around for long time and I think I know Ubuntu, our community 
and our upstreams well enough to represent the project interests as a 
member of the board.


I would like to help ensuring that the project keeps being welcoming and 
interesting to everyone by providing the right infrastructure and 
processes and by helping us to set the right technical decisions.


Cheers,
Sebastien Bacher

Le 29/11/2022 à 20:07, Torsten Franz a écrit :

Hi everyone,

We have received some applications for the new election of the Ubuntu 
Technical Board. A lot of great applications from very good 
candidates. In order to make a good decision in this selection, we 
would like to give the candidates the opportunity to introduce 
themselves here and to say a few words about their application and 
provide a few links to their work. Everyone will also have the 
opportunity to ask the candidates questions. We will start the 
election on 6 December. All five seats (besides Mark) will be filled.


Here is the list of candidates (by alphabetical order of surname):

- Sebastien Bacher
- Robie Basak
- Ben Collins
- Steve Langasek
- Lukas Märdian
- Alex Murray
- Simon Quigley
- Mathieu Trudel-Lapierre
- Łukasz Zemczak

If any questions arise, then the Ubuntu Community Council is available 
to help.


On behalf of the Ubuntu Community Council,
Torsten Franz


Am 22.11.2022 22:51 schrieb Merlijn Sebrechts:

WE ARE STILL LOOKING FOR CANDIDATES TO JOIN THE UBUNTU TECHNICAL
BOARD!

The call remains open until NOVEMBER 27TH, 2022, at 23:59 UTC. This is
a bit longer than initially anticipated.

Are you interested or do you know of someone who you want to see in
this role? Please submit the nomination.

WHAT IS THE UBUNTU TECHNICAL BOARD?

The Ubuntu Technical Board is responsible for the technical direction
of Ubuntu. It makes decisions on package selection, packaging policy,
installation systems and processes, kernel, X server, display
management, library versions, and dependencies. The board works with
relevant teams to establish a consensus on the right path to take,
especially where diverse elements of Ubuntu cannot find consensus on
shared components. The current Technical Board is expiring at the end
of the year, and the Community Council would like to confirm a new
Technical Board, consisting of five people, who will serve for two
years. The eligibility requirements are:

WHO IS ELIGIBLE?

Everyone who meets the following criteria:

* Be an Ubuntu Core Developer
* Be available during typical meeting hours [see
https://wiki.ubuntu.com/TechnicalBoardAgenda [1]]
* Have insight into the Ubuntu Development process, architecture, 
and

technical culture

HOW DO YOU NOMINATE YOURSELF OR SOMEONE ELSE?

Send the Community Council an email (community-council AT
lists.ubuntu.com [2]). With your nomination. Note that you can
nominate yourself too!

HOW DOES THE ELECTION WORK?

The call remains open until November 27th, 2022, at 23:59 UTC. After
that, the Community Council will review the submissions, submit them
to Mark Shuttleworth for shortlisting, and proceed with a vote by the
Ubuntu Development team.

Links:
--
[1] https://wiki.ubuntu.com/TechnicalBoardAgenda
[2] http://lists.ubuntu.com




--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Setting NotAutomatic for hirsute+1-proposed

[Sebastien Bacher]

Le 22/11/2022 à 20:24, Julian Andres Klode a écrit :
We have no idea why the test dependencies are failing to install in a 
normal setup,



Which case are you talking about? The dbus issue is clear, the base 
image used by the autopkgtest infra is build from kinetic with 
kinety-security versions of packages but the apt source are lunar ones 
without proposed. The packages are failing to install because 
kinetic-security has updates which are in lunar-proposed but didn't 
migrate to lunar.


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Setting NotAutomatic for hirsute+1-proposed

[Sebastien Bacher]

Hey there,

Le 22/11/2022 à 18:21, Paride Legovini a écrit :

The dbus package has now need force-migrated from lunar-proposed to
-release (currently pending publication). This should fix the issue.


I've stated that via chat but I still disagree that was the right thing 
to do. Without tests result how are we confident that the update isn't 
bringing a regression (one other update in lunar could create issue for 
the dbus in proposed)? Why didn't we fix the autopkgtest setup to use an 
lunar image or enable proposed to allow the tests to be correctly tried 
instead?


Also are we confident that they aren't other packages in the same 
situations?


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Removing the old ubuntu theme from plymouth

[Sebastien Bacher]

Hey,

We postponed the change to after the LTS but it has been uploaded to kinetic
https://launchpad.net/ubuntu/+source/plymouth/22.02.122-1ubuntu2

Cheers,
Sebastien Bacher

Le 18/03/2022 à 16:29, Sebastien Bacher a écrit :

Hey there,

A refresh of the Ubuntu logo is landing in Jammy, we updated the 
default plymouth theme (spinner, the one which displays the 
bios/vendor icon in the middle of the screen with an ubuntu watermark 
at the bottom) but it triggers the question of what to do with the old 
'ubuntu-logo' theme which we were using until focal.


Since the artwork is outdated and the theme unmaintained  the Desktop 
Team is proposing to remove ubuntu-logo now. The theme is still 
recommended by the unity and kylin desktop packages, we suggest 
replacing it by spinner as it has been done for ubuntu desktop.


Is anyone knowing of a reason why we shouldn't do that change? If so 
please reply to that email, otherwise we will go ahead and file a FFe 
to remove the theme before the LTS.


Cheers,
Sebastien Bacher




--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Point Release process addition

[Sebastien Bacher]

Hey Brian,

First it seems a bit short notice to give that warning a week before the 
milestone, even if the current report indicates there should be no 
practical issue it would be nice to have such changes discussed more in 
advance in the futur


And I've also some questions

1. Are we confident those issues are currently visible to owning teams? 
I think only the uploader get notified today, maybe it would make sense 
to also reports bugs and tag those rls-...-incoming as we do for archive 
rebuilds?


2. Are you going to make stakeholders part of the decision process and 
if so how?


3. If you decide to revert back to the previous version, what does it 
mean for users who already got the upgrade? Do we let them on a version 
we decided was buggy and should be reverted? If that's the case 
shouldn't we try to rather bump the revision to something newer to 
ensure everyone is moved out the buggy version?


Cheers,
Sebastien Bacher

Le 26/07/2022 à 01:05, Brian Murray a écrit :

With the imminent point release of Ubuntu 22.04 LTS, I wanted to let
everyone know of an addition to the point release process[1] followed by
the Ubuntu Release team.

The team will evaluate the packages currently phasing[2] which are also
on any installation media and make a decision as to whether the packages
should be fully phased or if the package should be reverted back to the
prior version.

The point of doing this is to ensure that we are not creating an image
(and subsequently an installed system) with a package version which
contains a regression in that package.

[1] https://wiki.ubuntu.com/PointReleaseProcess
[2] https://people.canonical.com/~ubuntu-archive/phased-updates.html

Thanks,
--
Brian Murray
on behalf of the Ubuntu Release Team



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Adding logo images to base-files?

[Sebastien Bacher]

Hey again,

I went ahead and uploaded the basic change initially suggested. I think 
it could make sense to allow flavors to divert os-release and tweak the 
content according to what they want to define but it shouldn't block us 
doing the first step.


Cheers,
Sebastien Bacher

Le 14/06/2022 à 15:06, Sebastien Bacher a écrit :


Hey,
Le 14/06/2022 à 02:09, Erich Eickmeyer a écrit :

Just chiming-in here from a Flavor Lead perspective. It seems like this
could be something that could be implemented via update-alternatives,
similar to how plymouth themes and distributor-logo and are controlled.


How are flavor handling /etc/os-release today? LOGO isn't the only 
thing there they might want to set differently from Ubuntu 
(pretty_name, support_url, bug_report_url are other examples).


Using alternatives for the logo here sounds like the wrong solution, 
it's the os-release that should be diverted instead.


Cheers,
Sebastien Bacher




--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: bash-dbgsym missing for jammy

[Sebastien Bacher]

Hey there,

Ok, since the job is long and failing on any connectivity I tried again 
with a smaller set and reduced to amd64. That worked and now the amd64/J 
indexes have been updated, bash-dbgsym and some other which were missing 
are not available. I'm doing similar updates for the other architectures 
now.


Cheers,
Sebastien Bacher

Le 06/07/2022 à 00:20, Sebastien Bacher a écrit :

Hey there,

I probably should post an update here. I poked at that issue on friday 
and it was indeed missing from the index, unsure why.


I tried to force an index refresh by doing some hacks to the retriever 
job (usually it ignores released series since those are not changing) 
which added bash-dbgsym back but lost other entries. The corresponding 
ddebs seem to be also missing from the archive 
(accountsservice-dbgsym_22.07.5-2ubuntu1_amd64.ddeb for example). 
Unsure how those went missing, the retriever log clean ddebs it 
believes to be outdated but logs the deletion and that one isn't 
listed. To try to fix the situation I started to trigger a re-import 
of the 22.04 ddebs but it's way slower than expected and ongoing since 
sunday. I will post an update once the job has finished.


Cheers,
Sebastien Bacher

Le 05/07/2022 à 17:48, Brian Murray a écrit :

On Fri, Jul 01, 2022 at 08:44:20PM +, Benjamin Drung wrote:

Hi,

while debugging the apport autopkgtest failures on armhf, I wanted to
install bash-dbgsym on jammy. I added the ddebs repository:

$ cat /etc/apt/sources.list.d/ddebs.list
deb http://ddebs.ubuntu.com jammy main restricted universe multiverse
deb http://ddebs.ubuntu.com jammy-updates main restricted universe 
multiverse
deb http://ddebs.ubuntu.com jammy-proposed main restricted universe 
multiverse


but "apt policy bash-dbgsym" did not show a result. Launchpad claims
that bash-dbgsym was built:
https://launchpad.net/ubuntu/+source/bash/5.1-6ubuntu1

bash-dbgsym can be found in kinetic though.

What's going on here?

I was unable to recreate this issue today and could install bash-dbgsym.

$ apt-get install bash-dbgsym
...
Get:1 http://ddebs.ubuntu.com jammy/main amd64 bash-dbgsym amd64 
5.1-6ubuntu1 [1788 kB]

Fetched 1788 kB in 2s (958 kB/s)
Selecting previously unselected package bash-dbgsym.
...

--
Brian Murray





--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: bash-dbgsym missing for jammy

[Sebastien Bacher]

Hey there,

I probably should post an update here. I poked at that issue on friday 
and it was indeed missing from the index, unsure why.


I tried to force an index refresh by doing some hacks to the retriever 
job (usually it ignores released series since those are not changing) 
which added bash-dbgsym back but lost other entries. The corresponding 
ddebs seem to be also missing from the archive 
(accountsservice-dbgsym_22.07.5-2ubuntu1_amd64.ddeb for example). Unsure 
how those went missing, the retriever log clean ddebs it believes to be 
outdated but logs the deletion and that one isn't listed. To try to fix 
the situation I started to trigger a re-import of the 22.04 ddebs but 
it's way slower than expected and ongoing since sunday. I will post an 
update once the job has finished.


Cheers,
Sebastien Bacher

Le 05/07/2022 à 17:48, Brian Murray a écrit :

On Fri, Jul 01, 2022 at 08:44:20PM +, Benjamin Drung wrote:

Hi,

while debugging the apport autopkgtest failures on armhf, I wanted to
install bash-dbgsym on jammy. I added the ddebs repository:

$ cat /etc/apt/sources.list.d/ddebs.list
deb http://ddebs.ubuntu.com jammy main restricted universe multiverse
deb http://ddebs.ubuntu.com jammy-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com jammy-proposed main restricted universe multiverse

but "apt policy bash-dbgsym" did not show a result. Launchpad claims
that bash-dbgsym was built:
https://launchpad.net/ubuntu/+source/bash/5.1-6ubuntu1

bash-dbgsym can be found in kinetic though.

What's going on here?

I was unable to recreate this issue today and could install bash-dbgsym.

$ apt-get install bash-dbgsym
...
Get:1 http://ddebs.ubuntu.com jammy/main amd64 bash-dbgsym amd64 5.1-6ubuntu1 
[1788 kB]
Fetched 1788 kB in 2s (958 kB/s)
Selecting previously unselected package bash-dbgsym.
...

--
Brian Murray



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Adding logo images to base-files?

[Sebastien Bacher]

Hey,
Le 14/06/2022 à 02:09, Erich Eickmeyer a écrit :

Just chiming-in here from a Flavor Lead perspective. It seems like this
could be something that could be implemented via update-alternatives,
similar to how plymouth themes and distributor-logo and are controlled.


How are flavor handling /etc/os-release today? LOGO isn't the only thing 
there they might want to set differently from Ubuntu (pretty_name, 
support_url, bug_report_url are other examples).


Using alternatives for the logo here sounds like the wrong solution, 
it's the os-release that should be diverted instead.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Adding logo images to base-files?

[Sebastien Bacher]

Hey there,

I'm trying to see how we can fix https://launchpad.net/bugs/1931582 in 
Ubuntu, which is about adding a LOGO= entry to os-release.


I think it somewhat would make sense to provide the logos (plural 
because following 
https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/985 
it makes sense to have -text/-dark/text-dark variants.) in the same 
package as the key is defined?


Checking the current logo images it would be ~15kB of svg (or maybe png) 
files added to the package.


Would that sound something reasonable?

Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: systemd-oomd issues on desktop

[Sebastien Bacher]

Le 09/06/2022 à 21:19, Dan Streetman a écrit :

Personally, I think this is the correct option. 1GB is not a good
default swap size.


Did we ever consider doing the same than fedora is doing there?

https://fedoraproject.org/wiki/Changes/SwapOnZRAM

Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: systemd-oomd issues on desktop

[Sebastien Bacher]

Le 10/06/2022 à 17:52, Julian Andres Klode a écrit :

but I think the main
problem is that there is no desktop integration telling the user
why something was killed so they assume malfunction.

If we had a popup after an oom event saying

   The application firefox was closed to maintain system performance

we'd have a lot less complaints.


I disagree with that. I think the main complain is that the users expect 
to be able to keep doing what they had started, especially when they had 
been doing the same type of work for a long time without experiencing 
any sluggishness.


It would probably better to be warning before facts than after, like 
when the system is getting close from the point displaying a 
notification, the same way than you get a low battery warning before 
having the laptop suspending.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: systemd-oomd issues on desktop

[Sebastien Bacher]

Le 10/06/2022 à 11:40, Julian Andres Klode a écrit :

The bug reports we see show that systemd-oomd is working correctly:
The browser gets killed, the system remains responsive without having
become unresponsive as would be the usual case.


It might be working 'correctly' but is not perceived as such by users. 
I've seen regular complains from users since the release stating that 
their browser or code editor got closed in front on them without 
warning, on a machine they had been using for years with the same 
configuration and software without issue.


They might be getting short in resources but in practice they never 
experienced a sluggish system due to it and just see the feature as buggy.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Error Tracker data retention

[Sebastien Bacher]

Le 17/05/2022 à 00:28, Brian Murray a écrit :

Yes, that data would still be kept.


Great, +1 for me to do the cleanups!


Yes, that sounds like a good idea and I've created
http://launchpad.net/bugs/1973646 about this.


Thanks

Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/kinetic-proposed] bluez 5.64-0ubuntu2 (Accepted)

[Sebastien Bacher]

Hey Dan,

Thanks for the reply, things make sense now ;-)

Cheers,
Sebastien

Le 13/05/2022 à 23:38, Dan Bungert a écrit :

On Fri, May 13, 2022 at 10:39:54PM +0200, Sebastien Bacher wrote:

Hey Brian,

I noticed that upload and I'm curious about the motivation. It's really
early in the cycle and we will get bluez updates and time for archive
rebuilds later on so I guess the aim is not to get packages built with a new
LTO by release time. Did we have a buggy LTO version in the archive and are
we rebuilding things with a fixed version? Which packages do need a rebuild
and do we need to organize the rebuilds with the owning teams?

Cheers,
Sebastien Bacher

Le 13/05/2022 à 21:56, Brian Murray a écrit :

bluez (5.64-0ubuntu2) kinetic; urgency=medium

* No change rebuild to pickup a new version of LTO.

Date: Fri, 13 May 2022 12:36:19 -0700
Changed-By: Brian Murray 
Maintainer: Ubuntu Bluetooth team 
https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2

Hi Seb,

Brian uploaded this at my behest.

If you were to build with LTO against
/usr/lib/x86_64-linux-gnu/bluetooth/plugins/sixaxis.a, which can be found in
libbluetooth-dev, then you would see an error like:

 fatal error: bytecode stream in file
 ‘/tmp/tmphqmwfhcw/archive-1/sixaxis_la-sixaxis.o’ generated with LTO
 version 11.2 instead of the expected 11.3

I did some work last week detecting cases like this and requesting rebuilds.
My view on this was that if we built these proactively, we might prevent some
FTBFS.  So not so much a buggy LTO as a mismatched one.

Real-world example of this sort of problem, when attempting to build gyoto
against liblorene-dev:
https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/g/gyoto/20220503_215822_37721@/log.gz
 lto1: fatal error: bytecode stream in file
 ‘/usr/lib/x86_64-linux-gnu/lorene/Lib/liblorene_g.a’ generated with LTO
 version 11.2 instead of the expected 11.3

-Dan


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [ubuntu/kinetic-proposed] bluez 5.64-0ubuntu2 (Accepted)

[Sebastien Bacher]

Hey Brian,

I noticed that upload and I'm curious about the motivation. It's really 
early in the cycle and we will get bluez updates and time for archive 
rebuilds later on so I guess the aim is not to get packages built with a 
new LTO by release time. Did we have a buggy LTO version in the archive 
and are we rebuilding things with a fixed version? Which packages do 
need a rebuild and do we need to organize the rebuilds with the owning 
teams?


Cheers,
Sebastien Bacher

Le 13/05/2022 à 21:56, Brian Murray a écrit :

bluez (5.64-0ubuntu2) kinetic; urgency=medium

   * No change rebuild to pickup a new version of LTO.

Date: Fri, 13 May 2022 12:36:19 -0700
Changed-By: Brian Murray 
Maintainer: Ubuntu Bluetooth team 
https://launchpad.net/ubuntu/+source/bluez/5.64-0ubuntu2



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Error Tracker data retention

[Sebastien Bacher]

Hey Brian,

Le 12/05/2022 à 22:38, Brian Murray a écrit :

Keeping in mind that a crash bucket would still indicate
that old release and package version were affected are there any
objections to this change in data retention?


Would that include the details of the 'number of report by version on 
the series' table? If so deleting the individual reports should be ok.


Speaking of that table, could be consider removing older series from the 
table, or maybe reverse the table older and put the newest serie in the 
first column? Currently it starts on precise, which means on a standard 
lowdpi resolution you need to scroll to the right to see the information 
about the maintained series which is suboptimal.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Restoring debhelper dh5 compat for the LTS?

[Sebastien Bacher]

Hey Steve,

Thanks for the reply.

Le 23/03/2022 à 20:16, Steve Langasek a écrit :

- Any package using compat level 5 does not, for example, get automatic
   support for default build flags from dpkg-buildflags.  This means any
   binaries built with compat level 5 should be considered insecure and
   dangerous in their own right at this point, due to the lack of compiler
   security flags.
I agree it's an issue but I don't find the position we have coherent so 
far. It seems also bogus to me that we hadn't been actively engaged or 
communicating about the issue if we believe it's of the higher importance.


Should we start reporting rls-...-incoming bugs for package built with 
dh5 in every supported Ubuntu series? That would seems proportionate 
step in regard of what you and Dimitri seems to consider the severity of 
the issue?

- The merge of the debhelper version from Debian that included this change
   (which was decided upstream) happened on February 14.  This was well
   before Feature Freeze on February 24.  While in an ideal world someone
   making this change would have communicated proactively to the Ubuntu
   developers that it was coming and what impact it would have had, the lack
   of such communication does not, in my view, invalidate the decision to do
   the merge from Debian.


I didn't mean to imply that the merge was technically wrong or not 
respect our processes. Still it is late, has an non trivial impact on 
our workload and seemed a change the we got by luck rather than being 
actively seeking to bring it so I felt it was fair to asking the 
question of whether we wanted to consider reverting.


It's especially suboptimal than we basically stopped syncing from Debian 
around the time we included the change that made packages stop to build, 
which means we aren't autoimporting the fixes for those issues.



 From my perspective, it is the responsibility of teams to factor time
post-FF for the fixing of build failures into their capacity planning, and
furthermore, the impact of this *particular* change on archive buildability
should be rather small.  I see no reason to revert the change in question.
Speaking for desktop I'm not worried about being able to fix the build 
of the packages in our set, I simply believe it would benefit our users 
more if we were focusing on fixing rls targeted and user visible 
problems at this point of the cycle.


I'm also thinking about the impact it will have on universe and the 
number of ftbfsing package we will have in the archive for the LTS.


Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Restoring debhelper dh5 compat for the LTS?

[Sebastien Bacher]

Le 23/03/2022 à 16:08, Dimitri John Ledkov a écrit :

Thus yes, there is an explicit
mandate, especially for the universe, to be buildable. It can be
resolved by fixing & upgrading packaging, or via removal of those
packages from the archive. These packages are likely to be
ubuntu-specific and/or niche leaf packages, not present in Debian.


I'm fine with that but it's a last minute change which created the issue 
just before the LTS (if the change had landed a few weeks later we would 
talk about it and I don't think we could argue that the LTS would be 
lesser quality as a result. and is adding a bunch of extra work now. I'm 
asking for us to delay that problem to the start of next cycle to allow 
us to focus our limited resources on fixes that are actually visible to 
our users and having a negative impact on our product.


I understand your opinion Dimitri and I think you stated it clearly, no 
offense but I would like to also hear from other teams and from the 
release team on the topic.


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Restoring debhelper dh5 compat for the LTS?

[Sebastien Bacher]

Le 23/03/2022 à 15:58, Dimitri John Ledkov a écrit :
It's best to upgrade packaging to compat level 13. Sounds like a long 
overdue packaging upkeep.


Yes it's better, but it requires work, do we have the resources to deal 
with those, especially for universe?


Also you claim it produces buggy debs but do we have any report of such 
problems or any way to grep the archive to figure out special cases we 
know about that would give a non working binary?


Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Restoring debhelper dh5 compat for the LTS?

[Sebastien Bacher]

Hey there,

Checking the desktop section of the ongoing archive rebuild we have a 
bunch of ftbfs due


> dh: error: Compatibility levels before 7 are no longer supported 
(level 5 requested)


That's because the newest debhelper upload removed compatibility for 
level 5 and 6

https://salsa.debian.org/debian/debhelper/-/commit/a80ba4f797

Those issues are easy to fix but I would prefer us to focus on spending 
our effort on more user impacting problems so I'm suggesting we revert 
the change for the LTS.


How do other feel like about that?

Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Removing the old ubuntu theme from plymouth

[Sebastien Bacher]

Hey there,

A refresh of the Ubuntu logo is landing in Jammy, we updated the default 
plymouth theme (spinner, the one which displays the bios/vendor icon in 
the middle of the screen with an ubuntu watermark at the bottom) but it 
triggers the question of what to do with the old 'ubuntu-logo' theme 
which we were using until focal.


Since the artwork is outdated and the theme unmaintained  the Desktop 
Team is proposing to remove ubuntu-logo now. The theme is still 
recommended by the unity and kylin desktop packages, we suggest 
replacing it by spinner as it has been done for ubuntu desktop.


Is anyone knowing of a reason why we shouldn't do that change? If so 
please reply to that email, otherwise we will go ahead and file a FFe to 
remove the theme before the LTS.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for nominations: Developer Membership Board

[Sebastien Bacher]

Hey Robie and DMB members,

Le 01/03/2022 à 16:51, Robie Basak a écrit :

Candidates must expect to be able to attend the majority of DMB
meetings. Currently these take place on IRC, are scheduled on alternate
Mondays with each meeting alternating between 1600 UTC and 1900 UTC, and
last around an hour.


Following the recent emails stating that we don't have enough candidate 
I'm going to drop a note about ^


I was pondering sending my application, I'm busy but I think it's 
important that we have a function DMB, but that 'must expect' statement 
convinced me to not.
I try to lock the 17h30-20h to be able to have some family time and 
that's not something I'm wanting to compromise on at this point.


I might not be the only one in that situation, since we are short on 
candidate maybe it would help to try to be less rigid on that 
requirement? (being open to different times? allow members to skip and 
vote via email? ...)


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Ubuntu bug reporting for snaps (was: Should we remove chromium-browser from the archive?)

[Sebastien Bacher]

Hey Olivier, thanks for raising the topic!

Le 08/02/2022 à 19:33, Olivier Tilloy a écrit :

  - a custom apport hook that collects additional information about the
snap and its dependencies


I'm going to sidetrack slightly the discussion in a new topic to address 
that point. I think that's a problem we need to resolve for snaps. We 
added some hooks to apport directly for subiquity or 
ubuntu-desktop-installer but it would be better if ubuntu-bug was able 
to find hooks provided by the snaps (either by having snapd exporting 
them to a system location or by teaching ubuntu-bug to look into 
/snap/<...>/current/.


Brian, any chance we could get that on the foundation backlog?

Cheers,
Sebastien


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Should we remove chromium-browser from the archive?

[Sebastien Bacher]

Le 08/02/2022 à 20:38, Thomas Ward a écrit :
We'd have to do some erasure of some packages (potentially 
transitional) and some other packages as well as a few shell 
extensions in order to make this removal work I think.


We should probably remove some of those packages or their chromium 
depends anyway since they rely on native messaging which isn't currently 
doesn't working with snaps browsers (it's being worked for firefox with 
portals but we will not likely get chromium working before the LTS at 
this point)


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: software-properties SRU stopped due to odd bug

[Sebastien Bacher]

Le 13/12/2021 à 18:26, Brian Murray a écrit :

This type of crash has come up before and it was always my thought that
it was an older pip-installed version of distro-info.


Would it be easy to include those installed packages as part of 
ubuntu-bug reports to help understanding such cases?


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports

[Sebastien Bacher]

Hey again,

Le 08/12/2021 à 00:14, Steve Langasek a écrit :

I expect that with this option set, we will find much fewer problems with
entanglement of library transitions, and in turn I hope developers will be
less frustrated by migration delays.
Right, I expect that to be the case. It's going to come at the cost of 
reducing the pressure for the team to complete the transitions since 
that's not going to get in the way of having their updates to land.
My personal feeling is that it's going to turn out to be an issue for 
the archive and the release teams and that we aren't going to find 
proper staffing to deal with the problems, but hopefully I'm wrong 
there, we will see.


Cheers,
Sebastien

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: proposed-migration, "SMOOTH_UPDATES", and NBS reports

[Sebastien Bacher]

Hey Steve,

Thanks for the email explaining the change, I've some questions

Le 07/12/2021 à 07:56, Steve Langasek a écrit :

The flipside is that this now means more packages will make it to the
release pocket while there are still reverse-dependencies of an old library
name; so when folks are working on proposed-migration, such as for +1
Maintenance, more attention will need to be paid to cleaning up these
stragglers.


 So you started by stating the change has been made to help on the 
openssl3 transition, it's a bit unclear to me if you mean it as a 
temporary thing or if you are suggesting that configuration to stay the 
default going forward?


 If the option is the proposed new default, what's the position of the 
release team on having NBS binaries around for the release? I guess that 
in principle we would want to clean that report, but in practice if we 
don't enforce that at proposed migration and lower the pressure to get 
those things resolved it's likely that we end building up debts we don't 
manage to pay.


Cheers,
Sebastien Bacher

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: SRU requirement to fix post-LTS stable releases

[Sebastien Bacher]

Le 23/06/2021 à 16:14, Robie Basak a écrit :
> Looking at the previous thread, I think that was Steve's own opinion
> rather than an SRU team decision.
Right, the point was to nuance your ' longer standing SRU team members
considered it to be a requirement' statement which made it sounds like
everyone in the SRU team was of the same opinion.
> fix. I don't think it's possible to justify reducing engineering effort
> on the basis of "well, other bugs we don't know about exist".

I was not trying to justify reducing engineering effort but mainly
pointing out that 'the user experience is harmed if a user installing
Focal subsequent to the bugfix landing in Focal, and therefore unaware
of any bug, then upgrades to Hirsute and is regressed' isn't a situation
in the hand of the SRU team alone and is a reality for users upgrading
to a new serie.

But focusing again on the point, we have limited manpower and we are
going to have cases where the maintainer isn't going to be wanting to
put the work to SRU to multiple series. Which means the question is 'Do
we believe it's better for the project and our users to have a bug fixed
in the LTS only or not fixed for anyone'?

I'm personally strongly in favor of not having a policy that could get
in the way of bringing higher quality and polish to LTS users (keeping
in mind that's where most of our users are and what our partners rely on
usually).

Cheers,
Sebastien



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report

[Sebastien Bacher]

Hey there,

Le 21/06/2021 à 18:29, Brian Murray a écrit :
> I had also looked at tiff / pylibtiff and used import-bug-from-debian,
> from ubuntu-dev-tools, to create http://launchpad.net/bugs/1932588 which
> I tagged 'update-excuse'. However, looking at the proposed migration
> report I don't see the bug listed. Is that because the bug doesn't have
> a task for the tiff package which isn't migrating?

Yes, the references are listed for the component the bug is report
against which in practice is often not useful. One workaround would be
to make the bug also list tiff so it would be picked by the report,
though that means keeping an invalid entry since there is actually no
problem in that source. We should perhaps standardize on an extra tag
'update-excuse-' and teach the report to parse those to cover
such cases?

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: SRU requirement to fix post-LTS stable releases

[Sebastien Bacher]

Hey Robie,

Le 16/06/2021 à 15:11, Robie Basak a écrit :
> Dear Ubuntu Developers,
>
> Imagine you land a bugfix in an SRU to Focal today, but leave out
> Hirsute even though it is also affected. A user who subsequently
> installs Focal, benefits from the bugfix, and then upgrades to Hirsute
> will be regressed. Is this acceptable?
>
> As a newer SRU team member, I never observed a requirement to also fix
> Hirsute in such a situation to be documented policy[1]. So I'd been
> taking it case by case.
>
Isn't that the same topic that was discussed back then on
https://lists.ubuntu.com/archives/ubuntu-release/2019-March/004729.html ?
> It turns out that other, longer standing SRU team members considered it
> to be a requirement all along, and therefore an omission in current SRU
> documentation that such a requirement isn't explicitly stated.

In that discussion Steve stated that SRUing to $currentstable should be
the default but not a requirement...

> Here's one consideration that might provide a compromise against the
> effort required. Today, the same situation would apply to Groovy, except
> that a user who is regressed still has the opportunity to upgrade to
> Hirsute to fix the regression if it is fixed there. So it might be
> considered sufficient to form a policy that says that a bugfix to an LTS
> must also land in only the most recent stable Ubuntu release, rather
> than in all later stable releases.
I think that would be a welcomed improvement to no require stable-1 to
get SRUed so thanks for the proposal! Speaking from a desktop
perspective it would allow us to focus on the series where most our
users are.

>
> There's also the observation that fixing Focal but not fixing Hirsute
> makes the situation better, not worse, by improving the experience at
> least for the Focal users. An argument can be made that some improvement
> is better than no improvement, and therefore such an incremental
> improvement that is volunteered should be accepted. Counterpoint: the
> user experience is harmed if a user installing Focal subsequent to the
> bugfix landing in Focal, and therefore unaware of any bug, then upgrades
> to Hirsute and is regressed.

I'm unsure the $currentstable should be a strong requirement rather than
a recommendation though for the reason discussed in the emails mentioned
before, you might end up pushing developers to delay their LTS fixes by
another cycle to avoid the extra workload which at the end doesn't
benefit anyone.

The 'user upgrades from a LTS to a new serie and hits a bug which didn't
exist in the LTS' is a problem we will have in any case. Software change
and you will have behavior changes and new problems coming from new
series, I don't think the lack of a SRU fix which was judged not
important enough by the developer to justify a SRU to a non LTS is what
is going to make the difference


Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: PHP 8.0 transition plan

[Sebastien Bacher]

Hey again there,

After checking the php-xmlrpc (build)depends is only useful for that
part of the tests, we can remove the requirement without having to
change the library API, which I'm going to do now

Cheers,

Le 21/05/2021 à 10:41, Sebastien Bacher a écrit :
> Hey Bryce, thanks for the reply!
>
> So it's a bit tricky. The new libsoup3 isn't out yet but even if it was,
> the new version includes quite some refactoring and API changes so I'm
> unsure if we will be able to transition the archive in a cycle or have 2
> and 3 arounds for a while, which means we need to figure out what to do
> with the current source.
>
> The commit you mentioned basically removes public functions so is an
> API/ABI incompatible change. Checking on codesearch.debian.net those
> functions have some users in the archive. Basically we would have to
> change the soname in a distro specific way if we were to do that
> properly but having a soname difference over upstream would make us
> incompatible with existing binaries...
>
> Would adding xmlrpc back on the php side temporarly until we get
> libsoup3 and the archive transitioned to it be an option? If not I'm
> unsure what's the best course of action...
>
> Cheers,
> Sebastien
>
> Le 21/05/2021 à 01:08, Bryce Harrington a écrit :
>> Looks like libsoup3 is beta (i.e. 2.99.5 released a couple weeks ago) so
>> would it be worth looking at merging that from upstream?  If not,
>> perhaps you could consider backporting the above commit to remove the
>> xmlrpc support?
>

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: PHP 8.0 transition plan

[Sebastien Bacher]

Hey Bryce, thanks for the reply!

So it's a bit tricky. The new libsoup3 isn't out yet but even if it was,
the new version includes quite some refactoring and API changes so I'm
unsure if we will be able to transition the archive in a cycle or have 2
and 3 arounds for a while, which means we need to figure out what to do
with the current source.

The commit you mentioned basically removes public functions so is an
API/ABI incompatible change. Checking on codesearch.debian.net those
functions have some users in the archive. Basically we would have to
change the soname in a distro specific way if we were to do that
properly but having a soname difference over upstream would make us
incompatible with existing binaries...

Would adding xmlrpc back on the php side temporarly until we get
libsoup3 and the archive transitioned to it be an option? If not I'm
unsure what's the best course of action...

Cheers,
Sebastien

Le 21/05/2021 à 01:08, Bryce Harrington a écrit :
> Looks like libsoup3 is beta (i.e. 2.99.5 released a couple weeks ago) so
> would it be worth looking at merging that from upstream?  If not,
> perhaps you could consider backporting the above commit to remove the
> xmlrpc support?


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: PHP 8.0 transition plan

[Sebastien Bacher]

Hey Bryce,

I noticed from the proposed-migrations team report that the libsoup2.4
tests were failing and that it needed updated depends. I tried to
rebuild it but it Build-Depends on php-xmlrpc which is still available
but depends on php8.0-xmlrpc which isn't existing

Checking salsa it seems the binary has been removed from php8.0, the
commit doesn't include any explanation of why though so I'm unsure if
that's a bug or wanted?
https://salsa.debian.org/php-team/php/-/commit/97dee5b

Any recommendatiob on what should I do for libsoup there?

Thanks,
Sebastien

Le 15/05/2021 à 05:54, Bryce Harrington a écrit :
> For items in that list that are FTBFS I've done some preliminary
> investigation and noted possible solutions.  Some of these will be
> pretty easy to fix.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

The missing focal ddebs have been restored

[Sebastien Bacher]

Hey there,

Status update on the focal ddebs situation.

We had a few people raising up that some of those went missing, which
was reported on launchpad
https://launchpad.net/bugs/1921940

After some investigation it does seem that indeed most of the
focal-updates ddebs vanished at some point in March. The ddebs-retriever
debug logs didn't contain enough information to figure out what happened
but there is an archive cleanup routine that basically remove any binary
that is older than 30 days and not listed by any of the indexes. A guess
is that error made focal-updates package index empty, either for real or
in the retriever cache, which did result in a cleaning of almost everything.

The ddeb-retriever is usually only importing files that got published
since its previous job. I did a special run importing everything
published since focal release which hopefully is enough to restore
everything that was missing. I checked that it at least fixed the cases
that were mentioned, gtk+3.0, gdm3, pam.

I've also added some extra debug logging and I'm going to try to make
the code more robust to errors.


Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Could someone help reviewing some code changes to the sponsoring queue?

[Sebastien Bacher]

Hey again,

Follow up, ignore that email, Brian already reviewed them but launchpad
didn't send me emails and I hadn't noticed :-/

Cheers,
Sebastien Bacher

Le 31/03/2021 à 15:22, Sebastien Bacher a écrit :
> Hey there,
>
> I'm unsure if anyone is actively maintaining that codebase or watching
> merge requests so I'm trying asking on the list in case someone from
> ~ubuntu-dev (which is the owning team) would like to help.
>
> I've submitted some small code changes which are waiting for review
> https://code.launchpad.net/%7Eubuntu-dev/ubuntu-sponsoring/+git/ubuntu-sponsoring/+ref/master/+activereviews
>
> Basically writting the json report in a subdir (where they can be easily
> enumerated without having to code a list of known names) and adding
> extra details to those. The change are going to be useful to improve the
> sponsoring queue KPI.
>
> Thanks in advance,
> Sebastien Bacher
>
>
>
>
>

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Could someone help reviewing some code changes to the sponsoring queue?

[Sebastien Bacher]

Hey there,

I'm unsure if anyone is actively maintaining that codebase or watching
merge requests so I'm trying asking on the list in case someone from
~ubuntu-dev (which is the owning team) would like to help.

I've submitted some small code changes which are waiting for review
https://code.launchpad.net/%7Eubuntu-dev/ubuntu-sponsoring/+git/ubuntu-sponsoring/+ref/master/+activereviews

Basically writting the json report in a subdir (where they can be easily
enumerated without having to code a list of known names) and adding
extra details to those. The change are going to be useful to improve the
sponsoring queue KPI.

Thanks in advance,
Sebastien Bacher





-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: turning on link time optimizations (LTO) for 21.04

[Sebastien Bacher]

Hey again Matthias,

Le 19/03/2021 à 16:19, Matthias Klose a écrit :
> This is now turned on by default, a bit later than expected (discussed and
> approved by Lukasz).
That's nice to know but https://wiki.ubuntu.com/FreezeExceptionProcess
states that 'Requests for freeze exceptions should be filed as bugs in
launchpad against the relevant package'.

I think it's important that we stick to public communication and follow
the documented practice and I hope others agree with that?

Cheers,
Sebastien

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: turning on link time optimizations (LTO) for 21.04

[Sebastien Bacher]

Hey Matthias,

I see that has been uploaded today [1], isn't it a bit late in the cycle
for such changes? Wouldn't it require a least a ffe?

Cheers,
Sebastien

[1] https://launchpad.net/ubuntu/+source/dpkg/1.20.7.1ubuntu4

Le 29/01/2021 à 13:34, Matthias Klose a écrit :
> Link time optimization (LTO) is a way to run optimizations across multiple
> translation units, enabling more opportunities for optimizations at link time.
> The optimizations allow for faster code and smaller files.
>
> LTO will be turned on for the 64bit architectures (except riscv64) by default
> for 21.04, after glibc 2.33 made it to the release pocket (just for
> disentanglement).
>
> Some upstream projects already turn on LTO by default, or provide 
> configuration
> options to turn it on (like GCC, Python).  Other Linux distributions are 
> already
> released with LTO turned on by default.
>
> If you want to test a package build with LTO turned on, use
>
> DEB_BUILD_OPTIONS=optimize=+lto dpkg-buildpackage ...
>
> using dpkg 1.20.7.1ubuntu2, currently in hirsute-proposed.
>
> Please make sure to add the 'lto' tag to bug reports when reporting issues 
> about
> LTO.
>
> Details at https://wiki.ubuntu.com/ToolChain/LTO.
> Feedback and improvements for the wiki page are welcome.
>
> Matthias
>
>


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

I've completed a +1 rotation over the past days, here are my notes

= Retries for flaky tests and builds or with specific triggers =

* rebuilt gnome-software with fixed fwupd depends
* retried schleuder with the correct triggers which unblocked rake
* retried mercurial, worked and migrated
* retried slime tests with newer emacs and proposed updated hints,
unblocked emacs
* retried rust-serial-test builds with rust-serial-test-derive/0.5.1-1,
worked and migrated
* retried rust-cbindgen with ^, built and migrated
* retried
https://autopkgtest.ubuntu.com/packages/syncthing/hirsute/amd64 , didn't
work
* retried ruby-em-synchrony tests to get ruby-eventmachine migrating
* retried python-redis tests, still failing on armhf
* retried the wp2latex/s390x build, worked and migrated
* retried wget tests, worked and migrated


= Transitions =

* rebuild and fixed packages for the evolution-data-server
* rebuild and fixed packages for the poppler transitions
* rebuilds for the libzip soname transition


= Debugging and fixing =

* debugged freedombox tests failing and workarounded while being
discussed upstream
https://salsa.debian.org/freedombox-team/freedombox/-/issues/2014

* investigated a bit the octave-symbolic/sympy test issue without success

* remove mmseqs2/s390x which isn't built anymore in the newest upload on
upstream request

* built libzip without -Wl,-Bsymbolic-functions to workaround failing tests
commented upstream on https://github.com/nih-at/libzip/issues/20 with
the finding, they fixed it by making the test be skipped in this case
forwarded the debian/rules stripping of -Wl,-Bsymbolic-functions to Debian

* fixed multipath-tools autopkgtests by allowing stderr

* reviewed the status of some ayatana indicator being blocked, they
transitioned to lomiri-url-dispatcher which got removed because it needs
to be updated to the new mir version, no obvious solution so we probably
need to remove the newer versions of the indicators for now

* hinted gemma/armhf which was blocking migration on an old result while
the source was removed previous cycle

* debugged a bit ruby-gnome tests failing with the new webkitgtk and
reported to Debian


Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report

[Sebastien Bacher]

Thanks Olivier, indeed  I just got a bunch of email about packages that
migrated ;-)

Cheers,
Sebastien Bacher

Le 09/02/2021 à 21:30, Olivier Tilloy a écrit :
> On Fri, Feb 5, 2021 at 5:00 PM Olivier Tilloy
>  wrote:
>> Hello everyone,
>>
>> This week I focused my 2-day shift on ruby-rugged, which is the last
>> blocker preventing libgit2 from migrating.
>> I had no prior experience with ruby so I learnt a few things along the way.
>> I uploaded 
>> https://launchpad.net/ubuntu/+source/ruby-rugged/1.1.0+ds-3ubuntu2,
>> which fixed the ruby-rugged autopkgtests.
>> Next I looked at ruby-licensee whose autopkgtests were failing because
>> of a version dependency mismatch with ruby-rugged.
>> I synced 9.14.1-1 from Debian experimental then uploaded
>> https://launchpad.net/ubuntu/+source/ruby-licensee/9.14.1-1ubuntu1
>> (including two patches submitted to Debian −
>> https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/1
>> and https://salsa.debian.org/ruby-team/ruby-licensee/-/merge_requests/2).
>> I then had to retry the ruby-gollum-rugged-adapter tests with an
>> additional trigger on the version in hirsute-proposed
>> (0.4.4.3~gitlab.1-1).
>>
>> At the time of writing, ruby-rugged hasn't migrated yet because the
>> hirsute armhf queue for autopkgtests is huge and processing slowly,
>> but it's otherwise looking good.
>> Once it does migrate, libgit2 should be able to follow suit, and with
>> it a number of reverse dependencies (calligra, criterion, fritzing,
>> geany-plugins, gnome-builder, gnuastro, horizon-eda, julia,
>> kup-backup, libgit-raw-perl, libgit2-glib, python-pygit2, rust-bat,
>> rust-git-absorb).
> As a follow-up, I uploaded
> https://launchpad.net/ubuntu/+source/ruby-licensee/9.14.1-1ubuntu2 to
> address autopkgtest failures on armhf, and with that ruby-licensee
> migrated, followed by ruby-rugged and all its reverse dependencies
> listed above.
>
>
>> I started to assess the status of gitaly, which is new in hirsute, and
>> depends on ruby-rugged. This will require upstream commit
>> https://gitlab.com/gitlab-org/gitaly/-/commit/0d1a7a18f26136453e781b011b3c1b9ab5f011f7,
>> but Debian is lagging behind a few upstream versions and doesn't have
>> this yet.
>> To build gitaly 13.6.5 (currently in salsa), we'll need
>> ruby-gitlab-labkit 0.13.2-2 from Debian experimental, which in turn
>> requires ruby-jaeger-client 1.1.0-1 from experimental too. Even with
>> those installed in a hirsute chroot, gitaly 13.6.5 is FTBFS. This will
>> require additional work, but I ran out of time, and gitaly isn't
>> blocking anything else, so not a high priority I guess.
>>
>> Have a good week-end,
>>
>>  Olivier

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

During this shift

* spent quite some time debugging systemd autopkgtest failing with the
new network-manager. Turned out to be a systemd udev regression under
lxc (https://launchpad.net/bugs/1914062)
* did the rebuilds and fixes needed for the libunity gir transition
* investigated some recent desktop build failures in hirsute, it seems
glibc 2.33 broken gobject-introspection (ldd returns the file are not
dynamic executable where 2.32 works)
* retried some flaky tests
* removed proftpd-mod-dnsbl which is included now in proftpd (which
migrated now)
* rebuilt unity-lens-photos for the new libsignon-glib abi version

* worked on old universe pending merges:
- mountmedia
- anna
- fonts-vlgothic
- light-locker
- libpam-ccreds
- sylpheed
- fonts-ipaexfont
- fonts-ipafont
- xserver-xorg-input-synaptics
- lxcfs
- libotr
- sensors-applet
- cfingerd
- gnome-system-tools
- p10cfgd

* got those packages back in sync with Debian
- monkeysphere, no need to disable the tests anymore they got fixed in
Debian
- libzip, Ubuntu packaged a new version when it was unmaintainer in
Debian but it got updated there now
- rabbitvcs the python2 depends was removed in Debian
- img2pdf again since imagemagick is built using openjpeg now
- rust-uuid
- golang-go.uber-zap, the flaky test is disabled in Debian now
- knot-resolver the archs restriction is in Debian now
- libhdate, debian removed the python bindings which had no rdepends,
port to python3 isn't needed anymore
- service-wrapper-java the changes are in Debian now
- jtharness the Ubuntu change was a newer version which is in Debian now

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

Summary of my recent shift, it's shorter than usual since I had some
time off work, one day colliding with the rotation

* submitted a change to include the MIR titles in the component mismatch
reports (waiting for eview)
* retried webkitgtk builds on arm since it seemed more of a toolchain
issue, worked
* retried hplip builds on arm, worked, migrated
* retried firefox tests
* retried libaperture on armhf, blocking gstreamer
* retried libgdata on arm blocking libxml
* debugged autopilot build failure but Dimitri beat me to upload
* rebuild gnome-builder for the glade transition
* rebuilds for the current libgit transition
* spent quite reading tests and builds issue to find things to work on
or retry

Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

That's the summary of the +1 rotation I did this week

* Spent quite some time browsing through update_excuses.html to find
actionable items
* removed scamp and theli armhf builds following Debian, scamp migrated
* fixed one issue in the crystal build
* remove the boxfort armhf binary since Debian stopped building it on
this architecture, it migrated
* retried ocrmypdf with the ghostscript from proposed but it's still
failing, found the upstream bug for the issue but no fix available yet
* got mercurial migrating by retrying tests
* fixed the python-fakeredis tests Depends
* submitted a fix upstream for the umockdev autopkgtest failing with the
new grep version
* fixed the jq build and sent the patch to Debian
* removed xfce-notes-plugin, orage and xfce4-equake-plugin for the xfce
transition
* removed the giac binaries on the architecture Debian stopped building for
* removed deprecated gconf-editor
* fixed notify-osd-icons build
* fixed unity-asset-pool build
* fixed a typo in the debian-pan Depends
* reported sks autopktest failure to Debian
* retried the gimp build on ppc64el, worked and should migrate now
* tpm2-tss migration
  - rebuilt tpm2-abrmd, tpm2-pkcs11, tpm2-tools  fwupd and fwupd-signed
with the new soname
  - cleaned out NBS binaries from proposed
  - fixed buggy depends in tpm2-pkcs11
* retried ibus-pinyin build on arm64 which worked
* fixed the jack-mixer build with python3.9
* retried meson/arm64 but the tests are still failing
* retried libimobiledevice tests with a trigger on the samba from proposed
* retried some failures, sometimes with tweaked triggers, those worked
https://autopkgtest.ubuntu.com/packages/b/binutils/hirsute/i386
https://autopkgtest.ubuntu.com/packages/f/firefox/hirsute/amd64
https://autopkgtest.ubuntu.com/packages/a/auto-apt-proxy/hirsute/amd64
https://autopkgtest.ubuntu.com/packages/liba/libaperture-0/hirsute/armhf
https://autopkgtest.ubuntu.com/packages/g/gimp-texturize/hirsute/armhf
https://autopkgtest.ubuntu.com/packages/m/mpd/hirsute/armhf
https://autopkgtest.ubuntu.com/packages/o/openjdk-8/hirsute/armhf
https://autopkgtest.ubuntu.com/packages/t/tpm2-abrmd/hirsute/amd64
https://autopkgtest.ubuntu.com/packages/s/sabnzbdplus/hirsute/arm64,
python-sabyenc migrated
https://autopkgtest.ubuntu.com/packages/n/nbsphinx/hirsute/armhf,
nbconvert migrated
https://autopkgtest.ubuntu.com/packages/f/fiat/hirsute/armhf, sympy migrated
https://autopkgtest.ubuntu.com/packages/check-manifest/hirsute/arm64
https://autopkgtest.ubuntu.com/packages/s/software-properties/hirsute/arm64
https://autopkgtest.ubuntu.com/packages/s/software-properties/hirsute/arm64
https://autopkgtest.ubuntu.com/packages/software-properties/hirsute/ppc64el
* retried alsa-lib tests, it migrated
* retried a stack of r-bioc-* tests with extra triggers which clear some
failures but several are still failing which seems likely because they
try to access internet resources

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report

[Sebastien Bacher]

Hey there,

Le 11/11/2020 à 18:39, Matthias Klose a écrit :
> - I don't think this should have been done as part of +1,
>   because the golang-defaults package is owned by a team.

Is that really worth calling out on like that? Proposed currently needs
work and I think people on +1 rotation helping to get things moving at
the start of the cycle, even if they are owned by a team, is welcome...

Thanks Didier for helping with the go stack migration, it's nice to have
someone who knows his way around the language to help there!

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Hirsute opening status?

[Sebastien Bacher]

Hey again there,

Small status update, seems like upload are being accepted now.
(hopefully that's right, I'm guessing in the absence of an official
release team follow up)

Cheers,
Sebastien Bacher

Le 26/10/2020 à 23:19, Sebastien Bacher a écrit :
> Currently the Hirsute serie seems ready but yet uploads aren't accepted,
> is there particular things that need to be sorted out? How long do we
> expect that to take and is help needed?

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Hirsute opening status?

[Sebastien Bacher]

Hey Christian,

Thanks for the reply. Indeed checking the status is easy enough (also
uploads return a 'waiting for approval' email instead of accepted). Is
it fine to upload in the queue though or should we hold on if possible
until the freeze is lifted?

The fact it's frozen doesn't tell us when we expect our work to be
unblocked or how we can help to get there though.

Laney kindly pointed out that
https://people.canonical.com/~ubuntu-archive/transitions/html/python3.9-add.html
was something currently being worked on, it's unclear to me if we want
that transition to be finished before accepting other uploads (how long
is that likely to take, days? weeks?). I'm also not sure if that's the
only thing blocking.

I'm Cc-ing ubuntu-release@ now, maybe they can help answering some of
those questions.

Cheers,
Sebastien Bacher

Le 27/10/2020 à 07:18, Christian Ehrhardt a écrit :
> I'm in no way denying the usefulness of such a mail, but as a hint for
> self-checking the state
> I can recommend to look at the release pages like [1] and avoid
> uploading before the status
> "Pre-release Freeze" is gone there.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Hirsute opening status?

[Sebastien Bacher]

Hey there,

Before the focal cycle we had an archive opening summary email [1], I
personally found it useful to have an idea what are the next steps,
could we try to make that maybe a regular thing and part of the new
cycle opening?

Currently the Hirsute serie seems ready but yet uploads aren't accepted,
is there particular things that need to be sorted out? How long do we
expect that to take and is help needed?

Thanks,
Sebastien Bacher

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2019-October/040817.html


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Second Groovy Gorilla test rebuild

[Sebastien Bacher]

Hey Matthias,

Le 28/09/2020 à 18:07, Matthias Klose a écrit :
> Some build failures on ppc64el and s390x are caused by a buildd issue, and 
> will
> be retried soonish. Please ignore these where you see a ftbfs just on those
> architectures, but successes on the other architectures.

There seems to be some flakyness on arm as well, are those going to be
retried or should that be requested by e.g pinging you?

Some examples

https://launchpadlibrarian.net/499016257/buildlog_ubuntu-groovy-armhf.colord-gtk_0.2.0-0ubuntu1_BUILDING.txt.gz
https://launchpadlibrarian.net/499209776/buildlog_ubuntu-groovy-arm64.gpm_1.20.7-6_BUILDING.txt.gz
https://launchpadlibrarian.net/499174464/buildlog_ubuntu-groovy-arm64.remmina_1.4.8+dfsg-1ubuntu1_BUILDING.txt.gz

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

That's the summary of my +1 maintainance this week

* Got those packages to migrate, mostly by retrying flacky tests or with
right triggers
- htslib
- golang-github-emersion-go-imap
- fpyll
- libfilezilla
- python-hypothesis
- sharutils
* Cherry picked an automake-1.16 upstream tests fix for gcc10
* merged sbuild 0.80 but tests are still failing
* merged pandoc from Debian to unblock some depwaiting packages
* rebuild some pandoc rdepends with the new abi
* merged doxygen to try to fix the ghostscript migration
* retried libfilezilla on amd64 build which worked
* removed renpy (following Debian testing) to unblock pygame-sdl2
* rebuilt ledit,ulex0.8,hol-light to complete the camlp5 transition
* boost71 transition
- retried ros-rosconsole with the right triggers, it's a candidate now
- retried ros-ros-comm with the right triggers
- fixed ledger/riscv/build by Build-Depending on tzdata which is
installed by default on Debian and Ubuntu builders but not on the riscv
ones it seems
* reported a hinawa-utils bug to Debian to update the depends for the
new libhinawa
* removed libipe7.2.15 NBS packages from poposed to unblock ipe
* removed s390x NBS binary from yanosim which let it migrate

Others small items not listed because they are still waiting on the
armhf backlog to clear up a bit

Cheers,
Sebastien Bacher






-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

That's the summary of my +1 maintainance this week

* Got those packages to migrate, mostly by retrying flacky tests or with
right triggers
 - libevent
 - phpunit
 - ncompress
 - python-cryptography-vectors
 - rsync
 - freetype
 - djvulibre
* removed falcon, was removed from Debian, fail to build and is unmaintained
* removed NBS binaries from nvidia-graphics-drivers packages to unblock
migration
* some NEW reviews
* spent quite some time on update_excuses.html poking at random items,
started poking a bit at some issues and gave up on most either because
the project was unmaintained and not worth the effort or because work
was already ongoing upstream or in Debian


Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

That's the summary of my +1 maintainance this week

* some NEW reviews
* fixed the formiko tests
* removed python3-stdlib-extensions from proposed which had a buggy
python depends and was breaking builds
* removed old bsdmainutils binaries
* merged util-linux which glib was depwaiting on
* fixed some merge and build issues with the previous update
* retried a stack of i386 tests with the right triggers for the
util-linux update
* reviewed test failures to add other triggers needed to try unblock
systemd, bsdmainutils, util-linux


Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

That's the summary of my +0 maintainance this week (somehow reduced one
again since I was working part time still)

* tested the by-team-report with the britney rebase and submitted a fix
for the script failing on some file formatting changes
 
https://code.launchpad.net/~seb128/ubuntu-archive-scripts/verdict-not-package/+merge/386000
* poked a bit at bug references being buggy with the new version,
waiting to see if that's fixed on the britney side now
* reported some other small nitpicks in the new reports
* bolt failed to build without log on riscv, retried, worked and migrated
* retried tests to unblock libgphoto, migrated now
* retried openssh/gvfs tests, worked
* retried balsa/sqlite3/armf64, worked
* retried cwltool/armhf which was blocking procps
* retried auto-apt-proxy/armhf which was blocking apt
* retried dgit/arm64, allowed git to migrate now
* started working on the fonts-font-awesome failures, not finished yet
* did some sponsoring and retries for Olivier

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: An updated version of proposed-migration is available to review

[Sebastien Bacher]

Hey Iain, thanks for the work!

Le 16/06/2020 à 19:07, Iain Lane a écrit :
> If you can see anything that's *wrong* in the output linked above, 
> please let me know. If you run any scripts which parse the yaml, please 
> try them against
>
>   
> https://people.canonical.com/~ubuntu-archive/laney/proposed-migration/update_excuses.yaml
>
> and ideally adapt them as necessary.

(That's a .xz compressed version which is a bit confusing)

The by-team-report is unhappy with the new file, it doesn't like the
policy_info/autopkgtest section having no package listed, e.g from gcc-9

  policy_info:
    autopkgtest:
  verdict: REJECTED_TEMPORARILY

Skipping those cases as a test workaround gives a report where bug
references are buggy (listed as #0).

I plan to work on those issues tomorrow


Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

+1 maintenance report

[Sebastien Bacher]

Hey there,

Somewhat a reduced shift since I had some days off last week, I did
continue a bit yesterday and today to make up for part of it but it's
still a somewhat short list

* spent some time talking with Olivier as part of his onboarding

* unblocked pygame by removing childsplay and pysycache

* NEWed libnma and filed a MIR (it superseed part of n-m-applet)

* retried some flacky tests

* retried fdroidserver tests with a fixed python-git to unblock git

* sponsored dejavu transition fixes from Olivier
- zatacka
- sarg
- blobwars
- blobandconquer
- astromenace

* did another fix for the dejavu transition


Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Defaulting to verify the image integrity before installing on desktop?

[Sebastien Bacher]

(cross posting
https://discourse.ubuntu.com/t/defaulting-to-verify-the-image-integrity-before-installing-on-desktop/13472)

Triaging ubiquity bug reports on launchpad, one of the most common
reason for failing installations is that the image/media used to do the
installation is invalid/corrupted. It shows in the log with such error
’SQUASHFS error: zlib decompression failed, data probably corrupt’

There is usually no user friendly explanation of what the problem is in
those cases, which means users just download the iso/write it/boot the
media and follow the steps and at some point get a random ubiquity error.
One recent example of such report
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1853769
Since we don’t explain the issue nor recommend a solution it’s often not
obvious to user what is going on and what they should be doing.

In that context, what would people think of making the default choice on
the desktop liveCD to be ‘check & install’ and make the start of the
installer conditional to not having error on the media?

I’ve tried to get some data for the discussion and tested the ‘check
disk’ option on some configurations with an old/slow usb stick and a
recent enough cheap usb3 one

  * a 10 years old latitude with an i5 cpu (bios)
  * an old/slow inspiron11 (uefi)
  * a recent XPS13 (uefi)

The check takes between 1 minute and a bit less than 3 minutes,
depending of the configuration/media. (I didn’t measure the installation
time then but it’s significantly longer on any of the machines)

And as an extra data point, I recently booted a fedora 31 ISO to test a
bug and the liveCD menu default to check the media first there.

I think that the cost is reasonable and that it would avoid an awkward
experience that some of the new Ubuntu users are getting.

What do others think? Should we default to check the media before
booting the ISO? (And if so do we need to ensure the menu still provide
a way to skip the testing (we should at least for automaticall
installation)?)

Cheers,

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Details of what is happening with python3.8 in Ubuntu?

[Sebastien Bacher]

Hey Michael, thanks for the reply.

Le 23/10/2019 à 01:01, Michael Hudson-Doyle a écrit :
>
>
> - Could someone explain why those .install tricks are needed exactly?
>
>
> It's because the "abi tag" for python c extensions has changed in a
> way that makes it a bit annoying / impossible to write a glob that
> matches 3.7 and 3.8 release build extensions and not the debug extensions.
>  
>
> Couldn't the issue be solved in the python packaging tools instead?
>
>
> Yes, probably.

Ok, thanks, that's useful information about the naming/matching. If it
could probably be fixed in the tooling shouldn't we have looked at that
first rather than dumping a stack of delta in the archive which is going
to bite us back later by having to deal with manually reviewing/merging
those packages later?

>
> I've made a bug report for cracklib2 now.*

Thanks!

>
> - Is that a transition we are under pressure to get through? 
>
>
> Well we want it to complete before opening the archive and I assume
> people want the archive to open...
Ok, I didn't know that it needed to be complete before archive opening
since we have proposed and I though it could be handle as a normal
transition and blocked in there still after opening.

>  
>
> Should we
> maybe take the time to document what's going on
>
>
> Well there was this
> mail: https://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/msg09144.html
>  
> And there is a transition
> tracker: 
> https://people.canonical.com/~ubuntu-archive/transitions/html/python3.8-add.html
>  (not
> sure this has been advertised but it's not hard to find).

Right, the first one is the one I referred to. I was more looking to an
email that explained e.g the technical of e.g the abi/naming change and
the problem it creates on .install matching and the recommended
solution. I think it's important to share knowledge in such cases so
other developers understand what is being done and why and then can be
helping.

>
> Maybe roping in more people would help, maybe not. The plan was for
> Matthias and I to work on this more or less full time and just crank
> through it.
>
Well, cranking through it is only one side of the story. Then we need to
maintain those changes. Do you plan to keep on maintaining those
packages you touched, doing Debian merges when needed, etc? If not and
the expectation is that the team 'owning' the packages deal with the
maintainance then the changes need to be understood by the people who
are going to maintain them...


Cheers,
Sebastien Bacher

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Details of what is happening with python3.8 in Ubuntu?

[Sebastien Bacher]

Hey there,

Matthias announced that F would have python3.8 and from the recent
upload, it looks like that's being worked on actively at the moment.

While looking at the update_excuses_by_team.html#desktop-packages report
I noticed some delta-over-debian being added to packages where I
can't really make sense of what's going on in the changelog.

Some examples
http://launchpadlibrarian.net/447713946/pygobject_3.34.0-1build1_3.34.0-1ubuntu1.diff.gz
http://launchpadlibrarian.net/447727952/pycairo_1.16.2-1ubuntu1_1.16.2-1ubuntu3.diff.gz
http://launchpadlibrarian.net/447772089/cracklib2_2.9.6-2build1_2.9.6-2ubuntu1.diff.gz

Some changes for example add a Build-Depends on dh-exec and hacks in the
.install, I guess those doing the changes understand why but it triggers
some questions to me

- Could someone explain why those .install tricks are needed exactly?
Couldn't the issue be solved in the python packaging tools instead?

- Can/should those changes be forwarded to Debian? (they are not at the
moment?) I would be happy to help with that once I understand the
technical approach being taken.

- Is that a transition we are under pressure to get through? Should we
maybe take the time to document what's going on and have more people
helping and do things in a way were we collectively understand what is
happening so we know what to do from those deltas in the futur/ help
forwarding to Debian for example?

Thanks,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Developer Office Hours Report for 07/02/19

[Sebastien Bacher]

Thanks Simon for the work and the summary,

Le 02/07/2019 à 18:42, Simon Quigley a écrit :
>  - Asked for clarification on https://pad.lv/1834211
I already mentioned that previously on the list but that bug has a SRU
template and a proper debdiff attached, you asked a question about
another bugs batched in the same SRU proposal but unsubscribing sponsors
seems a bit of a strong action.

I think it's fair to say that once those items are out of the sponsoring
queue there is a lot less chance that some sponsors will look at it
again which means we are discarding useful contributions on the basis of
trivial questions...

Could we try to figure out a process to deal with those cases better?
What about setting as "incomplete" there and having the report put those
in another section (if the concern is to have them out of the main
list). Or maybe some tag that allows to easily list such items back later


Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: eoan/armhf builds failing due to new binutils

[Sebastien Bacher]

And that's fixed now, thanks doko!

Le 02/07/2019 à 12:41, Sebastien Bacher a écrit :
> Hey there,
>
> Just as a FYI to avoid having people spending time figuring out that the
> problem is not on their side, currently eoan/armhf builds are failing
> with a ld error, that's not a problem in your package but due to the new
> binutils in eoan-proposed
>
> Cheers,
> Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

eoan/armhf builds failing due to new binutils

[Sebastien Bacher]

Hey there,

Just as a FYI to avoid having people spending time figuring out that the
problem is not on their side, currently eoan/armhf builds are failing
with a ld error, that's not a problem in your package but due to the new
binutils in eoan-proposed

Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: mlocate - what is it good for?

[Sebastien Bacher]

Hey Steve,

Le 24/05/2019 à 00:33, Steve Langasek a écrit :
>> Takes over 30 seconds (on a machine which not doing any other work)
>> where mlocate takes around 1 second on the same machine... and I do
>> personally find 30 seconds to be too long.
> I agree that 30 seconds is too long, but as a user of find I find this usage
> surprising, why would you be searching the whole root disk for the file?

I just used the same example than Julian gave so we would compare the
same things (but picked a file that I know existed on my disk), I agree
that the command/example doesn't make much sense.

> Anyway, agreed that 30s is too long.  Would you be annoyed if the solution
> to that 30s being too long was "get tired of waiting, run 'locate', get told
> it's not installed, apt install mlocate, run 'locate' again"?

No, I think it would be fine. Locate isn't going to be useful on "throw
away" installations/VMs since on a fresh install the index is not going
to be there, and if you have an installed machine you use then
installing the machine is a one action easy action.

> indexers on your desktop system - both tracker and mlocate.  It looks like
> nautilus currently depends on tracker, so I'm not sure how one would
> uninstall it and usefully fall back to the mlocate backend anyway, but at
> most I'd say this should be expressed as 'Depends: tracker | mlocate' in
> nautilus, and not have mlocate kept around on the system updating its
> database daily just in case a user removes tracker.

Right, GNOME sort of forced our hands there since several features in
nautilus now rely on tracker so yes I agree with you, our default
Desktop indexer is tracker and it's probably good enough for most users.
Those who need mlocate can go an install it from the archive, we
probably don't need it pre-installed on the desktop image.


Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: mlocate - what is it good for?

[Sebastien Bacher]

Le 22/05/2019 à 21:47, Julian Andres Klode a écrit :
> containing about 1435134 files. mlocate foo takes 1s, find / -mount
> -name '*foo*' takes about 7-9 secs, or 19 seconds with all mount points 
> (but there is a davfs mount of an internet server, so things might be

Well here on a few years old 80GB intel ssd doing

$ time find / -mount -name disco-desktop-amd64.iso

Takes over 30 seconds (on a machine which not doing any other work)
where mlocate takes around 1 second on the same machine... and I do
personally find 30 seconds to be too long.

Note that nautilus has a mlocate search provider which we have been
using by default until bionic, to avoid depending on tracker. Now we use
tracker so it's less important but some users do uninstall tracker
because they don't like having an indexer (and it still does have some
bugs) so it's nice to have the UI still responsive for those users.

Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: State of the Sponsorship Queue - Can we get it to 0?

[Sebastien Bacher]

Hey Robie,

Le 23/04/2019 à 11:54, Robie Basak a écrit :
> and I think it's unfair on
> Simon to criticize him for not going the extra mile given that he's
> seemingly one of the few who are going any miles at all right now.

That was not my intend to criticize him, it's fine for Simon or anyone
to decide to 'skip over' those and/or ask for the contributor to add the
SRU info, sorry if I gave the impression I was being negative on that

What I was trying to say is that I would prefer for those items to stay
on the report (or have another subpage if that makes more sense?) so we
don't 'lose' them completely. If they are removed from the page and the
submitter doesn't come back then there is a good chance that no-one is
ever going to go and fish the contribution back. I'm still interested to
have those listed somewhere because I personally do find of those items
worth sponsoring and I'm wanting to do the work needed in some cases
(but I can't if they vanish from the queue)

Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: State of the Sponsorship Queue - Can we get it to 0?

[Sebastien Bacher]

Hey Simon,

Le 21/04/2019 à 00:12, Simon Quigley a écrit :
> Today I spent a few hours sifting through the sponsorship queue. I
> sponsored everything I could review and was comfortable sponsoring, and
> asked for changes on many bug reports. The queue started out at about 70
> (I didn't catch the exact number) and is now down to 13.

Good work, it's nice to see some sponsoring activity :-)

> One of the most common changes I requested was that people edit bug
> descriptions to follow the SRU template for bugs which have sponsorship
> requests open for stable releases. Perhaps a message recommending that
> could be added to Brian's automatic reply bot.

I'm not sure I agree with that being enough of a reason to get them out
of the sponsoring queue though. Did you unsubscribe sponsors? Or marked
them incomplete? It would be nice to keep those on the list in some way
because they can still be useful.

Depending of the fix I sometime do edit the description myself the
upload rather than bouncing back to the contributor.

While it's nicer when the bug is ready/needs to work, I don't think
enforcing roundtrips over 'paperwork' always benefits the project. When
a fix makes sense and addresses a real issue which is easy to verify it
can be less effort for everyone to have the sponsor go the extra mile.

(in some cases it's not obvious how the bugs can be triggered/tested,
then it makes sense to ask for the details and set as incomplete though).

Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Cosmic test rebuild

[Sebastien Bacher]

Le 08/04/2019 à 22:50, Steve Langasek a écrit :
> rls-cc-incoming bugs?  I know Foundations does not actively process this
> queue for stable releases and I would not expect other teams to do so
> either.

Desktop does review the incoming lists for bionic/cosmic/disco weekly in
the team meeting. 

How important do you consider Cosmic packages failing to build at this
point though? Those are not problems directly impacting users and Cosmic
is about to be replaced as current stable...

(also some of the bugs mention the build failing on 'an updated
toolchain', what is the toolchain update those are referring to?)

Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Disco - debug symbols not working since binutils 2.32 (fixed)

[Sebastien Bacher]

Hey there,

Just as a follow up, the gdb update which is in disco-proposed since
today fixes the problem (without having to rebuild the packages which
had the issue)

Cheers,
Sebastien Bacher

Le 13/02/2019 à 23:41, Sebastien Bacher a écrit :
> Hey there,
>
> I'm sending that email as a FYI after having spent some time today
> figuring out why a recent gnome-control-center/glib segfault in disco
> was consistently giving failing-retrace-reports, it looks like gdb in
> disco is now failing to load the debug symbols from packages which have
> been built with the new binutils.
>
> The output looks like that
>
> 'BFD:
> /usr/lib/debug/.build-id/2a/4367ded6c5ba5f464c762f1576874694053c71.debug:
> unable to initialize decompress status for section .debug_aranges
>
> warning: File
> "/usr/lib/debug/.build-id/2a/4367ded6c5ba5f464c762f1576874694053c71.debug"
> has no build-id, file skipped'
>
> I opened a bug about it
> https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1815774
>
> Cheers,
> Sebastien Bacher
>
>
>


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Disco - debug symbols not working since binutils 2.32

[Sebastien Bacher]

Hey there,

I'm sending that email as a FYI after having spent some time today
figuring out why a recent gnome-control-center/glib segfault in disco
was consistently giving failing-retrace-reports, it looks like gdb in
disco is now failing to load the debug symbols from packages which have
been built with the new binutils.

The output looks like that

'BFD:
/usr/lib/debug/.build-id/2a/4367ded6c5ba5f464c762f1576874694053c71.debug:
unable to initialize decompress status for section .debug_aranges

warning: File
"/usr/lib/debug/.build-id/2a/4367ded6c5ba5f464c762f1576874694053c71.debug"
has no build-id, file skipped'

I opened a bug about it
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1815774

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Changing the rp_filter default in Ubuntu from strict to loose?

[Sebastien Bacher]

Le 07/02/2019 à 17:47, Marc Deslauriers a écrit :
> Loose is reasonable. +1 from me.

Thanks, Mark, I've uploaded that to disco now!
https://launchpad.net/ubuntu/+source/procps/2:3.3.15-2ubuntu2

Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Changing the rp_filter default in Ubuntu from strict to loose?

[Sebastien Bacher]

Hey there,

The new network-manager in disco does connectivity checking
per-device/connection type which doesn't play nicely with th rp_filter=1
default that procps sets in Ubuntu

The details of the discussions in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/116
but a summary is

'it uses libcurl and binds the HTTP request to the device, using the
SO_BINDTODEVICE socket option. rc_filter=1 rejects all incoming packets,
if the sender wouldn't also be reached via that device. It thus
counteracts SO_BINDTODEVICE.'

Basically those are conflicting so we need to either disable the
connectivity checker or change the rp_filter default. It looks like
systemd upstream and fedora already decided to change to default to
rp_filter=2 (loose)
https://github.com/systemd/systemd/commit/230450d4

Can we do the same in Ubuntu?


Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: 18.04.2 is coming

[Sebastien Bacher]

Hey Steve, thanks for the reply!

Le 31/01/2019 à 00:32, Steve Langasek a écrit :

> Thanks, it's not part of our documented point release process to have
> outbound communication about this perhaps due to the assumption that people
> would reference the release schedule on their own, but it doesn't hurt to
> give people a head's-up (and better late than never).

Where would be the right place to suggest that we add to the process a
reminder email about the incoming freeze for LTS point releases?
Something around the line of "if you want are working on some update
that really needs to be in and hasn't landed yet now is time to talk to
us about it/have the SRU going or you are going to miss the target".
I think it's not too much work and would be useful since it seems every
cycle we have some busy people who don't especially keep an eye on the
calendar and end up missing their landing target (do we have an
ics/something better than the wiki?)

> https://wiki.ubuntu.com/PointReleaseProcess describes that SRUs should be in
> -updates one week before the point release date.

Thanks, I should have clicked on that link from the schedule page :)

Btw that page mentions that base-files should have been updated some
weeks ago, seems that didn't happen (for whoever is handling that
milestone, hopefully they read u-d@)

> The list of bugs targeted to the 18.04.2 milestone is:
>
>   https://bugs.launchpad.net/ubuntu/bionic/?field.milestone%3Alist=86800
>
> It's always possible for developers to target bugs to the point release
> milestones if they believe they are critical.

Right, my main interrogation there is on what happens if those listed
bugs are not fixed? Currently 3 of those on the list seem to be in that
case.
The gnome-shell one has been uploaded and is waiting for review in
unapproved (though the update is non trivial and it feels late, maybe
best to release it after the .2 image is built as a 0-day SRU), the
ubiquity ones seem not have a fix in the queue yet?
Do we delay the point release to get those fix in? Is anyone reaching
out to stakeholder to figure out what we do? Or do we just get the point
release out on schedule without those?

> It appears the fwupdate packages are released from binary NEW now.

Great, thanks!

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: 18.04.2 is coming

[Sebastien Bacher]

Hey Lukasz!

Thanks, I looked at launchpad before emailing but I was on the -base
page for the packages and it looks like we did update those for .1 but
are not going to do that for .2 but rather go with normal delta update
there, which I guess makes sense

Cheers,
Sebastien Bacher


Le 30/01/2019 à 16:31, Lukasz Zemczak a écrit :
> Hey Seb!
>
> Since I am not driving the release, for now let me answer the question
> of the language pack updates. Those went into -proposed last week so
> are in progress and the testing deadline passed basically an hour ago
> (there were two call-for-testing e-mails on the translation ML). You
> can see all details regarding that here:
> https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
>
> Sadly, as with previous point releases, there was not too many
> languages tested, but better those few than none. I will be releasing
> the verified ones a bit later today.
>
> Cheers,



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

18.04.2 is coming

[Sebastien Bacher]

Hey there,

I feel like there isn't much communication around incoming Ubuntu LTS
point releases nowadays which makes it easy to miss the target. I don't
know if it's only me but hopefully others also find this email useful.

So first, for those who don't pay attention to the bionic schedule,
Ubuntu 18.04.2 is due on february 7th, now is probably time to
land/verify the fixes you care about!

Then some questions

* are we still on track for that date?

* when do we need to get the SRUs in proposed and moved to -updates to
be on the image? (having a freeze date on the schedule would be useful)

* do we have a list of "things that need to be in" somewhere? Looking at
the current queues (packages in unapproved or waiting verification in
proposed) and talking to some people we have teams who real care to get
at least those in

- snapd 2.37.1 (just landed in proposed,
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1811233)
- hwe/xorg update
(https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1798597)
- fwupdate (blocked in bionic/binNEW for some time,
https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1785165)

(do we plan a language pack update?)

Thanks for reading, hopefully we are not too late on the schedule to get
the important SRUs listed before still in

Cheers,
Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Upcoming transitions

[Sebastien Bacher]

Hey Steve,

Le 05/12/2018 à 11:14, Steve Langasek a écrit :

Before starting a new transition, they should look at the overlap between
reverse-dependencies of mysql, php that will need rebuilt for the
transition, and packages that are currently in -proposed waiting to migrate
as part of the poppler transition.

We wouldn't want new no-change rebuild uploads of packages that depend on
poppler causing the two transitions to be entangled, preventing poppler from
migrating to the release until mysql,php are also ready to migrate.


Right, that makes sense. I'm unsure there is much to "coordinate between 
teams" though, it's more up to whoever wants to start a new transition 
to check the state of things and if their uploads are going to be 
disruptive to some ongoing transition.


Cheers,
Sebastien Bacher



--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Upcoming transitions

[Sebastien Bacher]

Hey Matthias,

Le 05/12/2018 à 08:03, Matthias Klose a écrit :

please coordinate with the desktop team and the poppler transition which is
still in progress, started 12 days ago.


What sort of coordination are you looking after? Or did you mean "please 
wait for the poppler transition to be finished"?
It's currently down to xpdf and libreoffice which are actively working 
on/hopefully going to be sorted out today.


Cheers,
Sebastien Bacher


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Proper way to handle britney hints

[Sebastien Bacher]

Le 07/08/2018 à 00:00, Steve Langasek a écrit :
> It seems your MP has the review requested from a team that is not the owner
> of the target branch, do you know why that is? (~ubuntu-archive vs.
> ~ubuntu-release)

Just as a data point, I just did a mp for britney hints changes and the
reviewer has been set to ~ubuntu-release (I had initially let the
default target branch which was lp:britney and that mp defaulted to
~ubuntu-archive as reviewer though, which seems correct)

Cheers,

Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Bugs reports should include syslog warnings or not?

[Sebastien Bacher]

Hey there,

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1738581 was raised
to my attention in a discussion about apport/e.u.c and I'm wondering if
the change is right

The report pointed out that private info have been included in a report
through JournalError.txt, and the solution applied was to change apport
to include errors level messages only and not warning.

Looking a bit a journalerror on some bugs it seems we have indeed some
components that log too much content as "warning" (gdm in that case),
but changing to "error" has been cutting out useful warnings and doesn't
seem the right fix to me nor a step in the right direction. It doesn't
also protect us of the described issue (if a program logs sensitive info
in its errors messages we are still going to send them).

I suggest that we change apport back to report warnings as well and look
at how we can better fix the privacy issue.

The xession logs are filtering on "safe" keywords, maybe one option
would be to do something similar for the journal

https://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/hookutils.py#L517

Another thing we could/should do is to review the logs and fix programs
that are logging too much details to the journal as the warning/error
levels.

What do you think?


Cheers,
Sebastien Bacher


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Should Ubuntu systemd journal logs be persistent by default?

[Sebastien Bacher]

Hey there,

Le 07/11/2017 à 21:11, Mark Stosberg a écrit :
> /should the systemd journal be persistent by default?/

Just as a follow up on that topic, Dimitri made the journal persistent
by default now in bionic

https://launchpad.net/ubuntu/+source/systemd/235-3ubuntu3


Cheers,

Sebastien Bacher

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Drop "Ubuntu Desktop USB" task?

[Sebastien Bacher]

Hey Jeremy,

Thanks for sending that email. As discussed on IRC "USB" made sense at
the time Ubuntu was fitting on a cdrom, afaik it hasn't been used for
years and should be fine to remove.

Cheers,
Sebastien Bacher



Le 30/11/17 à 17:56, Jeremy Bicha a écrit :
> Are there any concerns if we drop this task and seed now?



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Old Firefox versions discourage real-world testing of Ubuntu development versions

[Sebastien Bacher]

Hey there,

Le 04/09/2017 à 14:48, Robie Basak a écrit :
> I imagine it's the Ubuntu desktop team
> who generally would look after this package; they have a separate
> mailing list if you'd like to talk to them about their priorities.

The desktop team has been suggesting to remove firefox from those
architectures because we don't have the resources to work on those build
issues and we believe there are little benefit to have firefox available
on e.g ppc64el but that request has been rejected by the foundation team
who said they would help to resolve the build issue so we are still
waiting on that.

In summary, there is no point moving the topic to another list. If you
want to help either work on a fix for the build issue or try to convince
foundations than most of our firefox users are on i386/amd64 and that if
we don't have the resources to deal with build issues in timelined
fashion (which experience from the previous cycles suggest) then we are
better off having firefox uptodate on those architectures only than
staying outdated for most of the cycle for the benefit of architectures
who don't have actual desktop users.


Cheers,

Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: aptdaemon

[Sebastien Bacher]

Le 15/03/2017 à 23:24, Jeremy Bicha a écrit :
> sessioninstaller is broken in zesty now (LP: #1661371)
>
> As I commented on the bug, gnome-software can replace sessioninstaller
> (at least for the purpose of installing the codecs to play an mp3),
> but it doesn't work with gnome-software apt backend.

Hey there,

Just a follow up about sessioninstaller. I had a look at the issue and
it's still working, the problem is that the packagekit backend build has
been turned on mid-cycle in zesty (looks like an error, it was not
documented in the changelog at least) resulting in gnome-software
including a dbus .service/claiming the org.freedesktop.PackageKit name
on the session bus, which means sessioninstaller can't do that and is
bailing out.

We discussed that on IRC and Jeremy has uploaded a new gnome-software
revision to disable packagekit back, which should be enough to fix the
issue for zesty.

It would still be good to fix gnome-software codec installation when
using our apt backend so we can deprecate sessioninstaller though, I'm
going to have a look to that next.

Cheers,

Sebastien Bacher



-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

16.04.1 schedule details?

[Sebastien Bacher]

Hey there,

The xenial schedule has 16.04.1 marked down for next week but do we have
a more detailed version (showing when we expect uploads to be frozen,
things to be migrated to updates, iso testing to start, etc)?

The desktop team has some packages in the unapproved queue that we would
like to see in .1 if possible (unity stack, usd, ...), is that still
realistic to get those accepted/verified/migrated/on the iso?

Cheers,
Sebastien Bacher




-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

2016-06-17 patch pilot report

[Sebastien Bacher]

Hey there,

I did a round of sponsoring today, not a full shift but I cleaned out
some items and sponsored some others, summary

https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1590508
in the xenial queue, unsubscribing sponsors

https://bugs.launchpad.net/ubuntu/xenial/+source/dh-make/+bug/1592134
sponsored xenial SRU

https://bugs.launchpad.net/ubuntu/+source/systemtap/+bug/1591008
synced

https://bugs.launchpad.net/ubuntu/+source/webkitgtk/+bug/1571071
was already uploaded, unsubscribed sponsors

https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1548425
the patch concernes a newer gtk than the one in the archive,
unsubscribing sponsors

https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1584485
unsubscribed normal sponsors security-sponsors is enough

https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1585928
sponsored

https://code.launchpad.net/~lathiat/unity-control-center/lp1304388/+merge/297137
reviewed

Cheers,
Sebastien Bacher

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: SRU never reviewed, why/how do we avoid that next time?

[Sebastien Bacher]

Le 19/05/2016 14:54, Martin Pitt a écrit :
> I'd say that cases like this at least require prodding some SRU team
> member with some good reason -- I wouldn't expect these uploads to get
> accepted as part of the regular workflow.

Thanks for the feedback Martin!

I think what you wrote makes sense and indeed there is no reason to not
land the update in yakkety (Bjoern said he would get it ready in the
next days, just need to set up his env for the new serie).

We had the case of build issue/new serie being prepared in wily though,
which might have contributed to that upload not being review

Cheers,
Sebastien

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel