Re: [ubuntu-studio-devel] Ubuntu Studio: We're out of space
On Thursday, March 24, 2022 4:26:13 PM PDT Steve Langasek wrote: > Ok. Brian Murray has addressed the source of this problem; the new images > were building successfully and being published, but incorrectly being > published as .img instead of .iso with the .iso being copied forward from > the previous directory. > > I have removed the wrongly-named '.img' files. The next daily build will > produce .iso files again. Thanks, Steve. Additionally, please increase the limit of the image size as we've decided USB media is OK for our purposes (discussed in a separate email). This should be reminiscent of when Ubuntu Studio had to go with the DVD route many years ago when other flavors were still on CDs. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Studio: We're out of space
On Thu, Mar 24, 2022 at 07:37:17AM -0700, Erich Eickmeyer wrote: > > If Ubuntu Studio decide they don't care about the image fitting on a > > DVD, we can simply raise the size limit. But in that case, I don't > > think we should call the image build itself a 'dvd' any more; and I also > > think that in short order (but not necessarily for 22.04) we should stop > > building this as a hybrid image since it's no longer practical to use it > > on optical media. If it's going to only be usable on a USB stick, then > > let's fix how we build it and avoid all the indirection that exists ONLY > > so that it can be used on optical media. > We have discussed going with the USB stick route. However, what spurred this > is because not only the OVERSIZED warning, but also because the images are > merely copies of the 20220322 image and are not updating upon build. I > thought > this was due to the oversize warning. Either way, this is very concerning as > we can't correctly test the builds due to a resolved bug involving automount > conflicting with Calamares. Ok. Brian Murray has addressed the source of this problem; the new images were building successfully and being published, but incorrectly being published as .img instead of .iso with the .iso being copied forward from the previous directory. I have removed the wrongly-named '.img' files. The next daily build will produce .iso files again. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Technical Board Call For Nominations
The Ubuntu Technical Board is responsible for the technical direction of Ubuntu. It makes decisions on package selection, packaging policy, installation systems and processes, kernel, X server, display management, library versions, and dependencies. The board works with relevant teams to establish a consensus on the right path to take, especially where diverse elements of Ubuntu cannot find consensus on shared components. At the moment there is one seat of the Technical Board vacant, which would have to be filled. This seat will be re-elected with the other Technical Board seats at the end of the year. The eligibility requirements are: - Be an Ubuntu Core Developer - Be available during typical meeting hours [see https://wiki.ubuntu.com/TechnicalBoardAgenda] - Insight into the Ubuntu Development process, architecture, and technical culture The Technical Board usually meets twice a month in IRC and has discussions on its mailing list. They are current Ubuntu Core Developers with a proven track record of activity in the community. They have shown themselves over time to be able to work well with others and display the positive aspects of the Ubuntu Code of Conduct. They should be people who can judge contribution quality without emotion while engaging in an interview/discussion that communicates interest, a welcoming atmosphere, and which is marked by humanity, gentleness, and kindness. You can find more information about the Technical Board at https://wiki.ubuntu.com/TechnicalBoard If this sounds like you or a person you know, please send your nominations to community-council AT lists.ubuntu.com. Please include the name, Launchpad ID, and Ubuntu Wiki page for whom you are nominating, as well as a few lines about the nominee, so the Community Council can get an idea of why you/they would like to join the Board and why you/they would like to be considered. If you nominate someone else, please make sure that they are willing to accept the nomination. Nominations are now open and will close on Wednesday, March 30th, 2022, at 23:59 UTC. After that, the Community Council will review the submissions, submit them to Mark Shuttleworth for shortlisting, and proceed with a vote by the Ubuntu Development team. Please do not hesitate to share this post with anyone you think deserves to be on the Technical Board. On behalf of the Community Council, Torsten Franz -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Second Jammy Jellyfish test rebuild
On Thu, Mar 24, 2022 at 07:44:11AM -0700, Erich Eickmeyer wrote: > I'm seeing a lot of failed arm64 builds without build logs. In the > past when I've seen this, I've merely retried the build and it has > succeeded. This shows a pattern in that it's likely we've got a buggy > build server. Yeah, this has been reported to us (Launchpad), but for the record we have no handle on a fix at present. The basic symptom is that buildd-manager timed out trying to poll the builder (probably over several attempts). This is either because the builder crashed or hung or something like that (possible under load, and sometimes particular builds will repeatedly OOM a builder or similar), or because of a network failure that meant we lost contact for too long, or because of a buildd-manager bug. Unfortunately it's extremely difficult even for us to tell which at present. Ubuntu test rebuilds tend to exacerbate this sort of thing, because the whole system is under significantly more load than usual. It's something that we'll keep trying to debug, but it's not as simple as a single buggy build machine, and so I want to set expectations that this may not be something we can fix quickly. -- Colin Watson (he/him) [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Second Jammy Jellyfish test rebuild
On Thursday, March 24, 2022 6:05:06 AM PDT Graham Inggs wrote: > The second test rebuild of Jammy Jellyfish was started on March 17, > 2022 for all architectures, all components. The rebuild is finished > for the main component, and finished for universe/multiverse on amd64 > and i386, and still running on the other architectures. > > Results (please also look at the superseded builds) can be found at > > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jamm > y-jammy.html > > A number of builds failed without logs, and these will be retried. > > Additional build failures for packages in jammy-proposed (not yet > migrated to jammy) can be found at > > http://qa.ubuntuwire.com/ftbfs/ > > Please help fixing the build failures. > > Graham I'm seeing a lot of failed arm64 builds without build logs. In the past when I've seen this, I've merely retried the build and it has succeeded. This shows a pattern in that it's likely we've got a buggy build server. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Studio: We're out of space
On Wednesday, March 23, 2022 11:56:30 PM PDT Steve Langasek wrote: > On Wed, Mar 23, 2022 at 10:28:06PM -0700, Erich Eickmeyer wrote: > If this is all because of the 'OVERSIZED' warning, I've addressed that on > IRC. The header on https://cdimage.ubuntu.com/ubuntustudio/dvd/current/ > explains further: > > Warning: This image is oversized (which is a bug) and will not fit onto a > single-sided single-layer DVD. However, you may still test it using a > larger USB drive or a virtual machine. > > If Ubuntu Studio decide they don't care about the image fitting on a DVD, we > can simply raise the size limit. But in that case, I don't think we should > call the image build itself a 'dvd' any more; and I also think that in > short order (but not necessarily for 22.04) we should stop building this as > a hybrid image since it's no longer practical to use it on optical media. > If it's going to only be usable on a USB stick, then let's fix how we build > it and avoid all the indirection that exists ONLY so that it can be used on > optical media. We have discussed going with the USB stick route. However, what spurred this is because not only the OVERSIZED warning, but also because the images are merely copies of the 20220322 image and are not updating upon build. I thought this was due to the oversize warning. Either way, this is very concerning as we can't correctly test the builds due to a resolved bug involving automount conflicting with Calamares. > > HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@, > > there is another ISO format that works for DVD: ISO 13346, aka UDF. This > > allows for a virtually unlimited filesize, although I've seen anecdotal > > mentions of 1024GB (1TB). This would be preferable, and on behalf of > > Ubuntu Studio, we request this switch if able, or even an alternative. I > > realize this is short notice prior to beta, > > I've established that it's not actually necessary here, but for the record > it would be completely impossible to make that switch in time for beta. We > have never built a UDF-format image, none of the tools are installed on the > image build server to support this format, we have certainly never done a > hybrid image with UDF (which means the easiest implementation would be a > *non*-hybrid image, so if it's not a hybrid image why not just do a USB > image instead? see above), and various parts of our installer-specific > initramfs code assumes iso9660. Fair. I honestly didn't expect that, but it was a thought. > > It seems that Ubuntu Kylin shares our plight. > > The only shared plight is that both flavors currently have images that are > oversized for the limits that have been declared in the code... Again, fair. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Second Jammy Jellyfish test rebuild
The second test rebuild of Jammy Jellyfish was started on March 17, 2022 for all architectures, all components. The rebuild is finished for the main component, and finished for universe/multiverse on amd64 and i386, and still running on the other architectures. Results (please also look at the superseded builds) can be found at https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220317-jammy-jammy.html A number of builds failed without logs, and these will be retried. Additional build failures for packages in jammy-proposed (not yet migrated to jammy) can be found at http://qa.ubuntuwire.com/ftbfs/ Please help fixing the build failures. Graham -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Studio: We're out of space
On Wed, Mar 23, 2022 at 10:28:06PM -0700, Erich Eickmeyer wrote: > At the time, it seemed like a good idea, as both Plasma and Xfce were > around the same size in disk space, and we also decided, Ubuntu Studio > isn't tied to its desktop environment. > The problem that I'm seeing is that the ISO 9660 spec, the standard on > which all of our ISO images are built, has a hard limit of 4096MB per file > size. In our case, the squashfs file size is exceeding that. This is > resulting in failed builds. No, it isn't? https://cdimage.ubuntu.com/ubuntustudio/dvd/ There have been multiple successful image builds over the past several days. If this is all because of the 'OVERSIZED' warning, I've addressed that on IRC. The header on https://cdimage.ubuntu.com/ubuntustudio/dvd/current/ explains further: Warning: This image is oversized (which is a bug) and will not fit onto a single-sided single-layer DVD. However, you may still test it using a larger USB drive or a virtual machine. If Ubuntu Studio decide they don't care about the image fitting on a DVD, we can simply raise the size limit. But in that case, I don't think we should call the image build itself a 'dvd' any more; and I also think that in short order (but not necessarily for 22.04) we should stop building this as a hybrid image since it's no longer practical to use it on optical media. If it's going to only be usable on a USB stick, then let's fix how we build it and avoid all the indirection that exists ONLY so that it can be used on optical media. > HOWEVER, and this is why I'm CCing the Release Team and ubuntu-devel@, > there is another ISO format that works for DVD: ISO 13346, aka UDF. This > allows for a virtually unlimited filesize, although I've seen anecdotal > mentions of 1024GB (1TB). This would be preferable, and on behalf of > Ubuntu Studio, we request this switch if able, or even an alternative. I > realize this is short notice prior to beta, I've established that it's not actually necessary here, but for the record it would be completely impossible to make that switch in time for beta. We have never built a UDF-format image, none of the tools are installed on the image build server to support this format, we have certainly never done a hybrid image with UDF (which means the easiest implementation would be a *non*-hybrid image, so if it's not a hybrid image why not just do a USB image instead? see above), and various parts of our installer-specific initramfs code assumes iso9660. > It seems that Ubuntu Kylin shares our plight. The only shared plight is that both flavors currently have images that are oversized for the limits that have been declared in the code... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
