Re: QT6 Package Requests
On Sat, Jan 20, 2024 at 09:17:35AM -0800, Peter Willis wrote: > Hello, > Some parts of QT6 appear to be missing from the package under 22.04. > Notably the following: > QTextToSpeech > QBluetooth.. > QGeoRoute > Qt6::Location > Qt6::Position I'm sorry, but Ubuntu 22.04 LTS is a stable release and for the most part we do not introduce new packages into the distribution after it is released. There are some exceptions, but it's unlikely that a set of Qt6 library components would see such an exception. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?
Having seen no objections to the proposal, I have filed an RT to have the ubuntu-motu mailing list address redirected to ubuntu-devel-discuss. On Wed, Oct 18, 2023 at 09:26:29PM -0700, Erich Eickmeyer wrote: > With my IRC op team hat on: let's be careful about the IRC channels which > are ultimately goverened by the IRC council (i.e. not a Canonical decision > except for what the IRC council has delegated to certain devel teams). While > I would be in favor of closing #ubuntu-motu and forwarding to #ubuntu-devel, > #ubuntu-next is a support channel (not a devel channel) and the volunteer > support in #ubuntu and #ubuntu-next would not be too keen to lose that one. > But, again, that's a discussion to be had with the IRC council. What would be the process for asking #ubuntu-motu to be closed/redirected? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: ubuntu (apt) specific bug in package xmobar
On Tue, Oct 24, 2023 at 03:18:37PM +, bja...@vivaldi.com wrote: > Greetings > It would seem ReCaptcha wants me to single handedly retrain their image > recognition AI before I can confirm my E-mail to be able to file this > through your bugreporting system. > The xmobar package is broken, it is missing the libraries in order to > compile .hs configurations for xmobar, and it appears to be reading the > files incorrectly. > Once I have a ~/.xmobar/xmobar.hs file and run "xmobar" I get the following > error: > Steps to reproduce: > sudo apt install xmobar > mkdir ~/.xmobar > #just get any xmobar.hs configuration file, this was the first I found > online. > wget https://raw.githubusercontent.com/Vonr/xmobar/master/xmobar.hs > xmobar I don't know anything about xmobar, but based on the above commands you've run, I would not expect it to work because you have not downloaded xmobar.sh to ~/.xmobar, you have downloaded it to ~/ - this is constistent with the error message you get: > Error detected while loading xmobar configuration file: > /home/bjarki/.xmobar/xmobar.hs > ghc: no input files On Ubuntu 23.10, xmobar seems to be missing a dependency on ghc, so I had to install it manually; and then after installing it, the config file you point at fails with: Error detected while loading xmobar configuration file: /tmp/xmobar/.xmobar/xmobar.hs xmobar.hs:1:1: error: Could not find module `Xmobar' Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 1 | import Xmobar | ^ There is no file shipped anywhere in Ubuntu 23.10 matching the string 'Xmobar'. I don't know what the expectations here are, but you're going to want to talk to the upstream of xmobar, or at least the Debian maintainer, because no one in Ubuntu works directly on this package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: nodejs version eof
On Mon, Oct 16, 2023 at 04:14:53PM +, Mathew Subin wrote: > Hi > > Why is the official version of nodejs hosted on the Ubuntu Jammy LTS > version 12. It has been end of life for a quite a number of months now. "LTS" (long-term supported) means the software that is shipped as part of the Ubuntu release is supported for the lifetime of the release. If you have differing requirements for other software, you are free to install it on top of Ubuntu; but that is not part of the operating system that we've released. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Merge ubuntu-motu@lists into ubuntu-devel-discuss@lists?
Hi folks, There is a mailing list, ubuntu-motu@lists.ubuntu.com, that sees very little activity. While MOTU as a concept still exists for those who are approved uploaders to universe but not main (https://launchpad.net/~motu), it's been quite some time that this list is not being used for discussions within that subcommunity of developers. Indeed, I think most MOTU are probably not tracking the list at all, and a look at the message history over the past 6 months shows the only threads started on there are from users asking for help with one universe package or another. It's not clear to me how users are finding this as a contact address, but it's not a good experience for them; the list is infrequently moderated (I have the impression that it's less frequently than ubuntu-devel*), and there are only a handful of developers who answer on the list (myself, Robie, maybe a few others?). I'd therefore like to propose we close this mailing list and forward the address on to ubuntu-devel-disc...@lists.ubuntu.com, which at least has a larger subscriber base and is more likely to result in users getting help with their questions. Opinions? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Broken package `yggdrasil` (0.4.7-1) [universe]
On Sun, Jun 04, 2023 at 07:22:03PM +0800, Александр Иванов wrote: > Hi, looks like you fucked up some package installation for all Ubuntu-based > distribution users. > Yggdrasil project already has proper instructions on how to build binaries > from source and has own maintained repository with instructions of > installation at > https://yggdrasil-network.github.io/installation-linux-deb.html > But looks like someone ignored that and pushed non-tested package with > version *0.4.7-1* instead of latest *0.4.7*, so it overrides official > package and after update installation users will have a surprise in logs > with errors such as "panic: open /etc/yggdrasil/yggdrasil.conf: no such file > or directory" (config file supposed to be at /etc/yggdrasil.conf) and "Admin > socket failed to listen: listen unix /var/run/yggdrasil.sock: bind: > read-only file system" (how did you manage to do that?) The vast majority of packages in universe are copied, unmodified and unreviewed, from Debian, in the hopes that they will be useful to Ubuntu users. If there are severe functional issues with the yggdrasil package, they have not been reported either to the Debian maintainer at https://bugs.debian.org/src:yggdrasil, or in Ubuntu at https://bugs.launchpad.net/ubuntu/+source/yggdrasil using the 'ubuntu-bug' command. Nothing in the packaging of yggdrasil 0.4.7-1 changes the path of either the config file or the Unix socket from the upstream defaults. You are free to use upstream binary packages if they are more to your liking. Such packages are not endorsed by Ubuntu or supported by the Ubuntu community. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-ir sponsorship
On Thu, Apr 13, 2023 at 07:37:27AM +0330, A. Shafiei wrote:
> Hello,
> Could anyone please review this package and possibly sponsor it?
> https://code.launchpad.net/~farsi-fonts/+git/fonts-ir
> Thanks in advance,
> A. Shafiei
debian/files should not be committed to your VCS, this is a file generated
as part of a package build.
The package also fails to build from source because README.md contains a
diff vs the upstream tarball. ('sponsored' vs 'sponsered')
lintian also complains about:
W: fonts-ir: extended-description-line-too-long line 1
Please wrap your paragraphs at < 78 chars.
Everything else looks good. Please fix the above and I will sponsor.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-irannastaliq
Thanks for the fixes. The package looks good. Please note the following lintian notice: I: fonts-irannastaliq source: out-of-date-standards-version 4.4.1 (released 2019-09-29) (current is 4.6.2) This is minor and does not block the inclusion of the package. I have sponsored the package and accepted it from the NEW queue for lunar. Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org On Tue, Apr 11, 2023 at 08:25:18PM +0330, A. Shafiei wrote: > Hello, > Thanks for your response. > > Where is the original source for this package? Is > > > > http://gitlab.flossir.org/farsi-fonts/irannastaliq/-/archive/1.5/irannastaliq-1.5.tar.gz > > the correct artifact? > > > > We have changed the path of the original source for this package: > http://gitlab.flossir.org/farsi-fonts/fonts-irannastaliq/-/archive/1.5/fonts-irannastaliq-1.5.tar.gz > > The version field in this file must be the version of the watch file format > > you are using, it is NOT an upstream version number. Please correct this > > for sponsorship. > > > > I have changed the version field in debian/watch. > Thanks. > > > On Tue, Apr 11, 2023 at 9:01 AM Steve Langasek > wrote: > > > Hello, > > > > > > > Where is the original source for this package? Is > > > > http://gitlab.flossir.org/farsi-fonts/irannastaliq/-/archive/1.5/irannastaliq-1.5.tar.gz > > the correct artifact? > > > > > > > Also, your debian/watch file appears to be broken: > > > > $ uscan > > uscan warn: debian/watch is an obsolete version 1 watch file; > >please upgrade to a higher version > >(see uscan(1) for details). > > uscan warn: debian/watch is an obsolete version 1 watch file; > >please upgrade to a higher version > >(see uscan(1) for details). > > uscan warn: there appears to be a version 2 format line in > > the version 1 watch file debian/watch; > > Have you forgotten a 'version=2' line at the start, perhaps? > > Skipping the line: version=1.5 > > uscan warn: there appears to be a version 2 format line in > > the version 1 watch file debian/watch; > > Have you forgotten a 'version=2' line at the start, perhaps? > > $ > > > > > > > The version field in this file must be the version of the watch file format > > you are using, it is NOT an upstream version number. Please correct this > > for sponsorship. > > > > > > > On Sat, Apr 08, 2023 at 02:58:26PM +0330, A. Shafiei wrote: > > > Hello, > > > Could anyone please review this package and possibly sponsor it? > > > https://code.launchpad.net/~farsi-fonts/+git/fonts-irannastaliq < > > https://deref-gmx.com/mail/client/V1d-p0HGpVo/dereferrer/?redirectUrl=https%3A%2F%2Fcode.launchpad.net%2F%7Efarsi-fonts%2F%2Bgit%2Ffonts-irannastaliq > > > > > > Thanks in advance, > > > A. Shafiei > > > > > -- > > > Ubuntu-motu mailing list > > > Ubuntu-motu@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > > > > > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > > signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-irannastaliq
Hello, Where is the original source for this package? Is http://gitlab.flossir.org/farsi-fonts/irannastaliq/-/archive/1.5/irannastaliq-1.5.tar.gz the correct artifact? Also, your debian/watch file appears to be broken: $ uscan uscan warn: debian/watch is an obsolete version 1 watch file; please upgrade to a higher version (see uscan(1) for details). uscan warn: debian/watch is an obsolete version 1 watch file; please upgrade to a higher version (see uscan(1) for details). uscan warn: there appears to be a version 2 format line in the version 1 watch file debian/watch; Have you forgotten a 'version=2' line at the start, perhaps? Skipping the line: version=1.5 uscan warn: there appears to be a version 2 format line in the version 1 watch file debian/watch; Have you forgotten a 'version=2' line at the start, perhaps? $ The version field in this file must be the version of the watch file format you are using, it is NOT an upstream version number. Please correct this for sponsorship. On Sat, Apr 08, 2023 at 02:58:26PM +0330, A. Shafiei wrote: > Hello, > Could anyone please review this package and possibly sponsor it? > https://code.launchpad.net/~farsi-fonts/+git/fonts-irannastaliq > <https://deref-gmx.com/mail/client/V1d-p0HGpVo/dereferrer/?redirectUrl=https%3A%2F%2Fcode.launchpad.net%2F%7Efarsi-fonts%2F%2Bgit%2Ffonts-irannastaliq> > Thanks in advance, > A. Shafiei > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: QtPy is now 2.3.1
On Wed, Apr 05, 2023 at 04:09:13PM +0300, Anton Yablokov wrote: > Dear maintainers, > Is there any way to update python3-qtpy to 2.3.1, as the version was > released <https://github.com/spyder-ide/qtpy/releases/tag/v2.3.1> last > week? You have countless packages to maintain, and I can't expect an > instant update. > Or should ask Debian Python Team instead? Lunar is now in release freeze, so this is not a priority for updating for inclusion in 23.04; we are focused on fixing high-priority bugs instead. We normally take updates from Debian, so you could contact them and request an update, but Debian is also in release freeze at this time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Asciio package
On Tue, Feb 28, 2023 at 10:40:26PM +0100, nadim khemir wrote: > Hi, I've send a mail to whom I believe to be the maintainer but I'm > not sure. Is there a debian group email, where I could contact them, > that you know about? It wouldn't be useful to email Debian developers as a whole about it. If the previous maintainer doesn't respond, the other thing you can do is file a 'Request for Package' bug https://www.debian.org/devel/wnpp/requested using the Debian bug tracker. https://www.debian.org/Bugs/ > On Tue, Feb 28, 2023 at 10:21 PM Steve Langasek > wrote: > > > > On Mon, Feb 27, 2023 at 01:54:24PM +0100, nadim khemir wrote: > > > Hi, are you still a package maintainer for ubuntu? > > > > The ubuntu-motu team is collectively the maintainer of all the packages in > > Ubuntu universe. > > > > > Asciio has received a massive upgrade and it would be great to see a > > > package for it > > > > The asciio package that was shipped in Ubuntu was always copied unchanged > > from Debian. It was removed from Ubuntu when it was removed from Debian, > > as described at <https://bugs.debian.org/968843>. > > > > It is unlikely that anyone will package this independently for Ubuntu and > > commit to maintain it. You could contact the previous Debian maintainer to > > see if they are interested in maintaining the new upstream version. > > > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Asciio package
On Mon, Feb 27, 2023 at 01:54:24PM +0100, nadim khemir wrote: > Hi, are you still a package maintainer for ubuntu? The ubuntu-motu team is collectively the maintainer of all the packages in Ubuntu universe. > Asciio has received a massive upgrade and it would be great to see a > package for it The asciio package that was shipped in Ubuntu was always copied unchanged from Debian. It was removed from Ubuntu when it was removed from Debian, as described at <https://bugs.debian.org/968843>. It is unlikely that anyone will package this independently for Ubuntu and commit to maintain it. You could contact the previous Debian maintainer to see if they are interested in maintaining the new upstream version. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Ubuntu 22.04 LTS support
On Thu, Feb 02, 2023 at 07:24:58AM +, alfredo.nodo wrote: > Hi, > I see here that you are the maintainer of the package hddtemp > https://packages.ubuntu.com/focal/hddtemp > Are you planning to port it to Ubuntu 22.04 LTS? > Thank you The hddtemp package was removed from Debian prior to the Ubuntu 22.04 release for the reasons given at https://bugs.debian.org/1002484. Unless there are specific reasons to the contrary, Ubuntu follows Debian on package removals. There are no plans to reintroduce this package in 22.04 or any later release as it is considered obsolete. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Old godot3 package
Hello, On Sun, Jan 22, 2023 at 05:36:41PM +0700, GREAT DNG wrote: > Hello. > Please update the /godot3/ package in the /jammy/ repository, it is out of > date. Installing from /snap/ is not an solution, it is too resource > intensive. Our Stable Release Update policy is described here: https://wiki.ubuntu.com/StableReleaseUpdates You are unlikely to find anyone on this mailing list who is willing to do the work to update godot3 in jammy, given that this is a package synced from Debian (so, no one in Ubuntu with specific expertise) and there is not even a newer version available currently in the devel series, lunar. There is also the backports pocket: https://wiki.ubuntu.com/UbuntuBackports But this also depends on there being an updated package available in later series. Why do you say that the godot snap is more resource-intensive? Anyway, the snap as it exists today seems to be at an earlier version than the deb that ships in jammy (3.1 vs 3.2.3). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Updating vim-ale package
Hello, On Tue, Jan 03, 2023 at 03:25:56PM +, w0rp wrote: > I don't know if I can email this list or not. I just found the email address > on a website. I'm just writing to inform whoever is maintaining the vim-ale > package that there are newer versions of ALE available, and they should work > with older systems just as well as the current vim-ale package version. See > here: https://github.com/dense-analysis/ale/releases/tag/v3.3.0 > The version I can see for Jammy is 3.1.0. > https://packages.ubuntu.com/cs/jammy/editors/vim-ale Our policy and procedure for updating packages in stable releases is documented here: https://wiki.ubuntu.com/StableReleaseUpdates It is unlikely that a new version of vim-ale would meet the requirements for an SRU. However, if you think such an update is important for Ubuntu users, that's the place to start. (As far as who maintains vim-ale: this package is synced from Debian and does not have an Ubuntu maintainer.) Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: LibGeos for Ubuntu 22.04 breaks code / improperly configured?
On Thu, Dec 08, 2022 at 08:25:18AM +0100, Basile Czajkowski wrote: > Hello, > I am writing to You with a question about libgeos package available for > Ubuntu 22.04. > Currently apt install provides system with version 3.10.2 of libgeos. > However this breaks code that worked previously with libgeos 3.8.0 > As described in this issue : > https://github.com/libgeos/geos/issues/760 > It seems that building libgeos from source solves the issue even though > source for required classes has not changed. Given the extensive > configuration of package could it be possible that available package in > Ubuntu repository would break code? This is <https://bugs.launchpad.net/ubuntu/+source/geos/+bug/1980147>. > If so, when would the updated version of libgeos (3.11.1) appear in Ubuntu > repository? That version is already present in lunar which will be released as Ubuntu 23.04. It will not be included in Ubuntu 22.04 (but nothing about that bug requires an update to 3.11.1). Fixing this bug requires someone to do the work of preparing a Stable Release Update https://wiki.ubuntu.com/StableReleaseUpdates This is a package in universe that is in sync from Debian. It is unlikely that this issue will end up being prioritized by an Ubuntu developer for upload. If you are using libgeos in a project of your own outside of Ubuntu, given this bug I would suggest you take it from upstream rather than depending on the system version of the library, which is present largely for supporting other application software (and language bindings) that Ubuntu ships. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Debian package shasta: source location moved
Thanks for the information. For reference, Ubuntu pulls shasta from Debian rather than upstream directly, so as long as you've also informed the Debian maintainer, Ubuntu should have no problems! On Thu, Dec 08, 2022 at 10:32:46AM -0800, Paolo Carnevali wrote: > I am the main developer of the source code for Debian package shasta. > I wanted to let you that the original GitHub repository > <https://github.com/chanzuckerberg/shasta> containing Shasta source code > has been phased out and Shasta development is continuing on this new > repository: > > https://github.com/paoloshasta/shasta > > Please use this new repository for future releases. > > I will continue Shasta development as GitHub user paoloshasta (email > address pacar...@ucsc.edu, copied here). I will lose my current email > address pa...@chanzuckerberg.com and I will no longer use my > paoloczi GitHub account. > > Thank you for including Shasta as a Debian repository. Your work on that is > highly appreciated. > > Paolo Carnevali > Chan Zuckerberg Initiative (until 12/31/2022) > University of California at Santa Cruz, Genomics Institute > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Frescobaldi package broken in Jammy
On Tue, Nov 22, 2022 at 06:56:21PM +0100, Jean Abou Samra wrote: > Le 18/11/2022 à 21:25, Steve Langasek a écrit : > > On Sun, Nov 06, 2022 at 01:03:02PM +0100, Jean Abou Samra wrote: > > > Le 25/10/2022 à 07:50, Steve Langasek a écrit : > > > > This doesn't obviously fix the problem of the missing dependency. I > > > > will > > > > check with the rest of the SRU team how they would want this handled. > > > Any update on this? > > The packages have been uploaded now and are awaiting review by an(other) SRU > > Team member. > > > > https://launchpad.net/ubuntu/jammy/+queue?queue_state=0_text=python-qpageview > > > > https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=frescobaldi > Thank you for doing this. Please let me know when the review step is > completed. If you are subscribed to the launchpad bugs, you'll be able to track the progress there. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Frescobaldi package broken in Jammy
On Sun, Nov 06, 2022 at 01:03:02PM +0100, Jean Abou Samra wrote: > Le 25/10/2022 à 07:50, Steve Langasek a écrit : > > This doesn't obviously fix the problem of the missing dependency. I will > > check with the rest of the SRU team how they would want this handled. > Any update on this? The packages have been uploaded now and are awaiting review by an(other) SRU Team member. https://launchpad.net/ubuntu/jammy/+queue?queue_state=0_text=python-qpageview https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=frescobaldi Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: mender-client package outdated in kinetic
Hi Lluís, On Fri, Nov 11, 2022 at 07:44:37PM +0100, Lluís M. Campos Martínez wrote: > Hi Ubuntu MOTU Developers, > I am one of the uploaders of mender-client package in Debian [1] > I just realized that the package is still in version for 3.0.0 Ubuntu > Kinetic [2]. However, by the time of the Debian Import Freeze (August 25 > according to [3]), it should have been at least 3.3.0 in Debian unstable. > Is there anything wrong with this package that requires my attention? > I know it is too late for Kinetic, I just want to understand what is going > on before the next release :) I couldn't find any open bug in > bugs.launchpad.net or any other indication of QA issues in > packages.ubuntu.com Any guidance is appreciated. > [1] https://tracker.debian.org/pkg/mender-client > [2] https://packages.ubuntu.com/kinetic/mender-client > [3] https://discourse.ubuntu.com/t/kinetic-kudu-release-schedule/27263 https://launchpad.net/ubuntu/+source/mender-client/+publishinghistory shows that 3.3 was never picked up for sync. Looking at https://launchpad.net/debian/+source/mender-client/+publishinghistory shows why: 3.3.0+ds1-1 was uploaded to experimental, not to unstable; and 3.3.0+ds1-2 was not uploaded to unstable until October 14. Ubuntu syncs from unstable, not from experimental. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Frescobaldi package broken in Jammy
On Sun, Oct 23, 2022 at 01:59:01PM +0200, Jean Abou Samra wrote: > I would like to call for attention on these bugs: > https://bugs.launchpad.net/ubuntu/+source/frescobaldi/+bug/1993213 > https://bugs.launchpad.net/ubuntu/+source/frescobaldi/+bug/1983579 > https://bugs.launchpad.net/ubuntu/+source/frescobaldi/+bug/1991322 > In a nutshell, the Frescobaldi package (LilyPond music sheet editor) > is completely unusable on Ubuntu Jammy. The fix is to upgrade it to > Frescobaldi 3.2. > I hope it's OK I raise this here. I do this because this issue has a > bad impact on our community, and has received no visible attention > from Ubuntu maintainers since it was first reported 2 months and > a half ago. In a serendipitous coincidence, my son has just started piano lessons and so I find myself using lilypond for the first time in years. I wasn't trying to use frescobaldi - a text editor is enough for me - but it means I am in a position to confirm the bugs in question. On Mon, Oct 24, 2022 at 06:02:37AM -0700, Simon Chopin wrote: > We usually don't upload new upstream releases to stable series¹, but > rather cherry-pick specific fixes. This is implied by the SRU rules in > the "New upstream microreleases" section. > https://wiki.ubuntu.com/StableReleaseUpdates > This is particularly relevant in this case since the 3.2 version seems > to have picked up a whole new dependency which isn't even in the > archive. > The best way to ensure we fix this in Jammy is to point us towards the > specific commit(s) that address the problem at hand, or, even better, > prepare a debdiff with those patches to get the package sponsored. > ¹: Whole new upstream versions can still be backported when going > through the Backports process, see https://wiki.ubuntu.com/UbuntuBackports I am prepared to argue in this case that a full-upstream update in SRU would be appropriate on the grounds that the package is completely unusable and therefore the regression potential is nil, and has a better chance of correctness than cherry-picking individual commits and hoping we've caught all the type errors. This doesn't obviously fix the problem of the missing dependency. I will check with the rest of the SRU team how they would want this handled. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: bug in Solaar 1.1.5
Hi Peter, On Tue, Oct 11, 2022 at 05:45:33AM -0400, Peter F. Patel-Schneider wrote: > Hi: > I'm the maintainer of Solaar. It appears that Solaar for Ubuntu was > recently upgraded from version 1.1.1 to version 1.1.5. I have a report that > something went wrong when he ran Solaar 1.1.5 - > https://github.com/pwr-Solaar/Solaar/issues/1785 > I'm not sure why he ended up with an empty ~/.config/solaar/config.yaml > file. I don't see a path in the code that would make this file empty. I'm > going to patch the file to handle this issue though. Unfortunately, we are now 3 days away from the Ubuntu 22.10 release. It's unclear to me if any Ubuntu Developers will step up and have an opportunity to upload a fix to this for inclusion in the 22.10 release before then. (As a member of the Release Team, I personally would definitely not!) Given that you say it's unclear how this broken config file ever happened, unless there are more users reporting the same breakage we might just have to accept this defect for 22.10. If you think it's important enough to warrant a post-release update of the package, the Ubuntu process is here: https://wiki.ubuntu.com/StableReleaseUpdates -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fis-gtm_6.3-014-3_amd64.deb
Hi Paul, On Thu, Oct 06, 2022 at 01:44:16PM +0100, Paul Burden wrote: > Hi > I've installed this from the ubuntu repo, but the links to the documentation > don't work. I'm not clear how to set up the environment to get a mumps > environment active. I programmed in mumps during the 80's and early 90's and > would like to get back into it. > Can you please help with these links that are in > /usr/share/doc/fis-gtm/README.Debian? Contents look like :- > FIS GT.M for Debian > === > > Please note the Release Notes & Supplementary Information for the latest > versions here: > > http://tinco.pair.com/bhaskar/gtm/doc/articles/index.html > > For documentation please visit > > http://fis-gtm.com > > and click on the User Documentation tab. > > -- Andreas Tille Sun, 24 Nov 2013 09:26:25 +0100 > It's the tinco.pair.com and the http://fis-gtm.com that don't appear to > work. > Thank for your help ubuntu-motu is not a very effective contact for these kinds of questions. This package is synchronized from Debian, and it's unlikely anyone here has specific knowledge about this package. I suggest you contact the Debian maintainer - either Andreas whose email address is listed above, or the Debian Med Packaging Team . -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: How to setup and use "Runit" init-system on Ubuntu?
On Fri, Sep 23, 2022 at 03:31:57AM +0200, Paul Gerdes wrote: > Could someone give me information on how to set up and use Runit on Ubuntu > please? Or maybe some info on how to Install Ubuntu with Runit? > I couldn't find a Guide for Runit on Ubuntu. My OS is Jammy (22.04). > The Runit Packages are available in Ubuntu Repos. Together with > 'init-system-helpers'. > (https://packages.ubuntu.com/search?keywords=runit=names) > (https://packages.ubuntu.com/jammy/init-system-helpers) Use of runit as an init system is not supported on Ubuntu. You can install runit to supervise services that specifically integrate with it, but you cannot use it as PID 1. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Why is the JetBrains Mono typeface in Multiverse?
Hi Sebastian, On Mon, Sep 19, 2022 at 08:53:42PM +0100, Sebastian Crane wrote: > Greetings! I use the Jetbrains Mono typeface (package font-jetbrains-mono) > extensively. For Debian, it's in the main archive, but Ubuntu 22.04 has it in > Multiverse. I was under the impression that Multiverse was for proprietary > packages, so JetBrains Mono seems to be in the wrong place. > Please could someone enlighten me on the situation? Thank you! This package was initially published to the 'contrib' component in Debian, which means it was auto-synced to 'multiverse' as the corresponding component in Ubuntu. The maintainer appears to have fixed the reason for it being in contrib in the second upload of the package to Debian, but such changes are not propagated automatically on the Ubuntu side. I've moved it to universe now, which will take effect for kinetic onwards. The best way to get such issues addressed is to file a bug against the package in Launchpad (https://bugs.launchpad.net/ubuntu/+source/fonts-jetbrains-mono/+filebug), and subscribe the ubuntu-archive team to the bug. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-sahel
On Wed, Sep 07, 2022 at 02:56:01AM +0530, Utkarsh Gupta wrote: > I've sponsored the upload after making some trivial changes, which are > visible here: https://git.launchpad.net/~farsi-fonts/+git/fonts-sahel/log/ > These basically are: > - d/watch: I've simplified the regex so it's now very simple to read > and understand. Let me know if you have any questions. > - d/control: I've added the Vcs-* fields. For the record, while this is in no way a blocker for accepting the package, I consider it a bug to have an Ubuntu Vcs-Git field pointing to any repository that can't be directly committed to by everyone who has access to upload the package. In this case, that could be addressed by adding ubuntu-motu to the farsi-fonts team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-vazirmatn
On Fri, Sep 02, 2022 at 11:48:03PM +0430, A. Shafiei wrote: > Hello Steve, > > Thanks for the feedback. All issues you mentioned are addressed and all are > fixed. > I added the debian/watch. I get a warning and I do not know why. The warning is because your download URL is http, which is insecure against man-in-the-middle attacks. Running 'uscan' gives output showing you are redirected to https, so it seems using an https url is possible. But this is only a warning and not a blocker for inclusion in Ubuntu. > I also changed the upstream-contact in copyright to the author of the font. > Could you please review the package? > https://code.launchpad.net/~farsi-fonts/+junk/fonts-vazirmatn > <https://deref-gmx.com/mail/client/RRy7eofpEnU/dereferrer/?redirectUrl=https%3A%2F%2Fcode.launchpad.net%2F%7Efarsi-fonts%2F%2Bjunk%2Ffonts-vazirmatn> > Sure, I will be happy if you could sponsor this package. > Thanks in advance. Thanks, I have sponsored the package now and it has been accepted into kinetic-proposed. Note that debian/changelog of your bzr branch showed it was targeting focal with the upload, so I had to change this. > On Fri, Sep 2, 2022 at 8:27 PM Steve Langasek > wrote: > > > Hi Shafiei, > > > > Some feedback: > > > > - please create a debian/watch file that says where to get (updates to) the > > upstream source. I was able to work out where to find the upstream > > tarball by looking at debian/copyright, but ideally this would be much > > more automatic. (debian/watch file syntax is documented in the uscan(1) > > manpage, but it is non-trivial; > > https://lists.debian.org/debian-mentors/2022/04/msg00052.html might be a > > useful starting point.) > > - "Description" in debian control is malformatted. The description field > > consists of a single-line short description (should fit under 72 > > characters) followed by an indented paragraph for the long description. > > The way you have this formatted currently, is a 700-character short > > description which will break display. (Running the lintian command over > > your built package would catch this error.) > > - you have the package marked as Architecture: any, but this means the > > package is built separately for each architecture - you do not have any > > architecture-specific contents here so the package should be > > Architecture: all > > - debian/copyright declares > > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ but > > does not follow the format. Your License: field should consist of a > > single one-word name for the license, followed by indented paragraphs. > > Continuation across multiple paragraphs should be encoded as ' .', not as > > a blank line. According to https://spdx.org/licenses/ the preferred > > short > > name for the license used here is OFL-1.1. > > - you list yourself as the upstream contact in debian/copyright but it is > > not clear to me why. You are not listed in the upstream AUTHORS.txt and > > https://gitlab.flossir.org/rshf who maintains the git repository is not > > obviously you. > > - font packages should be declared 'Multi-Arch: foreign' for maximum > > compatibility. (This issue was also identified by lintian.) > > > > If you address the above issues in the packaging, I am happy to sponsor > > this > > package into the Ubuntu archive for the upcoming kinetic release. > > > > > > > > > > On Fri, Aug 26, 2022 at 10:56:10AM +0430, A. Shafiei wrote: > > > Hello everyone, > > > > > > There are a number of fonts for Persian language which I am trying to > > > package. The first one is the Vazirmatn font. > > > > > > I would like to know if anyone could please review this package: > > > > > > https://code.launchpad.net/~farsi-fonts/+junk/fonts-vazirmatn > > > > > > https://launchpad.net/~farsi-fonts/+archive/ubuntu/farsi-fonts/+packages > > > > > > Thanks in advance. > > > Shafiei > > > > > -- > > > Ubuntu-motu mailing list > > > Ubuntu-motu@lists.ubuntu.com > > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu > > > > > > -- > > Steve Langasek Give me a lever long enough and a Free OS > > Debian Developer to set it on, and I can move the world. > > Ubuntu Developer https://www.debian.org/ > > slanga...@ubuntu.com vor...@debian.org > > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-vazirmatn
Hi Shafiei, Some feedback: - please create a debian/watch file that says where to get (updates to) the upstream source. I was able to work out where to find the upstream tarball by looking at debian/copyright, but ideally this would be much more automatic. (debian/watch file syntax is documented in the uscan(1) manpage, but it is non-trivial; https://lists.debian.org/debian-mentors/2022/04/msg00052.html might be a useful starting point.) - "Description" in debian control is malformatted. The description field consists of a single-line short description (should fit under 72 characters) followed by an indented paragraph for the long description. The way you have this formatted currently, is a 700-character short description which will break display. (Running the lintian command over your built package would catch this error.) - you have the package marked as Architecture: any, but this means the package is built separately for each architecture - you do not have any architecture-specific contents here so the package should be Architecture: all - debian/copyright declares https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ but does not follow the format. Your License: field should consist of a single one-word name for the license, followed by indented paragraphs. Continuation across multiple paragraphs should be encoded as ' .', not as a blank line. According to https://spdx.org/licenses/ the preferred short name for the license used here is OFL-1.1. - you list yourself as the upstream contact in debian/copyright but it is not clear to me why. You are not listed in the upstream AUTHORS.txt and https://gitlab.flossir.org/rshf who maintains the git repository is not obviously you. - font packages should be declared 'Multi-Arch: foreign' for maximum compatibility. (This issue was also identified by lintian.) If you address the above issues in the packaging, I am happy to sponsor this package into the Ubuntu archive for the upcoming kinetic release. On Fri, Aug 26, 2022 at 10:56:10AM +0430, A. Shafiei wrote: > Hello everyone, > > There are a number of fonts for Persian language which I am trying to > package. The first one is the Vazirmatn font. > > I would like to know if anyone could please review this package: > > https://code.launchpad.net/~farsi-fonts/+junk/fonts-vazirmatn > > https://launchpad.net/~farsi-fonts/+archive/ubuntu/farsi-fonts/+packages > > Thanks in advance. > Shafiei > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-yas
Hi,
Thanks for your interest in contributing to Ubuntu and improving Persian
support for our users!
I notice the branch in question is a bzr branch. Most Ubuntu code nowadays
is maintained in git, or does not use a version control system. Was there a
particular reason you put this into bzr? (If you were following some Ubuntu
documentation, for example, I would like to know which documentation, so we
can improve it.)
Your package uses what's referred to as a "non-native" version number, where
there is an upstream part ("4.0") and a Debian revision ("1"). Three points
on this:
- This means the package should include an upstream tarball. Is an upstream
tarball available somewhere for these fonts? I've checked
https://gitlab.flossir.org/farsi-fonts/yas/-/releases and don't see any.
There are references to 'irmug.org' in the source but this doesn't appear
to be a current domain for anything related.
- If there is an upstream tarball, then debian/watch should exist and tell
where to find it.
- The Debian revision for an Ubuntu package should be -0ubuntu1, rather than
1.
I could give other feedback about the packaging, but these are probably the
points to address first.
Also, if you don't have a specific reason to use bzr, it is probably going
to be easier to review a package if you build it and upload it to a PPA:
https://help.launchpad.net/Packaging/PPA
On Fri, Aug 19, 2022 at 11:35:56PM +0430, A. Shafiei wrote:
> Hello everyone,
>
> There are a number of fonts for Persian language which I am trying to
> package. The first one is the Yas font.
>
> I would like to know if anyone could please review this package:
> https://code.launchpad.net/~r-shf/+junk/fonts-yas
>
> Thanks in advance.
> A. Shafiei
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Help with NIS on ubuntu 22.04
Hi Michael, On Fri, Aug 12, 2022 at 09:48:51AM +, Michael Fitoussi wrote: > Hello > I've a docker image based FROM ubuntu:18.04 > At the end of the image, I've: > # Configure NIS > COPY yp.conf /etc/yp.conf > COPY nsswitch.conf /etc/nsswitch.conf > COPY default-nis /etc/default/nis > COPY common-session /etc/pam.d/common-session > RUN echo 'mobileye' > /etc/defaultdomain > RUN /etc/init.d/rpcbind restart > RUN /etc/init.d/nis restart > All is fine and I can see in the build output: > Step 53/55 : RUN /etc/init.d/nis restart > ---> Running in 0fe8684241e3 > * Stopping NIS services >...done. > * Starting NIS services > * binding to YP server... > * > * > * > * > * > * > * > * > * > * >...fail! >...done. > However, when migrating to FROM ubuntu:22.04, the /etc/init.d/nis doesn't > exists > I've tried to replace it with: > > * RUN /etc/init.d/ypxfrd restart > * RUN /etc/init.d/ypbind restart > * RUN /etc/init.d/ypbind reload > * ... > but nothing helped to have my tpclient binded to my ypserver > > Any help / external link / other will be greatly appreciated. > > Thanks a lot I'm sorry, but this is not a user support forum. You should probably refer to /usr/share/doc/nis/NEWS.Debian.gz in the 22.04 version of the nis package which explains what changes the Debian maintainer has made and how users are expected to configure/use the packages in the new version. Failing that, you can try asking on https://askubuntu.com. However, these packages are pass-through from Debian, not anything that is actively maintained by the Ubuntu community, so your mileage may vary as far as support is concerned. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Reporting Security Vulnerabilities - libaom0
Hi Christine, The best contact regarding security updates is secur...@ubuntu.com; adding them to Cc:. To see the status of a given CVE in Ubuntu, you can also use the website at https://ubuntu.com/security/cves On Fri, Jun 10, 2022 at 10:01:20AM +, Ruelo, Christine M. L. wrote: > Hello libaom0 Maintainers, > > Good day, We have used the libaom0 package and perform a security scan using > Palo Alto Network - Prisma Cloud and these vulnerabilities below are reported. > We would like to report it and let us know once the fix is available so we > can update accordingly. > > CVE-2020-36130 > CVE-2020-36131 > CVE-2020-36133 > CVE-2020-36135 > > Thank you > > Regards, > > [cid:image001.png@01D87CBC.A4D862D0] > I CHRISTINE MAE RUELO > I ATCP | Data + AI > I Global One Eastwood > I E: > christine.m.l.ru...@accenture.com<mailto:christine.m.l.ru...@accenture.com> > I M: +63 927 088 6796 > Accenture Confidential > PTO: > Holiday: > Training: > > > > > This message is for the designated recipient only and may contain privileged, > proprietary, or otherwise confidential information. If you have received it > in error, please notify the sender immediately and delete the original. Any > other use of the e-mail by you is prohibited. Where allowed by local law, > electronic communications with Accenture and its affiliates, including e-mail > and instant messaging (including content), may be scanned by our systems for > the purposes of information security and assessment of internal compliance > with Accenture policy. Your privacy is important to us. Accenture uses your > personal data only in compliance with data protection laws. For further > information on how Accenture processes your personal data, please see our > privacy statement at https://www.accenture.com/us-en/privacy-policy. > __ > > www.accenture.com -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: fonts-mathematica: Downloading fonts leads to 404
Hi David, On Wed, Apr 20, 2022 at 10:21:28AM +0200, David Haller wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > Dear maintainers, > the fonts-mathematica package is broken. The post-install script tries > to download > https://support.wolfram.com/data/uploads/2014/08/TrueType.zip which is > no longer available. > I'm using Ubuntu 21.10. The fonts-mathematica has been dropped from Ubuntu 22.04 LTS for exactly this reason: https://bugs.debian.org/994183 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Timeshift - Release for 15.04 Vivid Velvet
Hi Paul, Please note that the ubuntu-motu mailing list is for the Ubuntu MOTU team, which takes responsibility for packages in the Ubuntu universe repository. You are asking about a package from a ppa, which is not supported by the Ubuntu developers. Furthermore, you are asking for a package on Ubuntu 15.04. Ubuntu 15.04 reached end of life in February 2016, as anounced here: https://lists.ubuntu.com/archives/ubuntu-announce/2016-February/000204.html You are probably encountering an error trying to install from a ppa because the version of the SSL client libraries on your system have been out of support and not updated for 6 years, and are not compatible with current secure versions of the TLS protocol. I do not know why you say that you need this software in order to update to a supported version of Ubuntu. Since this is not an Ubuntu package, it is not part of our upgrade path. The recommended upgrade path is to make any necessary backups of your system, and then run 'update-manager' to begin the process of upgrading to a supported release. The supported upgrade path is Ubuntu 15.04 -> Ubuntu 15.10 (which has also reached end of life) -> Ubuntu 16.04 LTS (which has reached the end of standard support and only has security support via the ESM service) -> Ubuntu 18.04 LTS -> Ubuntu 20.04 LTS. On Sun, Jan 23, 2022 at 12:41:15PM -0800, Paul Romero wrote: > Dear Staff: > > I need a version of the timeshift utility for Ubuntu Linux version 15.04. > Currently, I cannot access or enable the the recommended repository which > is as follows. > > ppa:teejee2008/timeshift > > The diagnostics indicate there is an SSH certificate verification problem. > > Is there some way other than using apt-get by which I can download and > install > the utility package ? If so, please inform me about where I can obtain it > via ftp or sftp or > something similar ? > > This is important because I want to upgrade to a newer version of Ubuntu > Linux. > > Best Regards, > > > Paul Romero > > > -- > > > Paul Romero > --- > RCOM Communications Software > EMAIL: pa...@rcom-software.com > PHONE: (510)482-2769 Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Update Ubuntu packages
On Tue, Sep 14, 2021 at 12:02:03AM +0300, Nicholas Guriev wrote: > On Пн, 2021-09-13 at 08:35 -0700, Steve Langasek wrote: > > - Backports. These are available to all users of the stable release, but > > are opt-in; users must specifically choose to install the package from the > > backports repository, or by default they will see the older version that > > was available at the time of the stable release. You should be able to > > work directly with the Ubuntu Backports team to get a backport done (which > > has a baseline policy of: take the newer version of the package from the > > latest Ubuntu release, and publish it for the earlier release) without > > needing any sort of upload sponsorship by an Ubuntu Developer. > Nowadays backports are almost died in Ubuntu. For example, Ubuntu Focal > Backports offer only three(!) standalone software (Cockpit, Ibus-typing- > booster, and some closely related disk management utilities). > https://packages.ubuntu.com/focal-backports/allpackages > Too little benefits of using the repository. Please see the recent discussions about rebootstrapping the backports team. https://lists.ubuntu.com/archives/ubuntu-devel/2021-August/041587.html -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Update Ubuntu packages
Hi Chris, There are three channels available for updating software for Ubuntu users in stable releases. - Stable Release Updates. These are made available by default on stable releases; the policy for these updates is at https://wiki.ubuntu.com/StableReleaseUpdates and is quite strict. The only way that the package updates you describe might be acceptable as SRUs is if they qualified as "hardware enablement" updates, which would need to be discussed in greater depth to understand if that's the case. You would also need an Ubuntu Developer to drive the uploads of these packages for the SRU. - Backports. These are available to all users of the stable release, but are opt-in; users must specifically choose to install the package from the backports repository, or by default they will see the older version that was available at the time of the stable release. You should be able to work directly with the Ubuntu Backports team to get a backport done (which has a baseline policy of: take the newer version of the package from the latest Ubuntu release, and publish it for the earlier release) without needing any sort of upload sponsorship by an Ubuntu Developer. - Snaps. This is the supported solution for third-party application packages on top of Ubuntu. This option would enable you as an upstream to directly manage packages for your software and upload it to the Snap Store, without any Ubuntu Developer intermediaries required. It would require a committment on your part (or on the part of someone else involved in the upstream) to be responsible for the packaging and the updates to users. The packaging format is fairly straightforward, with limited packaging policy to trip you up: https://ubuntu.com/tutorials/create-your-first-snap#1-overview If this gives you a sense of which path you would want to pursue for this update, we can provide further guidance from there. On Thu, Sep 09, 2021 at 01:07:16PM +, Rorden, Chris wrote: > Hello > > The current LTS of Ubuntu includes ancient versions of my software (from > 2014 and 2018 respectively). These versions pre-date the release of new > formats like the Enhanced DICOM data generated by Siemens and GE MRI > scanners. Would it be possible to update these to match the Debian > packages? In general, my tools are updated each six months (Fall, Spring) > to keep pace with the latest features of GE, Philips, Siemens, UIH and > Mediso scanners. Is there any way we can make the releases on Ubuntu > match my own release cycle? > > See these packages: > https://packages.ubuntu.com/focal/science/mricron > https://packages.ubuntu.com/focal/science/dcm2niix > > Versus the Debian releases: > https://packages.debian.org/bullseye/mricron > https://packages.debian.org/source/bullseye/misc/dcm2niix > > > Thanks, > > Chris > > Prof. Chris Rorden, PhD > Endowed Chair of Neuroimaging > Director, McCausland Center for Brain Imaging > Department of Psychology > University of South Carolina > Columbia SC, 29208 > USA > ror...@mailbox.sc.ed<mailto:ror...@mailbox.sc.ed> > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu Regards, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: goaccess arm64 package for focal
Hi Andy, On Wed, Aug 19, 2020 at 10:54:31AM -0400, Andy Forceno wrote: > I recently installed the package goaccess for arm64 using apt-get, which > worked without a problem. I noticed today when I run apt-get update, I'm > seeing this error: > N: Skipping acquire of configured file 'main/binary-arm64/Packages' as > repository 'https://deb.goaccess.io focal InRelease' doesn't support > architecture 'arm64' > This is strange because according to the package repo, that package does > exist (unless I'm misunderstanding something): > https://packages.ubuntu.com/focal/arm64/goaccess/download This is referring to a third-party repository, https://deb.goaccess.io, and not to the goaccess package in the Ubuntu repository. Did you manually configure this third-party repository at some point? I see no evidence that the goaccess package is setting this up for you (which would be a serious bug if it were). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: KeePassXC package is outdated in Ubuntu Universe repo
On Tue, Jun 23, 2020 at 12:33:57PM +0500, a wrote: > https://github.com/keepassxreboot/keepassxc/releases/tag/2.5.4 > Current version is 2.5.4 from 9th of April 2020. > Universe has 2.4.3 from 12th of June 2019. > Please update it. Thanks for contacting us about this. The Stable Release Update policy for packages in universe precludes wholesale updates to new upstream releases, except in select circumstances. https://wiki.ubuntu.com/StableReleaseUpdates The Ubuntu development release, groovy, has keepassxc 2.6.0~beta1 already. So there doesn't appear to be anything to do with respect to the Ubuntu archive. keepassxc 2.5.4 is also available as a snap, which can be installed with 'snap install keepassxc'. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Cannot install wine32 on focal
On Tue, Apr 14, 2020 at 02:18:30PM +0200, Jan van der Vyver wrote: > Hi > I get the following error when trying to install wine32 > The following packages have unmet dependencies: > libgd3 : Breaks: libgd3:i386 (!= 2.2.5-5.2ubuntu0.19.10.1) but 2.2.5-5.2 is > to be installed > libgd3:i386 : Breaks: libgd3 (!= 2.2.5-5.2) but 2.2.5-5.2ubuntu0.19.10.1 is > installed You evidently have a system that is not fully upgraded to focal. The version of libgd3 in focal, on all architectures, is 2.2.5-5.2ubuntu2. 2.2.5-5.2ubuntu0.19.10.1 is the version from eoan-security. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: ROOT packages not found on bionic
On Sat, Dec 29, 2018 at 11:34:23PM +0100, Angelo Graziosi wrote: > It seems that upgrading from Mint 18 (xenial) to 19 (bionic) one loses > ROOT packages (root-system). Does that mean than from bionic onwards one > has to build ROOT directly from CERN sources? > May you confirm? WHY this occurred? Just out of curiosity... This Ubuntu package was synced from Debian, and was removed from the Debian repositories in 2016 (https://bugs.debian.org/827248). It was subsequently removed from Ubuntu as well, following suit, because we do not keep packages in Ubuntu that have no maintainer. (https://launchpad.net/ubuntu/+source/root-system/+publishinghistory) I don't have any specific knowledge of this software so I can't say what the best solution is for users who have need of it. In principle it would be possible for someone (perhaps upstream) to provide a snap package which would be installable on Ubuntu 18.04. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Openconnect and old gnutls on Ubuntu 14.04
Hi Dave, On Fri, Jul 20, 2018 at 09:54:35AM -0700, Dave Hansen wrote: > TL;DR: openconnect on Ubuntu 14.04 fails to connect to Intel VPN servers > that blacklist TLS 1.0. Where should this get fixed? On the Ubuntu side, we would tend to defer to openconnect upstream regarding what the correct way is to fix this to minimize risk of regression. But provided we have that guidance, this is potentially appropriate to have fixed in Ubuntu 14.04 via the stable release update process: https://wiki.ubuntu.com/StableReleaseUpdates Generally speaking, packages which need to be updated in order to remain compatible with changes to protocols on the Internet at large (such as in this case, changes to the baseline TLS version that clients must negotiate in order to be considered secure) qualify for SRU. If this is going to enable compatibility with some server endpoints that have moved on for security reasons (such as the Intel VPN servers), but break compatibility with other still-extant server endpoints that don't support current security protocols (such as the F5 firewalls, if they're still out there and have this bug), we would want to think deeply about making such a choice given that affected users also have the option to upgrade to newer versions of Ubuntu without impacting users who rely on the less-secure-but-stable support for pre-TLS1.1 endpoints. At this point I would suggest opening a bug report against the package so this question can be weighed there. https://bugs.launchpad.net/ubuntu/+source/openconnect/+filebug > --- > I'm running a rather vintage Ubuntu 14.04 which ships a rather > unmodified openconnect 5.02 package. It uses the following as a > priority string for the TLS session: > > "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:" > "%COMPAT:%DISABLE_SAFE_RENEGOTIATION:%LATEST_RECORD_VERSION > > This _appears_ to be forcing things down to TLS 1.0 and not using TLS > 1.1/1.2 despite libgnutls26 supporting the later TLS protocols. I > confirmed the attempt to use TLS 1.0 in a packet capture. gnutls-cli, > using the same gnutls library was confirmed in a packet capture to be > using TLS 1.2. > > Intel has stopped supporting TLS 1.0 on its VPN endpoints, leaving me > unable to connect. The failure message that comes back out of the > console from openconnect is something along these lines: > > > SSL connection failure: A TLS packet with unexpected length was received. > > The packet capture shows a TCP RST packet coming back from the server to > trigger these messages. > > So, yes, this is a vintage distribution, but it's _supposed_ to be > supported, and it _can_ connect to these VPN servers if the > "-VERS-TLS-ALL" is removed from the openconnect priority string. > > Further, this code still seems to be around in openconnect, at least > when compiled against old versions of gnutls: > > https://github.com/openconnect/openconnect/blob/master/gnutls.c#L2202 > > Is this something Ubuntu can fix in their openconnect? Or is it > something we should also be fixing in the upstream openconnect? > > -- > Ubuntu-motu mailing list > Ubuntu-motu@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: avr-gcc: why such an outdated gcc?
On Thu, May 10, 2018 at 10:53:56PM -0700, Jeremy Elson wrote: > Hi! I develop AVR microcontroller code using Ubuntu. I just upgraded to > Bionic and noticed that the avr-gcc version is still gcc 5.4.0, which is > nearly three years old. I'm curious, is there a reason the AVR > cross-compiler is being held back, instead of using a more modern version > of gcc? The release notes to gcc indicate they're making improvements to > the AVR back-end fairly regularly. This package in Ubuntu is synced from Debian. You would want to talk to the Debian maintainer about this: Hakan Ardo <ha...@debian.org> -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Apr-scan has a segmentation fault
Hi Antti, On Mon, Apr 30, 2018 at 10:31:31PM +0300, Antti Savolainen wrote: > The default arp-scan package version 1.9 crashes on startup. Currently on > Xubuntu 17.10. It's apparently fixed in the later versions but the patch > should be cherry picked for this release. > Here's a dump in case you have use for it > (gdb) bt > #0 0xe940 in get_hardware_address (if_name=0x77dd44e0 > "enp0s31f6", > hw_address=0x7fffdcca "\225\367\377\177") at > link-packet-socket.c:127 > #1 0x65f5 in main (argc=1, argv=0x7fffdfd8) at > arp-scan.c:165 Given that the new 18.04 LTS release is now out, it is unlikely that this issue will receive much attention in an SRU. You might want to consider upgrading to 18.04 instead to resolve this issue for yourself. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Package ncbi-entrez-direct extremaly outdated
Hi Alan, On Tue, Apr 17, 2018 at 06:16:58PM +, Alan Daniel Weiss wrote: > Dear mantainers, > The package ncbi-entrez-direct is very outdated, will it receave any update > soon? > Is there any way I can help? I have some knowledge in debian packaging. > ftp://ftp.ncbi.nlm.nih.gov/entrez/entrezdirect/versions/ > The latest versions provide new tools, archive-pubmed is and example. The ncbi-entrez-direct package in Ubuntu is synced with Debian. I would suggest that you work with the Debian maintainers (cc:ed) in order to get this package updated. Note that new upstream versions of a package will not be added to stable releases of Ubuntu. Unfortunately the timing of this question is such that any update will miss inclusion in the Ubuntu 18.04 LTS release, but you may still find it useful to work with the Debian maintainers to prepare an updated package which you could then build in a launchpad ppa for use on Ubuntu. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: libttspico-utils source package not found
Hi John, On Mon, Dec 04, 2017 at 01:45:53PM -0500, John McCardle wrote: > I was searching for ways to make espeak's text-to-speech sound more natural > (postprocessing, I imagined), and instead came across pico2wave- a tool from > libttspico-utils. The audio it generates does sound more natural, and it > sounded a little familiar. Apparently it's the default voice for at least > some previous versions of android. > I was interested in getting the source, partly to see how such a small > program made such a decent voice, and also to see if this program phones > home to big G in any way. (It works with the wifi off, but why not look and > see?) > $ apt source libttspico-utils > Reading package lists... Done > Picking 'svox' as source package instead of 'libttspico-utils' > E: Unable to find a source package for svox 'apt source' uses the entries in your /etc/apt/sources.list to locate the sources, and you evidently don't have deb-src lines configured for multiverse. So even though your apt sees the binary package, it does not know how to get the source package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Bitcoin and Ubuntu
Hi Micha, On Fri, Dec 13, 2013 at 12:00:18AM +0200, Micha Bailey wrote: For these reasons and others, including the Bitcoin software in any stable, no-updates release is not a good thing for Ubuntu users nor for the bitcoin network as a whole. There is already a PPA, maintained by Matt Corallo, one of the core developers, and linked to from http://bitcoin.org/en/download. Said PPA provides both the Bitcoin software and the BDB 4.8 packages needed for wallet compatibility with the software on other platforms. Over at Debian, their Bitcoin Packaging Team has been maintaining the package, keeping it in the unstable branch (sid) only, where it is allowed to be updated with new releases of the software. It is not included in the stable repository (wheezy), nor in testing (jessie). If I understand correctly, Ubuntu doesn't have that kind of release. It is my opinion that, given Ubuntu's methods of managing its software, it would be better to not include Bitcoin in the Ubuntu repositories, unless exceptions to the policies could be made, allowing all supported Ubuntu versions to get the latest updates as they come down from upstream. As a first step, the Bitcoin software should be removed from Trusty's repositories, assuming no exception can be made. Ideally, it would also be removed from the older repositories (Precise, Quantal, Raring, Saucy) if it can't be updated, though I'm told that's significantly harder from the perspective of the standard workflows. Since this package is in unstable only, I agree that it should not be included in Ubuntu. I've removed the package from trusty now and blacklisted it so that future versions are not synced from Debian (https://bugs.launchpad.net/ubuntu/+source/bitcoin/+bug/1260602). Unfortunately, it is not feasible to remove the package from stable releases. If there are versions of the package in stable releases that are actively harmful, we could accept an SRU that disables the problematic parts on upgrade (with a suitable notice). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Thu, Feb 18, 2010 at 01:02:43PM +0100, Stefan Potyra wrote: Definitely makes sense. I don't have a strong preference over the exact procedure as well. How did ubuntu-release handle FFe's so far? I assume the worklist is the list of subscribed bugs? Yep, precisely. Do you also use the +nominations page? No, the conclusion a couple cycles back was that the +nominations list has a low S:N ratio, and anyway that feature doesn't add anything over the subscribed bugs list. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
Since there are no objections to the proposed diff, I've applied it now (plus Daniel's correction). I'll send out an announcement mail in the next day or so informing developers of the new procedure, then mass-migrate the motu-release bug subscriptions over to ubuntu-release. On Sun, Feb 28, 2010 at 12:35:26AM +0100, Stefan Potyra wrote: I think the attached diff for FreezeExceptionProcess reflects the emerging consensus. Are there any objections if I apply this to the wiki and send out an updated freeze process mail to u-d-a? no objection, but still got a few questions: 1) how are FFe's handled? I assume that one ACK from a member of ubuntu-release suffices, correct? Yes, that's the intent, consistent with my own feeling on the subject and the feedback from Scott. The wiki changes reflect this, I think, by removing all mentions of the two-vote requirement. 2) new packages: do we also just require one ACK there, or do we want two ACKs? Also, new packages was delegated from MOTU to motu-release (or rather motu-uvf which got renamed to motu-release later). Even later ubuntu-release was made a member of motu-release, acknowledging that ubuntu-release should always be able to decide for motu-release. Do we need a formal MOTU decision to transfer this responsibility? If so (please speak up if you anyone think that it's needed, otherwise I'll assume consensus), what is the current process to get this decision? Effectively, the ubuntu-release team and the motu-release team are now identical, so I don't think redelegation would be needed here. As for a two-ack requirement on new packages, I have no strong feeling here either, but I think a single ack from ubuntu-release should be sufficient as it is for other exceptions. The wiki page mentions that the packages still have to go through https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages. 3) Universe used to have a later deadline for final freeze, to get latest bug fixes in. Past the deadline we used -proposed to get very late fixes in, handing over the queue to -sru. I think this could prove worthwhile again. Maybe we should replace universe with unseeded packages and decide later on it? Yes, I agree that this probably needs to be s/universe/unseeded/. I don't see any explicit mention of this on the wiki page, so I think the details can be hashed out closer to the release. WRT delegations: I think between Riddell and myself Kubuntu is already well covered. In the past I was the server team delegate for Universe, but the only purpose that served was to obviate the double ack rule. Since we're getting rid of that rule, I think there's no need. I woulnd't let getting delegation sorted out stop announcing thins. delegations also served to have the people with best knowledge cover an FFe. Teams not mentioned yet were we had delegates are: * mythbuntu * mozilla team * ubuntustudio * xubuntu * desktop (gnome) * netbook * edubuntu I'm not yet 100% sure how delegates fit in with the motu-release and ubuntu-release merge. I for one am happy to see the delegation process continue, at least for packages in universe (not to be confused with unseeded packages - obviously a mythbuntu or xubuntu delegate only makes sense for seeded packages :). I was never involved in delegate selection or observing closely how well particular delegated decisions worked, so I'll defer to you guys regarding who you think the delegates should be. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Thu, Feb 18, 2010 at 03:52:49PM -0500, Scott Kitterman wrote: Regarding the team unification, is there an expectation that the two-vote approach will continue? I don't have a strong preference between the ubuntu-release and motu-release approaches, but I think it would be strange to be applying different procedures for different archive sections - or to different members of the team! - so we should probably pick one... I think it should go. IMO one of the main reasons to unify the teams is to simply the process for people trying to work through getting needed approvals. If we have two separate rule sets, we may as well keep it two teams (I'm not proposing we do this). I think the attached diff for FreezeExceptionProcess reflects the emerging consensus. Are there any objections if I apply this to the wiki and send out an updated freeze process mail to u-d-a? Are there any team delegations we want to have in place before sending out the announcement? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org --- tmpdCsjqP.moin.orig 2010-02-25 07:47:35.037545082 -0800 +++ tmpdCsjqP.moin 2010-02-25 07:58:00.317544338 -0800 @@ -139,7 +139,7 @@ == General Instructions == -Requests for freeze exceptions for `main` should be filed as bugs in launchpad against the relevant package (or just Ubuntu if the package is not available yet). Once the bug is filed and the necessary information is available, subscribe [[https://launchpad.net/~ubuntu-release|ubuntu-release]] (main, restricted) or [[https://launchpad.net/~motu-release|motu-release]] (universe, multiverse). All freeze exceptions must include the following information, in order to provide them with enough information to weigh the risk of regressions against the benefit of the changes: +Requests for freeze exceptions should be filed as bugs in launchpad against the relevant package (or just Ubuntu if the package is not available yet). Once the bug is filed and the necessary information is available, subscribe [[https://launchpad.net/~ubuntu-release|ubuntu-release]]. All freeze exceptions must include the following information, in order to provide them with enough information to weigh the risk of regressions against the benefit of the changes: * A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution * A rationale for the exception, explaining the benefit of the change @@ -157,25 +157,6 @@ * installs and upgrades, * does not break packages which depend on it, or that corresponding updates have been prepared. -== UserInterfaceFreeze Exceptions == - -The exception request bug report needs to have a justification why the user interface needs to be changed at that point, and give a rationale why the benefits of it are worth breaking existing documentation and translations. - -Every change of the user interface (either a string or the layout) requires you to notify the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc|documentation]] and [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators|translation]] teams. Please include a link to these posts in the mailing list archives of [[https://lists.ubuntu.com/archives/ubuntu-doc/|ubuntu-...@]] and [[https://lists.ubuntu.com/archives/ubuntu-translators/|ubuntu-translat...@]]. - -After that, subscribe the release team, as usual. - -== Milestone freeze Exceptions (like BetaFreeze) == - -During milestone/final release freeze periods, extreme caution is exercised when considering exceptions, as a regression could cause a deadline to be missed, or a build to receive less testing than desired. A request for an exception must demonstrate strong rationale and minimal risk for the update to be considered. - -Exception requests must include the following additional details: - - * It must fix a bug milestoned for that particular milestone. - * A complete `debdiff` of the proposed upload must be provided (preferably as bug attachment). - -== Exceptions for Universe/Multiverse == - === FeatureFreeze for new upstream versions === If you want to introduce a new upstream version with new features and/or ABI/API changes, please @@ -196,45 +177,63 @@ * for instance a copy and paste of the install messages from console when installing * mention what testing you've done to see that it works * a screenshot showing the main features could also be nice - * subscribe (not assign) it to the '`motu-release`' team. - * In some cases a standing freeze exception for multiple uploads is the most efficient way to manage the freeze process. Standing freeze exceptions should be requested in bugs using the normal process, although not all elements of a standard FFe request
Re: motu-release
On Wed, Feb 17, 2010 at 01:42:29PM +0100, Stefan Potyra wrote: As a first step, I suggest merging motu-release and ubuntu-release for lucid. This seems to be the consensus so far, anyone disagree? As FeatureFreeze is already tomorrow, I think we should immediately try to find the procedure how to handle freeze exception requests (which I guess will start to get filed from tomorrow on). To not block lucid development on the lack of a procedure, I suggest that we keep the status quo and have motu-release handle universe/multiverse exception requests with two +1 votes and have ubuntu-release handle main/restricted as an interim solution. Ack; freeze announcement sent out with the status quo. Regarding the team unification, is there an expectation that the two-vote approach will continue? I don't have a strong preference between the ubuntu-release and motu-release approaches, but I think it would be strange to be applying different procedures for different archive sections - or to different members of the team! - so we should probably pick one... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Wed, Jan 27, 2010 at 03:03:35PM +0100, Stefan Potyra wrote: I've (only) talked to Daniel so far and we came up with the following possible alternatives: - Flavours like Kubuntu can approve their own members, so it would make sense to let them make decisions in terms of freeze exceptions too. (The MOTU Release team had delegates of various teams that made decisions, which worked out well.) Between Jonathan's Riddell's status as a member of the release team, and his repeated delegation by motu-release regarding Kubuntu packages in universe, I think that reasonably approximates the status quo; but I hesitate to describe this as flavors making their own decisions about freeze exceptions. So long as the Ubuntu family of distributions continue to make releases together out of the same archive, there's a need for coordination on such matters as the timing of the archive freeze, buildd quiescing for ISO mastering, and release-readiness criteria; I think the best option is to continue having a central team, which can either solicit team members from the flavour communities or delegate freeze decisions for a set of packages. - Merge motu-release and ubuntu-release? Add team members of the flavours to ubuntu-release to form kind of a release taskforce? As a first step, I suggest merging motu-release and ubuntu-release for lucid. - Just drop motu-release and let ubuntu-release make the decisions? I think that would only frustrate contributors, as the existing ubuntu-release team isn't likely to be able to keep up with all requests. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Thu, Jan 28, 2010 at 01:04:25AM +0900, Emmet Hikory wrote: Scott Kitterman wrote: On Wednesday 27 January 2010 09:03:35 am Stefan Potyra wrote: FeatureFreeze is less than a month away, so the discussion over restaffing the current MOTU Release team, which is a short of members [1], brought up the topic how best to deal with release decisions in light of Permissions Reorg. ... motu-sru and ubuntu-sru merged into a single team. I've had a couple of conversations with people in terms of doing something simllar with motu- release and ubuntu-release. I think it's the right answer. So far it's been a matter of finding time to talk with everyone about it and decide what should be done. Could such an item be added to the agenda of the next release meeting? It seems like the various groups typically reporting there would be natural delegates for the various areas on which they report If you mean that they should be delegates for all the packages related to their teams, I don't think that's a good idea. If not an outright conflict of interest, leaving these decisions to the individual teams directly brings the problem of myopia alluded to in my previous message. The point of having a team approve freeze exceptions at all, instead of letting individual developers continue to upload directly to the archive, is to make sure we're collectively on the same page regarding what should be going into the release when; that means the people approving freeze exceptions for packages that land on CDs need to have an overview of the release as a whole. I don't think per-team delegates are the way to achieve this. (and those groups that had historical delegates ought be encouraged to participate and report in that forum). Unfortunately, the structure of the release meetings today doesn't scale well to a large number of teams, and the length of the meeting is already a challenge for scheduling. Where there is a need for other coordination within the release team, I would prefer to see this take place via either separately scheduled meetings, or email. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: motu-release
On Wed, Feb 17, 2010 at 11:32:13PM +0100, Stefan Potyra wrote: Agreed. Delegating freeze decisions for a set of packages matches very much what we've done with delegates so far :). motu-release chose the relevant delegates themselves. With decisions in terms of freeze exceptions, I meant that not motu-release chooses delegates, but any team can handle freeze exception requests for a given subset of packages how the team think it's best. Of course this should include a responsibility to ask the release-team in case of potentially contentious packages. That's precisely the model that I'm arguing against. If there are to be delegations here, they should be decided on a per-team basis, not as a blanket policy. So not any team can handle - only teams for which we identify delegates that we're confident are on the same page with the rest of the release team. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Patch systems in packages
On Wed, Aug 20, 2008 at 11:31:41AM +0900, Emmet Hikory wrote: Steve Langasek wrote: If you have more than one change to the upstream source of a Debian package, then you need some system to manage the changes to indicate which parts of the patch belong to which functional change -- i.e., a patch management system. This can be a set of VCS feature branches, if you prefer (in which case it's important to use the Vcs-* headers in debian/control in the Ubuntu upload), or it can be an in-package patch system; but it is important to have /some/ mechanism for labelling your changes so that you aren't left with a single massive diff. Why? Why should the Debian Maintainer care about the monolithic patch as applied in Ubuntu (perhaps also cluttered by several changelog entries about merges that have happened, or rebuilds). Is it not best practice to send those patches relevant to Debian to bugs in the BTS, as separated patches? If this is done, to whom is it useful to track the patches independently, so long as the patches remain easy to maintain? I think this is a misleading question: it is /not/ easy to maintain patches that are jumbled together in a monolithic diff, because even if it's easy for the person who created the patches (which is likely to change over time), it's not necessarily easy for $random_other_ubuntu_developer who comes along afterwards. Even the most innocuous-seeming of patches can become head-scratchers over time if they aren't accompanied by appropriate metadata (description, + some sort of bounding box saying which bits belong). So for *Ubuntu's* benefit, I believe our best practices should be to use some sort of patch management whenever patching upstream sources, not just a monolithic diff. (Again, I think this can be either VCS feature branches or an in-package patch system, whichever is easier for the people doing the work.) If the Debian maintainer already has a patch system in place, it's far better to continue using that one (no matter how bad it is, sometimes); otherwise, adding a patch system *should* be done when needed. I generally argue against the introduction of patch systems, as 1) I am very much opposed to working with a package that has both changes in diff.gz (from the original packaging), and 2) a patch system. If we're talking about packages where the Debian maintainer has already patched upstream and done so without a patch system, then I agree that this is ugly; in that case I think the best outcome is if the Debian maintainer can be persuaded to /use/ some form of patch management. These are painfully ugly, and the monolithic diff frequently becomes completely unreadable (was this a change to a previous Debian change, to an upstream change, or to a combination?); and 2) I have heard a number of Debian maintainers complain about the useless introduction of a patch system when they maintain the package in a VCS with no patch system. Can you give examples of these? Ideally if the maintainer is already using feature branches in a distributed VCS, Ubuntu could hook into that with its own feature branches, and that would entirely satisfy my concerns about maintainability of the patches. But the highest percentage of Vcs-* fields in Debian packages still point at subversion, which is not at all useful for this purpose. That said, in the case where there are no previous diff.gz changes external to debian/, I think it is best practice to review other packages with the same Debian Maintainer to attempt to determine the preferred patch system of that maintainer (which may be monolithic diff.gz), and follow that practice. In the rare case where there are no patches external to debian/ in any of the packages maintained by that Maintainer, the introduction of a patch system seems the least bad way to do things, but this is very much an exceptional case, and for most packages we would do well to instead follow the existing practice (even where that is a monolithic diff.gz). I agree; I was assuming the common case was that the Debian package did not include patches to the upstream source, or that if there were any such patches, they were managed with a patch system. Perhaps this is not such a common case as I believed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Good communication with upstream is good idea
Hi Neil, On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). That doesn't seem particularly Debian-specific, though? It's not out of the question that Ubuntu could have an armel port later, and that's the only thing I can think of that /should/ cause emdebian-tools to be incompatible with Ubuntu. emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package. emdebian-tools is tightly integrated into Debian (and Debian unstable in particular) and is, naturally, a Debian native package (it was written to support Embedded Debian after all, not UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does not provide the foreign packages needed for linking when cross building, those come exclusively from Debian. So if an armel port of Ubuntu becomes available, is there anything else that stops emdebian-tools from working with it? Same with apt-cross, it is exclusively designed for Debian, Debian mirrors and Debian buildd configurations. How does apt-cross have anything to do with the Debian buildds, at all? Surely you're not using this as a build-dependency to force Debian cross-builds on the Debian buildds, are you? Nor do I see how apt-cross would be affected by differences between a Debian vs. an Ubuntu mirror. (Ubuntu main is smaller than Debian main, but is still self-contained, to be sure.) How is emdebian-tools meant to cross-build for ARM on Ubuntu when Ubuntu does not provide ARM packages and makes changes to the equivalent Debian packages? Hrm, what changes are at issue here? The Debian maintainers also make changes to Debian packages, all the time. In what way do the Ubuntu changes differ that makes emdebian-tools incompatible with Ubuntu? To me it seems highly unlikely that cross versions of Debian packages would install over a Ubuntu base, especially when those packages are the typical debootstrap selection that have a variety of changes in Ubuntu. I don't run Ubuntu, I have no inclination to test for Ubuntu and as no-one else has offered, I cannot support Ubuntu. While the current absence of any official Ubuntu armel port seems like a pretty good reason to omit emdebian-tools from Ubuntu for the moment, the fact that the Debian package maintainer or upstream author doesn't support Ubuntu would not generally be a reason for Ubuntu not to include the package. Debian also has any number of upstreams who don't support Debian, after all. How many packages could be in this situation? I don't expect it to be many. Some form of filter on the Ubuntu side may be necessary. Yes, there is a blacklist in Ubuntu to prevent certain packages from being synced from Debian. Scott Kitterman has already started the process now of getting emdebian-tools added to that list. BTW, in your cited blog post, I noticed that you wrote: I really don't like Launchpad (I have quite enough web-logins thank you very much) or the PTS link that shows Ubuntu bugs that I cannot close from Debian. You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Stable Release Update Regression/Build Problem
On Mon, Jun 23, 2008 at 11:17:37PM -0400, Scott Kitterman wrote: An SRU for aptoncd was just moved from hardy-proposed (where it worked) to hardy-updates where it does not due to a pending python-central SRU. https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/199600 The aptoncd package was apparently built against python-central 0.6.7ubuntu0.1 in hardy-proposed which produces a versioned depends on python-central (=0.6.7) but 0.6.5ubuntu1 is all that is currently available in Hardy's release pocket. I'm not sure if there are other packages that use python-central in hardy-proposed, but none should be pocket copied from hardy-proposed to hardy-updates until python-central gets moved. Filed in launchpad as bug 242554. https://bugs.launchpad.net/ubuntu/+source/aptoncd/+bug/242554 Scott got ahold of me on IRC shortly after sending this email, and I've followed through on the python-central SRU candidate which has now been validated and copied to hardy-updates. I've marked bug #242554 as 'fix released', as the dependency of aptoncd should now be satisfiable within hardy-updates as soon as the package has been published and the mirrors catch up. This highlights the need for a check as part of our SRU process to verify that packages which are being copied into -updates won't cause uninstallability problems. python-central is not a unique case in warranting such a check; whenever an ABI-changing kernel SRU is done, it's important to be sure that all the packages are copied as a group to avoid regressions in installability such as this, and currently this check is done entirely by hand. An appropriate follow-up to prevent this problem from recurring would be to implement such a check. Perhaps britney is the right starting point for this? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: What DIF means to Universe (was: Impending Debian import freeze)
Hi Emmet, On Wed, Dec 12, 2007 at 12:56:22AM +0900, Emmet Hikory wrote: On Dec 11, 2007 7:53 PM, Steve Langasek wrote: Just a brief note to remind you all that the DebianImportFreeze[1] for Hardy is two days away[2]. This is the deadline for initial merges of packages for Hardy; after Thursday, December 13, merging packages is a freeze exception, so please have your remaining merges for hardy finished before this point. As this message has resulted in some confusion in #ubuntu-motu, Ack, sorry for this; the message was drafted somewhat quickly with the intention of giving people a reminder with as much lead time as possible, but at the expense of clarity. To clarify now: this wasn't meant to be taken as any sort of policy change, just a reminder of the impending deadline. I've drafted the following guidelines on what DebianImportFreeze means for Universe. I'm not speaking authoritatively, and would welcome correction if I am mistaken. 1) Go visit MoM, DaD, or multidistrotools, and merge everything by Wednesday night/ Don't worry if it doesn't have your name on it: at this point any merge is fair game. This sounds like a reasonable policy to me for packages which have not yet been merged in hardy (which is what the deadline is actually for - initial merges), but I also don't presume to speak authoritatively here; as Scott mentions, there may be reasons for not merging a particular package, and I don't want to be blamed for encouraging people to merge recklessly. :-) Further, if you were waiting for a sync, now is the time to push the merge in: there's no more wait needed. I'm not sure I understand what you mean here. By waiting for a sync do you mean waiting for the archive admins to sync a package, or waiting for the Debian package to be in a state that's syncable? If the latter, I agree completely. If you mean the former, I would hope that's not an issue, and if it is please let me know so that we can address that. 2) After this point, merges may still be done, but should only be done when the Debian change is explicitly desireable for inclusion in hardy (e.g. Contains feature foo which integrates better with the default installation, or Fixes bug bar which annoys a bunch of people or The assigned merger didn't merge by the deadline, and we want the new updates (the last of these should be done in the next week or two)). Merges that change binary package names or otherwise cause transitions should be avoided, and anyone contemplating such a merge becomes responsible for coordinating updates to all the rdepends (this typically requires a truly significant feature or important bug) I think this is a bit more conservative than necessary. The aim of the DIF, as I understand it, is to make sure we don't find ourselves with packages getting merged right before FeatureFreeze for the first time in the release cycle, bringing in six months worth of Debian changes when we're supposed to be stabilizing. As long as the bulk of these changes have been merged in advance of the DIF, I don't think the justification for an updated merge needs to be particularly elaborate. I do agree with you that mergers need to take responsibility for any transitions they cause after this point, and that any exceptions for the DIF should be made sooner rather than later. 3) The Universe DIF Freeze exception process works as follows: A: Document why the package should be merged (bugs are good for this) B: Determine the rdepends, and plan any required transition (avoid these) C: Get a member of ~ubuntu-dev (possibly including yourself) to agree D: Upload all affected packages (should be less than 10) (may include sync requests) All of the above sounds perfectly reasonable to me. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
timeline for full archive freeze
Hi all, This is a quick note to let everyone know the timeline for the gutsy freeze. To ensure a successful build of all release images in time for Thursday's scheduled release, the CD building process will begin on Monday after 18:00 UTC. Since main must be frozen at that time, we will be freezing universe as well so that the gutsy-updates queue can be set up in parallel to the CD building. This means that any fixes that you are targetting for gutsy need to be uploaded with enough lead time to be reviewed by the release team, accepted, and built by the buildds prior to 18:00 UTC on Monday. As a fuzzy deadline, I would suggest aiming to have packages uploaded to gutsy by 10:00 UTC, and preferably well before that. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Archive frozen for Gutsy release
Hi folks, On Fri, Oct 05, 2007 at 02:43:15PM -0700, Steve Langasek wrote: Hi all, We continue to roll on towards release of Gutsy, and as of today the archive is now frozen. Many thanks to all whose contributions have gotten us to this point! This freeze means that the only uploads that will be accepted for gutsy between now and release are uploads fixing specific, release-relevant bugs. There are still a number of bugs to try to resolve before the release candidate goes out on October 11. A list of these milestoned bugs can be found at https://launchpad.net/ubuntu/+milestone/ubuntu-7.10-rc. Your help in hammering these out is appreciated. If you have bugs which you believe should be listed there but aren't yet, please get in touch with me or another member of the release team. There have been a number of questions about how this applies to universe. Although the freeze applies to the entire archive in the sense that package uploads have to go through the unapproved queue, the rule that only bugfixes are allowed is not intended to apply to universe. Instead, universe packages are only subject to the Upstream Version / New Package Freeze. In light of the timeline remaining before Gutsy release I think it might be a good idea to focus attention on bugfixes, but this is left to the discretion of the MOTUs. My apologies for the lack of clarity. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Archive frozen for Gutsy release
Hi folks, On Fri, Oct 05, 2007 at 02:43:15PM -0700, Steve Langasek wrote: Hi all, We continue to roll on towards release of Gutsy, and as of today the archive is now frozen. Many thanks to all whose contributions have gotten us to this point! This freeze means that the only uploads that will be accepted for gutsy between now and release are uploads fixing specific, release-relevant bugs. There are still a number of bugs to try to resolve before the release candidate goes out on October 11. A list of these milestoned bugs can be found at https://launchpad.net/ubuntu/+milestone/ubuntu-7.10-rc. Your help in hammering these out is appreciated. If you have bugs which you believe should be listed there but aren't yet, please get in touch with me or another member of the release team. There have been a number of questions about how this applies to universe. Although the freeze applies to the entire archive in the sense that package uploads have to go through the unapproved queue, the rule that only bugfixes are allowed is not intended to apply to universe. Instead, universe packages are only subject to the Upstream Version / New Package Freeze. In light of the timeline remaining before Gutsy release I think it might be a good idea to focus attention on bugfixes, but this is left to the discretion of the MOTUs. My apologies for the lack of clarity. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
