Re: pastebinit default target on Ubuntu

[Timo Aaltonen]

Sergio Durigan Junior kirjoitti 15.4.2024 klo 20.51:

On Monday, April 15 2024, Robie Basak wrote:


Reason to keep it dpaste.com:

People have complained that the login requirement makes it unusable for
helping Ubuntu users at large who don't necessarily have an Ubuntu SSO
account.


The requirement for login is really a pain.  I find myself avoiding
paste.ubuntu.com most of the time because of it, especially if I know
that the target audience might not even have a Launchpad account.


+1


Reason to keep it paste.ubuntu.com:

I'm not keen on relying on third party services when not necessary,
especially ad-supported ones. I have no reason to distrust the current
operator, but in general, these things tend to go wrong sooner or later.


dpaste.com also runs a proprietary backend, so I'm -1 on using it.
There's dpaste.org, which is FLOSS and doesn't seem to load any ads.


dpaste.org seems like a fine alternative, so +1 here too


--
t


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: +1 maintenance report (dogtag-pki vs 389-ds-base)

[Timo Aaltonen]

On 21.1.2021 18.59, Lukas Märdian wrote:
NO - dogtag-pki vs ['389-ds-base/1.4.4.9-1build2', 
'net-snmp/5.9+dfsg-3ubuntu1']


So I had a closer look into the dogtag-pki failure on s390x. I could 
easily reproduce the problem inside a s390x LXD container, but wasn't 
able to isolate the root cause... After quite some investigation I was 
able to produce a debug trace of the problem, and to me it looks like 
the issue is actually not inside this package, but rather inside the 
LDAP server (i.e. 389-ds-base), as the debug log shows an "SEVERE: 
Unable to modify o=pki-tomcat-CA: netscape.ldap.LDAPException: error 
result (1); Operations error", i.e. "Internal Server Error" 
(https://docs.oracle.com/cd/E19957-01/816-5618-10/netscape/ldap/LDAPException.html#OPERATION_ERROR 
). 
I do not really understand why the LDAP server would behave differently 
on s390x than on all the other architectures, but I guess this is for 
another time...


Debug log: https://paste.ubuntu.com/p/vx9JB6VTjF/ 



This seems to go back to at least 389-ds-base 1.4.4.4, probably longer. 
Would be useful to know where it regressed.


As to why it only happens on s390x my guess would be that it's related 
to endianness (it's big-endian). Upstream tests only on amd64 (LE).



--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Version regression report

[Timo Aaltonen]

On 2.4.2019 13.28, Julian Andres Klode wrote:
> * libdrm backport in trusty is 2.4.67-1ubuntu0.14.04.2, when it probably 
> should be
>   2.4.67-1~ubuntu0.14.04.2 (as xenial has 2.4.67-1, which is lower).
yes, that's a mistake, but xenial-updates has 2.4.91-2~16.04.1 so there
should be no issues when upgrading with updates enabled.


-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Timo Aaltonen]

On 15.02.2018 18:04, Julian Andres Klode wrote:
> On Thu, Feb 15, 2018 at 04:10:01PM +0100, Martin Pitt wrote:
>> Hello Timo,
>>
>> Timo Aaltonen [2018-02-15 16:50 +0200]:
>>> On 14.02.2018 22:03, Dimitri John Ledkov wrote:
>>>> Hi,
>>>>
>>>> I am on bionic and managed to build bionic container for testing using:
>>>>
>>>> $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
>>>>
>>>> Note this uses Ubuntu Foundations provided container as the base,
>>>> rather than the third-party image that you are using from "images"
>>>> remote.
>>>>
>>>> Why are you using images: remote?
>>>
>>> Because that's what the manpage suggests :)
>>
>> Right, and quite deliberately. At least back in "my days", the ubuntu: and
>> ubuntu-daily: images had a lot of fat in them which made them both
>> unnecessarily slow (extra download time, requires more RAM/disk, etc.) and 
>> also
>> undesirable for test correctness, as having all of the unnecessary bits
>> preinstalled easily hides missing dependencies.
>>
>> The latter can be alleviated by purging stuff of course, and that's what
>> happens for the cloud VM images in OpenStack:
>>
>>   
>> https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n242
>>
>> But this takes even more time, and so far just hasn't been necessary as the
>> images: ones were just right - they contain exactly what a generic container
>> image is supposed to contain and are pleasantly small and fast.
>>
>>>> Is the failure reproducible with ubuntu-daily:bionic?
>>>>
>>>> If you can build images with ubuntu-daily:bionic, then you need to
>>>> contact and file an issue with images: remote provider.
>>>
>>> ubuntu-daily: works, images: fails for artful and bionic while xenial
>>> works, and the image server is:
>>>
>>> https://images.linuxcontainers.org/
>>
>> These are being advertised and used a lot, so maybe Stephane's LXD team can
>> help with fixing these? Them having no network at all sounds like a grave bug
>> which should be fixed either way.
> 
> That's not what's going on at all. They do have working networking, but the
> network does not come up fast enough. The apt update is not retried because
> it exits with 0 because all it sees are transient errors.

True, I added a 'sleep 10' in front of the apt-get update line, and now
it works..

filed a bug:
https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1749736


-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Timo Aaltonen]

On 14.02.2018 22:03, Dimitri John Ledkov wrote:
> Hi,
> 
> I am on bionic and managed to build bionic container for testing using:
> 
> $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
> 
> Note this uses Ubuntu Foundations provided container as the base,
> rather than the third-party image that you are using from "images"
> remote.
> 
> Why are you using images: remote?

Because that's what the manpage suggests :)

> Is the failure reproducible with ubuntu-daily:bionic?
> 
> If you can build images with ubuntu-daily:bionic, then you need to
> contact and file an issue with images: remote provider.

ubuntu-daily: works, images: fails for artful and bionic while xenial
works, and the image server is:

https://images.linuxcontainers.org/




-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

autopkgtest-build-lxd failing with bionic

[Timo Aaltonen]

Hi

I'm not able to build a bionic container:

autopkgtest-build-lxd images:ubuntu/bionic/amd64
Creating autopkgtest-prepare-1ay
Starting autopkgtest-prepare-1ay
Container finished booting. Distribution Ubuntu, release bionic,
architecture amd64
Running setup script /usr/share/autopkgtest/setup-commands/setup-testbed...
grep: //etc/network/interfaces: No such file or directory
Err:1 http://archive.ubuntu.com/ubuntu bionic InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/bionic/InRelease  Temporary
failure resolving 'archive.ubuntu.com'
W: Failed to fetch
http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease
Temporary failure resolving 'archive.ubuntu.com'
W: Some index files failed to download. They have been ignored, or old
ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
dbus is already the newest version (1.12.2-1ubuntu1).
The following NEW packages will be installed:
  eatmydata libeatmydata1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.1 kB of archives.
After this operation, 54.3 kB of additional disk space will be used.
Err:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 libeatmydata1
amd64 105-5
  Temporary failure resolving 'archive.ubuntu.com'
Err:2 http://archive.ubuntu.com/ubuntu bionic/main amd64 eatmydata all 105-5
  Temporary failure resolving 'archive.ubuntu.com'
E: Failed to fetch
http://archive.ubuntu.com/ubuntu/pool/main/libe/libeatmydata/libeatmydata1_105-5_amd64.deb
 Temporary failure resolving 'archive.ubuntu.com'
E: Failed to fetch
http://archive.ubuntu.com/ubuntu/pool/main/libe/libeatmydata/eatmydata_105-5_all.deb
 Temporary failure resolving 'archive.ubuntu.com'
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?

while building a sid container worked fine. Is there a bug open I've not found 
yet, or should I file one?


-- 
t


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: CFT: xserver 1.18 for xenial

[Timo Aaltonen]

05.02.2016, 18:23, Timo Aaltonen kirjoitti:
> 
>   Hi
> 
>   I've prepared the latest xserver release in a PPA for xenial, and
> while the update shouldn't cause problems it deserves more eyes before
> putting it in the main repo .
> 
> You can get it by enabling the staging-ppa:
> 
> apt-add-repository ppa:canonical-x/x-staging
> apt update && apt upgrade
> 
> However, if you are using the fglrx driver do note that there is no
> version of the driver that works with this xserver, meaning that by
> using this PPA the driver will be removed and the OSS driver stack is
> enabled instead. This is expected and something the x-team will make
> sure works more smoothly in 16.04.
> 
> If you bump into new issues (compared to stock xenial), file a bug
> against 'xorg-server' and mention that you're using this PPA. Feel free
> to ping me on #ubuntu-x (freenode, ~UTC office hours) and report
> successful upgrades too :)

This is now in xenial since last night. Thanks to everyone who helped
with testing.



-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

CFT: xserver 1.18 for xenial

[Timo Aaltonen]

Hi

  I've prepared the latest xserver release in a PPA for xenial, and
while the update shouldn't cause problems it deserves more eyes before
putting it in the main repo .

You can get it by enabling the staging-ppa:

apt-add-repository ppa:canonical-x/x-staging
apt update && apt upgrade

However, if you are using the fglrx driver do note that there is no
version of the driver that works with this xserver, meaning that by
using this PPA the driver will be removed and the OSS driver stack is
enabled instead. This is expected and something the x-team will make
sure works more smoothly in 16.04.

If you bump into new issues (compared to stock xenial), file a bug
against 'xorg-server' and mention that you're using this PPA. Feel free
to ping me on #ubuntu-x (freenode, ~UTC office hours) and report
successful upgrades too :)


-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu Server seeded package review

[Timo Aaltonen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

03.12.2013 18:33, James Page kirjoitti:
> Hi Folks
> 
> As part of tidying for the next LTS release, the Server Team are 
> proposing a review of server released seeded packages that are 
> currently in Ubuntu main (proposed changes tracked in [0] for
> now).
> 
> Here's the initial review of seeds, and some proposed moves and
> drops we are considering:
> 
> Description: Server ISO image
> 
> likewise-open (largely unmaintained in distro - 
> https://help.ubuntu.com/community/LikewiseOpen)

please drop it, not necessary to have something like this on the
image, and sssd replaces it in multiple ways and will be in main soon..


- -- 
t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKf5JMACgkQCf/ckHZoKjd7CgCdH6McUePYzPnqtWtqwtKfZY4v
UmcAniOOjoP8GhVp5Dfzyyhe2baKeYU3
=LErF
-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: Legacy hardware support in MIR

[Timo Aaltonen]

On 18.06.2013 21:10, Nedas Pekorius wrote:
> I think my question could fit in this topic also. 
> How about MIR and switchable graphics like Nvidia optimus?

Should be easier to support, since the xserver is out of the picture.
Proper hybrid support depends on kernel features that are about to land
in 3.12 I'm told.. then it's "just" a matter of providing RandR-support
in Mir and the UI/policy for switching to the offload gpu.

> As far as I know nouveau doesn't support discrete graphic chip. 

supports just fine, just that there's no way to switch on the fly with
xserver, nor is there any power management so nouveau will eat your
battery if not disabled from the BIOS or otherwise.

-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: non-Unity flavours and Mir

[Timo Aaltonen]

On 17.06.2013 23:00, Jonathan Riddell wrote:
> On Fri, Jun 14, 2013 at 11:41:29AM -0400, Marc Deslauriers wrote:
>> Do you have any more details, or opened bugs about the issues?
> 
> An X one for example
> https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu

That's simply a regression from upstream, and not by any patches of our
own (the package had none)..

Of course, we're probably the only ones now* carrying a patch that isn't
upstream yet, even though I sent it to xorg-devel for further review 3mo
ago (on behalf of Ritesh)...


* checked fedora & opensuse

-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: non-Unity flavours and Mir

[Timo Aaltonen]

On 14.06.2013 18:55, Scott Kitterman wrote:
> On Friday, June 14, 2013 11:50:05 PM Ma Xiaojun wrote:
>> On Fri, Jun 14, 2013 at 11:33 PM, Scott Kitterman  
> wrote:
>>> Upstream kwin tells us they already see bug reports from Kubuntu users due
>>> to mesa changes to support Unity.  I don't think it's just a new back
>>> end.
>> I checked mesa source package the other day. It looks more like a
>> straight sync from Debian drop some kfreebsd patches.
>>
>> What are the bugs?
> 
> As I mentioned, I'm relying on what upstream kwin has said.  I know there 
> have 
> been times (quantal) when Ubuntu moving to a new mesa version in a manner 
> that, from the perspective of our upstream, was overly aggressive caused 
> problems.  I would assume that was done because the features were wanted for 
> Ubuntu specific reasons and not just version chasing.  It may be no more than 
> that.

I guess one such issue was a regression in mesa 9.0 found on 12.10
causing problems with KDE on some (older) intel hw. We need to offer the
latest releases in order to support newer hw for OEM's, it's not just
version chasing. We also have a MRE for mesa so we can push
point-releases as SRU which provides a way to fix such regressions and
other bugs of course.

The current packaging _does_ have something for Unity; reverts a couple
of commits which caused the blur effect to be painfully slow on a few
generations of Intel hw, easily noticed when alt-tabbing or opening the
dash etc. Upstream says this should be fixed on git master (which will
be released as 9.2 or 10.0 in August), but this hasn't been confirmed yet.


-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: CFT: new Mesa 9.1.1

[Timo Aaltonen]

On 06.04.2013 01:37, Timo Aaltonen wrote:
> 
>   Hi
> 
>   The Ubuntu X team has prepared a new Mesa release for raring. The
> reason why it hasn't been uploaded before is that it had a known
> regression on newer intel hw (at least gen6 & 7) causing issues with
> KWin and Unity; the blur effect was so slow that in Unity the dash took
> some seconds to open instead of happening ~instantly. Upstream fixed
> that recently, so we think the new version could enter raring now
> despite being so late in the release cycle.
> 
> The FFe bug is:
> https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093
> 
> and the package is available for testing on a ppa:
> 
> https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
> 
> if you test it and find new bugs, please report them with 'ubuntu-bug
> mesa' and add a pointer to the FFe bug.

oops that won't work, just use 'ubuntu-bug xorg' as normal.

-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

CFT: new Mesa 9.1.1

[Timo Aaltonen]

Hi

  The Ubuntu X team has prepared a new Mesa release for raring. The
reason why it hasn't been uploaded before is that it had a known
regression on newer intel hw (at least gen6 & 7) causing issues with
KWin and Unity; the blur effect was so slow that in Unity the dash took
some seconds to open instead of happening ~instantly. Upstream fixed
that recently, so we think the new version could enter raring now
despite being so late in the release cycle.

The FFe bug is:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1164093

and the package is available for testing on a ppa:

https://launchpad.net/~ubuntu-x-swat/+archive/x-staging

if you test it and find new bugs, please report them with 'ubuntu-bug
mesa' and add a pointer to the FFe bug. Feel free to add a note to the
FFe bug if it's working fine for you, with a description of the gfx hw
you have. Give it a proper beating over the weekend, we'll evaluate the
feedback on Monday!

Thanks!

-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: reflecting on first UDS session on "rolling releases"

[Timo Aaltonen]

On 06.03.2013 23:51, Phillip Susi wrote:
> On 3/6/2013 1:28 AM, Jonathan Carter (highvoltage) wrote:
>> As far as I understand, a really good effort is already put into the
>> hardware enablement part in LTS. So hypothetically, if a dozen or so
> 
> It is?  The kernel team backports drivers for new hardware to the LTS
> kernel?  I didn't think that was the case and that would be a big reason
> for OEMs not to want a 2 year cadence.

It is based on the backported quantal kernel and X stack, both of which
are on the main archive and installable by anyone willing to migrate to
it, and 12.04.2 images use it by default.

-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [CFT] Intel graphics SNA acceleration

[Timo Aaltonen]

On 18.01.2013 13:31, Till Kamppeter wrote:

On 01/18/2013 10:43 AM, Timo Aaltonen wrote:

On 10.01.2013 21:05, Timo Aaltonen wrote:


 Hi!

   The Ubuntu X team would like people running raring on machines with
Intel graphics to try the new acceleration method called 'SNA'. It
should have slightly better performance and less bugs than the current
default. Check this wiki page for further details on how to participate:

http://wiki.ubuntu.com/X/Testing/IntelSNA


Thanks to all who provided feedback!

The testing was a success, though we've identified a minor rendering
issue with gen4 chips (#1098334), which is already known upstream.
Despite this bug we will flip the default to SNA early next week.




I have added a small glitch:

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1101159


You are using quantal, we're only interested in results with raring ;)



--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: [CFT] Intel graphics SNA acceleration

[Timo Aaltonen]

On 10.01.2013 21:05, Timo Aaltonen wrote:


 Hi!

   The Ubuntu X team would like people running raring on machines with
Intel graphics to try the new acceleration method called 'SNA'. It
should have slightly better performance and less bugs than the current
default. Check this wiki page for further details on how to participate:

http://wiki.ubuntu.com/X/Testing/IntelSNA


Thanks to all who provided feedback!

The testing was a success, though we've identified a minor rendering 
issue with gen4 chips (#1098334), which is already known upstream. 
Despite this bug we will flip the default to SNA early next week.



--
t

--
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

[Timo Aaltonen]

Didn't get to bzr branches this time. Also, don't know how to best 
handle a branch that already has a dedicated reviewer..


commented:
https://launchpad.net/bugs/1064475

dropped from the list, assignee can upload the package(s):
https://launchpad.net/bugs/1091068

upload debdiff:
https://launchpad.net/bugs/973014
https://launchpad.net/bugs/857983
https://launchpad.net/bugs/586279
https://launchpad.net/bugs/1095052
https://launchpad.net/bugs/1098162

changed status back to WIP:
https://code.launchpad.net/~mfisch/nano/update_to_2.3.1/+merge/140133


--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[CFT] Intel graphics SNA acceleration

[Timo Aaltonen]

Hi!

  The Ubuntu X team would like people running raring on machines with 
Intel graphics to try the new acceleration method called 'SNA'. It 
should have slightly better performance and less bugs than the current 
default. Check this wiki page for further details on how to participate:


http://wiki.ubuntu.com/X/Testing/IntelSNA

thanks!

--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Xorg update - Was: Re: Intel SNA in Raring

[Timo Aaltonen]

On 09.01.2013 04:43, Scott Kitterman wrote:

On Tuesday, January 08, 2013 11:33:29 AM Bryce Harrington wrote:

We likely will try again this cycle.  We are planning on an X.org stack
update rather late in the cycle, and if we include SNA we believe it
will be most stable with that stack; thus the lack of attention we've
given it right now - any testing we do now would have to be redone with
the newer code anyway.


What are we updating at the last minute this time?  Being on the bleeding edge
with mesa 9 (IIRC) last cycle was no fun at all as we got to find all the mesa
9 unique issues in kwin.  What are we in for this cycle?


Mesa 9.1/10.0 (whichever it ends up being called), xserver 1.14 (nothing 
dramatic happened there), and the usual driver updates.


"late" might also mean "for alpha2", we haven't decided yet.

--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

new X stack moved to quantal, nvidia users beware

[Timo Aaltonen]

Hi

  Just a heads-up, the new xserver et al moved to quantal, but the
nvidia binary driver doesn't work with it, instead it'll likely just
crash on login.

So if you're using the blob, don't upgrade to current quantal until
there's a new driver provided by NVIDIA.


-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

new xorg stack in quantal-proposed

[Timo Aaltonen]

Hi!

  Quantal-proposed now has xserver 1.13rc2 and all the relevant drivers
built against it. So by enabling -proposed and doing a dist-upgrade it
should update the stack nicely. This doesn't include working versions
for nvidia or fglrx, so only the opensource drivers should work at the
moment (nvidia has a beta driver that supports the ABI but has other
issues preventing an upload for now).

I've tested with intel and it works fine. The stack will get copied to
quantal proper after some more testing, and possibly more updates are
pushed (1.13rc3 is out already).

I didn't push updates for obsolete video drivers not depended on by
xserver-xorg-video-all, since I think it's probably time to remove them
from the archive (we dropped them from -video-all for 11.10). This
includes -apm, -ark, -chips, -glide, -glint, -i128, -i740, -rendition,
-s3virge, -tseng, -voodoo. Both users of such hw can still use 12.04 for
the next ~5y.


t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: release cadence for Q and R

[Timo Aaltonen]

On Fri, 17 Jun 2011, Soren Hansen wrote:


2011/6/16 TImo Aaltonen :

Well, the Father's Day for us Scandinavians is the second Sunday of
November, so traveling the weekend from US would basically mean missing it
:)


Father's day in Denmark is actually June 5th.

(We also don't consider Finland part of Scandinavia. Perhaps these
facts are somehow connected :) )


Boo, you and your monarchies ;)

This should be more accurate, then: "Nordic countries, including Estonia 
but apart from the separatist Denmark, have Father's Day the second Sunday 
of November" :P


--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: release cadence for Q and R

[TImo Aaltonen]

On 16.06.2011 09:17, Bryce Harrington wrote:

On Wed, Jun 15, 2011 at 09:41:49PM -0500, Ted Gould wrote:

On Wed, 2011-06-15 at 14:48 -0700, Allison Randal wrote:

A few practical considerations I ran through:

- Release on Oct 11 means UDS on Oct 29-Nov 2 (the week of Halloween)
- Release on Oct 18 means UDS on Nov 5-9
- Release on Oct 25 means UDS on Nov 12-17 (the week before Thanksgiving)


Does UDS have to be a fixed number of days from the release?


If we're looking to permanently align schedules, then +1 for UDS on Nov
5-9.  Many of us have kids and it would not be pleasant to set things up
such that we *always* miss Halloween.  The week before Thanksgiving
might work, but seems like some people get hit by Ubuflu or Icelandic
volcanoes or whatever, so guess it could be risky for folks.


Well, the Father's Day for us Scandinavians is the second Sunday of 
November, so traveling the weekend from US would basically mean missing 
it :)


--
t

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Patch Pilot Report 2011-04-15

[Timo Aaltonen]

On 15.04.2011 23:36, Scott Moser wrote:
> I did make some progress.  One overall theme I see is that there are
> things in that queue that should not be there.  That means that
> patch-pilots (or anyone using it, really) potentially lose time reading
> bugs and coming to the conclusion that "this is not ready".

My thoughts exactly.. it was the first pilot day for me, and after
learning how the procedure works I spent quite a lot of time going
through the bugs on the list. I could've documented those to save you
some time, but.. :)

t

-- 
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 2011-04-15

[TImo Aaltonen]

https://bugs.launchpad.net/ubuntu/+source/sea-defender/+bug/745876

- turned into a sync request, 0.9-2 has the FTBFS fix in it

https://code.launchpad.net/~mathieu-tl/ubuntu/natty/openwsman/lp760835/+merge/57790

- test-built, and uploaded to natty

https://bugs.launchpad.net/ubuntu/+source/ucarp/+bug/760223

- test-built, and uploaded to natty
- SRU, uploaded to lucid-proposed, pending approval

https://bugs.launchpad.net/ubuntu/+source/gcc-defaults-armel-cross/+bug/676454

- test-built, and uploaded to natty, pending approval

-- 
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: Aubergine-love for Server folks!

[TImo Aaltonen]

On 18.03.2011 04:01, Dustin Kirkland wrote:
> So what does all of this look like?  Here are some screen shots!
>  * On the console
>   * before: http://bit.ly/fvm16s
>   * after: http://bit.ly/dRF9yi
>  * And in the installer
>   * msdos6: http://bit.ly/gyQgJL
>   * before: http://bit.ly/i1cc5Q
>   * after: http://bit.ly/hRLDDI

I think the new gray is too light, less contrast to white than before,
and that makes readability worse IMO. I bet you can't distinguish grey
from white on the new aubergine background ;)


t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel