Recent Britney changes regarding i386 autopkgtests
Hi all, We recently made a change to britney which causes source packages that produce only Architecture: all binaries on i386 to not ever get queued for autopkgtest.ubuntu.com. This is because, for actual end users, the dependencies of an arch: all package on non-arch: all packages are satisfied by the amd64 binaries, not i386 binaries. So these i386 source packages with all `Architecture: all` binaries are redundant because of the amd64 tests for the same package. The change has been made to both regular britney, and security britney. autopkgtest.ubuntu.com does not do any similar check - you can still queue these packages via the webpage if you so wish. Regards -- [image: Canonical-20th-anniversary] *Tim Andersson* Software Engineer (Canonical Ubuntu Release Management) Email: tim.anders...@canonical.com Location: United Kingdom canonical.com ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
autopkgtest.ubuntu.com - User Page
Greetings! We have a new feature for autopkgtest - in the Release Management team we recently finished working on our new "User Page". This page can be reached at: https://autopkgtest.ubuntu.com/user// Or by logging in, and clicking on your username in the navbar. This page lists all of your currently queued and running tests, as well as all of your test results. There's a navigation section where you can choose to view only queued, only running, or only previous test results. The previous test results has pagination and you can go back as far as you need :) A disclaimer - PPA test results aren't supported on this page. Big thanks to Simon Chopin for requesting this new feature! We hope you all like it and if you run into any issues, please contact us on #ubuntu-quality on IRC. Thanks! Tim Andersson, Paride Legovini, Florent (Skia) Jacquet & Brian Murray -- [image: Canonical-20th-anniversary] *Tim Andersson* Software Engineer (Canonical Ubuntu Release Management) Email: tim.anders...@canonical.com Location: United Kingdom canonical.com ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
autopkgtest.ubuntu.com - all-proposed in retries, running page and results pages
Hi all! We recently made some quality of life changes to autopkgtest.ubuntu.com, and thought we'd share them with you all. Up until now, when requesting a test with "all-proposed=1" via the webpage, you could never see on the results or running pages whether a test was requested with or without "all-proposed=1" (for those wondering what this means in practice, it just means that when installing packages on the testbed, *all* of them are installed from the proposed pocket, rather than just the specified triggers). This is now amended (fixing [1]). We added a new column to the results page, titled "env", in which you can see "all-proposed=1" if the test was requested with this additional param (nothing will be displayed if it wasn't). You will also now start seeing "all-proposed: 1" on the /running page for tests that were requested with this additional param. Additionally to this, when retrying a test by clicking the retry button on the results page, "all-proposed=1" is now preserved when retrying. For those wondering why we titled the column "env" and not "all-proposed", we intend to use this "env" column for additional features in the future. If you run into any issues regarding this feature or any others, please contact us on IRC in the #ubuntu-quality channel. Regards, Tim [1] https://bugs.launchpad.net/auto-package-testing/+bug/1999163 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Duplicate Requests in autopkgtest-cloud
Hi Athos, Sorry, we overwrote the hotfix the other day with a deployment, sorry. I've reinstated it now. Please let me know if you have any issues! Regards, Tim On Wed, 16 Aug 2023 at 16:54, Athos Ribeiro wrote: > On Fri, Jul 28, 2023 at 10:01:50AM +0100, Tim Andersson wrote: > >Hi Steve, > > > >This is something I missed in the initial implementation, but there's now > >an MP for a fix ready to go into master. Right now, however, I've hotfixed > >prod so that if you pass `all-proposed`, the duplicate request check is > >disabled. I made this quick change to unblock ginggs > > Hi Tim, > > is the hotfix still up? > > I just got a request with all-proposed blocked because a request without > it was queued. > > > > >On Fri, Jul 28, 2023 at 5:19 AM Steve Langasek > > >wrote: > > > >> Hi Tim, > >> > >> On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > >> > Hi all, > >> > >> > In the Ubuntu QA team we recently made and deployed a change which now > >> > makes it impossible to queue duplicate requests. > >> > >> > If a request is currently in the queue, or is currently running, and > you > >> > request the same test, you will be taken to an error page which tells > you > >> > the test details and whether it is currently queued or currently > running. > >> > It looks like this: > >> > ``` > >> > > >> > You submitted an invalid request: > >> > > >> > Test already queued: > >> > > >> > release: lunar > >> > > >> > pkg: gzip > >> > > >> > arch: arm64 > >> > > >> > triggers: gzip/1.12-1ubuntu1 > >> > > >> > ``` > >> > This is to try and ease the load on autopkgtest-cloud. > >> > >> > If you experience any bugs or unexpected functionality, please file a > bug > >> > against `autopkgtest-cloud` and let us know. We expect it to work > >> > seamlessly but always expect the unexpected right :) > >> > >> Does the code also properly distinguish between tests queued with > >> proposed=1 > >> and those without, so that it's possible to queue both ways in parallel? > >> > >> Thanks, > > -- > Athos Ribeiro > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Duplicate Requests in autopkgtest-cloud
Hey Utkarsh, Thanks for reporting this! Yeah we've recently become aware of this. It takes a few seconds for a request to hit the queue, so if you spam refresh or re-queue you can queue multiple times. Not really sure how to amend this just yet, but we'll look to amend it in the future. Thanks, Tim On Tue, Aug 8, 2023 at 3:50 PM Utkarsh Gupta wrote: > Hi Tim, > > On Thu, Jul 27, 2023 at 4:01 PM Tim Andersson > wrote: > > In the Ubuntu QA team we recently made and deployed a change > > which now makes it impossible to queue duplicate requests. > > Super, this is great stuff! > > However, this isn't working as advertised. Or perhaps I've gotten it > wrong. But I wanted to trigger 'livecd-rootfs/23.10.12' for > mantic/ppc64el and I did but just to try the whole duplicating thing, > I did another time, and it did again. On the third time, however, it > said it's already queued. Upon checking > https://autopkgtest.ubuntu.com/running, I can confirm that the > autopkgtest is running twice, triggered 9 seconds apart. Is that > anyhow expected? > > > - u > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Duplicate Requests in autopkgtest-cloud
Hi Steve, This is something I missed in the initial implementation, but there's now an MP for a fix ready to go into master. Right now, however, I've hotfixed prod so that if you pass `all-proposed`, the duplicate request check is disabled. I made this quick change to unblock ginggs Regards, Tim On Fri, Jul 28, 2023 at 5:19 AM Steve Langasek wrote: > Hi Tim, > > On Thu, Jul 27, 2023 at 11:10:05AM +0100, Tim Andersson wrote: > > Hi all, > > > In the Ubuntu QA team we recently made and deployed a change which now > > makes it impossible to queue duplicate requests. > > > If a request is currently in the queue, or is currently running, and you > > request the same test, you will be taken to an error page which tells you > > the test details and whether it is currently queued or currently running. > > It looks like this: > > ``` > > > > You submitted an invalid request: > > > > Test already queued: > > > > release: lunar > > > > pkg: gzip > > > > arch: arm64 > > > > triggers: gzip/1.12-1ubuntu1 > > > > ``` > > This is to try and ease the load on autopkgtest-cloud. > > > If you experience any bugs or unexpected functionality, please file a bug > > against `autopkgtest-cloud` and let us know. We expect it to work > > seamlessly but always expect the unexpected right :) > > Does the code also properly distinguish between tests queued with > proposed=1 > and those without, so that it's possible to queue both ways in parallel? > > 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 Developer https://www.debian.org/ > slanga...@ubuntu.com vor...@debian.org > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Duplicate Requests in autopkgtest-cloud
Hi all, In the Ubuntu QA team we recently made and deployed a change which now makes it impossible to queue duplicate requests. If a request is currently in the queue, or is currently running, and you request the same test, you will be taken to an error page which tells you the test details and whether it is currently queued or currently running. It looks like this: ``` You submitted an invalid request: Test already queued: release: lunar pkg: gzip arch: arm64 triggers: gzip/1.12-1ubuntu1 ``` This is to try and ease the load on autopkgtest-cloud. If you experience any bugs or unexpected functionality, please file a bug against `autopkgtest-cloud` and let us know. We expect it to work seamlessly but always expect the unexpected right :) Thanks, Ubuntu QA -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Timestamps added to logs in autopkgtest and autopkgtest-cloud
Hey there, Recently in Canonical Ubuntu QA we made some changes to autopkgtest which went into both upstream and ubuntu-devel which preprends timestamps to the logs. The timestamps are in seconds and are measured since the beginning of all the tests when you run autopkgtest against a package. We hope that this can make it easier to extract valuable information from log files when reading logs from the autopkgtest-cloud environment. It can help with determining where tests are hanging, for instance. A log snippet can be seen below: ``` 0s autopkgtest [18:59:38]: starting date and time: 2023-06-12 18:59:38+0100 0s autopkgtest [18:59:38]: git checkout: a2cc92d Merge branch 'add_timestamp_to_logs' into 'master' 0s autopkgtest [18:59:38]: host duckstation7; command line: runner/autopkgtest -o /home/andersson123/tests/ mawk -- qemu --ram-size=1536 --cpus 2 /home/andersson123/canonical/images/autopkgtest-lunar-amd64.img 13s autopkgtest [18:59:51]: testbed dpkg architecture: amd64 17s autopkgtest [18:59:55]: testbed running kernel: Linux 6.2.0-20-generic #20-Ubuntu SMP PREEMPT_DYNAMIC Thu Apr 6 07:48:48 UTC 2023 17s autopkgtest [18:59:55]: apt-source mawk 19s Get:1 http://archive.ubuntu.com/ubuntu lunar/main mawk 1.3.4.20200120-3.1 (dsc) [1,776 B] 19s Get:2 http://archive.ubuntu.com/ubuntu lunar/main mawk 1.3.4.20200120-3.1 (tar) [469 kB] 19s Get:3 http://archive.ubuntu.com/ubuntu lunar/main mawk 1.3.4.20200120-3.1 (diff) [14.1 kB] 19s gpgv: Signature made Fri 17 Jun 2022 04:38:22 PM BST 19s gpgv:using RSA key 406220C8B8552802378CCE411F5C7A8B45564314 19s gpgv:issuer "b...@debian.org" 19s gpgv: Can't check signature: No public key 19s dpkg-source: warning: cannot verify inline signature for ./mawk_1.3.4.20200120-3.1.dsc: no acceptable signature found 19s autopkgtest [18:59:57]: testing package mawk version 1.3.4.20200120-3.1 19s autopkgtest [18:59:57]: build not needed 20s autopkgtest [18:59:58]: test mawktest: preparing testbed 22s Reading package lists... 22s Building dependency tree... 22s Reading state information... 22s Starting pkgProblemResolver with broken count: 0 22s Starting 2 pkgProblemResolver with broken count: 0 ``` It does not prepend the timestamp to stdout, just to the log file itself. You will soon start seeing this in all logs in autopkgtest-cloud soon. Let us know if you run into any issues. If you use autopkgtest from source (both ubuntu-devel and from debian) and update your master branch, you will also start to see this in your log files. *Ubuntu QA* (Brian Murray, Paride Legovini & Tim Andersson) *The upstream MP can be seen here:* https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/229 *The change fixes this debian bug from a little while ago:* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977037 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: We need nominees for the Developer Membership Board
Hey Laney, I would consider nominating for this, but given timezones and the current meeting times, half the meetings would be impossible for me to attend, the other half run at about 5-6am my time. Would there be flexibility to changes those slightly? Tim On 11/03/16 20:10, Iain Lane wrote: > Hi, > > We have only received 2 nominees for the DMB to fill the 5 seats which > just became vacant. The 5 members all expired off the team yesterday, so > we are currently *without a DMB*. > > Please could at least 3 more developers (~ubuntu-dev members) see if you > can find the time to serve for 2 hours every 2 weeks for the next 2 > years (all the '2's...)? Without a properly functioning board there is > no path for new contributors to get upload rights or developer > membership. > > https://wiki.ubuntu.com/DeveloperMembershipBoard > > Cheers, > > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Google Code In Opportunities
Hi Nicholas, Are flavours able to participate in this mentorship? Quite certain Ubuntu GNOME could come up with a handful or more of tasks, that fit into those requirements. Tim On 25/11/15 07:46, Nicholas Skaggs wrote: > Hello everyone! As you may have heard, ubuntu has been accepted as a > mentoring organization for Google Code In (GCI). GCI is a opportunity for > high school students to learn about and participate in open source > communities. Mentoring organizations create tasks and review the students > work. Google then provides rewards for those students who do the best work. > The contest is very similar to GSOC, but is much shorter, and > isn't intended for intense mentoring. The contest runs from December 7, 2015 > to January 25, 2016. > > As part of being a mentoring organization, we are committed to creating 100+ > tasks for students to work on during GCI. This involves finding > mentors who are willing to write up tasks, and agree to answer questions and > review the task when it's complete. A task is a simple item of > work that can be completed in 2-5 hours. As a mentor, it's not intended for > you to train or teach any skills; the students should have those > skills before attempting the task. You can find a full list of details about > mentoring and what it entails here[1], as well as on the > community portal that describes our role and goals for the contest[2]. You > can create a be a mentor for as little as a single task, and we > appreciate all the tasks and mentors we get. . > > In short, this is an excellent opportunity to reach high school students and > inform them about ubuntu and the opportunities they have within > ubuntu and open source. I hope you consider taking part. If you have any > questions or would like to volunteer, don't hesitate to get in touch > with myself, Alan Pope, or José Antonio Rey who are acting as mentors for the > organization. Look for some new faces in ubuntu soon! > > Thanks for your consideration, > > Nicholas > > 1. https://wiki.ubuntu.com/GoogleCodeIn > 2. http://community.ubuntu.com/contribute/google-code-in/ > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
patch pilot report
My first shift as a community pilot ;) Here is what I got done in between lots of distractions on IRC! Sync gnome-backgrounds 3.18.0-1 (universe) from Debian unstable (main) - http://pad.lv/1510696 - Synced "Cancel", "Next", and "Sign In" functioning incorrectly on login or locked screen in "Sign In?" section - http://pad.lv/1479014 - marked won't fix, not sru'ing 7 patches this late into vivid! [SRU] trying to overwrite '/usr/bin/skip-tracker', which is also in package python-tempest-lib - http://pad.lv/1461573 - This is fixed in Xenial and Wily, doesnt seem critical enough to SRU into vivid this late in its lifecycle. Removed from queue. Please sync libcommons-net-java (?) 3.3-2 from Debian unstable (main) - http://pad.lv/1510663 - Removed sponsors, has been synced waiting NEW approval Update gnome-desktop3 to 3.18.1 - http://pad.lv/1510813 - Reviewed merge, approved. In NEW queue atm, but could wait for e-d-s and poppler transition to land before starting another one. Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: upower 0.99
On 16/06/14 18:49, Jackson Doak wrote: > Upower 0.99 is now required by gnome 3.12. As a result, we are trying to have > the transition completed this cycle. The new release changes the > SONAME, changed from the "changed" signal to "notify" as well as the function > signature, and drops suspend support (which systemd now > handles). This means nearly all packages that use upower will need changes. > > A number of upstreams already have fixes (gnome, xfce, mate, cairo-dock, and > telepathy) but a few packages need work. If anyone involved with > sugar or kde could let me know the status, that would be great. Just to add here, as far as canonical components go, powerd, indicator-power and python-dbusmock need porting. > > The bug report is at https://launchpad.net/bugs/1330037 . > > wmbattery will need removal, as it is orphaned and broken with new linux > anyway > > Jackson > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] 12.04.5
On 02/07/2014 09:00 AM, Leann Ogasawara wrote: > Hi All, > > With 12.04.4 having just released, I wanted to propose the idea of > having a 12.04.5 point release for Precise. > +1 -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Removing reiserfs support from the installer
On 09/12/2013 08:47 AM, Dmitrijs Ledkovs wrote: > On 12 September 2013 16:37, Colin Watson wrote: >> Debian has removed reiserfs support from its kernel packages and its >> installer (http://bugs.debian.org/717517). I don't really want to keep >> maintaining it without Debian; for instance it would mean adding support >> for http://bugs.debian.org/696123 as an Ubuntu-specific patch once we >> have the underpinnings done. Does anyone feel desperately that we have >> to keep this or shall I just go ahead and drop it? >> > > I've informally raised this with #ubuntu-kernel team on irc / > one-to-one conversions as well. I think the rough consensus was that > we should follow suite and also drop reiserfs support from both our > kernel configuration and installer. > Not sure if the kernel configuration should be kept in-tact because of > hardware enablement stack backports, I would hope that it wouldn't be > necessary. > Ditto other kernel modules that were dropped from the debian kernel > config at the same time as reiserfs. > > I agree that reiserfs support should simply be dropped, and ideally > should have been done earlier in the cycle when the same change was > done in debian. > > Regards, > > Dmitrijs. > As was pointed out on IRC this is the original email from Ben Hutchings regarding his decision to remove reiserfs from kernel udebs: https://groups.google.com/forum/#!topic/linux.debian.maint.boot/QO187Szy2_o I'm not really in favor of entirely dropping reiserfs support from the kernel, e.g., CONFIG_REISERFS_FS=n. Doubtless, there are still folks out there using it that would be pretty annoyed on upgrading to find they can no longer access their file system. I am, however, OK with dropping resierfs from any udebs that we produce. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Release engineering sprint, July 2013
On 08/08/2013 08:45 AM, Colin Watson wrote: > On Mon, Jul 29, 2013 at 12:43:11PM +0100, Colin Watson wrote: >> A noticeable amount of time here will be improved by pending hardware >> upgrades. Adam spent some sprint time working on the installation of >> new Calxeda systems; we don't know how much those will shave off the >> livefs build phase (currently 52m or so) but it wouldn't be a surprise >> if they removed 20m or so, and the current Panda boards occasionally >> corrupt data which causes extra delays while people debug them. > > The Calxeda builders are now deployed and in service, both for package > building and live filesystem building. My test live filesystem build > ran in 30 minutes. > > Thanks to Adam and a cast of several sysadmins for getting this sorted > out. > Saucy armhf kernel builds dropped from 18 hours to approx 5. I'm liking that trend. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Update ibus to 1.5 in saucy?
On 10/07/13 03:23, Sebastien Bacher wrote: > Before doing the update I wanted to check if anyone has an opinion on the > update (we don't have so many ibus users in the desktop team which > means we might be overlooking issues) and if the upgrade is fine for the > other flavors. > > +1 for Ubuntu GNOME. input switching has been broken in gnome-shell since 3.6, basically waiting for updated ibus. - Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: indicator-weather broken, should we drop it from raring?
On 20/04/13 04:25, Barry Warsaw wrote: > On Apr 19, 2013, at 06:36 PM, Sebastien Bacher wrote: > >> I guess you have a configured indicator with your location, right? ;-) > I do! But I fear I might forget my umbrella the next time I travel out of my > home location. :) > >> The current bug makes impossible to configure it/add a location, so it's >> basically useless as a new package to install (or you need to get the woeid >> code and tweak the config by hand, but if you do that you can probably as >> well get the package from a ppa or launchpad library). >> >> The users who have it installed can keep it, nothing is going to remove it > >from your system because we drop it from the archive. > > That's a good point. Given that as a fresh install, it's currently pretty > useless, I suppose it makes sense to remove it. OTOH, I don't like making > this decision so close to the release. Isn't there a chance that someone will > be motivated to do an SRU to fix the most egregious problems later? > > -Barry > Not really an option for Raring, but perhaps it would make sense to use libgweather as the backend for the applet. That has received a fair bit of attention during the 3.8 cycle due to the new gnome-weather app. I believe it has Yahoo and Yr.no weather providers. Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding Spidermonkey 17esr to Raring
yes, indeed. But debian will be in for some confusion, they current package the non-standalone engine as libmozjs17d etc (as part of iceweasel). - Tim On 06/03/13 18:06, Dmitry Shachnev wrote: > Yes, a new source package (mozjs17) makes sense I think. As the > current package is in sync with Debian, maybe it'll be a good idea to > get the new one uploaded there, as well. > > -- > Dmitry Shachnev > > On 3/6/13, Tim wrote: >> Its currently at RC, due for release in the next few days. >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c44 >> >> I have spent quite a bit of time, patching their build system etc, to make >> this happen, but still it has taken forever to get to this point. >> >> - Tim >> >> On 06/03/13 17:29, Dmitry Shachnev wrote: >>> According to <https://developer.mozilla.org/en-US/docs/SpiderMonkey>, >>> "SpiderMonkey 1.8.5 is the most recent standalone source code >>> release", and that's what we already have in Debian/Ubuntu >>> (src:mozjs). I also don't see anything newer on their FTP. >>> >>> Are you sure there was a new *standalone* release? >>> >>> -- >>> Dmitry Shachnev >>> >>> On 2/28/13, Tim wrote: >>>> Hi, >>>> Finally after about 2 years Mozilla are releasing a version of the >>>> standalone spidermonkey engine. This release is based off the engine >>>> from >>>> Firefox 17esr. It has taken quite a long time to get to this stage, and >>>> I >>>> was hoping it would happen earlier in the cycle, but I would still >>>> like to get this into raring if at all possible. My motivation for this >>>> is >>>> the great improvements it brings to gnome-shell. >>>> >>>> This release fixes a number of high impact issues including greater >>>> performance, greatly reduces memory leaks, and finally solves the long >>>> standing and quite common issue with Garbage Collection deadlocks. I >>>> ported >>>> gjs to this engine a few months ago and while it hasnt landed >>>> upstream yet, the plan for 3.8 is to branch gjs and release 2 versions >>>> of >>>> gjs, one for each engine. This new gjs is API compatible with 3.6, >>>> and in fact works great with gnome-shell 3.6, so essentially it would be >>>> great to bring these improvements into raring. >>>> >>>> There are big API/ABI breaks in this release compared to previous 185 >>>> release. Currently none of the other rdepends have been ported as far as >>>> I >>>> know, and its probably not realistic to get all of them ported this >>>> cycle. >>>> Mostly the porting is easy enough, however it does result in quite >>>> large diff's so would really want to be done upstream, as it would >>>> probably >>>> be a nightmare to maintain these as Distro patches. Add to this >>>> CouchDB is fundamentally incompatible with this new release, due to >>>> their >>>> use of illegal javascript syntax (in 185 enforcement of this was >>>> optional) as a core feature of their user scripts. >>>> >>>> Given the above, replacing/upgrading the old package is simply not going >>>> to >>>> be feasible this cycle. I propose adding this new engine as an >>>> additional library, I discussed this on IRC a bit with seb128 and >>>> chriscoulson, however they were unsure about whether this is something >>>> that >>>> could want to go ahead and suggested that I raise it here for more >>>> widespread discussion. Main issues raised were overall its a low >>>> priority >>>> but >>>> also some security concerns. >>>> >>>> Hopefully now with all the patches on their way into the upstream >>>> mozilla >>>> code-base, future releases will be more regular, they will be tracking >>>> the firefox esr releases. Although not really guaranteed just yet, it is >>>> planned for some point releases over the life of each version. >>>> Probably issues with overlapping versions will continue to be a problem >>>> until the JS C API settles down, next release 24 will again break all >>>> rdepends. >>>> >>>> - Tim >>>> >>>> >>>> -- >>>> ubuntu-devel mailing list >>>> ubuntu-devel@lists.ubuntu.com >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >>>> >> -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding Spidermonkey 17esr to Raring
Its currently at RC, due for release in the next few days. https://bugzilla.mozilla.org/show_bug.cgi?id=735599#c44 I have spent quite a bit of time, patching their build system etc, to make this happen, but still it has taken forever to get to this point. - Tim On 06/03/13 17:29, Dmitry Shachnev wrote: > According to <https://developer.mozilla.org/en-US/docs/SpiderMonkey>, > "SpiderMonkey 1.8.5 is the most recent standalone source code > release", and that's what we already have in Debian/Ubuntu > (src:mozjs). I also don't see anything newer on their FTP. > > Are you sure there was a new *standalone* release? > > -- > Dmitry Shachnev > > On 2/28/13, Tim wrote: >> Hi, >> Finally after about 2 years Mozilla are releasing a version of the >> standalone spidermonkey engine. This release is based off the engine from >> Firefox 17esr. It has taken quite a long time to get to this stage, and I >> was hoping it would happen earlier in the cycle, but I would still >> like to get this into raring if at all possible. My motivation for this is >> the great improvements it brings to gnome-shell. >> >> This release fixes a number of high impact issues including greater >> performance, greatly reduces memory leaks, and finally solves the long >> standing and quite common issue with Garbage Collection deadlocks. I ported >> gjs to this engine a few months ago and while it hasnt landed >> upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of >> gjs, one for each engine. This new gjs is API compatible with 3.6, >> and in fact works great with gnome-shell 3.6, so essentially it would be >> great to bring these improvements into raring. >> >> There are big API/ABI breaks in this release compared to previous 185 >> release. Currently none of the other rdepends have been ported as far as I >> know, and its probably not realistic to get all of them ported this cycle. >> Mostly the porting is easy enough, however it does result in quite >> large diff's so would really want to be done upstream, as it would probably >> be a nightmare to maintain these as Distro patches. Add to this >> CouchDB is fundamentally incompatible with this new release, due to their >> use of illegal javascript syntax (in 185 enforcement of this was >> optional) as a core feature of their user scripts. >> >> Given the above, replacing/upgrading the old package is simply not going to >> be feasible this cycle. I propose adding this new engine as an >> additional library, I discussed this on IRC a bit with seb128 and >> chriscoulson, however they were unsure about whether this is something that >> could want to go ahead and suggested that I raise it here for more >> widespread discussion. Main issues raised were overall its a low priority >> but >> also some security concerns. >> >> Hopefully now with all the patches on their way into the upstream mozilla >> code-base, future releases will be more regular, they will be tracking >> the firefox esr releases. Although not really guaranteed just yet, it is >> planned for some point releases over the life of each version. >> Probably issues with overlapping versions will continue to be a problem >> until the JS C API settles down, next release 24 will again break all >> rdepends. >> >> - Tim >> >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding Spidermonkey 17esr to Raring
I guess this got lost in the flood of Rolling Release discussions Is there any reason why we couldnt have both versions of spidermonkey in the archive? It is simply not feasible to port all rdepends to the new engine, and I guess most other upstreams (apart from gnome) arent going to start porting things until new engine is readily available in distros. - Tim On 28/02/13 12:33, Tim wrote: > Hi, > Finally after about 2 years Mozilla are releasing a version of the > standalone spidermonkey engine. This release is based off the engine from > Firefox 17esr. It has taken quite a long time to get to this stage, and I was > hoping it would happen earlier in the cycle, but I would still > like to get this into raring if at all possible. My motivation for this is > the great improvements it brings to gnome-shell. > > This release fixes a number of high impact issues including greater > performance, greatly reduces memory leaks, and finally solves the long > standing and quite common issue with Garbage Collection deadlocks. I ported > gjs to this engine a few months ago and while it hasnt landed > upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of > gjs, one for each engine. This new gjs is API compatible with 3.6, > and in fact works great with gnome-shell 3.6, so essentially it would be > great to bring these improvements into raring. > > There are big API/ABI breaks in this release compared to previous 185 > release. Currently none of the other rdepends have been ported as far as I > know, and its probably not realistic to get all of them ported this cycle. > Mostly the porting is easy enough, however it does result in quite > large diff's so would really want to be done upstream, as it would probably > be a nightmare to maintain these as Distro patches. Add to this > CouchDB is fundamentally incompatible with this new release, due to their use > of illegal javascript syntax (in 185 enforcement of this was > optional) as a core feature of their user scripts. > > Given the above, replacing/upgrading the old package is simply not going to > be feasible this cycle. I propose adding this new engine as an > additional library, I discussed this on IRC a bit with seb128 and > chriscoulson, however they were unsure about whether this is something that > could want to go ahead and suggested that I raise it here for more widespread > discussion. Main issues raised were overall its a low priority but > also some security concerns. > > Hopefully now with all the patches on their way into the upstream mozilla > code-base, future releases will be more regular, they will be tracking > the firefox esr releases. Although not really guaranteed just yet, it is > planned for some point releases over the life of each version. > Probably issues with overlapping versions will continue to be a problem until > the JS C API settles down, next release 24 will again break all > rdepends. > > - Tim > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Adding Spidermonkey 17esr to Raring
Hi, Finally after about 2 years Mozilla are releasing a version of the standalone spidermonkey engine. This release is based off the engine from Firefox 17esr. It has taken quite a long time to get to this stage, and I was hoping it would happen earlier in the cycle, but I would still like to get this into raring if at all possible. My motivation for this is the great improvements it brings to gnome-shell. This release fixes a number of high impact issues including greater performance, greatly reduces memory leaks, and finally solves the long standing and quite common issue with Garbage Collection deadlocks. I ported gjs to this engine a few months ago and while it hasnt landed upstream yet, the plan for 3.8 is to branch gjs and release 2 versions of gjs, one for each engine. This new gjs is API compatible with 3.6, and in fact works great with gnome-shell 3.6, so essentially it would be great to bring these improvements into raring. There are big API/ABI breaks in this release compared to previous 185 release. Currently none of the other rdepends have been ported as far as I know, and its probably not realistic to get all of them ported this cycle. Mostly the porting is easy enough, however it does result in quite large diff's so would really want to be done upstream, as it would probably be a nightmare to maintain these as Distro patches. Add to this CouchDB is fundamentally incompatible with this new release, due to their use of illegal javascript syntax (in 185 enforcement of this was optional) as a core feature of their user scripts. Given the above, replacing/upgrading the old package is simply not going to be feasible this cycle. I propose adding this new engine as an additional library, I discussed this on IRC a bit with seb128 and chriscoulson, however they were unsure about whether this is something that could want to go ahead and suggested that I raise it here for more widespread discussion. Main issues raised were overall its a low priority but also some security concerns. Hopefully now with all the patches on their way into the upstream mozilla code-base, future releases will be more regular, they will be tracking the firefox esr releases. Although not really guaranteed just yet, it is planned for some point releases over the life of each version. Probably issues with overlapping versions will continue to be a problem until the JS C API settles down, next release 24 will again break all rdepends. - Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: GCC 4.7, STL and binary compatibility of objects built with different language standards
On 13/06/12 04:47, Didier Roche wrote: Le 12/06/2012 18:22, Matthias Klose a écrit : On 08.06.2012 17:10, Chris Coulson wrote: I've just finished debugging a Unity crash which occurs when we try a test rebuild of Unity and Nux with GCC4.7 in quantal. Although the original issue was caused by mixing 2 C++ ABI's (because libsigc hasn't been rebuilt yet in quantal), it was no better even after rebuilding libsigc with the quantal toolchain. correct, afaics there is no ABI incompatibility between 4.6 and 4.7, but between c++98 and c++0x/c++11. c++98 and c++0x/c++11 code should not be mixed in one binary, and best avoided in a distribution. This here is the kicker. What is happening is, in GCC4.7, std::_List_base::_List_impl has a data member which only exists for compilation units that are built with -std=c++0x (_M_size). This means that the STL ABI is dependent on the language standard. This obviously causes issues when a process loads libraries that are built with different language standards and which pass std::list's across public API's indeed, this is the one issue, which is new in 4.7, so you didn't see it in precise with 4.6. In the Unity case, both Unity and Nux are built with -std=c++0x, but they use libsigc which is not built with it and which exposes STL objects in its public API. Rebuilding libsigc locally with -std=c++0x is sufficient to make Unity work properly. However, uploading this will probably break anything else in the archive using libsigc which isn't built with -std=c++0x, so I'm not sure of the best way to proceed. both -std=c++0x and -std=c++11 are still marked as experimental. So don't use them :-/ I don't think that building c++ libraries for both modes is the right approach, so let's avoid that for now, until the c++11 support in 4.7 is more complete, and maybe not experimental. Hmm... not entirely sure about this. I'm hoping we can find a different solution. Yes, indeed, the situation is suboptimal. as this feature is marked as experimental. However, I'm afraid that we have an issue about this. Indeed, Unity is written using a lot of c++11 facilities, and taking it out won't be trivial now AFAIK. I'm CCing Tim who can give more information about it. We started using the --std=c++0x flag about 10 months ago. A large amount of the code that has been added over that time is using the more stable parts of the C++11 standard: * auto variable type * range based for loops * strong enums * lambda functions Taking those out would be a massive task. Tim -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Quantal: End of the line for i386 non-PAE
On 05/08/2012 08:13 AM, Phillip Susi wrote: On 5/2/2012 10:57 AM, Tim Gardner wrote: Any ideas on how we might allow PAE capable CPUs to upgrade? Is this the job of update-manager ? It seems likely that Debian must have encountered this issue before. With a Replaces: line in the control file of the new kernel? The suggestion offered yesterday in the kernel flavours session was to add a pre-install hook in the meta package to determine if the CPU was PAE capable, and to stop the upgrade if not. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Quantal: End of the line for i386 non-PAE
As decided by the Tech Board, 12.04 is the last release to have the i386 non-PAE kernel flavour. So, how do we upgrade folks ? IIRC a non-PAE kernel was installed because 1) there was less then 4GB RAM, or 2) their CPU did not have PAE support. The folks in case 2 are simply out of luck (and no longer supported). I have removed the non-PAE kernel meta package from Quantal that would allow a non-PAE upgrade. Its likely that folks attempting an upgrade to Quantal will be left with a Precise kernel. Any ideas on how we might allow PAE capable CPUs to upgrade? Is this the job of update-manager ? It seems likely that Debian must have encountered this issue before. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
Dustin, There is a blueprint started for cleaning old kernels. Perhaps you should add your thoughts to it. https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-clean-old-kernels rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Drop Non-smp PowerPC Kernel Flavor
On 03/15/2012 06:02 AM, Colin Watson wrote: On Thu, Mar 15, 2012 at 11:02:09AM +0800, Jeremy Kerr wrote: Hi all, We consulted Jeremy Kerr about this. He says that an SMP kernel will run on all 32 bit powerpc platforms, including non-SMP. To clarify: the hardware supported by the powerpc and powerpc-smp flavours is almost identical. The differences probably don't matter Ubuntu users, as it'll be obscure hardware. I've CC-ed benh in case he wants to correct me on this one. However, the SMP kernel supports (surprise!) bringing up>1 CPU on machines that have>1 CPU. With a UP kernel on these machines, the other CPUs are left doing nothing. The main class of 32-bit SMP powerpc machines are the Apple dual-G4s. So, since the hardware coverage is essentially the same, but we get SMP support on SMP machines, I'd say that we would prefer the powerpc-smp kernel over the powerpc flavour. OK, that all makes sense, and I agree based on that. I'd forgotten about the dual G4 class. I would switch the installer over to powerpc-smp today, then, except that the kernel doesn't ship powerpc-smp udebs yet, only powerpc and powerpc64-smp. Can somebody fix that so that I can do this transition? I'll take care of it. Leann plans to upload later in her day Friday, so the kernel ought to be available by Monday. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] Drop Non-smp PowerPC Kernel Flavor
On 03/14/2012 11:00 AM, Colin Watson wrote: On Wed, Mar 14, 2012 at 09:52:01AM -0700, Leann Ogasawara wrote: The Ubuntu Kernel Team has been evaluating some of the current maintenance burdens for the upcoming Precise Pangolin 12.04 LTS release. One area which would reduce the maintenance costs would be to drop the non-smp PowerPC kernel flavor. There are currently three PowerPC flavors: Making the associated installer changes shouldn't be a big deal, but I suggest you ask the Xubuntu and Lubuntu communities about this since a good proportion of powerpc users are there. * non-smp (linux-image-powerpc) * smp (linux-image-powerpc-smp) * smp-64 (linux-image-powerpc64-smp) It's not clear to me whether it would make more sense to drop -powerpc or -powerpc-smp. My memory is that -powerpc-smp was significantly less used and would be a better candidate for removal. Do you have notes on which hardware is covered by -powerpc-smp that can't use -powerpc64-smp? We consulted Jeremy Kerr about this. He says that an SMP kernel will run on all 32 bit powerpc platforms, including non-SMP. I don't recall discussing if the 64 bit SMP kernel would run on all SMP capable hardware. That combination is not possible on all x86 platforms, so I was likely biased. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
On 03/01/2012 03:08 PM, Gary Poster wrote: Hi. aufs was reliable for us on Oneiric when creating ephemeral lxc instances based on an underlying template. The most recent overlayfs issue that we discovered is today's https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 The summary is that, within an overlayfs, this fails: gary@garubtosh:~/tmp$ touch 3 gary@garubtosh:~/tmp$ chmod 0444 3 gary@garubtosh:~/tmp$ ln 3 4 ln: failed to create hard link `4' => `3': Operation not permitted That error makes xvfb unable to start, in this particular case. I'd feel a *lot* more comfortable if aufs were still around, in case we end up not finding the next overlayfs bug until it is too late for our project's delivery. Thank you, Gary In light of the concerns about overlayfs being sufficiently cooked in time for Precise, Andy Whitcroft and I have decided to re-enable aufs. We will continue to advocate for dropping aufs in favor of a sufficient upstream solution at each development cycle. This means that aufs _will_ disappear in future backported LTS kernels. In other words, don't bet your business on aufs. I am speaking directly to the lxc and server folks. aufs has _one_ maintainer, is enormously complex, is difficult to integrate with each new kernel version, and will _never_ be accepted upstream. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Distro-provided mechanism to clean up old kernels
On Fri, Feb 17, 2012, at 07:23 AM, Martin Pitt wrote:
> linux-headers-* is already covered by apt-get autoremove, which is
> good. Perhaps we can mark older kernels as auto-removable as well, so
> that without any other tools you at least have one command to clean
> them up all?
Are you sure about this? I did a test and I don't think that autoremove
removes the linux-headers-*:
$ dpkg -l | awk '/^ii/{print $2}' | grep ^linux
linux-firmware
linux-generic
linux-headers-3.0.0-14
linux-headers-3.0.0-14-generic
linux-headers-3.0.0-15
linux-headers-3.0.0-15-generic
linux-headers-3.0.0-16
linux-headers-3.0.0-16-generic
linux-headers-generic
linux-image-3.0.0-15-generic
linux-image-3.0.0-16-generic
linux-image-generic
linux-libc-dev
linux-sound-base
$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 10 not upgraded.
I'd like to suggest instead the following modifications to the script
that was posted before:
#!/bin/bash
OLDKERNEL=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | awk
'{print "linux-image-" $0}')
OLDHEADERS=$(ls -tr /boot/vmlinuz-* | head -n -2 | cut -d- -f2- | sed
's/-generic//g' | awk '{print "linux-headers-" $0}')
if [ -n "$OLDKERNEL" -o -n "$OLDHEADERS" ]; then
sudo apt-get -q remove --purge $OLDKERNEL $OLDHEADERS
fi
(note that this version is not fully automatic as apt will prompt the
user before removing packages)
Tim
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boot hangs after Oneiric update
Barry Warsaw ubuntu.com> writes: > > On Jul 26, 2011, at 04:43 PM, Barry Warsaw wrote: > > >I just updated my laptop VM and now the boot hangs. Here's the status from > >Landscape about what got updated. Note that this is an Oneiric machine > >that's been working for quite a while. It's gotta be one of the packages in > >this list, because the previous update I did via Landscape also required me > >to > >reboot and that worked out just fine. > > > >The last thing I see is "Checking battery state... [OK]" > > > >Any thoughts? Anybody else seeing boots hang now with an up-to-date Oneiric? > > Seb helped out in #ubuntu-devel. Apparently I was a little to eager for > update/reboot. If you hit this problem, switch to a vt and apt-get install > lightdm-gtk-greeter. > > -Barry > Installing lightdm-gtk-greeter works, but I also found that the problem was that unity-greeter wasn’t installed. I think the problem was that unity-greeter was being called by the /etc/lightdm/lightdm.conf file but since it wasn’t installed, it was just stalling. Anyway, by doing a: sudo apt-get install unity-greeter it fixed the situation and the machine boots. I also have the lightdm-gtk-greeter installed, but it isn’t being used. I am not sure why the unity-greeter wasn’t installed. My upgrade failed and I had to restart it, but for some reason, starting the upgrade over didn’t solve the problem. I wonder if maybe the upgrade installer didn’t like my hardware or something. To check to see if your unity-greeter is installed, run the following command: dpkg --get-selections | grep unity-greeter -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Smoke testing of Precise X server bits
On 01/19/2012 11:43 PM, Chase Douglas wrote: On 01/20/2012 03:01 AM, Chase Douglas wrote: Hi all, We have everything ready (almost) for the upload of the X server into Precise. It includes X server 1.11 plus the input stack from 1.12. It also includes a bunch of interdependent packages that would break if you were only to update your X server. Here's the known issues with the PPA: * No utouch-geis support, which means most of your gestures won't work - Will be fixed by feature freeze * Multitouch in Qt from indirect devices (e.g. trackpads) is broken - Will be fixed in next Qt upload *after* we push these packages * Qt is still building for armel, so don't test this on armel yet * A security hole will kill your screen saver if you type Ctrl+Alt+KP_Multiply - Will be fixed in xkeyboard-config upload in the next couple hours Notably, xserver-xorg-input-synaptics has a large patch added in today for multitouch support. The X synaptics module is used for all trackpads. Please test that your trackpad is behaving sanely. We are mostly looking for blocker bugs right now (random X server crashes, really obnoxious behavior, etc.). Please reply with any such bugs you find. Oops, I forgot to mention the packages are in ppa:canonical-x/x-staging. The following should get you set up for testing: $ sudo add-apt-repository ppa:canonical-x/x-staging $ sudo apt-get update $ sudo apt-get upgrade I don't think you need to dist-upgrade for this as there shouldn't be any new packages or packages needing to be removed, but I'm not entirely certain. -- Chase Will any of these updates address cut and paste on a Mac touchpad ? It appears to be impossible to select text without using an external mouse. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for testing: Upstart 1.4 in Ubuntu
On 12/22/2011 03:01 PM, James Hunt wrote: Hi All, We're looking to land Upstart 1.4 in Ubuntu Precise early January 2012. If you have an Ubuntu Precise test system [1] and you'd like to help with testing these new features, read on... = New Features = The two main new features are: - new 'setuid' and 'setgid' stanzas Allows you to specify the user and group a job runs as (this should help minimize the intricate su/sudo/start-stop-daemon command-lines) - Logging of job output for system jobs [2] Job logging is enabled by default in 1.4. Since this is the first version of Upstart that writes to *any* files, this is quite a big change. 3 new command-line options have been added to support this feature: '--no-log' (disable logging entirely) '--logdir=DIR' (specify alternate log directory) '--default-console=VALUE' (specify default value for 'console' stanza). = How to Obtain the Upstart 1.4 Package = please add the following 'upstart-job-logging' PPA [3] to your system and give it a spin: sudo add-apt-repository ppa:jamesodhunt/upstart-job-logging = Feedback = Please provide feedback via a bug report: https://bugs.launchpad.net/ubuntu/+source/upstart/+filebug = Further Details on Features = Full details on these features can be found in the usual places: - init(5) - init(8) - cookbook: http://upstart.ubuntu.com/cookbook/#console-log http://upstart.ubuntu.com/cookbook/#configuration http://upstart.ubuntu.com/cookbook/#setuid http://upstart.ubuntu.com/cookbook/#setgid Thanks for your help. Kind regards, James. [1] - Usual caveats apply: do *not* install this on any critical systems. [2] - Two limitations to be aware of: - logging *only* currently applies to system jobs, - any job that produces output and ends *before* the disk becomes writeable will not currently have output logged. Note: both limitations are currently being addressed. [3] - https://launchpad.net/~jamesodhunt/+archive/upstart-job-logging -- James Hunt http://upstart.ubuntu.com/cookbook http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf James - The kernel team has plenty of Precise systems that we can update. Given the fundamental nature of Upstart, is there any way to recover short of reinstalling if it completely breaks the boot ? Can we stash the original /sbin/init somewhere and hack the grub command ? rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/28/2011 11:44 AM, Kees Cook wrote: On Mon, Nov 28, 2011 at 09:40:53AM -0700, Tim Gardner wrote: non-pae has a ginormous and ugly NX emulation patch This is about dropping non-PAE support, not dropping non-NX support. The NX emulation patch must remain in the kernel since a large number of systems have PAE but not NX. You can see this in the table here: https://wiki.ubuntu.com/Security/Features#nx Dropping non-PAE just eliminates the top line in that table. NX-emu will still be needed. I guess you are correct. I naively assumed that execute-disable was introduced with PAE in the Pentium Pro series. However, it did not appear in Intel CPUs until Pentium 4 (approx Q1 2005). AMD had it from the beginning in the Athlon series. that has consumed substantial maintenance resources in the past, I'm also curious about this claim, as you've expressed to me in the past that carrying it has been surprisingly trivial. In fact, since I'm the one maintaining it these days, it's actually going to require 0 resources from Canonical. ;) http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/nx-emu I did say "in the past". I remember encountering several issues with the early implementation, as well as maintenance hassles while 32 and 64 bit arch support was converging. I would characterize the NX emulation patch as deeply intrusive, arguably one of the more complex patches against the core of Linux that we carry. Its a moot point given the model gap between PAE and NX introduction. The kernel team has limited resources. Obviously I want to apply what resources we have to the problems that affect the most important platforms. Furthermore, I anticipate new ARM flavours in the coming months which will take up any slack afforded by the loss of non-PAE. I'm curious why pushing non-PAE to universe and leaving it in the main linux source package is a burden? Then people using non-PAE get automatic security updates without any hassle on anyone's part. This is what the Ubuntu Security Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034457.html as well as the Ubuntu Platform Team manager wants: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034463.html I'm not convinced there's enough evidence to say that dropping it from the main linux source package will actually save any time at all. Dropping this flavour saves 5 minutes per build on a 4-way 80 thread server, which for some of the team can add up to quite a bit of time over the course of a day. Its one less variant that needs to be tested in Q/A, and its one less flavour we have to mess with in our meta and LBM packages. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/09/2011 02:43 PM, Tim Gardner wrote: Per discussion at UDS the kernel team is proposing to drop the non-PAE i386 flavour. The upgrade path for non-PAE users will be the PAE kernel. Those CPUs that do not have i686 and PAE support will be orphaned. To the best of my knowledge, these include Intel CPUs prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no laptop or desktop class CPUs being produced that do not meet these minimum requirements. Before I do something that is difficult to revert, I would like to hear from the development community why we should continue to maintain a kernel flavour that is (in my opinion) getting increasingly low utilization. It is my feeling that an extremely high percentage of users of the non-PAE kernel have a CPU that is PAE capable. If there is sufficient community demand (and support), I would be willing to sponsor the first non-PAE kernel upload to Universe. https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview We'll be conducting a similar survey for powerpc. rtg P.S. For those of you that are totally confused by this email, PAE (Physical Address Extension) was an addition to 32 bit x86 CPUs that allowed them to address more then 4GB physical memory. http://en.wikipedia.org/wiki/Physical_Address_Extension Thank you to everyone who responded to this thread. To summarize, no compelling hard evidence has been presented to change my original decision. I am opposed to supporting non-PAE CPUs for another 5 years. Colin King has developed power and performance profiling data that indicate the differences between PAE and non-PAE are negligible. I've also discussed this with OEM regarding possible future LTSP projects and have concluded it will have no detrimental impact. Every flavour maintained by the kernel team has an incremental impact, especially when it comes to test builds and the full packaging cycle. Every flavour must also be tracked by meta packages. Every flavour has its unique class of bugs; non-pae has a ginormous and ugly NX emulation patch that has consumed substantial maintenance resources in the past, not to mention all of the bugs complaining about memory holes and the 4Gb limit. The kernel team has limited resources. Obviously I want to apply what resources we have to the problems that affect the most important platforms. Furthermore, I anticipate new ARM flavours in the coming months which will take up any slack afforded by the loss of non-PAE. It is my recommendation that folks running PAE incapable CPUs stay on Lucid (10.04), a release for which they'll still receive more then 3 years of official support. If you feel passionately that I've made an incorrect decision, then I suggest contacting the Ubuntu technical board. https://wiki.ubuntu.com/TechnicalBoard rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/10/2011 08:14 AM, Tim Gardner wrote: On 11/09/2011 03:14 PM, Colin Watson wrote: Does KVM work properly with PAE kernels at the moment? I've had trouble with it within the last six months, and when running server installations I've had to tweak them on the fly to install the generic kernel in order that I could boot the installed system. This just seems like a bug. If we don't address it early in this cycle, then what incentive would we have to address it during the 12.10 dev cycle? I tested this on Precise today using testdrive on a 32 bit PAE server kernel to host a 32 bit Precise PAE guest kernel. Similarly, I also tested using a 64 bit host and a 32 bit PAE guest kernel. Are those combinations sufficient ? rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
On 11/09/2011 03:14 PM, Colin Watson wrote: On Wed, Nov 09, 2011 at 02:43:28PM -0700, Tim Gardner wrote: Per discussion at UDS the kernel team is proposing to drop the non-PAE i386 flavour. The upgrade path for non-PAE users will be the PAE kernel. Those CPUs that do not have i686 and PAE support will be orphaned. To the best of my knowledge, these include Intel CPUs prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no laptop or desktop class CPUs being produced that do not meet these minimum requirements. Does KVM work properly with PAE kernels at the moment? I've had trouble with it within the last six months, and when running server installations I've had to tweak them on the fly to install the generic kernel in order that I could boot the installed system. This just seems like a bug. If we don't address it early in this cycle, then what incentive would we have to address it during the 12.10 dev cycle? Before I do something that is difficult to revert, I would like to hear from the development community why we should continue to maintain a kernel flavour that is (in my opinion) getting increasingly low utilization. I'd have thought we needed data here? As far as I can tell there hasn't been a mass produced non-PAE cpu in over 5 years that we (as a distro) care about. The consumer grade electronics lifecycle is _well_ below 5 years. Furthermore, the distro focus has been desktop with high performance 3D graphics and servers. Where do non-PAE CPUs fit in that world? There are better distro choices to fill that niche. I'm worried about dropping the kernel that's been the default during the installer for some time, in one step. If we want to switch the installer to generic-pae and then drop the non-PAE kernel in the next cycle if that works out well, I'd be happier with that approach; that gives us a much more graceful fallback plan in the event that our opinions are mistaken. I want to drop the non-PAE kernel _before_ the LTS. Otherwise we have to deal with the complexities of LTS backported kernels _not_ having the same flavour set as the released LTS kernel (something I'd prefer not to have to do). What do you think about dropping x86 32 bit kernels altogether for 14.04 ? By then we should have _really_ good multi-arch support, and the CPUs that we care about will all be 64 bit capable. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Dropping i386 non-PAE as a supported kernel flavour in Precise Pangolin
Per discussion at UDS the kernel team is proposing to drop the non-PAE i386 flavour. The upgrade path for non-PAE users will be the PAE kernel. Those CPUs that do not have i686 and PAE support will be orphaned. To the best of my knowledge, these include Intel CPUs prior to Pentium II, 400Mhz Pentium M, VIA C3, and Geode LX. As far as I know, there are no laptop or desktop class CPUs being produced that do not meet these minimum requirements. Before I do something that is difficult to revert, I would like to hear from the development community why we should continue to maintain a kernel flavour that is (in my opinion) getting increasingly low utilization. It is my feeling that an extremely high percentage of users of the non-PAE kernel have a CPU that is PAE capable. If there is sufficient community demand (and support), I would be willing to sponsor the first non-PAE kernel upload to Universe. https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview We'll be conducting a similar survey for powerpc. rtg P.S. For those of you that are totally confused by this email, PAE (Physical Address Extension) was an addition to 32 bit x86 CPUs that allowed them to address more then 4GB physical memory. http://en.wikipedia.org/wiki/Physical_Address_Extension -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boost bug, (was re: Boost transition status)
I'll see if i can track it down On Aug 8, 2011, at 12:18 PM, Scott Kitterman wrote: > On Sunday, August 07, 2011 11:00:35 PM Tim Hawkins wrote: >> can you make sure that this bug is fixed which was introduced in 1.44 and >> fixed in 1.47 is not present, its a killer, as it causes any app that uses >> the locale services to terminate with an exception. >> >> https://svn.boost.org/trac/boost/ticket/4688 >> >> It may be worth back porting the fix to 1.46 > > It wasn't clear from the discussion in the bug what change was made. It did > not appear that the upstream fix was any of the patches from the bug. If you > can find the change that is in 1.47, I can take a look at including it. > > Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Boost transition status
can you make sure that this bug is fixed which was introduced in 1.44 and fixed in 1.47 is not present, its a killer, as it causes any app that uses the locale services to terminate with an exception. https://svn.boost.org/trac/boost/ticket/4688 It may be worth back porting the fix to 1.46 On Aug 8, 2011, at 5:18 AM, Scott Kitterman wrote: > We announced at the start of the cycle moving from boost1.42 to boost.1.46 as > the default boost (and the only one in Main) with the objective of removing > boost1.42 from the archive. We are close. The six packages below are the > only ones left building against the 1.42 versions of the various boost -dev > packages. Could someone from the Ubuntu Desktop team please take a look at > updating these? > > I haven't checked all the binaries for rdepdends yet. That's my next step. > > Scott K > > $ reverse-build-depends libboost1.42-dev > Reverse Build-depends in universe: > - > > utouch-compiz > compiz-plugins-extra > > Found a total of 2 reverse build-depend(s) for libboost1.42-dev. > > Reverse Build-depends in main: > -- > > unity > libcompizconfig > nux > compiz-plugins-main > > Found a total of 4 reverse build-depend(s) for libboost1.42-dev. > > > $ reverse-build-depends libboost-serialization1.42-dev > Reverse Build-depends in universe: > - > > utouch-compiz > compiz-plugins-extra > > Found a total of 2 reverse build-depend(s) for libboost-serialization1.42-dev. > > Reverse Build-depends in main: > -- > > unity > libcompizconfig > compiz > compiz-plugins-main > > Found a total of 4 reverse build-depend(s) for libboost-serialization1.42-dev. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ARM: Dropping debian-installer armel+versatile kernel and netboot kernel
On 06/28/2011 03:57 PM, Loïc Minier wrote: On Tue, Jun 28, 2011, Tim Gardner wrote: I talked to Oliver Grawert about this. We are quite happy to drop the distro versatile flavour in favor of the Linaro packaged versatile-express kernel. Cool! I was about to followup on this, but didn't have time to cook an ubuntu-oneiric.git patch yet The only thing to be careful about is to keep generating linux-libc-dev on armel; all the versatile related stuff in the linux source package can go away IMO (Other impacted packages: debian-installer, I can take care of it, and maybe rootstock?) Dunno about rootstock. I'll go ahead and rip out the versatile flavour. Note that we still have an omap armel flavour, and we'll continue to generate the other armel binaries (such as linux-libc-dev). rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ARM: Dropping debian-installer armel+versatile kernel and netboot kernel
On 06/20/2011 03:17 PM, Loïc Minier wrote: Hey there On armel, we currently have a versatile flavor of the linux packages and a versatile netboot image of debian-installer. ARM Versatile was added in Debian a long time ago and then in Ubuntu because it could be run within QEMU. Nowadays in oneiric we have a linaro-vexpress kernel flavor and a corresponding d-i netboot image which supports ARM Versatile Express platforms. I'd like to kill the old versatile stuff: - ARM Versatile is an obsolete hardware platform (it got superseded by ARM RealView and then ARM Versatile Express, and even that is getting old) - versatile boards only supports up to ARMv6 CPUs but Ubuntu's userspace is ARMv7+, so we currently carry a patch to user an ARMv7 CPU in our linux versatile build, which is hackish. Vexpress supports SMP with ARMv7 CPUs, but can of course still run a v5 userspace like Debian's. Basically, Vexpress should be technically superior in all respects; notably, it can emulate 1024 MiB of RAM. - this would cut down the build time of "linux" on armel by one flavor out of two; perhaps from 28 hours to 14 hours - however, the kernel tree is slightly different: the linaro-vexpress flavor is based of linux-linaro which includes the Linaro kernel bits while versatile is built of the linux source package, with less patches over mainline Is there any objection to the removal of the versatile bits? NB: I'm seeing two annoying bugs with qemu/vexpress, which I think are present with versatile as well: qemu stalls regularly when accessing the emulated SD (LP #732223) but eventually proceeds; and some network I/O is corrupted or interrupted (LP #799757), but retrying allows to proceed. The latter prevents using things like debootstrap as it can't do any retries. Cheers, I talked to Oliver Grawert about this. We are quite happy to drop the distro versatile flavour in favor of the Linaro packaged versatile-express kernel. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu 11.04 Kernel Configurations
On 03/25/2011 05:49 PM, Scott Ritchie wrote: On 03/24/2011 11:09 AM, Leann Ogasawara wrote: Hi All, With the Ubuntu 11.04 Beta-1 release approaching, the Ubuntu Kernel Team felt this would also be an appropriate time to advertise what we intend to be the final kernel configurations for all the main distro and ports kernel flavors. The purpose is to expose the main configuration changes and provide pointers to the full configurations for those who are interested. To aid in the comparison of kernel config changes from Ubuntu 10.10 (Maverick) to Ubuntu 11.04 (Natty) we have generated a delta report [1]. We have also posted the full Ubuntu 10.10 and Ubuntu 11.04 configurations for each flavor [2]. Thanks, The Ubuntu Kernel Team [1] https://wiki.ubuntu.com/Kernel/Configs/MaverickToNatty [2] http://kernel.ubuntu.com/~kernel-ppa/configs Perhaps this is an appropriate time to ask, since I've been trying to ask for months now in mailing list/IRC but never apparently to the right person... Can the kernel team please raise the hard limit for file descriptors (but keep the soft limit)? https://bugs.launchpad.net/bugs/663090 I'm having real applications break from this, and the change shouldn't affect any app that doesn't request it manually. Thanks, Scott Ritchie The initial hard limit value is not a CONFIG option, so the only way it can be changed is by carrying a patch in the kernel, something I would prefer not to do. This is the macro that initializes the hard limit: include/linux/fs.h:#define INR_OPEN 1024/* Initial setting for nfile rlimits */ What is the issue with having upstart set this limit early in the boot cycle? Won't all new processes inherit the modified limit? rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
