Re: Question about submitting patches for repositories on Launchpad

[Dan Bungert]

On Thu, Mar 30, 2023 at 05:34:10PM +, Alexander Koskovich wrote:
> I submitted my patch to the 'master' branch since that looked to be active
> development, ubuntu/devel seemed abandoned.
> https://code.launchpad.net/~nexusprism/curtin/+git/curtin/+merge/439880

Hi Alexander,

Thanks for the merge proposal.  I have responded with some feedback, so we can
continue the discussion there.

-Dan

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

Re: Question about submitting patches for repositories on Launchpad

[Steve Langasek]

On Thu, Mar 30, 2023 at 05:34:10PM +, Alexander Koskovich wrote:
> Steve Langasek wrote:

> > Which branches are you looking to submit to? There are lots of branches
> > that unfortunately we don't have monitoring of. MPs are great, but I
> > wouldn't want you to do work on one only to have it go nowhere because no
> > one is listening.

> I submitted my patch to the 'master' branch since that looked to be active 
> development, ubuntu/devel seemed abandoned.

> https://code.launchpad.net/~nexusprism/curtin/+git/curtin/+merge/439880

> I have an MP here, is this the correct way to go about it, or would I need
> to seek sponsorship like you had mentioned?

Conveniently, curtin is a project whose upstream is maintained in Launchpad,
and you've targeted your MP to the correct branch - and there are sensible
default reviewers ("curtin developers" instead of, say "Ubuntu Core
Development Team" who do not receive launchpad email) so everything's on
track for this to be reviewed by the maintainers, there's nothing else you
need to do out of band.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Re: Question about submitting patches for repositories on Launchpad

[Alexander Koskovich]

Steve Langasek wrote:

> Which branches are you looking to submit to? There are lots of branches
> that unfortunately we don't have monitoring of. MPs are great, but I
> wouldn't want you to do work on one only to have it go nowhere because no
> one is listening.

I submitted my patch to the 'master' branch since that looked to be active 
development, ubuntu/devel seemed abandoned.

https://code.launchpad.net/~nexusprism/curtin/+git/curtin/+merge/439880

I have an MP here, is this the correct way to go about it, or would I need to 
seek sponsorship like you had mentioned?

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

Re: Question about submitting patches for repositories on Launchpad

[Steve Langasek]

Hi Alexander,

On Thu, Mar 30, 2023 at 03:03:10PM +, Alexander Koskovich wrote:

> I'm fairly new to submitting patches for Ubuntu and I wanted to confirm
> that I'm doing everything right inline with Ubuntu procedures.

> I read that you should fork the original repository in Launchpad, upload
> your commit to it, and open a merge request on the original repository. 
> This is fairly similar to GitHub, but I also read somewhere else that you
> should submit the relevant patches through a mailing list?  Just wanted
> some clarification.

Where did you read that patches should be submitted by email?  Because
that's definitely incorrect.

> Also, if there's anything I would need to do on a merge request past just
> pushing it to get it reviewed.

Which branches are you looking to submit to?  There are lots of branches
that unfortunately we don't have monitoring of.  MPs are great, but I
wouldn't want you to do work on one only to have it go nowhere because no
one is listening.

The official process for getting patches included in Ubuntu is
.  The sponsorship queue is
sadly also under-managed at this time, so sometimes a ping on IRC
(#ubuntu-devel@libera) or email is productive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


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

Question about submitting patches for repositories on Launchpad

[Alexander Koskovich]

Hello,

I'm fairly new to submitting patches for Ubuntu and I wanted to confirm that 
I'm doing everything right inline with Ubuntu procedures.

I read that you should fork the original repository in Launchpad, upload your 
commit to it, and open a merge request on the original repository. This is 
fairly similar to GitHub, but I also read somewhere else that you should submit 
the relevant patches through a mailing list? Just wanted some clarification.

Also, if there's anything I would need to do on a merge request past just 
pushing it to get it reviewed.

Thanks!-- 
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

[Steve Langasek]

I was on +1 maintenance this week.  I'm on PTO today/tomorrow, so sending my
report now.

High-level feedback from me on how proposed is going: we are in very good
shape for the cycle.  We have several years of history now on queue sizes
and "backlog" (package count x time stuck) at
https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.csv
and compared to the past couple of cycles, we are in much better shape now
than we had been at the same point - and that's ignoring the fact that we
recently (post-jammy) fixed how we track the "age" of packages to not reset
on a new release.  There are only 3 packages stuck in -proposed for over 200
days, and only 19 packages that have been stuck for more than 100 days. 
Nice work, everyone who's contributed!  I would say that from the Release
Team / Archive Team side, this has been one of the easiest cycles ever in
terms of managing devel-proposed.

Details:

* Looked at bootstrapping `crystal` which has a self-build-dependency.
The Debian unstable binary isn't installable because `libevent` has a
different package name in Debian vs Ubuntu.  Turns out @zhsj patched libevent
in Debian to not break ABI.  Merged this from Debian to restore package
dependency compatibility, then requested a bootstrap build against the
now-installable Debian binary.
* Had a second thought about the `libevent` implementation, decided this
should be a transitional package for the upgrade from kinetic to lunar
instead of a `Provides`.  Reuploaded.
* Groomed the NBS list; contacted Till about sourceful changes required to
the two packages referencing `libcupsfilters1` (because he's the maintainer
of both).  Those packages are now in -proposed awaiting autopkgtest results.
With this and `libevent` resolved, we'll be down to 0 NBS packages for lunar.
* took another brief look at `nthash`.  FTBFS (regression) on riscv64 in its
own right due to non-portable references to atomic function implementations.
blocked on s390x because `btllib` build-depends on `libomp-dev` from llvm,
which has not been ported to s390x (a brief attempt to address this at
https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/25686061, but
ultimately requires s390x assembly coding which I'm not touching.  And it
FTBFS on armhf due to test timeouts; it would be reasonable to raise the
timeouts or skip the tests on this slower arch, but as that's the only
change that's particularly tractable and wouldn't unblock, I'm not spending
effort on it currently.
* looked at `node-address` autopkgtest failure on ppc64el.  Appears to be a
genuine upstream regression, and is probably cross-architecture but happens
to only trigger on ppc64el because of coincidental idiosyncracies of device
naming on the testbed for ppc64el.  Not trivially reproducible and packaging
all of NPM in Ubuntu is uninteresting, so punting.
* `kgb-bot`: package in release pocket FTBFS the same way (since the package
in -proposed is a no-change rebuild).  Reproducible locally, so is not
caused by a proxy configuration or network issue.  The build failure is not
reproducible in a Debian chroot.  Thanks to a hint from @juliank, learned
about `apt build-dep -s` which can be used to find out which packages apt
would install as build-dependencies, with version numbers, to ease
comparison of build-deps between Debian and Ubuntu.  After eliminating all
the interesting package version differences in the perl build-deps between
Debian and Ubuntu (i.e., any differences that are not due to no-change
rebuilds), the package still FTBFS in Ubuntu.  So unfortunately I had to dig
down into what the test suite was actually doing.  Ultimately strace seemed
the best tool for cutting through the various layers, and showed me an error
that:
I had a problem posting to event json_request of session KGB for DIR
handler '^/json-rpc'. As reported by Kernel: 'No such file or directory',
perhaps the session name is spelled incorrectly for this handler? at
/usr/share/perl5/POE/Session.pm line 483
and the immediately prior syscall is wait4() which fails, as this process has
never spawned a subprocess anyway.  And an attempt to get a stack trace out
of perl shows nothing but POE::Kernel functions, and `libpoe-kernel` isn't even
one of the packages that was at a different version between Debian and Ubuntu.
So at this point I've given up.
* `sc-im`: FTBFS, sponsored a fix from the Debian maintainer (@ItzSwirlz)
* `bettercap-caplets`: uninstallable because it depends on `bettercap-ui`
which is in the Debian NEW queue.  Ignoring for now, but if someone wanted it
removed and out of the way, we could remove it and add it to extra-removals
so that it got pulled back in once bettercap-ui is available.
* `nextepc`: confirmed that the ppc64el ftbfs is caused by a compiler issue
incorrectly calculating object sizes when identifying overflows
(-Werror=stringop-overflow), seen on ppc64el in several cases.  Filed
[LP:

[ubuntu-studio-devel] Ubuntu Studio daily CD health check

[noreply+ubuntu-cdimage]

This is a daily health check report on the Ubuntu Studio CD images.
If you have any questions, contact Colin Watson .

ubuntustudio/dvd: jammy-dvd-amd64.iso oversized by 131620352 bytes (5131620352)
ubuntustudio/dvd: lunar-dvd-amd64.iso oversized by 193368320 bytes (5693368320)

-- 
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