Re: Let's Discuss Interim Releases (and a Rolling Release)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/02/13 19:03, Steve Langasek wrote: > Yes, with my SRU hat I'm in complete agreement here. Unverified > SRUs for interim releases every time we do an SRU to an LTS are a > constant source of frustration for me, and make it starkly clear > that testers (and by extension, users) don't actually care about > interim releases to the same degree that they do about the LTS. > That makes interim release SRUs a pretty demotivating thing to work > on for everyone involved, because it's a lot of extra work for > little extra benefit. A huge +1 from me on this. - -- Alberto Milone Software Engineer Hardware Enablement Team Professional and Engineering Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEv4JAACgkQFZJJ6Y6yavGsrQCgsQmim0uuB2VMSgusItIowwB5 01gAoM/2wOprZetFekRbF2tp80c1MLA1 =5Obv -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: This missing kernel headers on our latest stable release madness...
On 22/02/13 04:24, Scott Ritchie wrote: > I've been absolutely flooded with informal reports over a period of > several months now of 12.10 being still broken with regards to > proprietary drivers. > > Reports like this are typical, especially after the influx of steam users: > "Installed ubuntu + proprietary amd drivers, got no unity at 800x600 on > next reboot and uninstalled." > > The proximate cause is a combination of > https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-updates/+bug/1068341 > and https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1070427 > > > But more worrisome is that this appears to be something we still haven't > fixed for 12.10, even if the fix is a hackish ugly workaround such as > forcing the install of the headers-generic pacakge in the additional > drivers tool. > > > I'm not sure what the underlying fix should be, but it is making me > question if there's some sort of larger process issue here because we've > managed to drop this on the floor for so long. > After a discussing the best approach with infinity and cyphermox, I worked around the issue in Raring first (in January) and opened the following bug report about Precise (it's in -proposed, waiting to be tested): https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/1123107 I didn't know about the bug in ubiquity in 12.10, otherwise I would have backported the fix from Raring shortly after doing it in Precise. I have completed my tests on the backport for 12.10 today and I will upload the code tomorrow. Sorry it took so long. Cheers, -- Alberto Milone Software Engineer Hardware Enablement Team Professional and Engineering Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [ubuntu/raring-proposed] fglrx-installer-updates 2:9.010-0ubuntu4 (Accepted)
On 21/01/13 17:05, Micah Gersten wrote: > On 01/21/2013 09:55 AM, Alberto Milone wrote: >> fglrx-installer-updates (2:9.010-0ubuntu4) raring; urgency=low >> >> * debian/rules: >> - Revert change to separate regen-from-templates from >> the build target. This fixes a FTBFS. >> >> Date: Mon, 21 Jan 2013 16:49:43 +0100 >> Changed-By: Alberto Milone >> Maintainer: Ubuntu Core Developers >> https://launchpad.net/ubuntu/raring/+source/fglrx-installer-updates/2:9.010-0ubuntu4 >> > Looking at the diff [1], the problem seems to have been a lack of a > build-arch target, not the split out. > > Thanks, > Micah > > > [1] > http://launchpadlibrarian.net/129029705/fglrx-installer-updates_2%3A9.010-0ubuntu3_2%3A9.010-0ubuntu4.diff.gz > The build log complained about the lack of the dkms file and I preferred to revert the change before looking again into the problem so as to get the packages at least to build again (they previously built only in pbuilder, not in PPAs or in the archive). This said, I thank you for your suggestion and I promise to try that soon. Cheers, -- Alberto Milone Software Engineer Hardware Enablement Team Professional and Engineering Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: when not to use an epoch and how to avoid a sync
On 06/05/2011 10:30 AM, Micah Gersten wrote: > On 06/04/2011 05:25 AM, Alberto Milone wrote: >> nvidia-common (1:0.2.30+1) oneiric; urgency=low >> >> * Add epoch to override the sync. The packages in Debian and Ubuntu >> have the same name but different code and scope (LP: #792576). >> > > So, in Ubuntu we have a sync blacklist to avoid syncing something from > Debian. There's no need to add an epoch to avoid this. In fact, adding > an epoch will not necessarily help, since you never know when Debian > will add one as well. > > The process for requesting something to be blacklisted from being sync'd > from Debian is to simply file a bug against the package and subscribe > ubuntu-sponsors if you cannot upload the package (to verify if this is > indeed the correct course of action) or subscribe ubuntu-archive and set > the status to confirmed if you can upload the package. > > Adding an epoch makes it harder to get back in sync with Debian. It > requires manual intervention until Debian has a situation where they add > a similar epoch. Granted, that for this package, it might not happen > for a while; but, if we ever were to get these packages in sync, we are > now stuck with the epoch forever. > > Generally, people have been using BAD_VERSION+reallyGOOD_VERSION when > something like this happens to avoid having to add an epoch. > > IMHO, epochs should not be used in Ubuntu at all for this very reason. > > In order to prevent autosyncs in the future, one can use an x.y-0ubuntu1 > or x.yubuntu1 version scheme. > > Micah > Hi Micah, I don't plan on syncing my package with the one in Debian as, put simply, they are too different in scope and it's just a coincidence that now they share the same name. This is why I decided to use an epoch instead of having something as 20110426+1+really0.2.x (which, in this case, I found unnecessarily ugly). Furthermore I knew that Steve Langasek had already blacklisted nvidia-common and, in the light of these facts, I made my choice as a maintainer and upstream author. Regards, -- Alberto Milone Sustaining Engineer (system) Premium Engagements Team Canonical OEM Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
fglrx support in Natty
Hi all, A new fglrx driver (2:8.840-0ubuntu1) is now available in Natty and it finally works with the new xserver. There are still a few issues whose fixes should land after Beta 1 is released: 1) compiz needs to be updated so that fglrx can work with Unity. Currently the "Classic Desktop" session works well but the "Ubuntu Desktop" one doesn't. If you'd like to test Unity with the new driver, you can use Unity's daily builds from the PPA, as described here: https://wiki.ubuntu.com/DesktopExperienceTeam/UnityWithFglrxBeta 2) currently the driver is not offered for installation in Jockey. A fix is already available in Jockey's development branch though. In the meantime, if you wish to install the new fglrx driver, you can do it manually by following these commands: sudo apt-get install fglrx sudo update-alternatives --config gl_conf (and select the line with fglrx) sudo update-initramfs -u and finally reboot. No xorg.conf is required as the driver will be automatically loaded. Note: despite what the relevant article from Phoronix claims, the driver doesn't support AMD's PowerXpress. Regards, -- Alberto Milone Sustaining Engineer (system) Premium Engagements Team Canonical OEM Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: OpenCL for Natty?
On 08/01/11 20:54, Scott Ritchie wrote: > Debian has a few (Nvidia-based) OpenCL packages, however they didn't > make their way into Natty. Is this something possible for us? > > Thanks, > Scott Ritchie > Hi Scott, What packages are you referring to? Are you referring to the OpenCL headers? Regards, -- Alberto Milone Sustaining Engineer (system) Premium Engagements Team Canonical OEM Services -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
