Re: Can we collaborate with Debian better?
there any way to get my packages included into some sort of noble "updates", or something like that? I'm looking at the "mrcal" source package that had an ininteresting FTBFS bug due to some dependency changing its interface. There was a Debian bug report filed and quickly fixed, but this happened too late for noble: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398 The fix is to update the "mrbuild" package to at least 1.9. Is it possible to get an updated "mrbuild" and "mrcal" into 24.04? If I'm misinterpreting what's going on, please let me know. Right now I see this: dima@shorty:~$ rmadison -u ubuntu mrbuild | grep noble mrbuild | 1.8-1 | noble/universe| source, all dima@shorty:~$ rmadison -u ubuntu libmrcal-dev | grep noble libmrcal-dev | 2.4.1-1build1 | noble-proposed/universe| arm64, ppc64el, riscv64 The latest mrcal IS 2.4.1, but here it's in "noble-proposed" and not for amd64 for some reason. I would highly suggest filing a bug against the package in Launchpad following the Stable Release Update procedure: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure If you can articulate your case and the rationale for the update well, it is unlikely that it will be rejected. Best regards, -- Simon Quigley si...@tsimonq2.net @tsimonq2:ubuntu.com on Matrix tsimonq2 on LiberaChat and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[PSA] When uploading to Ubuntu, use SSH, not FTP
Hello, There is currently some slight flakiness with the FTP server accepting uploads, for both PPAs and upload.ubuntu.com. The Launchpad team indicated on IRC that they're looking into it. That being said, those issues don't currently affect SSH uploads. It's generally a good idea to do SSH-based uploads regardless: - Instead of `dput ubuntu your_source.changes`, try `ssh-ubuntu` in place of `ubuntu` - Instead of e.g. `dput ppa:lubuntu-dev/backports-staging your_source.changes`, use `dput ssh-ppa:lubuntu-dev/backports-staging your_source.changes` - Also, if you're a DD, try `ssh-upload` instead of `ftp-master` or `ftp-eu` Note, your SSH key has to be in Launchpad for this to work, and you may need to manually specify your Launchpad username in the configuration if it's different from your machine username. Here's some example config stanzas, for your /etc/dput.cf: [ssh-upload] login = tsimonq2 fqdn= ssh.upload.debian.org method = scp incoming= /srv/upload.debian.org/UploadQueue/ allow_dcut = 1 allowed_distributions = (?!UNRELEASED|.*-security) [ssh-ubuntu] fqdn= upload.ubuntu.com method = sftp incoming= /ubuntu login = * [ssh-ppa] fqdn= ppa.launchpad.net method = sftp incoming= ~%(ssh-ppa)s login = * I hope this helps, -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Responses Needed: Flavor Participation for 24.04 LTS
Hello flavors! As we do around the start of every new cycle, I am reaching out to all the current official Ubuntu flavors to confirm active participation in the upcoming Ubuntu release - 24.04 LTS, codenamed Noble. Working towards a release requires a lot of effort, so we'd like to make sure all the flavors are ready, properly staffed, and have enough time allocated to make 24.04 LTS happen for their users. This is why, similarly to last time, I will need a confirmation follow-up message about Noble participation and your planned efforts this cycle from every flavor, that is: * Edubuntu * Kubuntu * Lubuntu * Ubuntu Budgie * Ubuntu Cinnamon * Ubuntu Kylin * Ubuntu MATE * Ubuntu Studio * Ubuntu Unity * Xubuntu Diversity of opinion within the Ubuntu ecosystem makes us stronger. Flavors play an important role in making a resilient, inclusive, and technically-sound Ubuntu, for all of us, inspiring us to do better, and be better. As important players within the project, we especially value your opinions, and are happy to address concerns if you run into trouble. This release, we are making a concerted effort to move off of Ubiquity entirely and across the board, in time for the LTS. Ubuntu Budgie has paved the way for flavor participation with the new Ubuntu Desktop Installer, while Lubuntu continues to innovate and push the limits of what is possible with Calamares. Whatever route your flavor chooses, it would be an incredibly wise decision to move off of Ubiquity. If you have any concerns regarding your participation, or a switch in installers, please feel free to reach out to me, or anyone from the ~ubuntu-release team. Thank you! -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Fetching source code in Ubuntu: apt source, pull-lp-source, and git-ubuntu
Hello, Yesterday, I worked on a patch for ubuntu-dev-tools[1] to display the same message that apt source does when fetching a package tracked in a VCS. Here's an example of that message: $ apt source lxqt-about Reading package lists... Done NOTICE: 'lxqt-about' packaging is maintained in the 'Git' version control system at: https://git.lubuntu.me/Lubuntu/lxqt-about-packaging.git Please use: git clone https://git.lubuntu.me/Lubuntu/lxqt-about-packaging.git to retrieve the latest (possibly unreleased) updates to the package. [...] This message is quite useful as a reminder to fetch the code the "right way." I've uploaded this to unstable. I would like to bring git-ubuntu into this message, somehow. If a package does not have a Vcs-Git line, a message such as this should be displayed: Alternatively, you may use: git ubuntu clone lxqt-about to get the latest updates. While this seems great at first, there's quite a few edge cases to consider. After talking with Julian and Robie on IRC[2], an approach of automatically adding a "Vcs-Clone" field via Launchpad was brought up. I would like to further this discussion here, and ask a few specific questions: - Is there an easy way for determining whether a given source package is imported via git-ubuntu? - Would it be appropriate to consolidate those messages, only giving the "Vcs-Clone" field? - Is there a better approach to this, one that's more sustainable long-term? - Is git-ubuntu ready for this kind of exposure, and if it isn't, how can we bring it to that point? Thank you for your time; I hope this email helps move the needle forward for our developers. [1] https://git.launchpad.net/ubuntu-dev-tools/commit/?id=2f396fe54956c85e0f0e62891f29dc7bab7d110b [2] https://irclogs.ubuntu.com/2023/10/04/%23ubuntu-devel.html#t18:39 -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Hello, My name is Simon Quigley, and I'm currently the Lubuntu Release Manager. I have been an Ubuntu Member since February 2016 (about a month before I turned 14 years old). I once held hats on the Ubuntu Membership Board, Ubuntu Developer Membership Board, Ubuntu Weekly Newsletter, Kubuntu Team, and a few others. In terms of upload rights, it looks like I became a MOTU at about August 2017, applying for Ubuntu Core Developer a year afterwards. Also worth noting, I have been a Debian Developer since November 2018. I love Ubuntu, the community and development side, and would be honored to serve on the Ubuntu Technical Board. Ask away! On 11/29/22 01:07 PM, Torsten Franz wrote: 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 -- Simon Quigley si...@tsimonq2.net tsimonq2 on LiberaChat and OFTC @tsimonq2:linuxdelta.com on Matrix 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 OpenPGP_signature Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: preparing for the next archive opening
Hello, I would also like to work on finalizing the Qt 4 removal as close as possible to the beginning of the cycle (sooner rather than later). Most of my "between release" work will probably be focused on preparing a final list for an Archive Admin. Is the plan to use Trello/some implementation of Kanban for this again? I would be interested in helping with some pre-opening tasks like I did for this cycle (as well as creating the codename wiki page like I've done for the past few years). Thank you. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Removing Qt 4 from Ubuntu before the 20.04 release
Hello, I would like to completely remove Qt 4 from the Ubuntu archive before the 20.04 release. This includes all of KDE 4 and dependencies. The Debian Qt/KDE Team (which I am a part of) is raising the status of the Qt 4 removal bugs to RC[1], and since the Qt 6 work is starting upstream in the dev branch in the coming months, now is the time for Qt 4 to go. My timeline for this is to change all of the bugs filed to ask people to port[2] to removal bugs, and go over the list of Qt 4 reverse dependencies one last time, so the removal can be done at the beginning of the 20.04 cycle before the archive opens. This would make 19.10 the last release with Qt 4. Flavors, please check if Qt 4 is on your ISO, and if it is, make plans to remove it as soon as you can. Please hop in #ubuntu-qt if you would like help porting your favorite application. Does anyone object to this plan? [1] https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2019-August/002920.html [2] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt4-removal -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Developer Office Hours Report for 07/02/19
Smaller time spent today, but some progress was made nonetheless: - Followed up on https://code.launchpad.net/~tsimonq2/autopkgtest-cloud/+git/bug-1654761/+merge/363643 - it would be good to get this merged before the post-Buster rush of packages and transitions. - Asked for clarification on https://pad.lv/1832059 - Keeping https://pad.lv/1773324 but it really needs action from Server. - https://pad.lv/1833067 is a glibc patch that's a bit over my head, someone from Foundations should look. - Asked for clarification on https://pad.lv/1834211 - Unsubscribed sponsors on https://pad.lv/1829562 since teward already sponsored. Want to get involved with Ubuntu Developer Office Hours? Check the calendar[1] to see when others are signed up. If you're an Ubuntu Developer and want to sign up, let me know and I'll add you to the calendar. Thanks! [1] https://calendar.google.com/calendar/embed?src=og8p18pet6kc9o46aktuau2jh8%40group.calendar.google.com -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Developer Office Hours Report for 06/25/19
Hello, Here is my report for today: - I added cyphermox to the calendar for this upcoming Thursday. - Sponsorship queue work: + Pinged some Snappy people on IRC about https://pad.lv/1802483 - I'd personally like some confirmation that it works before sponsoring, since no other feedback has been provided on the bug report. + https://pad.lv/1770093 needs review from someone who works with the Raspberry Pis more than I do; I have a Pi 3 and I'll circle back once I can get an SD card for it later this week, if needed. + Poked sil2100 about reviewing https://pad.lv/1814118 + Asked bluesabre about https://pad.lv/1822380 - the sponsors team should be unsubscribed (done) but it does seem there's a GTK 3 problem here. I'll circle back later this week. + Asked for further changes on https://pad.lv/1815684 because some of the changes included in the debdiffs are not suitable for an SRU. + Pinged jamespage about https://pad.lv/1827340 - I'm not comfortable reviewing it and he has TIL on swift. + Synced minetest - https://pad.lv/1828933 + Pointed https://pad.lv/1766068 towards submitting the patch to Debian, and pinged juliank (the maintainer). + Asked in #ubuntu-kernel if anyone could look at https://pad.lv/1826845 + Pinged cyphermox, who sponsored the Eoan upload for https://pad.lv/1828948 to see if he plans on driving the SRU. + Sponsored https://pad.lv/1828230 + Asked for the location of the package to be sponsored on https://pad.lv/1829562 + Asked LocutusOfBorg to review https://pad.lv/1829677 as he has experience with the LLVM packages. cyphermox is next on the calendar[1], and I'm scheduled for the same time next week. Thanks! [1] https://calendar.google.com/calendar/embed?src=og8p18pet6kc9o46aktuau2jh8%40group.calendar.google.com -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Revisiting the +1 Vanguards: Ubuntu Developer Office Hours
Hello, I wanted to revisit a proposal by Mathieu Trudel-Lapierre[1] from last September regarding +1 vanguards. I think this is a great idea and I wanted to push to make it happen. To do this, I have created an "Ubuntu Developer Office Hours" calendar. The goal is to define times in which Ubuntu Developers are available to assist with sponsoring and work with newcomers and other developers to reduce friction and improve the deb package development story in Ubuntu. During this time, the person signed up would "@pilot in" in #ubuntu-devel, and to be available to do any of the following: - Sponsor packages and discuss patches with sponsorees. - Work on fixing packages which FTBFS in devel-proposed. - Work on proposed migration, regression analysis, and Britney output interpretation to drive packages to devel-release. Compared to +1 vanguards, this is more of an overarching idea; while this time could be used to work on devel, it could also be used on SRUs, Universe security updates, and less technical work such as polishing documentation. The aforementioned tasks are only examples. Towards the end of their scheduled shift, the Ubuntu Developer would then write up the results of their shift; it could be as verbose as describing underlying issues or outlining important work on large projects, or it could be as simple as bullet points. The calendar is available here[2]. The goal would be for different people with a variety of backgrounds to sign up, to emphasize quality over quantity (less of the patch pilot "sign everyone up for a day" style and more of "different people from different backgrounds are available at some point in the same week"). To sign up, either contact me with a Google-compatible email address (@canonical.com and @gmail.com are examples) and I can give you write access to the calendar, or send me specific dates/times and I can add them myself. Thank you, and let me know if you have any questions. [1] https://lists.ubuntu.com/archives/ubuntu-devel/2018-September/040501.html [2] https://calendar.google.com/calendar/embed?src=og8p18pet6kc9o46aktuau2jh8%40group.calendar.google.com&ctz=America%2FChicago -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Patch Pilot Report for May 11th, 2019
Hello Andreas, On 5/13/19 7:37 AM, Andreas Hasenack wrote: > Thanks for this work! Could you perhaps include a link in your > template to the report that shows bugs needing sponsorship? People can > get curious, take a look, see a package they are familiar with, ..., > profit! > > :) That's a good idea; I'll do it next time. Thanks! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report for May 11th, 2019
Hello, I did another round of sponsoring today. Here's my report. - https://pad.lv/1825733 - unsubscribed sponsors, since bdmurray sponsored the upload. Thanks! - https://pad.lv/1825194 - the debdiff has been uploaded to the queue (by someone else), unsubscribed sponsors. - https://pad.lv/1828615 - asked the reporter to file a bug in Debian, but someone familiar with kernel API calls should really be the one to review. - https://pad.lv/1827340 - pinged jamespage to take a look, as I'm not particularly comfortable reviewing OpenStack packages. Current analysis of the queue, 𝚫 my last email[1]: - https://pad.lv/1828288 - it needs an SRU template, but I'm not going to unsubscribe sponsors, given previous discussions. We're down to 11 packages in the queue! Let's keep up the good work. :) [1] https://lists.ubuntu.com/archives/ubuntu-devel/2019-May/040678.html -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch Pilot Report for May 3rd, 2019
Hello, Today I had some spare time, so I did some patch piloting. Here is my report on the packages I reviewed and/or sponsored. - https://pad.lv/1821410 - unsubscribed sponsors, but talked to seb128 on IRC; I'm not opposed to resubscribing if someone else is willing to drive it, it just needs an SRU bug description. - https://pad.lv/1824560 - unsubscribed sponsors because LocutusOfBorg has already sponsored. Thanks! - https://pad.lv/1822062 - unsubscribed sponsors since slashd has already sponsored. Thanks! - https://pad.lv/1827327 - just a manual sync from Debian Experimental since Buster is frozen, sponsored. - https://pad.lv/1815684 - everything checks out (with the exception of needing the bug number in the changelog, but that's trivial enough for the sponsor to just do it and leave a note), but when I went to sponsor it, I got this error: - dh clean --parallel --with maven_repo_helper --with systemd --with php --with python3 --with python2 --with javahelper debian/rules override_dh_auto_clean-arch make[1]: Entering directory '/tmp/tmp.B2gDfkOcuE/zeroc-ice-3.7.1' /usr/bin/make V=1 prefix=/usr DESTDIR=/tmp/tmp.B2gDfkOcuE/zeroc-ice-3.7.1/debian/tmp OPTIMIZE=yes LANGUAGES=cpp CONFIGS="shared cpp11-shared static cpp11-static" distclean make[2]: Entering directory '/tmp/tmp.B2gDfkOcuE/zeroc-ice-3.7.1' make[2]: *** No rule to make target 'distclean'. Stop. make[2]: Leaving directory '/tmp/tmp.B2gDfkOcuE/zeroc-ice-3.7.1' make[1]: *** [debian/rules:114: override_dh_auto_clean-arch] Error 2 make[1]: Leaving directory '/tmp/tmp.B2gDfkOcuE/zeroc-ice-3.7.1' make: *** [debian/rules:76: clean] Error 2 - I can look later, but it seems like a simple `debuild -S -d -sa` won't work for this package. Someone else is welcome to try. Current analysis of the queue, 𝚫 my last email[1]: - https://code.launchpad.net/~azzar1/update-notifier/hide-livepatch-indicator-if-disabled/+merge/366569 - someone at Canonical that can verify the patch should be the one to review it. - https://pad.lv/1827451 - talked with oSoMoN on IRC, who said that the fix will be driven by someone other than himself; I plan on following up on it next time I Patch Pilot if things haven't changed. Thanks everyone! [1] https://lists.ubuntu.com/archives/ubuntu-devel/2019-April/040665.html -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Improving the Sponsorship Queue and Other Reports (WAS: Re: State of the Sponsorship Queue - Can we get it to 0?)
Hello Sebastien, On 4/23/19 4:47 AM, Sebastien Bacher wrote: > 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 :-) Thanks (to Robie and Gunnar as well)! >> 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&do 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). While I agree with Robie that we have limited contributors working on the queue (I have noticed more activity lately from others, thank you!), my rationale was to review it purely with an Ubuntu Sponsors Team hat on while I was getting the queue to a manageable point; a package is either ready to sponsor (sometimes with fix-ups) or it isn't. Sometimes, I can understand what a patch is doing by reviewing it, but I would like to understand the wider ramifications (if any) from the person that reported it. While I recognize this isn't always the case, getting their feedback from what can otherwise be a terse bug report has, in my experience at least, led to a higher quality paperwork end result. Perhaps this is because most of the items I have dealt with recently either have an Ubuntu Developer, a Canonical employee, a Debian Developer, and/or upstream working on them. I would like to address the wider point here, though. Right now we have no way to leave a comment directly on the sponsorship queue, much like we do with MoM, which would solve this. We have sorting, but the CSS (while not entirely important) looks outdated. While I could spend a day or two polishing that page specifically, and make it look presentable with all the fields we would need, we have several other pages that are in a similar state. Here are a few examples: https://people.canonical.com/~ubuntu-archive/pending-sru.html https://people.canonical.com/~ubuntu-archive/phased-updates.html http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html These pages are quite scattered; while outputs can come from different machines (I have no idea what this looks like internally at Canonical, this is just a guess) and different sources (Britney, sru-report, etc.), it would be nice to bookmark *one* page that has each of these as clean, modern-looking, and consistent pages as sub-pages. From there, we could generate reports, perhaps similar to the Debian Maintainer Dashboard. I understand this might seem like a significant undertaking, and I am willing to do the work in order to make this happen, but I would like to have the conversation about whether others would find this useful. Please let me know if you are an Ubuntu Developer who would like this (or if you object to it, more importantly), and I can create an initial specification and mockup to send back to this thread. Thanks! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
State of the Sponsorship Queue - Can we get it to 0?
Hello, 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. 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. Here is my current analysis of the queue: Requests left: 13 - https://pad.lv/1802483 - snap-related libnotify patch which I am not comfortable reviewing. It otherwise seems ready. - https://pad.lv/1803385 - debian-installer-related patches which I am not comfortable reviewing. I pinged slashd asking if he could take a look. - https://pad.lv/1763520 - Disco was fixed, but there are debdiffs for Cosmic and Bionic as well. I pinged Laney to ask if he could review them. - https://pad.lv/1754075 - debian-installer-related patch which I am not comfortable reviewing. - https://pad.lv/1762572 - dput patch which juliank said he would review; I pinged him on IRC. - https://pad.lv/1814791 - dput patch which should probably be uploaded alongside the above patch. - https://pad.lv/1770093 - debian-installer-related patch which I am not comfortable reviewing. - https://pad.lv/1814118 - sil2100's name is on it; I subscribed him but he hasn't had the chance to review it yet. - https://pad.lv/1778844 - vorlon sponsored it for a previous release; I am assuming that, with it only being four days old, it is on someone's TODO list. - https://pad.lv/1821811 - sarnold was looking into it but has not followed up yet on the bug report. I pinged him on IRC. - https://pad.lv/1823778 - The Desktop Team has yet to review. - https://code.launchpad.net/~azzar1/update-notifier/handle-applying-state-livepatch/+merge/366059 - Related to livepatch, so a Canonical employee with access to test that should probably be the one to merge it. - https://pad.lv/1824073 - Looks to be an OEM-related debian-installer-related patch that I am not comfortable reviewing. Wouldn't it be excellent if we could get this down to 0 so we can start the Eoan cycle with a clean slate? :) -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Disco Dingo (19.04) Final Freeze - is it available?
On 4/13/19 1:26 PM, Ian Bruntlett wrote: > Hi, > > Are the above isos available for testing yet - and where are they? Was > hoping to test it this morning but I haven't heard a peep so far. I announced this a day before you said something here, check your spam ;) -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Release Candidate (and testable!) Disco Dingo builds ready to test (hint hint!)
Hello, Disco Final builds should now be available on the ISO QA tracker[1]. These builds are not final. We're still waiting on a few more fixes, a few things to migrate, etc. Neither base-files or the ISO labels are updated yet, so please don't file bugs about those. What there are, however, are "close enough" for people to be testing in anger, filing bugs, fixing bugs, iterating image builds, and testing all over again. So, please, don't wait until Wednesday night to test, testing just before release is *TOO* *LATE* to get anything fixed. Get out there, grab your favorite ISO (if you don't have a favorite, grab them all), beat it up, find bugs, report bugs, escalate bugs, fix bugs, respin (if you're a flavor lead with access), and test, test... And test. Did I mention testing? Please[2] test. [1] http://iso.qa.ubuntu.com/qatracker/milestones/403/builds [2] Please. Pretty please? -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Delegating hinting for autopkg failures to core developers and MOTU
Hello, On 4/10/19 12:20 AM, Matthias Klose wrote: > Please can we delegate the hinting for autopkg test failures to core > developers > and MOTU? > > When ignoring an autopkg test failure, you usually have a reason to do so. > As a > core developer you already can work around autopkg test failures with > uploading > a work-around in a new package version, both for main and universe packages. > The disadvantage is a longer turn-around, re-triggered autopkg tests, > introducing a delta which has to be maintained. MOTU could be limited to only > hint failures for universe packages. > > The current limitation of autopkg related hints being done by the release team > seems to be a technical limitation, because other hints are done by the > release > team only. Of course there should be informal restrictions for hinting during > archive freezes, release freezes. I generally disagree with this. The Release Team is ultimately responsible for ensuring the archive is releasable; if we let every Ubuntu Developer hint packages, the Release Team would ultimately be giving up enforcement of what is supposed to be a hard freeze at some points in the cycle, and what are generally supposed to be clear release goals. If the role of the Release Team were to be dissolved and the power were to be given to individual developers, I doubt we would be able to keep a stable release pocket, which hurts both our users and our customers. If I believe a package should be hinted, I always discuss it on #ubuntu-release; sure, sometimes they don't have to follow up with me about it and the Release Team just does it, but I'm not perfect, and productive discussion out in the open about hinting a package not only fosters understanding for prospective developers, but it allows for a higher-quality release. I am aware of a handful of Ubuntu Developers who regularly either come to me personally or to #ubuntu-release because they don't quite understand the ramifications behind hinting something or are lost in proposed-migration. From a DMB perspective, while we are working towards setting forth clearer expectations, we don't always thoroughly verify that a candidate knows top-to-bottom how proposed-migration works. I personally have faith that the vast majority of Ubuntu Developers know general Ubuntu processes and packaging, but I don't have faith that a majority can walk through p-m past simple cases. Where I would tend to agree with your general point is, we should have a clearer process on becoming a member of the Release Team (and a more diverse set of people on the team). If an Ubuntu Core Developer very evidently knows proposed-migration and the ramifications of hinting packages, they should be empowered to make rational decisions rather than having to nag the Release Team all the time. To be clear, I'm not suggesting the Release Team begins adding people left and right, and the candidates should be high quality, but the Release Team has 7 members at the moment; one of which is a community member, the rest work for Canonical and (last time I checked) either are members of Canonical Foundations or once were, with the most recent two members being added in 2016 and 2017 (the rest are in the 2006-2012 range). Thoughts on this, especially from the Release Team, would be appreciated. Thanks, -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital 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: drop rails and its reverse-dependencies from Ubuntu 19.04 [Re: Maintaining language-specific module package stacks]
On 4/9/19 10:53 PM, Matthias Klose wrote: > On 10.04.19 05:48, Simon Quigley wrote: >> On 4/9/19 10:15 PM, Matthias Klose wrote: >>> On 10.04.19 04:37, Simon Quigley wrote: >>>> On 4/9/19 9:27 PM, Matthias Klose wrote: >>>>> rails is ready to migrate, there is no puma package in the release >>>>> pocket. the >>>>> failing puma autopkg test in -proposed shouldn't be any concern. >>>>> >>>>> Filed LP: #1824049 for that. >>>>> >>>>> Now we could go on removing puma from -proposed, and then rails should >>>>> migrate. >>>>> How can we do that without removal? >>>> >>>> (disclaimer: not on the release team) >>>> >>>> This isn't a bug in Britney; Britney is designed to block on *any* >>>> autopkgtest failures if there aren't any test hints (thus, a documented >>>> reason for it failing). Passing autopkgtests for all packages is a >>>> release goal, and unless the package has a hint (which is an exception >>>> to the rule), any failing autopkgtests shouldn't let a package into the >>>> release pocket. This autopkgtest should be evaluated to see if it's a >>>> real regression in rails or if it's puma autopkgtests not working properly. >>> >>> Call it a britney bug or a proposed-migration bug. But to what extent >>> should we >>> care about a regression which doesn't show in the software that we ship? >>> It's >>> certainly not contradicting your statement "Passing autopkgtests for all >>> packages is a release goal", because puma then wouldn't be part of the >>> release. >>> Now remove rails and dependencies and you might be able to update to a new >>> ruby >>> version much earlier, with even more regressions outside the archive. >> >> I think we should care about it to the extent that we can ensure that >> puma's failure is not caused by ruby. > > s/ruby/rails/ ? ruby currently isn't part of any migration. Sorry; we are discussing this on a higher level and I overlooked it. >> If puma's autopkgtests are >> flaky/unfixable without Very Horrible Hacks, they should be hinted. If >> the failures are irrelevant to the ruby update, ruby should be hinted >> when all other rdep pass their tests. If the puma test failure is easy >> to fix, we should solve that, and then we're done here. All of these >> actions can be completed without the Archive Admins. > > But in this case, puma would migrate with rails and you have the incompatible > puma and rails versions in the release pocket. Not necessarily. puma is considered a candidate if its autopkgtests pass or are hinted. rails itself can be hinted without puma being hinted, while puma still fails (thus staying in proposed). One question we should seek to answer is if this is a rails regression; if it is, it might be a wider problem that we should solve in rails itself prior to letting it migrate. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital 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: drop rails and its reverse-dependencies from Ubuntu 19.04 [Re: Maintaining language-specific module package stacks]
On 4/9/19 10:15 PM, Matthias Klose wrote: > On 10.04.19 04:37, Simon Quigley wrote: >> On 4/9/19 9:27 PM, Matthias Klose wrote: >>> rails is ready to migrate, there is no puma package in the release pocket. >>> the >>> failing puma autopkg test in -proposed shouldn't be any concern. >>> >>> Filed LP: #1824049 for that. >>> >>> Now we could go on removing puma from -proposed, and then rails should >>> migrate. >>> How can we do that without removal? >> >> (disclaimer: not on the release team) >> >> This isn't a bug in Britney; Britney is designed to block on *any* >> autopkgtest failures if there aren't any test hints (thus, a documented >> reason for it failing). Passing autopkgtests for all packages is a >> release goal, and unless the package has a hint (which is an exception >> to the rule), any failing autopkgtests shouldn't let a package into the >> release pocket. This autopkgtest should be evaluated to see if it's a >> real regression in rails or if it's puma autopkgtests not working properly. > > Call it a britney bug or a proposed-migration bug. But to what extent should > we > care about a regression which doesn't show in the software that we ship? It's > certainly not contradicting your statement "Passing autopkgtests for all > packages is a release goal", because puma then wouldn't be part of the > release. > Now remove rails and dependencies and you might be able to update to a new > ruby > version much earlier, with even more regressions outside the archive. I think we should care about it to the extent that we can ensure that puma's failure is not caused by ruby. If puma's autopkgtests are flaky/unfixable without Very Horrible Hacks, they should be hinted. If the failures are irrelevant to the ruby update, ruby should be hinted when all other rdep pass their tests. If the puma test failure is easy to fix, we should solve that, and then we're done here. All of these actions can be completed without the Archive Admins. I still don't personally see this as a bug in currently-deployed code. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital 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: drop rails and its reverse-dependencies from Ubuntu 19.04 [Re: Maintaining language-specific module package stacks]
On 4/9/19 9:27 PM, Matthias Klose wrote: > rails is ready to migrate, there is no puma package in the release pocket. the > failing puma autopkg test in -proposed shouldn't be any concern. > > Filed LP: #1824049 for that. > > Now we could go on removing puma from -proposed, and then rails should > migrate. > How can we do that without removal? (disclaimer: not on the release team) This isn't a bug in Britney; Britney is designed to block on *any* autopkgtest failures if there aren't any test hints (thus, a documented reason for it failing). Passing autopkgtests for all packages is a release goal, and unless the package has a hint (which is an exception to the rule), any failing autopkgtests shouldn't let a package into the release pocket. This autopkgtest should be evaluated to see if it's a real regression in rails or if it's puma autopkgtests not working properly. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Tiago Stürmer Daitx
Yesterday (Monday) Tiago was approved as an Ubuntu Core Developer by the Ubuntu Developer Membership Board. He now has upload rights to the entire Ubuntu archive. Launchpad URL: https://launchpad.net/~tdaitx Please join me in congratulating him! On behalf of the Ubuntu Developer Membership Board, -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Requiring Launchpad 2FA from Ubuntu uploaders
Hello, On 08/14/2018 11:34 AM, Colin Watson wrote: > How would this work, even conceptually? Some kind of extra challenge > when doing SFTP uploads or git/bzr pushes to ask for 2FA (and some > timeout arrangement so that it isn't hopelessly annoying)? What about > FTP uploads? In my opinion, SFTP should be the default for uploads to Ubuntu*, and we should phase out FTP. My local /etc/dput.cf has been patched to do this for a while now, and it works fine. If this is done, we should be able to use PAM with google-authenticator. Thoughts on going this route? *If I recall correctly, Debian has already done this for uploads to security-master. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: New Ubuntu Core Developer - Simon Quigley
Thanks! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Ubuntu Core Developer - Simon Quigley
Today, I was voted to be an Ubuntu Core Developer by the Ubuntu Developer Membership Board (a board which I already sit on, so I'm taking care of myself here). I now have upload rights to the entire Ubuntu archive. Thanks everyone! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Inconsistencies in package versions for stable releases
Hello Łukasz, On 07/09/2018 02:32 AM, Lukasz Zemczak wrote: > Just a few cents from me as an SRU member. For the sake of clarity, are you representing yourself as an uploading Ubuntu Developer, or the SRU team as a whole? > There is no 'inconsistencies' among the SRU team regarding versioning > as there is no 'standard' way of versioning packages. Standards are not a prerequisite of inconsistency. If I complete a task a different way than someone else does, and there's no written standard way of completing this task, our actions are still not consistent. > Rejection of a package because of the versioning scheme, to me, is > only a case of preference and can vary between SRU members. Right, this is the inconsistency I'm describing. > In my view the ubuntu-report scheme is the most invalid, but it has > been accepted conditionally as the package was not targeted for > backporting to anywhere else than bionic. I should have probably > rejected it and re-uploaded with a more fitting versioning applied, as > I did for a few others like this. But as I said, there generally is no > standard we *need* to enforce, so as long as the version works - > there's no requirement for rejection. I think this is a slippery slope. There are a lot of versioning schemes which *technically* work, but should we use them in practice? For example, if I were to upload version 1.7.5-1bionicbeaveristhe1804ltsrelease.0.18.04.0.1 of a package which has only been in Bionic and Cosmic, following this standard, as long as it works, the SRU team would have to accept it. > We should keep advertising the security team's versioning as the best > way to go, but right now - for what I can tell - there are no rules > for that. My argument is that we *should* have rules here. If we say that the security team versioning scheme should be followed, but if you don't follow it and it still works anyway it'll still be accepted, then what's the point of linking to the security team versioning scheme? Thanks for your response. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Inconsistencies in package versions for stable releases
Hello, This email is following several discussions I have had over the past few weeks on how the versioning scheme of packages work with respect to stable releases. It seems there is some inconsistencies with SRU team members accepting different-versioned packages due to somewhat varied standards. Some people say that the Security Team document on versions[1] is the (lowercase c) canonical document on how things should be versioned, while others just say "as long as the version isn't a problem." As someone who has had their packages rejected before because the version did not match the former of the two preferences, I think it is worth having a discussion on how we should do version numbers in a uniform and agreed-on way. Here are some uploads that I would have probably seen rejected depending on the SRU team member because of the version: https://launchpad.net/ubuntu/+source/snapd/2.33.1+18.04ubuntu2 https://launchpad.net/ubuntu/+source/ubuntu-report/1.2.0~bionic https://launchpad.net/ubuntu/+source/shim/13-0ubuntu2 With snapd, it seems to be somewhat inverted from the typical case, where Xenial gets the native package upload with no additions, Xenial+ gets +XX.YY, and Trusty- gets ~XX.YY. With ubuntu-report, I have always been discouraged from using codenames in the version number, because if, for some reason, we needed this in Xenial, being consistent with the naming scheme wouldn't work: $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~xenial"; echo $? 1 $ dpkg --compare-versions "1.2.0~bionic" ">>" "1.2.0~16.04.1"; echo $? 0 This means we would have to be inconsistent across releases. With shim, I have also been discouraged from doing ubuntuX, as opposed to ubuntuX.Y. In this case, I would have gone with 13-0ubuntu0.2. My objective in pointing these out is not that these versioning schemes do not work, or to pick on any one package or person. My point is, they lack consistency with the rest of the archive, and some of these do not work in other cases where a variable has changed. Most importantly though, I have observed varied tolerance among the SRU team for these version numbers. Is the existing document by the Security Team[1] lacking any important considerations? Can we adopt it as the uniform standard for updates in a stable release, or is there a good reason to continue with inconsistency here? Thanks. [1] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- 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
> https://qt-kde-team.pages.debian.net/www/symbolfiles.html Moved again, hopefully for the last time: https://qt-kde-team.pages.debian.net/symbolfiles.html -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- 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
Hello, Putting on my Debian/Qt KDE Team hat. On 05/18/2018 01:29 PM, Matthias Klose wrote: > yes, and that is a very easy process using the pkg kde symbols helper. > See https://pkg-kde.alioth.debian.org/symbolfiles.html, but this link is now > not > accessible anymore. We just migrated the site from Alioth to Salsa today. Here's the new URL: https://qt-kde-team.pages.debian.net/www/symbolfiles.html Thanks! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital 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: Let's drop i386
Hello, On 05/09/2018 04:29 PM, Walter Lapchynski wrote: >> here are some i386 to amd64 ratios for 18.04: >> Lubuntu cdimage - 0.87 > > And there is my concern. That says the vast majority of Lubuntu's users > are using i386. The question becomes whether or not they have to. There > has been documentation all over the place to download i386 if you don't > know which is the right one and so people may still be running on this. > So maybe the number is skewed. But if it's not, does this mean Lubuntu > becomes irrelevant? You're misreading the statistics. *Less* people use i386, not more. 87 i386 users per 100 amd64 users. Additionally, with Lubuntu modernizing a bit, I would argue that Lubuntu can and will still stay relevant in the future. This is before we dropped LXDE, and it's the LTS. We can judge whether or not Lubuntu is still relevant by seeing how the LXQt transition plays out. Also, to be fair, Lubuntu 18.04 could be considered for sort of a niche audience; people who need to run Linux (specifically, with LXDE and Ubuntu) on older machines. Lubuntu's LXQt transition does modernize things a bit, while still preserving some of those light selling points. I would also not use this as a determining factor, because we have no idea how things will look three years from now. My best guess is that i386 users will drastically diminish. >> The first step would be to all agree on dropping images/installers but >> we should keep the end goal of dropping the port in mind ideally soon >> as well. > > Maybe keeping only the netboot image might make sense? If the port goes away entirely, so will the netboot images. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubiquity NG - was Re: ubiquity migrated to git
Hello Mark, On 05/05/2018 01:15 AM, Mark Shuttleworth wrote: > First, we have Curtin, which knows how to take a description of a > machine and do-the-right-thing; partitioning, installing, and cleaning > up. Curtin is neat and efficient, super-fast, and it's used by both MAAS > and the new Ubuntu Server installer, Subiquity. It knows how to install > a couple of different flavours of Linux, including Ubuntu and CentOS, > which could be handy. It's probably the best place for us to handle new > kinds of partitioning and root filesystem and network storage. > > Second, we have MAAS, which has some very nice HTML interfaces for > configuring network and storage on a machine. All of that lines up with > Curtin, because MAAS uses Curtin to do the actual install. So we have > the beginnings of an HTML5 installer. Would we be able to customize this in a way that's fit for desktop users rather than server users? A fork might need to happen there. > Third, we have Electron, which is the HTML5 app framework used by world > class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu > are Electron apps. I respectfully disagree that this is the correct approach for a system installer. With all due respect to these very popular applications, Electron uses quite a bit of system resources and could be interesting to get working correctly. If you are absolutely certain that this is the way to go, I won't argue this point too much, but I believe that you would have triple the speed (and/or it would use a third of the memory) by writing a native application rather than an Electron one, and with proper testing and organization (perhaps by using a compiled language rather than an interpreted one, etc.), it would be a very welcome speed jump over the current Ubiquity codebase. > Fourth, we have snaps, which are just amazingly tasty ways to get the > latest bits in the hands of your community. I would also respectfully disagree that this is the correct way to deliver a desktop system installer. With snaps, while you have the advantage of one installer across all versions of Ubuntu (and the usual advantages of such a workflow), it could sacrifice stability, especially if the snap has to be updated to a new version on boot (think about systems with no internet access on install time), and with confinement, it needs to be done just right to get the proper bits to do a full system install. There is also the issue currently with desktop integration (so GTK or Qt theming will not work correctly, and a few other issues that won't make the experience as smooth as can be). I'm not entirely opposed to the idea of snapping it and delivering it that way, but the ecosystem and integration has some issues that should really be worked out before the installer is done this way. Delivering as a deb does have the advantage of the Stable Release Updates process for stable releases, which can ensure that proper QA processes are followed (with bug tracking), and any Ubuntu Core Developer has the upload access to provide bugfixes (and doesn't have to learn an entirely new ecosystem to fix a bug in the installer, which is important for flavors). Thanks for the thread, Mark! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Fwd: New Qt Discussion Channel
Might be useful for this list to know as well. Forwarded Message Subject: New Qt Discussion Channel Date: Mon, 1 Jan 2018 19:46:01 -0600 From: Simon Quigley To: kubuntu-de...@lists.ubuntu.com, lubuntu-de...@lists.ubuntu.com CC: ubuntubudgie-...@lists.launchpad.net Hello everyone, Since Qt is a major foundational framework for two flavors (Kubuntu and Lubuntu Next), and soon to be Ubuntu Budgie (given where upstream Solus/Budgie is going), I thought it was about time to create a place to collaborate on Qt-specific packaging, transition, and bug triage work pertaining to the Qt framework. That place is now #ubuntu-qt on freenode and is bridged to Telegram at https://t.me/joinchat/DH6s1A5_bOpAVbiu9QzvVg Anyone is welcome to join, but please keep in mind that it's Qt-specific technical discussion, and *this is not the place to get support for your favorite Qt-based Ubuntu flavor*. Thanks everyone, and Happy New Year! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
New Qt Discussion Channel
Hello everyone, Since Qt is a major foundational framework for two flavors (Kubuntu and Lubuntu Next), and soon to be Ubuntu Budgie (given where upstream Solus/Budgie is going), I thought it was about time to create a place to collaborate on Qt-specific packaging, transition, and bug triage work pertaining to the Qt framework. That place is now #ubuntu-qt on freenode and is bridged to Telegram at https://t.me/joinchat/DH6s1A5_bOpAVbiu9QzvVg Anyone is welcome to join, but please keep in mind that it's Qt-specific technical discussion, and *this is not the place to get support for your favorite Qt-based Ubuntu flavor*. Thanks everyone, and Happy New Year! -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- kubuntu-devel mailing list kubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Recommending people Snap things in response to valid packaging problems (WAS: Re: need help resolving python-setuptools backport fail)
to work on, depending on their interests and goals. I don't think Snaps are a bad thing, I just think that they have a time and place (much like deb packages, and other "universal" packaging formats like flatpak and appimage, each has their advantages and disadvantages, and none of them are complete replacements for all the rest), one that hasn't really reached the point where I as a contributor use them enough or have enough of a need for them to warrant contributions from my end. One point that I would like to make is that my end goal in contributing to this discussion and starting a new subthread (if you will) is because I want to help Walter and anyone else that may come across this list archive in the future solve a packaging problem and to have a discussion about how packaging problems like this could be solved in the future. Just my two cents, speaking for myself. Thanks for both of your time, -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Recommending people Snap things in response to valid packaging problems (WAS: Re: need help resolving python-setuptools backport fail)
Hey, On 12/06/2017 04:32 AM, Oliver Grawert wrote: > Yes, if the original question was about a python backport exercise it > definitely does not answer this and i'm sorry if i de-railed the track > with the answer ... it is just that creating a 20 line snapcraft.yaml > file to backport something is a lot easier than having to manage a > whole python stack :) The difference here is that in order to figure out that 20 line yaml file it often takes a fair bit of time (several hours in my experience), to get all the isolation bits etc. working properly. I guess maybe I'm not a fan of the fact that now apparently the standard solution to "I'm having this interesting packaging problem, any ideas?" is now "have you tried packaging the thing in this completely different packaging format that oversimplifies things?" because it doesn't really help the people who want to learn and work on actual packaging (as opposed to putting everything in a yaml file) and it completely avoids the actual problem at hand. But maybe this is just me who has noticed that this is an increasing trend in responses to emails like this... >> I >> find it quite possible that the question will still stand regardless >> of >> whether or not I considered a snap. This is a build-level issue, from >> what I can tell, not necessarily a matter of the packaging framework. >> That said, do you have any relevant advice? >> > not for doing a backport of the whole python stack as deb packages, > no... i disagree that this is no build level issue though, given that > snapcraft will simply care for getting the right deps for you without > any additional backport work when packaging offlineimap with it though > ... > > anyway, sorry for hijacking the thread, i was just trying to point out > an easy way here to achieve the same goal ... "I know how to package in this one format that just involves throwing it all into a yaml file and it will automagically figure out all the deps for you" -- doesn't really solve the problem, but as I said above, seems to be the "blanket solution" nowadays. Just my two cents, my opinions are my own. Thanks, -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 signature.asc Description: OpenPGP digital signature -- 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
Hello Sebastian, On 09/04/2017 08:20 AM, Sebastien Bacher wrote: > 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. So then what happens with stable releases? I would much rather have an out-of-date firefox on devel if it means it's working for release for most arches. I say this because Lubuntu 16.04 users on PowerPC or Lubuntu users on the Raspberry Pi 3* will not have an up-to-date Firefox (see: security issues). From the point of view of Lubuntu Release Manager, I don't like that option. I don't personally know enough about Firefox (otherwise we'd have ALSA support) to help with this, but I would if I could (maybe I can look more as to what's involved). But I think I can speak for the many users of Lubuntu on PowerPC (16.04) and the Pi 3 when I say that this really should not be an option. Even if it's not me, I really really hope someone will step up to help with this. If anyone wants statistics, I can gather some. *Ubuntu MATE ships PowerPC 16.04 images and Raspberry Pi 3 images as well. -- Simon Quigley tsimo...@lubuntu.me tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: linting wrapper for dput
Hey Michael, > If, like me, you spend time preparing uploads for ppas, the ubuntu > development release, SRUs and/or debian, sometimes you no doubt screw up > and upload a package without ~ppa1 to your ppa or upload a package with > version X.Y~17.04 to xenial (at least, I do this sort of thing quite a > lot). I've written a wrapper around dput that checks for many of these > mistakes before invoking real dput: > > https://gist.github.com/mwhudson/616499edb1191bd99c987bbbd8781ce9 > > (it also checks that for SRU bugs the listed bugs have open tasks for > the appropriate distro / source packages). Amazing, this will be really useful. Thank you! > I've only been using this for a couple of days but I hope it's going to > save me a bunch of time, maybe it will for you too :) I wonder if there's a way to bake this into dput officially (i.e. running these checks and giving an option to override if necessary). Maybe file a bug in Debian? -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386
Greetings, Let's also factor in flavors like Lubuntu that aim to use very minimal resources and that have the ability to run with ~ 300 MB of RAM on an i386 machine. While I understand modern applications are removing i386 support, we have a nice application base for Lubuntu for both LXDE and LXQt that provides a minimal but yet functional desktop environment and we have people to maintain these applications. So I'm sort of going with what Mark is saying. Please also factor this in the discussion. -- Simon Quigley tsimo...@ubuntu.com tsimonq2 on Freenode -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
