Re: Unity became low graphics after upgrade to 14.04.04 LTS with wily hardware enablement stack
Thanks Marco. Here it is: :~$ /usr/lib/nux/unity_support_test -p OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD RS780 (DRM 2.43.0, LLVM 3.6.0) OpenGL version string: 3.0 Mesa 11.0.2 Not software rendered:yes Not blacklisted: yes GLX fbconfig: yes GLX texture from pixmap: yes GL npot or rect textures: yes GL vertex program:yes GL fragment program: yes GL vertex buffer object: yes GL framebuffer object:yes GL version is 1.4+: yes Unity 3D supported: yes On 26/04/16 01:44, Marco Trevisan wrote: Il 25/04/2016 15:29, Amr Ibrahim ha scritto: I found a launchpad bug #1491555 https://bugs.launchpad.net/unity/+bug/1491555 On 25/04/16 15:01, Amr Ibrahim wrote: Hello everyone, I have Radeon HD 3200 (780G) graphics chipset. I use the open-source radeon driver. After upgrading to 14.04.4 LTS w/ wily HWE stack, Unity became low graphics by default (Dash is not transparent). I also have this issue with another laptop that has a different AMD graphics card. Is this a common issue with AMD graphics and 14.04.4 LTS w/ wily HWE stack? That bug doesn't seem the same problem. Could you please paste the output of: /usr/lib/nux/unity_support_test -p Cheers -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
On Mon, Apr 25, 2016 at 01:12:47PM -0700, Steve Langasek wrote: > > E, no. Anything that's in main is LTS-supported. As of 16.04, this > should be 100% guaranteed; if it's not supported it wouldn't be in main. So, the code in launchpad has never reflected this position. It has always marked main-but-non-server/desktop-seeded as the non-LTS support length. Given we *just* released xenial, it's *possible* we could very carefully regenerate the release pocket to reflect a better view of reality, if there's an agreement on what reality is, but this is not a regression from how we generated that field in the past. ... Adam -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
On Mon, Apr 25, 2016 at 08:33:49PM +, Adam Conrad wrote: > On Mon, Apr 25, 2016 at 01:12:47PM -0700, Steve Langasek wrote: > > E, no. Anything that's in main is LTS-supported. As of 16.04, this > > should be 100% guaranteed; if it's not supported it wouldn't be in main. > So, the code in launchpad has never reflected this position. It has > always marked main-but-non-server/desktop-seeded as the non-LTS support > length. Given we *just* released xenial, it's *possible* we could > very carefully regenerate the release pocket to reflect a better view > of reality, if there's an agreement on what reality is, but this is > not a regression from how we generated that field in the past. Understood that it's not a regression. I think the current implementation follows logically from the time when we had multiple products in main, via the same seed pod (ubuntu), with different support lengths. But it's surely an oversight that packages seeded in a seed called "supported-foo" are shown as not supported by ubuntu-support-status! A completely correct implementation would have to take into consideration which product each package is "supported" as part of. But for 16.04, since we don't have any products in main with differing support periods, I think it should suffice to slam everything to 5y. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wine(tricks) needs a new maintainer
Thanks for the bug and quick reply Bryan. I've subscribed to the bug. On Mon, Apr 25, 2016 at 9:35 AM, Bryan Quigley wrote: > Debian's wintricks package doesn't work that well right now on 64-bit with > wine 1.9xx, either. > > Anyway I did make a Merge/Sync request so we can track this in a bug: > https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1574681 > > Thanks, > Bryan > > On Mon, Apr 25, 2016 at 9:53 AM, Bryan Quigley > wrote: >> >> I can relate, winetricks wasn't working for me in the archive, >> eventually figured out I should just download it. >> >> Debian has 20151116, so just dropping our delta might be a good option >> too. >> >> I'm hoping to be able to drop our Wine delta too (stuck on 1.6 - more >> complicated transition though) and winetricks might be something worth >> looking at first. >> >> Kind regards, >> Bryan >> >> >> On Mon, Apr 25, 2016 at 4:35 AM, Daniel Holbach >> wrote: >> > Hello Austin, >> > >> > On 25.04.2016 09:12, Austin English wrote: >> >> So, I'd like to know what the process is for having a maintainer >> >> removed >> >> from a package, so that someone else can maintain it. If not, I'd >> >> prefer >> >> to see Winetricks removed from Ubuntu, as currently it's more broken >> >> than useful. I'd say Wine should probably also be removed if it's not >> >> going to be maintained, but that's my personal opinion as it's not been >> >> discussed upstream. >> > >> > we have no maintainer lock in Ubuntu. So we either need to find somebody >> > who's willing to get updated packages into Ubuntu via the sponsorship >> > process: >> > >> > https://wiki.ubuntu.com/SponsorshipProcess >> > >> > >> > The other option would be to remove the packages altogether, but if wine >> > upstream already provides packages, they could maybe be put into Ubuntu >> > using the process mentioned above? >> > >> > Have a great day, >> > Daniel >> > >> > -- >> > Get involved with Snappy Ubuntu Core! developer.ubuntu.com/snappy/ >> > Follow @ubuntudev on twitter.com/facebook.com/G+ >> > >> > -- >> > Ubuntu-devel-discuss mailing list >> > Ubuntu-devel-discuss@lists.ubuntu.com >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > > -- -Austin -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
On Mon, Apr 25, 2016 at 03:05:23PM -0400, Stéphane Graber wrote: > > Short answer: don't use ubuntu-support-status, it doesn't work. > > Long answer: ubuntu-support-status is a deprecated tool that used to be used > > when we had a 3y/5y split on desktop and server packages. It returns the > > contents of the "Supported:" tag which hasn't been updated since Ubuntu > > 10.04 > > LTS. I've filed a bug to get it removed: > > https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670 > The Supported: field logic actually got updated on release week for > 16.04, so it's absolutely meant to be meaningful. > The code for that logic can be found at: > http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py > If the logic doesn't match reality, then someone should send a branch to > fix the logic. > Note that it's long been the case that the fact that a package is in > main or in universe doesn't necessarily indicate support length. We have > plenty of packages in universe with support for 3 years or 5 years > during LTS cycles and there are a number of packages that are in main > but aren't part of a product and so aren't supported past the 9 months > mark. E, no. Anything that's in main is LTS-supported. As of 16.04, this should be 100% guaranteed; if it's not supported it wouldn't be in main. And when you say that there are packages in universe that are supported for 3 or 5 years, I believe you are referring to support for flavor images. I think this a case of an unfortunate conflation of different kinds of "support". How many packages shipped in community flavors have had CVEs issued for them over the years? And how many of these CVEs have we had USNs for? If the answer to the first question is "we don't know how many CVEs there have been because nobody is tracking", then clearly, this is not the same kind of support that we mean when we talk about the support that Canonical provides for packages in main - and which does encompass all of main, not just packages that are seeded on images. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Unity became low graphics after upgrade to 14.04.04 LTS with wily hardware enablement stack
Il 25/04/2016 15:29, Amr Ibrahim ha scritto: > I found a launchpad bug #1491555 > https://bugs.launchpad.net/unity/+bug/1491555 > > > On 25/04/16 15:01, Amr Ibrahim wrote: >> Hello everyone, >> >> I have Radeon HD 3200 (780G) graphics chipset. I use the open-source >> radeon driver. After upgrading to 14.04.4 LTS w/ wily HWE stack, Unity >> became low graphics by default (Dash is not transparent). I also have >> this issue with another laptop that has a different AMD graphics card. >> >> Is this a common issue with AMD graphics and 14.04.4 LTS w/ wily HWE >> stack? That bug doesn't seem the same problem. Could you please paste the output of: /usr/lib/nux/unity_support_test -p Cheers -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
Hi, On 25 April 2016 at 19:45, Andreas Wundsam wrote: > Hello Ubuntu Maintainers, > > I was surprised to see that ubuntu-support-status shows the support of > package nginx expired in February 2015? > > --- > $ ubuntu-support-status --show-all > [] > Supported until February 2015 (9m): > [...] nginx nginx-common > --- > > apt show shows the package as being in main, but receiving only 9 months of > support: > > --- > Supported: 9m > APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages > > > So far, it has been my world view that packages that reside in the main > repository would receive the full 5 years of LTS support. > > What am I missing? > To answer your question about Trusty however, nginx source package builds some thing into main (with 5 years of security support) and into universe (community security support only). Main: nginx, nginx-common, nginx-core, nginx-doc Universe: nginx-extras, nginx-full, nginx-light, nginx-naxsi, nginx-naxsi-ui My understand is that nginx packages that are in main, should be in the server supported seed and should have received Supported: 5 years field. This is the case in xenial. Looking at the package set changes, in xenial nginx correctly declares "5 years" of support. Which seems to be due to this commit from stgraber: revno: 1978 committer: Stéphane Graber branch nick: platform.utopic timestamp: Fri 2014-08-15 11:22:21 -0400 message: Move server stuff from ubuntu/supported I guess we can do a similar commit for trusty, and then the supported fields will be corrected in the -security/-updates pockets. If server team agrees. -- Regards, Dimitri. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
On 2016-04-25 03:05 PM, Stéphane Graber wrote: > On Mon, Apr 25, 2016 at 02:57:22PM -0400, Marc Deslauriers wrote: >> Hi, >> >> On 2016-04-25 02:45 PM, Andreas Wundsam wrote: >>> Hello Ubuntu Maintainers, >>> >>> I was surprised to see that ubuntu-support-status shows the support of >>> package >>> nginx expired in February 2015? >>> >>> --- >>> $ ubuntu-support-status --show-all >>> [] >>> Supported until February 2015 (9m): >>> [...] *nginx nginx-common * >>> --- >>> >>> apt show shows the package as being in main, but receiving only 9 months of >>> support: >>> >>> --- >>> Supported: 9m >>> APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages >>> >>> >>> So far, it has been my world view that packages that reside in the main >>> repository would receive the full 5 years of LTS support. >>> >>> What am I missing? >>> >> >> Short answer: don't use ubuntu-support-status, it doesn't work. >> >> Long answer: ubuntu-support-status is a deprecated tool that used to be used >> when we had a 3y/5y split on desktop and server packages. It returns the >> contents of the "Supported:" tag which hasn't been updated since Ubuntu 10.04 >> LTS. I've filed a bug to get it removed: >> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670 >> >> Marc. > > The Supported: field logic actually got updated on release week for > 16.04, so it's absolutely meant to be meaningful. > > The code for that logic can be found at: > http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py > > If the logic doesn't match reality, then someone should send a branch to > fix the logic. > > Note that it's long been the case that the fact that a package is in > main or in universe doesn't necessarily indicate support length. We have > plenty of packages in universe with support for 3 years or 5 years > during LTS cycles and there are a number of packages that are in main > but aren't part of a product and so aren't supported past the 9 months > mark. Now I'm confused what "supported" means. For security updates provided by the security team, this is what we rely on: https://wiki.ubuntu.com/SecurityTeam/FAQ#Official_Support What does the Supported: field mean? Marc. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
On Mon, Apr 25, 2016 at 02:57:22PM -0400, Marc Deslauriers wrote: > Hi, > > On 2016-04-25 02:45 PM, Andreas Wundsam wrote: > > Hello Ubuntu Maintainers, > > > > I was surprised to see that ubuntu-support-status shows the support of > > package > > nginx expired in February 2015? > > > > --- > > $ ubuntu-support-status --show-all > > [] > > Supported until February 2015 (9m): > > [...] *nginx nginx-common * > > --- > > > > apt show shows the package as being in main, but receiving only 9 months of > > support: > > > > --- > > Supported: 9m > > APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages > > > > > > So far, it has been my world view that packages that reside in the main > > repository would receive the full 5 years of LTS support. > > > > What am I missing? > > > > Short answer: don't use ubuntu-support-status, it doesn't work. > > Long answer: ubuntu-support-status is a deprecated tool that used to be used > when we had a 3y/5y split on desktop and server packages. It returns the > contents of the "Supported:" tag which hasn't been updated since Ubuntu 10.04 > LTS. I've filed a bug to get it removed: > https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670 > > Marc. The Supported: field logic actually got updated on release week for 16.04, so it's absolutely meant to be meaningful. The code for that logic can be found at: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-publishing/trunk/view/head:/scripts/maintenance-check.py If the logic doesn't match reality, then someone should send a branch to fix the logic. Note that it's long been the case that the fact that a package is in main or in universe doesn't necessarily indicate support length. We have plenty of packages in universe with support for 3 years or 5 years during LTS cycles and there are a number of packages that are in main but aren't part of a product and so aren't supported past the 9 months mark. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
Hi, On 2016-04-25 02:45 PM, Andreas Wundsam wrote: > Hello Ubuntu Maintainers, > > I was surprised to see that ubuntu-support-status shows the support of package > nginx expired in February 2015? > > --- > $ ubuntu-support-status --show-all > [] > Supported until February 2015 (9m): > [...] *nginx nginx-common * > --- > > apt show shows the package as being in main, but receiving only 9 months of > support: > > --- > Supported: 9m > APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages > > > So far, it has been my world view that packages that reside in the main > repository would receive the full 5 years of LTS support. > > What am I missing? > Short answer: don't use ubuntu-support-status, it doesn't work. Long answer: ubuntu-support-status is a deprecated tool that used to be used when we had a 3y/5y split on desktop and server packages. It returns the contents of the "Supported:" tag which hasn't been updated since Ubuntu 10.04 LTS. I've filed a bug to get it removed: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1574670 Marc. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Support status of nginx in Ubuntu 14.04LTS expired in Feburary 2015?
Hello Ubuntu Maintainers, I was surprised to see that ubuntu-support-status shows the support of package nginx expired in February 2015? --- $ ubuntu-support-status --show-all [] Supported until February 2015 (9m): [...] *nginx nginx-common * --- apt show shows the package as being in main, but receiving only 9 months of support: --- Supported: 9m APT-Sources: http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages So far, it has been my world view that packages that reside in the main repository would receive the full 5 years of LTS support. What am I missing? Thanks, -Andreas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [pulseaudio] Enable support for libsoxr
On Monday, 25 April 2016 19:29:22 MSK Luke Yelavich wrote: > On Mon, Apr 25, 2016 at 05:38:59PM CEST, Robie Basak wrote: > > You can certainly track this in a bug, yes. > > There is already a bug for this, can't find it right now, but will reply > back when I have found it. I couldn't find the bug either, only a question: https://answers.launchpad.net/ubuntu/+source/pulseaudio/+question/ 289537 Anyway, I created a bug: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1574746 Let me know if it's a duplicate. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [pulseaudio] Enable support for libsoxr
On Mon, 25 Apr 2016. 16:38:59 MSK Robie Basak wrote: > On Mon, Apr 25, 2016 at 02:22:33PM +0200, Ralf Mardorf wrote: > > On Mon, 25 Apr 2016 15:16:46 +0300, Andrey Semashev wrote: > > >Should I create a bug report asking for this feature? > > > > I'm not a developer/maintainer, but I'm quite sure that you need to do > > this. > > You can certainly track this in a bug, yes. Another thing you'll need to > address though is that libsoxr0 (and libsoxr-lsr0 if that's relevant) libsoxr-lsr0 is not needed in run time, the dependency is on libsoxr0 only. But you do need libsoxr-dev to build pulseaudio and it depends on both libsoxr0 and libsoxr-lsr0. > Perhaps pulseaudio is suitably pluggable so users could opt into soxr at > runtime? Unfortunately, no. Resamplers are configured at build time and cannot be plugged in at run time. > Or else, soxr would need to enter main, so it is relevant to > most users? I think this would be the solution. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [pulseaudio] Enable support for libsoxr
On Mon, Apr 25, 2016 at 05:38:59PM CEST, Robie Basak wrote: > You can certainly track this in a bug, yes. Another thing you'll need to > address though is that libsoxr0 (and libsoxr-lsr0 if that's relevant) > are in universe, but pulseaudio is in main. So there's a question about > security support for pulseaudio with respect to libsoxr, for example. > Ubuntu doesn't allow packages in main to depend on packages in universe. There is already a bug for this, can't find it right now, but will reply back when I have found it. > Perhaps pulseaudio is suitably pluggable so users could opt into soxr at > runtime? Or else, soxr would need to enter main, so it is relevant to > most users? The latter I think. PulseAudio's resampler support has to be built into the main binary. Luke -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [pulseaudio] Enable support for libsoxr
On Mon, Apr 25, 2016 at 02:22:33PM +0200, Ralf Mardorf wrote: > On Mon, 25 Apr 2016 15:16:46 +0300, Andrey Semashev wrote: > >Should I create a bug report asking for this feature? > > I'm not a developer/maintainer, but I'm quite sure that you need to do > this. You can certainly track this in a bug, yes. Another thing you'll need to address though is that libsoxr0 (and libsoxr-lsr0 if that's relevant) are in universe, but pulseaudio is in main. So there's a question about security support for pulseaudio with respect to libsoxr, for example. Ubuntu doesn't allow packages in main to depend on packages in universe. Perhaps pulseaudio is suitably pluggable so users could opt into soxr at runtime? Or else, soxr would need to enter main, so it is relevant to most users? HTH, Robie -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wine(tricks) needs a new maintainer
Debian's wintricks package doesn't work that well right now on 64-bit with wine 1.9xx, either. Anyway I did make a Merge/Sync request so we can track this in a bug: https://bugs.launchpad.net/ubuntu/+source/winetricks/+bug/1574681 Thanks, Bryan On Mon, Apr 25, 2016 at 9:53 AM, Bryan Quigley wrote: > I can relate, winetricks wasn't working for me in the archive, > eventually figured out I should just download it. > > Debian has 20151116, so just dropping our delta might be a good option too. > > I'm hoping to be able to drop our Wine delta too (stuck on 1.6 - more > complicated transition though) and winetricks might be something worth > looking at first. > > Kind regards, > Bryan > > > On Mon, Apr 25, 2016 at 4:35 AM, Daniel Holbach > wrote: > > Hello Austin, > > > > On 25.04.2016 09:12, Austin English wrote: > >> So, I'd like to know what the process is for having a maintainer removed > >> from a package, so that someone else can maintain it. If not, I'd prefer > >> to see Winetricks removed from Ubuntu, as currently it's more broken > >> than useful. I'd say Wine should probably also be removed if it's not > >> going to be maintained, but that's my personal opinion as it's not been > >> discussed upstream. > > > > we have no maintainer lock in Ubuntu. So we either need to find somebody > > who's willing to get updated packages into Ubuntu via the sponsorship > > process: > > > > https://wiki.ubuntu.com/SponsorshipProcess > > > > > > The other option would be to remove the packages altogether, but if wine > > upstream already provides packages, they could maybe be put into Ubuntu > > using the process mentioned above? > > > > Have a great day, > > Daniel > > > > -- > > Get involved with Snappy Ubuntu Core! developer.ubuntu.com/snappy/ > > Follow @ubuntudev on twitter.com/facebook.com/G+ > > > > -- > > Ubuntu-devel-discuss mailing list > > Ubuntu-devel-discuss@lists.ubuntu.com > > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wine(tricks) needs a new maintainer
I can relate, winetricks wasn't working for me in the archive, eventually figured out I should just download it. Debian has 20151116, so just dropping our delta might be a good option too. I'm hoping to be able to drop our Wine delta too (stuck on 1.6 - more complicated transition though) and winetricks might be something worth looking at first. Kind regards, Bryan On Mon, Apr 25, 2016 at 4:35 AM, Daniel Holbach wrote: > Hello Austin, > > On 25.04.2016 09:12, Austin English wrote: >> So, I'd like to know what the process is for having a maintainer removed >> from a package, so that someone else can maintain it. If not, I'd prefer >> to see Winetricks removed from Ubuntu, as currently it's more broken >> than useful. I'd say Wine should probably also be removed if it's not >> going to be maintained, but that's my personal opinion as it's not been >> discussed upstream. > > we have no maintainer lock in Ubuntu. So we either need to find somebody > who's willing to get updated packages into Ubuntu via the sponsorship > process: > > https://wiki.ubuntu.com/SponsorshipProcess > > > The other option would be to remove the packages altogether, but if wine > upstream already provides packages, they could maybe be put into Ubuntu > using the process mentioned above? > > Have a great day, > Daniel > > -- > Get involved with Snappy Ubuntu Core! developer.ubuntu.com/snappy/ > Follow @ubuntudev on twitter.com/facebook.com/G+ > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Unity became low graphics after upgrade to 14.04.04 LTS with wily hardware enablement stack
I found a launchpad bug #1491555 https://bugs.launchpad.net/unity/+bug/1491555 On 25/04/16 15:01, Amr Ibrahim wrote: Hello everyone, I have Radeon HD 3200 (780G) graphics chipset. I use the open-source radeon driver. After upgrading to 14.04.4 LTS w/ wily HWE stack, Unity became low graphics by default (Dash is not transparent). I also have this issue with another laptop that has a different AMD graphics card. Is this a common issue with AMD graphics and 14.04.4 LTS w/ wily HWE stack? Thanks, Amr -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Unity became low graphics after upgrade to 14.04.04 LTS with wily hardware enablement stack
I found a launchpad bug #1491555 https://bugs.launchpad.net/unity/+bug/1491555 On 25/04/16 15:01, Amr Ibrahim wrote: Hello everyone, I have Radeon HD 3200 (780G) graphics chipset. I use the open-source radeon driver. After upgrading to 14.04.4 LTS w/ wily HWE stack, Unity became low graphics by default (Dash is not transparent). I also have this issue with another laptop that has a different AMD graphics card. Is this a common issue with AMD graphics and 14.04.4 LTS w/ wily HWE stack? Thanks, Amr -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Unity became low graphics after upgrade to 14.04.04 LTS with wily hardware enablement stack
Hello everyone, I have Radeon HD 3200 (780G) graphics chipset. I use the open-source radeon driver. After upgrading to 14.04.4 LTS w/ wily HWE stack, Unity became low graphics by default (Dash is not transparent). I also have this issue with another laptop that has a different AMD graphics card. Is this a common issue with AMD graphics and 14.04.4 LTS w/ wily HWE stack? Thanks, Amr -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [pulseaudio] Enable support for libsoxr
On Mon, 25 Apr 2016 15:16:46 +0300, Andrey Semashev wrote: >Should I create a bug report asking for this feature? I'm not a developer/maintainer, but I'm quite sure that you need to do this. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[pulseaudio] Enable support for libsoxr
Hi,
I'd like to ask to enable support for libsoxr-based resamplers in the official
Ubuntu
packages for pulseaudio. The upstream already supports libsoxr and
automatically detects its availability, so the only change really needed is to
add
the build dependency to debian/control.
The resamplers based in libsoxr offer better quality and better performace
while
introducing more delay compared to the speex resamplers that are used by
default. The resamplers are documented in the man pages of pulseaudio in
Ubuntu 16.04 but unfortunately are not enabled at build time ('pulseaudio
--dump-
resample-methods' doesn't list them). I've built local packages with libsoxr
and
verified that the resampler works as expected.
I'm new to this list, so I'm not sure how to proceed from here. Should I create
a
bug report asking for this feature?
Thanks.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Wine(tricks) needs a new maintainer
Hello Austin, On 25.04.2016 09:12, Austin English wrote: > So, I'd like to know what the process is for having a maintainer removed > from a package, so that someone else can maintain it. If not, I'd prefer > to see Winetricks removed from Ubuntu, as currently it's more broken > than useful. I'd say Wine should probably also be removed if it's not > going to be maintained, but that's my personal opinion as it's not been > discussed upstream. we have no maintainer lock in Ubuntu. So we either need to find somebody who's willing to get updated packages into Ubuntu via the sponsorship process: https://wiki.ubuntu.com/SponsorshipProcess The other option would be to remove the packages altogether, but if wine upstream already provides packages, they could maybe be put into Ubuntu using the process mentioned above? Have a great day, Daniel -- Get involved with Snappy Ubuntu Core! developer.ubuntu.com/snappy/ Follow @ubuntudev on twitter.com/facebook.com/G+ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Notify about a new CEGUI release - 0.8.6.
To CEGUI package mainteiners, Hi, This is Yaron Cohen-Tal from the CEGUI team. 0.8.5 introduced a critical bug, therefore we've just released 0.8.6, shortly after 0.8.5, which fixes that bug and contains a few more minor fixes. You're advised to update your packages, especially if you use 0.8.5. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Wine(tricks) needs a new maintainer
Howdy all, I'm the upstream maintainer of Winetricks [1], a script used by Wine users to work around wine bugs, as well as a Wine developer. The reason I'm writing is that the version in Ubuntu is over two years old, and for a project that involves downloading files from live internet links, that version is almost completely broken after Microsoft removed a lot of old downloads for <=XP. Of course, there has also been a lot of new features added and bugs fixed in that time. Ubuntu currently ships 20141009, latest is 20160329 (though I'm planning to make a new release in the next couple days). This leads to a lot of confused users [2], who apt-get update && apt-get dist-upgrade, then file bugs with wine/winetricks that have been fixed for months or years in some cases. Anyway, Scott Ritchie is listed as the current maintainer, who's been inactive with Wine for a long time, leading Wine upstream to start provide their own packages because Ubuntu wasn't providing current releases [3]. Wine hasn't been updated since trusty (14.04), still stuck at 1.6.2, while upstream is on 1.9.8, with 3 new stable releases if Ubuntu didn't want to use the development versions. So, I'd like to know what the process is for having a maintainer removed from a package, so that someone else can maintain it. If not, I'd prefer to see Winetricks removed from Ubuntu, as currently it's more broken than useful. I'd say Wine should probably also be removed if it's not going to be maintained, but that's my personal opinion as it's not been discussed upstream. Cheers, Austin [1] https://github.com/Winetricks/winetricks/ [2] https://bugs.winehq.org/show_bug.cgi?id=40514#c5 [3] https://wiki.winehq.org/Ubuntu signature.asc Description: OpenPGP digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
