Re: popcon.ubuntu.com gone?
[ your email was html only? ] On Mon, Oct 10, 2022 at 11:43:03AM +0300, Ozgur wrote: > Please read: href="https://discourse.ubuntu.com/t/popcon-to-be-removed-from-the-standard-seed/17238; > rel="noopener noreferrer" > target="_blank">https://discourse.ubuntu.com/t/popcon-to-be-removed-from-the-standard-seed/17238 > oh, thanks. TIL meh, that's why I don't like discourse, I really can't get used to that :( Since the domain and obviously a web server is still there, couldn't somebody make it show a page at least telling that the service is gone? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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
popcon.ubuntu.com gone?
Hi!
I'd like to ask what happened to popcon.ubuntu.com, that is now showing
the default nginx page instead of any useful data.
Also, https://popcon.ubuntu.com/all-popcon-results.txt.gz is a text file
with "Thanks!" in it, rather than containing anything...
Was the service disabled at some point?
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: Proposal: revert recent debianutils changes for Jammy
On Tue, Nov 30, 2021 at 12:45:56PM +, Robie Basak wrote:
> tempfile still prints a deprecation warning to stderr. This looks like
> it was introduced since Hirsute in Ubuntu and so also exists in Impish
> and Jammy currently. Do we still want the deprecation warning in Jammy,
> or should I drop the deprecation warning too, for Jammy, on the same
> principle as what we're doing for the which command? I ask because I'm
> not aware that anybody complained about the warning in Hirsute or
> Impish.
I think it's fine to keep that deprecation warning.
`tempfile` has been formally deprecated and discouraged for so long,
that it just makes sense to get rid of it.
A stderr warning on usage is just fine.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: Add ubuntu-advantage-tools to Recommends on ubuntu-minimal
On Thu, Nov 25, 2021 at 12:56:18PM +, Robie Basak wrote: > On Mon, Nov 22, 2021 at 05:19:38PM -0300, Lucas Moura wrote: > > We want to ask for opinions of this change to other Ubuntu developers, to > > see if we are not missing any other aspect around the original decision to > > include the package into *Depends*. > > Thank you Lucas for raising this here! > > Unfortunately I think that unless someone advocate for the case for this > here, this discussion can't go anywhere, and the status quo will remain. > > I'm saying this for the record: if those who want the change don't > participate, then it's unlikely to happen. FWIW, I'd also like this to be changed. As a very practical example of why: I find very annoying that by default on 14.04 it keeps bothering me that ESM has however many other updates available that -oh how unfortunate- I can't install, and what should have been the trivial way to avoid that to creep into my systems (i.e., removing ubuntu-advantage-tools well before that change came) couldn't be done. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]
owners doing this 'from above'. > > IMHO, that ship has sailed. The "from above" approach has become > necessary because the existing team and team leadership has not managed > to make any progress on this themselves; nor did they engage when Thomas > volunteered to join the team to help. You can't have it both ways here. > > I expect Dan to work with you, and Ubuntu developers at large, to figure > out a process that works for everybody. But I don't think he should be > tied by the need to seek approval from team alumni who have neglected > their responsibilities for years[1]. I think that one way to make this > clear is by explicitly removing old, inactive team members from the team > in Launchpad. This makes it clear that decisions will be made by the > *new* team. Opinions from old team members are valued but they should > not have any decision making powers. Their inability in this area is > exactly why this change is happening. > > If Dan thinks otherwise then my view is moot, of course, since he's part > of the new team that determines membership for themselves. However I > don't think he should be burdened by social obligations of keeping old > and inactive team members around because they might be offended at being > removed, and so I think now is the best time to start afresh. Once the > team works out how they want to manage team membership, he can then add > or re-add anyone as appropriate. > > Robie > > > [1] I hope "neglect" doesn't come across too strong. Everyone has their > own priorities, and when they're volunteering their time (whether > themselves or through an employer), we're grateful for what time they > can commit, not ungrateful for what they cannot find the time to do. > However, from the perspective of the team as a whole, I think that > "neglect" is the only fair way of describing what has happened, and it's > important for us to acknowledge this in order to make progress. > -- > ubuntu-backports mailing list > ubuntu-backpo...@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]
On Wed, Jul 28, 2021 at 11:40:47AM -0400, Dan Streetman wrote:
> I'm fine with Mattia's suggestion for the first irc mtg the week of
> Sept 6-10; my TZ is us/eastern (currently UTC-4) so my preference
> would be anytime between 12:00 and 22:00 UTC, but I could push that a
> bit earlier or later if needed.
I'm based in central Europe, so CEST (currently UTC+2), and I'm a late
sleeper, so my normal times for meetings is between 9:00-21:00 UTC.
22:00 UTC would start be a tad late for me.
> mapreri, teward, any preference on the day and/or time for the first
> mtg? Does Wed, Sept 8 at 14:00 UTC sound ok?
Now, you picked a week where I'll likely be busy during daytime, so I'd
be available only after 16:00 UTC or so.
So I'd be up for https://time.is/compare/1600_08_Sep_2021_in_UTC :)
That said, it's more than a month away, and covid is still in flux, so
who knows how my exact time availability might be!
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]
[ FYI: I just subscribed ubuntu-backports@ (where I wasn't before) - so if we want to discuss specific bpo plans we can drop u-devel@ ] On Thu, Jul 22, 2021 at 05:00:26PM -0400, Dan Streetman wrote: > 1) Open call for initial volunteers > - this email thread seems like a good enough call to the community for > anyone else who wants to volunteer, either in a leadership role or > day-to-day role > 2) Administrative changes to ~ubuntu-backporters > - I don't see any public documentation on an existing process for > membership changes to ~ubuntu-backporters, so I assume your proposal > along with the disussion here is enough justification to ask the TB to > make the changes, assuming there is no objection from the TB of > course, or from existing active members (Laney I assume all this > sounds ok to you?) > 3) New team has initial public irc meeting (and email/chat > communication as needed) to make any process reforms (membership, > backports process, etc) TBH, I'd swap these items 2 and 3 ;) Better decide everything in one swoop rather than risking needing any change later again. > 4) update public documentation > 5) New team starts work on reviewing backports Shall we settle on some dates already? Keeping in mind that August is a month of holiday for quite a few people, plus there is the Debian release in the middle, what about settling on September 5th as a deadline for point 1, trying for an (IRC?) meeting sometime the next week? I'm being very slow-minded in my scheduling here, if you'd like to keep a quicker momentum, I can agree with an earlier date as well. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: Plan to reform the Ubuntu Backporters Team [was: Proposal: sunset the backports pockets]
Hi! Thank you Robie for drafting this! On Wed, Jul 21, 2021 at 11:11:33AM +0100, Robie Basak wrote: > # Team Roles > > For clarity, initially there will be two roles in the team: 1) a > leadership role, driving re-establishment and reform; 2) people doing > the regular day-to-day work, such as reviews. > > I think the first role could only effectively be taken by suitably > qualified, existing and established Ubuntu developers. We'll see if > there are any other volunteers, and if there are, see if there is > consensus that they can also take on the role. I agree on this. > The second role would be open to anyone who meets the requirements of > the new process, which is yet to be defined. I also hereby volunteer me for the day-to-day tasks. Mostly, I don't have enough cycles available to drive discussions and anything related on how to reform the process, else I'd volunteer for more, but if anything I'm positive I can handle reviews and similar. As such, I'm happy to follow Dan or whoever is going to take lead on the project, provided that they present a viable reform path. > # Team responsibilities > > * Establish and manage an effective process to handle backport >requests. Any review process must accept or reject every backport >request on its technical merit, and be neutral to who is requesting >it[1]. > > * Maintain the backports pocket based on this process, making sure that >all requests receive an appropriate answer in a reasonable amount of >time. > > * Maintain quality in the backports pocket, where the definition of >quality is driven by the team, but defined by consensus within the >wider Ubuntu developer community. > > * Handle your own process reform and membership management, but making >sure that any responsibility can be carried by any contributor who >demonstrates the required capacity and competence. Specifically, >since the DMB has never managed membership of ~ubuntu-backporters, >there is no requirement for the DMB to be involved. Unless you want >to delegate that, in which case that's a conversation to have with >the DMB. I don't think there is a need to involve the DMB here. I'd just say that any members should be part of ~ubuntu-dev already, nothing more complex than that. > How does this sound? Feedback appreciated. Nothing to add, your starter is great already, now we only need a lead to lead :) > [1] To be clear, I believe that the current process requires > sponsorship/upload of a suitable backport, and the backporters team only > reviews once an upload has taken place. I believe you are wrong on this. They way the current process is worded, uploads should be done by people in ~ubuntu-backports only, effectively causing a huge load on the team. The reform needed here (as you more or less imply), is that upload rights should follow the usual rules, with ~ubuntu-backports only reviewing the uploads once they end in the "unapproved" queue (i have no idea how the staging queue for backports is currently called). > [2] Availability of sponsors is a separate issue. I'd like to address > that too, but I don't think it's appropriate to pull that into the scope > of backports reform. Aye, unrelated. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: Proposal: sunset the backports pockets
On Mon, Jul 19, 2021 at 10:18:08PM +, Seth Arnold wrote: > On Mon, Jul 19, 2021 at 02:24:30PM +0200, Mattia Rizzolo wrote: > > I'd love to see it working the same way it works in Debian. With > > random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO > > KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is > > only tasked with basically verifying that the version string is sane and > > won't break update. > > 'Put the responsibility on the uploader' sounds like PPAs. With one crucial difference: -backports are distributed through archive.ubuntu.com. You should not downplay the importance of a name. Saying that it's the "official ubuntu backports" kind of gives it some extra assurances of quality. > I think part of why -backports hasn't worked for Ubuntu in the time that > I've been paying attention is that PPAs do a decent job of replacing it. > Anyone who would be interested in using -backports can instead upload > to their own PPA and get immediate sucess. […] > ps I was curious to see how many packages are in -backports: You can see how trusty is full, and then it starts to be smaller and smaller. So you can easily see when the process finally "broke". Of course people use PPA, but I always have a hard time trusting PPAs from random people in certain settings, so way too often I end up needing to do my own builds of things. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: Proposal: sunset the backports pockets
On Mon, Jul 19, 2021 at 01:05:49PM +0100, Robie Basak wrote:
> Any objections? If you do object, please provide an alternative proposal
> that will mean that users stop getting misled.
I'd love to see it working the same way it works in Debian. With
random developers uploading (AND TAKING ON THEM THE RESPONSABILITY TO
KEEP IT WORKING AND POSSIBLY UPDATED EVER AFTER), whilst a "team" is
only tasked with basically verifying that the version string is sane and
won't break update.
I don't remember teward's proposals from 2 years ago, but I do realize
the current way the backports pockets are handled just makes it not
sustainable.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: curl in Debian behind latest version?
On Wed, Jan 06, 2021 at 06:07:33PM -0800, Paul Hoffman wrote:
> Greetings. curl in debian is at version 7.68,
It's not. I can't even figure where you saw 7.68 and decided that's the
version that's in Debian…
curl | 7.38.0-4+deb8u11 | oldoldstable | source
curl | 7.52.1-5+deb9u10 | oldstable| source
curl | 7.64.0-4+deb10u1 | stable | source
curl | 7.74.0-1 | testing | source
curl | 7.74.0-1 | unstable | source
curl | 7.22.0-3ubuntu4| precise | source
curl | 7.22.0-3ubuntu4.17 | precise-updates | source
curl | 7.35.0-1ubuntu2| trusty | source
curl | 7.35.0-1ubuntu2.20 | trusty-updates | source
curl | 7.47.0-1ubuntu2| xenial | source
curl | 7.47.0-1ubuntu2.18 | xenial-updates | source
curl | 7.58.0-2ubuntu3| bionic | source
curl | 7.58.0-2ubuntu3.12 | bionic-updates | source
curl | 7.68.0-1ubuntu2| focal| source
curl | 7.68.0-1ubuntu2.4 | focal-updates| source
curl | 7.68.0-1ubuntu4| groovy | source
curl | 7.68.0-1ubuntu4.2 | groovy-updates | source
curl | 7.72.0-1ubuntu1| hirsute | source
> several times since then. Is there a reason that the Debian package hasn't
> been updated? If so, where can I track that conversation?
Please state your actual problem.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Dependency question
On Wed, Jul 01, 2020 at 07:18:56PM +0200, Gunnar Hjalmarsson wrote:
> Your application is packaged in Debian, i.e. Ubuntu simply syncs it from the
> Debian repo.
And it seems like I was the one sponsoring the last upload some 4 years
ago. umpf.
> I notice this bug: https://bugs.debian.org/908694
>
> Unfortunately the Debian package maintainer seems to have stepped down, and
> nobody else has fixed the bug. As a result the album-data package is not
> available in Debian Buster and Ubuntu 20.04.
I just pinged the "maintainer" on IRC, but I have no idea what it'll
yield.
> So the Debian package needs a new maintainer. Or at least it needs some love
> by some Debian developer who helps out by dropping that dependency.
I could do that update, if it is really just dropping the dependency.
But unfortunately it's not:
https://sources.debian.org/src/album-data/4.05-7/debian/rules/#L68
i.e., it's removing an embedded js library. Is it really fine for it to
embed said library…? In Debian we don't particularly like embedded
libraries. Also I'm not spotting immediatly that .js in the copyright
file, which is a RC bug by itself.
I don't have enough time to actually go and see what's really going on
there, but if somebody produces an update and tells me that's fine I
could be convinced to sponsor it.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Upgrading GHC 8.8.1+dfsg1+is+8.6.5+dfsg1-3 to 8.8.1?
On Tue, Apr 28, 2020 at 09:50:13AM +0200, Martijn Bastiaan wrote:
> Are there any plans to make it actually package 8.8.1? More
No; the whole point of stable releases is that once a version is there
it stay there. There are very few exceptions to this, and all of them
are just because the new versions promises to not break unrelated
things.
The version of ghc is tighly coupled with many things, and it's not as
easy as "updating the package" (for example, we'd want to rebuild all
haskell packages, which are _many_).
> fundamentally, what's the reason for including "xxx+is+yyy" packages?
the +is version (usually is spelled +really, +is is weird) are used as a
way to "downgrade" the version.
Most likely, 8.8.1 was uploaded, then realized too many things broke and
the whole archive wasn't ready for that version, so it was rolled back
to 8.6.5. Since versions can't go backward, here comes the +really (or
+is in this case..) in play.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Hexchat in 19.10 still missing color emojis
On Thu, Oct 03, 2019 at 09:13:10PM -0400, Jeremy Bicha wrote: > On Thu, Oct 3, 2019 at 4:33 PM wrote: > > Was wondering who to ask about getting color emoji support in hexchat > > included with ubuntus repos. Checked 19.10 to see if it was fixed, but it > > still doesn't have color emoji support. Been using the flatpak version of > > hexchat that includes color emojis, but it doesn't handle plugins well due > > to flatpak. > > I think hexchat needs to switch from GTK2 to GTK3. That would be https://github.com/hexchat/hexchat/issues/2047 Anyway, I know that I sometimes see coloured emojis in my hexchat, probably that just comes from the fonts though. If anybody know how comes flatpak works any better, then please share that with and I'll see if I can make the debian package do that as well (best would be in a bug report). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: GB speller in Ubuntu
On Thu, Sep 20, 2018 at 03:25:12PM -0400, Jeremy Bicha wrote: > On Thu, Sep 20, 2018 at 3:19 PM Marco A.G. Pinto wrote: > > I noticed that the GB speller only has the .dic + .aff : > > https://packages.ubuntu.com/cosmic/all/hunspell-en-gb/download > > > > Is it possible also to include the README file?: > > https://github.com/marcoagpinto/aoo-mozilla-en-dict > > Ubuntu gets this package directly from Debian's libreoffice-dictionaries . > > I see that the README is already in the Debian source package. > https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/blob/master/dictionaries/en/README_en_GB.txt > > Would you be interested in filing a Debian bug to request that the > binary package includes that README? Or consider yourself lucky that the maintainer of that package reads this ML :) https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice-dictionaries/commit/d09d224b136d6bb0bf1e6ec2fbd08fb65fd7b1aa But yes, the correct way to go here would have been to file a bug in debian. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Feedback needed] New tool for proposed migration help
On Fri, Sep 21, 2018 at 09:29:55AM +0200, Mathieu Trudel-Lapierre wrote: > Now, all this was pushed to ubuntu-dev-tools as a way to get more eyes > and more use -- so when you see things you disagree with, it's > absolutely fine for you to go ahead and fix the code. :) If that was your goal, then I'd say it would have been much nicer to do so in a separate branch, rather than pushing a ton of code to master. > I wasn't using > ubuntutools because it was "not available", not really practical to use > and keep the tree (and a snap) to use as few dependencies as possible You are talking about a tool to be used by ubuntu developers. Asking for python3-ubuntutools to be installed is entirely reasonable, and I doubt you'll find anybody buying the "as few dependencies as possible" argument in this context... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: [Feedback needed] New tool for proposed migration help
On Thu, Sep 20, 2018 at 10:57:49AM +0200, Mathieu Trudel-Lapierre wrote:
> Lukasz and I wrote a new tool to attempt to help with proposed migration
> (well, we did that at least a year ago). I just added it to
> lp:ubuntu-dev-tools (apologies, this was done without much consultation
> prior to this email). Now we need help to make this tool even better.
> Your feedback is welcome.
It strikes me as a clourful and interactive (and kinda more nice that
way) version of devscripts' grep-excuses.
It feels like those two things could be merged together and gain a lot
from each other (especially the plain grep-excuses…). I think it that
much that I even opened a bug... https://bugs.debian.org/909247 :)
> work to integrate 'update-output-helper' and to generally "parse"
> update_output.txt and get users more information
Well, IME that's when most of annoying issues come into being.
Reading update_excuses.html is very easy; sure it may be handier to not
have to load the whole page each time, but it's too bothersome. OTOH
understanding update_output.txt is much harder, and often one needs to
use other tools (dose, …) to understand the failure reasons.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: Does the backporters team need help?
On Tue, May 02, 2017 at 03:26:12PM +0200, Martin Pitt wrote: > As a first step t it might help to make the process similar to SRUs: After > filing the backport request bug, a developer could just go ahead and upload it > with "backportpackage" or "dput" by themselves -- it seems much simpler to me > as an archive admin/backports team member to review it from the +queue page > and > just click accept than having to build/upload the backport by myself? Totally agree. I was actually quite shocking when I realized it didn't work like that. As a proof that that actually works, that's how it's done in Debian since about ever. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: Does the backporters team need help?
On Mon, Apr 24, 2017 at 06:44:29PM -0400, Scott Kitterman wrote:
> The answer is clearly yes. I've attempted a few times to pass off backports
> to someone new and apparently failed. I'll be glad spend a few minutes
> getting you up to speed, but as I'm not involved in Ubuntu development
> anymore, I don't really have time for more than that.
I also wanted to join the team, and I had a few words with Scott about
that, but then failed at arranging the few minutes he is talking about…
Anyhow, I'm interested in the position just because I'm interested in
backports, but if somebody was to take care of approving the uploads,
etc, I'm more than happy to retract my proposition :)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
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: What happened to the *-dbg packages in Ubuntu 17.04?
On Fri, Apr 07, 2017 at 11:31:07AM -0700, Nathan Osman wrote:
> I recently switched to the second beta of Kubuntu 17.04. I attempted to
> install the qtbase5-dbg package, only to discover that it was absent. In
> fact, not only was this package missing but all of the *-dbg packages for
> Qt components were missing.
> Is there another package that provides the debug symbols? Why were these
> packages removed?
Debian is slowly dropping manual debug symbol packages (-dbg) in favour
of automatic ones (-dbgsym).
https://lists.debian.org/debian-devel/2015/12/msg00262.html
Ubuntu have automatic debug packages (.ddebs) since ever, and in case a
manual -dbg package exists it transitionally pulls it in:
https://wiki.ubuntu.com/Debug%20Symbol%20Packages
I know a little work happened to make Ubuntu build debug packages as
does Debian now, I guess this work will (very) slowly make them
converge.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
apt and pdiff files
I wonder why Ubuntu's archive doesn't use pdiff as Debian does. I looked around but I wasn't able to find any reason. Can someone tell me something about? ps. I don't like write too much ;P -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: apt and pdiff files
On Mon, Feb 17, 2014 at 8:23 PM, Dan Chen email address hidden wrote: cf. http://comments.gmane.org/gmane.linux.ubuntu.devel/28674 thanks, didn't catch that during my hunting... But seems the discussion dropped without any serious motivation... Shall we discuss it another time? Just my 2 cents in support of the adoption of pdiff: 1) archive for stable release doesn't change so often, pdiff will became useful 2) maybe we can change dinstall crontab to run every 2 hours, it's not such a loss from my point of view 3) with my not-so-fast connection download ~20 MB of archive is slower than all debian pdiffs for ~5 days delta. Let's see if anyone else is interested in this. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
