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: Unresolved tomcat9 issue

[Timo Aaltonen]

Troels Arvin kirjoitti 10.3.2024 klo 19.17:
In a side discussion of the same ticket, there is talk about handling 
Tomcat 9/10 for Ubuntu 24: The suggestion is for Ubuntu 24 to have 
Tomcat 10 only (i.e. do like Debian and only have one Tomcat generation 
per release). I think the discussion should be taken, but where?


Hi,

With my dogtag-pki/tomcatjss maintainer hat on, I wasn't too happy to 
see a bug report about tomcat9 getting removed from bookworm while it 
was frozen already. Upstream doesn't support tomcat10 yet and so far has 
no plans for it (even after a year of poking about it).


Tomcat9 is in universe. According to rmadison, it hasn't received many 
updates and even less security ones... Would it be unreasonable to keep 
an uncrippled tomcat9 in noble so that dogtag-pki has a chance? Or at 
least provide the minimal set of packages for it (lib, -user, -common)..



Upstream says tomcat9 still has life left in it:
https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0


--
t


--
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: +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: devices on 20.04 LTS

[Timo Aaltonen]

On 10.1.2021 1.13, Jerry Geis wrote:

When I run these commands:

  lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 605 
(rev 03)


ubuntu-drivers devices >
Nothing shows for devices.  This should be an Intel driver for X.
Why is it not showing ?


It does the right thing since you're already using the driver which came 
preinstalled with the system



How do I ensure the Intel X11 driver is loaded ?
I dont see /var/log/X anything


it's ~/.local/share/xorg/Xorg.0.log these days, and you're already using 
the supported driver which is called 'modesetting'... 'intel' is 
deprecated and only used on old hw which don't work with modesetting.




--
t

--
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: FreeIPA on 20.04

[Timo Aaltonen]

On 11.3.2020 19.18, Herbert Alexander Faleiros wrote:
> Hi,
> 
> I didn't found any FreeIPA packages on 20.04.
> 
> The final release will have it (like 18.04 has)?
> 
> Thanks,

We'll see.

The server is currently blocked by new BIND breaking things (upstream is
working on them), and not having a -dev package for bind9-dyndb-ldap. An
older issue is that Dogtag still depends on JDK8 which is why it got
removed in the first place (again).

But if you just need the client, then that could maybe be restored. The
problem is that something changed after the removal and now client
enrolling is broken..


-- 
t

-- 
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: 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 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: Add Africa-Togo Keyboard Layout in the Linux Distribution

[Timo Aaltonen]

On 23.05.2016 03:22, Mats Blakstad wrote:
> I tried to make a ptach to update xkeyboard-config package to new version:
> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1584314
> 
> For Xlib it seems like last release was march 2015:
> https://cgit.freedesktop.org/xorg/lib/libX11/log/
> Maybe we can just commit the whole pack as it is now?

no, just ping upstream to cut a release.

-- 
t

-- 
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: [Request] FGLRX driver package

[Timo Aaltonen]

10.03.2016, 12:26, Andrea Bernabei kirjoitti:
> 
> 
> On Wed, Mar 9, 2016 at 6:11 PM, Steffen Winkler  > wrote:
> 
> Hi,
> 
> after an update yesterday evening, I was greeted by a mirrored desktop
> today and the fact that I couldn't find the AMD configuration utility.
> 
> After some searching and digging, I found that someone decided to
> remove fglrx from Ubuntu 16.04 and it was even published on the
> ReleaseNotes site: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#fgl
> rx [I'm pretty sure that that wasn't there two weeks ago when I
> switched to Ubuntu 16.04 Beta]
> 
> I'm not sure what the reason for that is, but I'd hope someone could
> reverse that decision.
> 
> Why reverse it? Without FGLRX/Catalyst AMD users don't have any way of
> running OpenGL 4.3/4.4/4.5 applications. You may say 'so install the
> package from AMD's website' to which I'd reply that I tried that but
> DKMS decided that that is a really bad idea and denied me that request.
> 
> With kind regards
> Steffen Winkler
> 
> 
> Hi Steffen,
> 
> I was also setting up a machine with AMD GPUs just yesterday and ended
> up having the same problems.
> I managed to get the DKMS module to build though, using the patches from
> https://github.com/kolasa/fglrx-15.30.1025
> but that wasn't enough, the setup still doesn't get past the lightdm
> login screen.
> 
> Running Xorg -configure fails with "Failed to load module fglrxdrm"...
> 
> I'll spend some more time on it this evening, let's see if I manage to
> get anywhere :)

There's no reason to shoot yourself in the foot, the driver won't work
with the xserver no matter what you try. The DKMS is only half of the
story..


-- 
t

-- 
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: [Request] FGLRX driver package

[Timo Aaltonen]

09.03.2016, 20:11, Steffen Winkler kirjoitti:
> Hi,
> 
> after an update yesterday evening, I was greeted by a mirrored desktop
> today and the fact that I couldn't find the AMD configuration utility.
> 
> After some searching and digging, I found that someone decided to
> remove fglrx from Ubuntu 16.04 and it was even published on the
> ReleaseNotes site: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#fgl
> rx [I'm pretty sure that that wasn't there two weeks ago when I
> switched to Ubuntu 16.04 Beta]
> 
> I'm not sure what the reason for that is, but I'd hope someone could
> reverse that decision.
> 
> Why reverse it? Without FGLRX/Catalyst AMD users don't have any way of
> running OpenGL 4.3/4.4/4.5 applications. You may say 'so install the
> package from AMD's website' to which I'd reply that I tried that but
> DKMS decided that that is a really bad idea and denied me that request.

Can't be done, sorry. AMD won't support fglrx on 16.04*, period. There
will be a userspace blob released later this year that should cover the
missing bits and it will be added to 16.04, but it's been well known for
quite a while already that they were moving towards a shared core stack
(amdgpu kernel driver), and we had to make a decision for 16.04.

And installing the package from AMD doesn't help, as it doesn't support
the xserver 1.18 video ABI, which got in xenial earlier this week and is
what removed the incompatible driver from your system.

*
http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/857070-ubuntu-is-deprecating-fglrx-catalyst-in-16-04-lts?p=857203#post857203

-- 
t

-- 
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: Xenial freeze if I plug a second monitor

[Timo Aaltonen]

09.03.2016, 10:19, Gérard BIGOT kirjoitti:
> Mine is Ivy Bridge (Intel(R) Core(TM) i7-3540M CPU @ 3.00GHz).

Could still be a kernel bug. I tested on a Haswell laptop and it's
working fine too.


-- 
t

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

Re: Xenial freeze if I plug a second monitor

[Timo Aaltonen]

07.03.2016, 21:20, Martinx - ジェームズ kirjoitti:
> This is clearly a bug... Where should be fill a bug report? Against
> which Ubuntu package?

If it's a skylake based system, and kernels >= 4.4.0-9 are broken it's
probably caused by i915_bpo (="backport") driver. File a bug against
'linux' and assign to me. Can't reproduce it here.


-- 
t

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

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: Move old ldap auth solution from main?

[Timo Aaltonen]

On 07.01.2015 12:04, Robie Basak wrote:
 On Tue, Jan 06, 2015 at 02:25:13PM -0500, Bryan Quigley wrote:
 Hi,

 I noticed that libnss-ldap was no longer maintained upstream* (and has
 a good amount of bugs) and has good replacements available (sssd, but
 libnss-ldap*d* also works) so I thought it might be a good candidate
 to move out of main in Vivid.

 In Ubuntu it's also dependent on libpam-ldap, ldap-auth-config and
 ldap-client-config.  The ldap-auth-* packages are custom to Ubuntu.
 All would have to be moved out to universe (or none).

 Thoughts?
 
 +1, assuming that sssd is a suitable replacement. Are there any
 important use cases that sssd cannot cover? Is sssd use in Ubuntu well
 enough documented now? I note it's in main already (that was your doing
 IIRC - thanks!).

SSSD offers much more than the old lib*-ldap packages ever did, and is
easier to set up. That's why it was requested to be moved to main..

 The ldap-auth-* packages are custom to Ubuntu.
 
 I vote to deprecate and remove these if nobody is looking after them.

yep, kill them


-- 
t

-- 
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: 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 ubu...@kitterman.com 
 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: Authentication services in Ubuntu

[Timo Aaltonen]

On 03.06.2013 12:36, Ballock Tokarski wrote:
 Hello, 
 
 Thanks for the comments, the feedback is very much appreciated.
 
 Now I am wondering what are the next steps. Thanks to Timo's points and
 his efforts, there is not much to do on the pure SSSD part:
 - SSSD in main
 
 For directory joining stuff - for MS-based server-side Kerberos tickets
 we are currently using msktutil, which works decently in the MS
 environment. This tool is neither in Main nor in Universe. Perhaps
 that's something we can at least upload to Universe (which I believe
 would mean uploading to Debian?)?
 
 We could also do some investigations on realmd from Fedora/RedHat which
 is their tool for joining a Directory service. I believe it's not just
 for MS AD. Realmd has not been packaged for .deb yet, I believe. And I
 am not sure how RedHat-specific it is.

It's on raring  saucy at least (0.12-0ubuntu1), but not on Debian.

 Then the remaining thing is the configuration helper. Perhaps we could
 fork RedHat's system-auth-config?

If that'd work with the installer.. but I doubt it. Adding support for
this in user-setup shouldn't be too hard, just use the UI/ideas from
authconfig as a starting point..

Or maybe I'm hoping too much to be able to just preseed a few values and
it'd all be automatic from there on, and provide the gui bits for
joining a realm manually :)

 Even if we decided that we do not need to care about legacy LDAP
 authentication, I would propose to fix the Ubuntu packages in the same
 way the Debian packages are done - by not requiring ldap-auth-config. I
 have just checked the Ubuntu maintainer of the libpam-ldap and it seems
 to be Ubuntu Core Developers
 mailto:ubuntu-devel-discuss@lists.ubuntu.com with an email to this
 list. So, can we make it happen?

ldap-auth-config is an ubuntu specific package, which seems to be
basically unmaintained for some time now. Then again I don't see why
libpam/nss-ldap should be touched, if we're going to use lib*-sss.. the
obsolete package(s) could be dropped once the new stuff is working.


-- 
t

-- 
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: Authentication services in Ubuntu

[Timo Aaltonen]

On 22.05.2013 11:02, Ballock Tokarski wrote:
  I strongly vote for this to be SSSD. RedHat is actively developing it
  and it seems to be running quite decently on Precise already. For
 this,
  the following obstacles need to be handled:
  - SSSD needs to be included in main (Main Inclusion Request #903752)
 
 The blocker is getting the new-ish samba stuff (samba4, ldb, libtevent)
 in main. Looking at the bug again it looks like the ball is on my court,
 boo.. I'll file the missing MIRs soon.
 
  
 You mean SSSD has some Samba4 correlation too? I wouldn't mind using it
 to replace winbind4, but using samba4 client to talk to Windows servers
 at the same time.

Starting from 1.9.x SSSD has an authentication and identity provider for
AD, which also makes configuration easier. It also supports SID to
UID/GID mapping etc, more details on

https://fedorahosted.org/sssd/attachment/wiki/Documentation/SSSD_1.9_Overview_Oct_2012.pdf

 There have been talks about adding support for authentication services
 in user-setup, so that it could have a box to tick when you need to join
 the machine as a directory client. Configuring this all should be less
 of a hassle these days, not sure if realmd could be used during install
 phase though or something more manual. In any case, the values could
 then be preseeded for automatic installation.
 
 This is also something I've wanted to add for quite some time now, but
 never had the time to finish. How about adding a blueprint now? Not
 being able to join a directory from the installer tends to be a
 recurring topic on every review of Ubuntu at least on certain Finnish
 press ;)
 
 
 There is room for discussion. I vote for. As it's still 3 months till
 the next UDS I've been suggested to create a wiki for that, so that's
 what I did (https://wiki.ubuntu.com/Enterprise/Authentication).

thanks!

 Btw, the Edubuntu guys have experimented with something similar, and I
 think for client they are using SSSD as well..? So for the client, we
 should indeed standardize on something, and SSSD does seem like the best
 bet :)
 
  
 I guess we should invite them to the discussion too. Who should that be?

Stéphane Graber, CC'd :)



-- 
t

-- 
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: Authentication services in Ubuntu

[Timo Aaltonen]

On 21.05.2013 12:37, Bolesław Tokarski wrote:
 Hello,
 
 I put some time and effort creating this, please read at the very least
 introduction and suggestions.

Thanks, this was quite a detailed post and brings back memories :)

 We are using SSSD with some success now. Thanks to Timo Aaltonen's
 efforts, the packages available in Precise were working pretty well and
 were updated to the latest point releases. There is a Main Inclusion
 Request for SSSD (Bug #903752), I hope it gets included since Saucy.

Hope so.. details below

 = Authentication configuration by package =
 == sssd ==
 
 SSSD does not provide a configuration for you aside from entries to
 /etc/nsswitch.conf and PAM. You are pretty much on your own editing
 /etc/sssd/sssd.conf yourself. Also, because you need some other backend
 too, you likely get LDAP and Kerberos backends too. This causes you to
 have 3 authentication modules in PAM and 2 NSS backends in NSS (I might
 be wrong about the latter, though).

SSSD handles those in libpam-sss/libnss-sss, it doesn't need
libpam-krb5/ldap etc.

 = Automatic configuration of authentication =
 == SSSD ==
 
 SSSD is easy to deploy. The problem is that you probably also need the
 backends - LDAP and Kerberos and actually those configurations interfere
 with SSSD and you get install-time questions.

nope, shouldn't happen as mentioned above

 = Suggestions =
 
 I believe it is crucial to pick a preferred authentication solution for
 Ubuntu. Of course local file authentication is good for most cases, but
 when there is some directory service, it should be at least one obvious,
 preferred and supported method.
 
 Currently this seems to be LDAP and Kerberos using libnss-ldap,
 libpam-ldap and/or libpam-krb5, but this is not perfect, as mentioned
 before.
 
 I strongly vote for this to be SSSD. RedHat is actively developing it
 and it seems to be running quite decently on Precise already. For this,
 the following obstacles need to be handled:
 - SSSD needs to be included in main (Main Inclusion Request #903752)

The blocker is getting the new-ish samba stuff (samba4, ldb, libtevent)
in main. Looking at the bug again it looks like the ball is on my court,
boo.. I'll file the missing MIRs soon.

Saucy will get SSSD 1.10.x which builds against libnl-3-dev, so that's
the first version to get in main.

 - SSSD lacks some configuration questions. I'm ok with that, I deploy it
 with CFEngine, but I guess it might be considered a requirement

The current status is on purpose, since it makes no sense to drop a
dummy config there.

 - SSSD will likely use libnss-ldap and either libpam-ldap or
 libpam-krb5. Those do not need to be configured and if there is any use
 of it, these variables should be taken from sssd's config dialogs.

It doesn't use or need them.

 I like RedHat's approach of providing a separate piece of software that
 configures authentication. If you don't like it or you want to configure
 it with CFEngine or with text files, you don't run it or you don't even
 install it. If the configuration absolutely needs to be done inside
 package maintainer scripts, I would lower the question's priorities,
 those are too difficult to be answered by average user anyway.

There have been talks about adding support for authentication services
in user-setup, so that it could have a box to tick when you need to join
the machine as a directory client. Configuring this all should be less
of a hassle these days, not sure if realmd could be used during install
phase though or something more manual. In any case, the values could
then be preseeded for automatic installation.

This is also something I've wanted to add for quite some time now, but
never had the time to finish. How about adding a blueprint now? Not
being able to join a directory from the installer tends to be a
recurring topic on every review of Ubuntu at least on certain Finnish
press ;)

Btw, the Edubuntu guys have experimented with something similar, and I
think for client they are using SSSD as well..? So for the client, we
should indeed standardize on something, and SSSD does seem like the best
bet :)


-- 
t

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

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

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

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

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

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

Re: Crashes from Unity/Xorg continues with 12.10

[Timo Aaltonen]

On 23.10.2012 09:36, Thomas Novin wrote:
 Hello
 
 I had lots of problems (and lots of lost data) because of this bug in 12.04:
 
 https://bugs.launchpad.net/debian/+source/xorg-server/+bug/956071
 
 Even after that I've had an occasional Unity/Xorg crash. And it's very
 inconvenient every time since I always loose work when working in
 applications that can't auto-save etc.
 
 Now I had my first crash in 12.10 and it generated a crash-file in
 /var/crash:
 
 -rw-r-  1 root whoopsie 5718069 okt 22 16:14 _usr_bin_Xorg.0.crash
 
 However, after logging in, I didn't get any notification that my system had
 crashed and question about submitting. I then read here:
 https://wiki.ubuntu.com/ErrorTracker and changed under Privacy 
 Diagnostics, Send error reports to Canonical. This has no effect though,
 after logging out and then in again I get no question about submitting my
 crash.
 
 Now I entered this setting again and the option was unchecked! It seems
 that checking that option doesn't stick.
 
 Please advice, how should I handle/report my crashing Xorg/Unity..

File a bug with 'apport-bug /var/crash/_usr_bin_Xorg.0.crash'.



-- 
t

-- 
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: Crashes from Unity/Xorg continues with 12.10

[Timo Aaltonen]

On 23.10.2012 20:33, Thomas Novin wrote:
 On Tue, Oct 23, 2012 at 7:22 PM, Thomas Novin tho...@xyz.pp.se wrote:
 
 On Tue, Oct 23, 2012 at 10:44 AM, Timo Aaltonen tjaal...@ubuntu.comwrote:

 On 23.10.2012 09:36, Thomas Novin wrote:
 However, after logging in, I didn't get any notification that my system
 had
 crashed and question about submitting. I then read here:
 https://wiki.ubuntu.com/ErrorTracker and changed under Privacy 
 Diagnostics, Send error reports to Canonical. This has no effect though,
 after logging out and then in again I get no question about submitting
 my
 crash.

 Now I entered this setting again and the option was unchecked! It seems
 that checking that option doesn't stick.

 Please advice, how should I handle/report my crashing Xorg/Unity..

 File a bug with 'apport-bug /var/crash/_usr_bin_Xorg.0.crash'.


 Ok, did that now. One thing is a bit buggy I think, it asks me twice Your
 display manager log files may help developers diagnose the bug, but may
 contain sensitive information such as your hostname.  Do you want to
 include these logs in your bug report? and also Would you be willing to
 do additional debugging work?

 Now I think it's submitted. Although I got no confirmation or bug-id after
 it was done.

 Rgds//Thomas


 -rw-r-  1 root whoopsie 8384540 okt 23 19:21 _usr_bin_Xorg.0.crash
 -rw-r--r--  1 root whoopsie   0 okt 23 19:21 _usr_bin_Xorg.0.upload
 -rw---  1 whoopsie whoopsie   0 okt 23 19:21
 _usr_bin_Xorg.0.uploaded
 
 Now it looks like this in /var/crash so there it looks like it has been
 uploaded.

Well, I guess it uploads it to errors.u.c, and doesn't actually file it
as a bug on launchpad.. sigh.

File a new bug with 'ubuntu-bug xorg' and then attach the crash file there.


-- 
t

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

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: Accessing GVFS mounts from 3rd party applications?

[Timo Aaltonen]

07.04.2012 10:47, David Klasinc kirjoitti:
 Greetings,
 
 Each time a device is automatically mounted by operating system every
 gnome/gtk aware application can access it without any problems. The
 problem is with non-gnome applications. There is no way to access all
 those devices and auto mounting loses its purpose.
 
 With various storage devices the workaround is to open your home
 directory and navigate to .gvfs and open the directory of the device.
 This is cumbersome and not always possible, because one might not see
 the dot directory.
 
 Now, the real problem. Digital cameras that are recognized by gphoto2
 and are 'mounted' with PTP there is no way to access them.
 
 This is seriously disturbing the work flow of someone that deals with a
 lot of photographs and is not using a gnome-aware software for post
 processing and cataloging. It means that photographs have to be copied
 to the disk and then imported in chosen software.
 
 Unfortunately using Shotwell isn't an option, because it lacks a lot of
 RAW processing functionality and post processing filters and options.
 
 So, are there any workarounds that don't require a lot of manual work?

gvfs mounts show up under ~/.gvfs/name at least here, so navigate
there to access them from 3rd party apps (like, the terminal.. :)

t

-- 
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: 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: White-on-black terminal should be default

[Timo Aaltonen]

On Sat, 6 Mar 2010, Martin Pitt wrote:

 Chris Jones [2010-03-06  9:52 +1000]:
 Although I'm an avid fan of a white-on-black terminal theme and agree that
 it should be the default, I'm not going to add to the argument even more
 than what's necessary.

 It's not necessary indeed -- the new default theme in Lucid for
 terminals is white-on-black (well, some slightly different colors, but
 in principle).

 But oh well, easy enough to fix that to an ergonomically sane
 black-on-white again. :-)

White is way too bright for me. Gray-on-black ftw! :)


-- 
Timo Aaltonen
Systems Specialist
IT Services, Aalto University School of Science and Technology

-- 
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: Lack of support for 32bits libraries under Ubuntu 64bits

[Timo Aaltonen]

On Wed, 21 Jan 2009, Patrice Vetsel wrote:

 Hi,

 I'm part of beta team test for a proprietary software (bibble 5). This
 software is compiled for 32 bits and 64bits is not planed at all.

Err.. I've bought BibblePro, and AIUI a native 64bit version should be 
released when v5 is out?


 So after reporting a new bug for this app, I discovered a big difference
 between Ubuntu64 and OpenSuse64.

 Bibble 5 beta need libuuid in 32 bits installed. OpenSuse have many,
 many libraries installed in 64 AND 32, and many others available.
 Under Ubuntu it's the oposite. 4 libraries are provided in 32 bits for
 compatibilities and are available for installation in ubuntu64.

 The result is that i had to manually download/extract the libuuid for
 32bits. Manually because installing automatically (forcing installation
 of i386 package) libuuid in 32bits overwrite the 64bits verion files.

 What is the position of ubuntu devs for this kind of problem ?

Depend on ia32-libs, which does include libuuid and many others.

t

-- 
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: Lack of support for 32bits libraries under Ubuntu 64bits

[Timo Aaltonen]

On Wed, 21 Jan 2009, Timo Aaltonen wrote:

 On Wed, 21 Jan 2009, Patrice Vetsel wrote:

 Hi,

 I'm part of beta team test for a proprietary software (bibble 5). This
 software is compiled for 32 bits and 64bits is not planed at all.

 Err.. I've bought BibblePro, and AIUI a native 64bit version should be
 released when v5 is out?

Ok, checked the forums and 64bit is not coming in the initial release, but 
likely later with a point-release.

 So after reporting a new bug for this app, I discovered a big difference
 between Ubuntu64 and OpenSuse64.

 Bibble 5 beta need libuuid in 32 bits installed. OpenSuse have many,
 many libraries installed in 64 AND 32, and many others available.
 Under Ubuntu it's the oposite. 4 libraries are provided in 32 bits for
 compatibilities and are available for installation in ubuntu64.

 The result is that i had to manually download/extract the libuuid for
 32bits. Manually because installing automatically (forcing installation
 of i386 package) libuuid in 32bits overwrite the 64bits verion files.

 What is the position of ubuntu devs for this kind of problem ?

 Depend on ia32-libs, which does include libuuid and many others.

 t

 -- 
 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: Wacom tablets, TabletPC and Xorg support for Ubuntu 9.04 (Jaunty)

[Timo Aaltonen]

On Sun, 9 Nov 2008, Loïc Martin wrote:

 I contacted upstream, and their answer can be found at:
 http://sourceforge.net/mailarchive/message.php?msg_name=167e8a330811070926n3024605m7bd7baa6e24bfedf%40mail.gmail.com
 Here is an extract:
 Hotplugg is a server-wide issue. It will be resolved for all input devices
 in Xorg, not just for Wacom devices.

 So what is Xorg going to do about wacom devices support, and how can we
 make sure that, after one year, this support (or a distribution
 solution) will at least make it into Jaunty?
 Loïc

Seems like he didn't understand your question. Resolved for all input 
devices means input-hotplug which is used as you know.. The problem is 
just that wacomdrv doesn't have the options or infrastructure to configure 
stylus/eraser/pad all in one go. HAL/input-hotplug/xserver can't do that 
for the driver.

Seems like some work is happening, but so far no comments from Ping:

http://sourceforge.net/mailarchive/forum.php?thread_name=20081009171824.GV5387%40cathedrallabs.orgforum_name=linuxwacom-devel

t

-- 
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: Joysticks/joypads/etc information needed for Ubuntu 8.10 Intrepid Ibex and later

[Timo Aaltonen]

On Mon, 20 Oct 2008, Loïc Martin wrote:

 Hi,

 Stating with Ubuntu 8.10 Intrepid Ibex and due to changes in Xorg, each
 model of joystick needs a special file to be recognised properly. For
 the moment 8.10 doesn't ship with these files, and thus your joystick
 shouldn't be working anymore (instead, it should move the mouse cursor,
 sometimes preventing the use of the mouse until you unplug the joystick).

No, we don't need that. The reason why it moves the mouse cursor is that 
the evdev driver picks it up, and the situation would be exactly the same 
if xserver-xorg-input-joystick would pick up the device (that's what the 
driver is used for, a fact that I admit having missed earlier.. ahem).

The problem here is that HAL doesn't know that the joystick you plug in is 
a joystick, instead it thinks it is a mouse (and/or a keyboard). That's 
why the evdev driver picks it up and all attempts to use /dev/input/js? 
fails. The correct fix would be to fix hal/kernel to know that it really 
is a joystick, and blacklist evdev for such devices. Then you should be 
able to use the joystick just like before input-hotplug.

Why wasn't this discovered earlier? The first bug regarding joysticks was 
filed on Sep 20th (bug 272421 [1]), and it took a while to fix the crasher 
for good. Input-hotplug had been in use for nearly two months by then, and 
there simply was not enough time to fix it properly after the crasher was 
fixed.

You have the workaround, which is to disable loading evdev for the 
joystick locally. That should do for Intrepid. Disabling AutoAddDevices 
is another way, but then you disable i-h for every input driver and it 
shouldn't be encouraged on the forums or elsewhere..



t

-- 
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: tablet-support in Ubuntu

[Timo Aaltonen]

On Sun, 5 Oct 2008, Loïc Martin wrote:

 Now the workarounds:
 
 -If you like to disable input-hotplug completely, add 'Option 
 AutoAddDevices false' to the ServerFlags-section. Then you are on your 
 own, and get to keep both pieces.
 
 The syntax is the xorg.conf one, however I see no ServerFlags or even Server 
 sections in Intrepid's xorg.conf. Do you mean Section ServerLayout, and if 
 not in which file is the option AutoAddDevices supposed to go?

No, you have to add the ServerFlags-section yourself, see man xorg.conf.

 -If you like to just skip i-h for a single device you have, add an fdi file 
 to /etc/hal/fdi/policy which matches your device and leaves 
 input.x11_driver empty. Then you can configure that device in xorg.conf and 
 prosper.
 
 I tried that, but failed. There's two problems as an user :
 1. The only example file in /etc/hal/fdi/policy,  preferences.fdi is about 
 hotpluggable storage devices
 device
   match key=storage.hotpluggable bool=false
 match key=storage.removable bool=false
   merge key=storage.automount_enabled_hint type=boolfalse/merge
 /match
   /match
 /device
 What is the syntax for a wacom tablet, and what is the syntax for a joystick?

Copy the file provided by the driver from 
/usr/shale/hal/fdi/policy/20thirdparty/ and edit as you like. Note that 
for joysticks you just need to run 'lshal' and attach that to a bug 
report. The driver doesn't ship an fdi file yet, but it will be fixed 
soon, and the more coverage we get for various devices the better.

 2. Wacom Cintiq 12wx shows as both /dev/input/tablet-cintiq12wx and 
 /dev/input/wacom.
 Does it need 2 fdi in /etc/hal/fdi/policy, and if so does it need duplicate 
 entries in xorg.conf?

No and no.

 To update Ubuntu community documentation, I think it's better to chose your 
 second solution (skip i-h for a single device).
 Then, since Ubuntu's xorg.conf doesn't have any configuration for wacom 
 devices anymore, are the lines from 
 https://help.ubuntu.com/community/WacomTroubleshooting still good - for 
 example added at the end of /etc/X11/xorg.conf? Bryce Harrington (cced) 
 edited the page two month ago : *This content is quite old and may not be 
 applicable to current versions of Ubuntu.
 *

snip

should work if evdev doesn't grab the device.

 Is there anything to add to xorg.conf for joysticks?

No, the fdi method is enough.


t

-- 
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: tablet-support in Ubuntu

[Timo Aaltonen]

On Sun, 5 Oct 2008, Loïc Martin wrote:

 Timo Aaltonen wrote:
 By default, the evdev-driver handles all input devices that HAL is aware of 
 and which list input.keys/input.mouse as a capability of the device. Evdev 
 might not be the best choice for example touchpads or tablets, and that's 
 why there needs to be a driver specific HAL fdi-file that makes the device 
 use the correct driver. This is true for synaptics touchpads, wacom tablets 
 and (some) joysticks (WIP).
 If a device isn't handled properly by the evdev-driver, should start filing 
 bugs against xserver-xorg-input-evdev for not providing a driver specific HAL 
 fdi-file, or do these have to be filed against another package (xorg?)?

Against the driver which _should_ handle the device, for example 
xserver-xorg-input-joystick.

 Someone needs to kick^H^H^H^Hask upstream  :) 
 If we want to forward the bugs upstream, do we do this on xorg (wherever it 
 might be), evdev or linuxwacom bug tracker?

I was referring to linuxwacom upstream, which should be aware of the 
problems with input-hotplug, but has not done anything about it AFAIK.

t


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

tablet-support in Ubuntu

[Timo Aaltonen]

Hi!

   I'll start a new thread, because the ongoing thread became a bit too 
confusing to follow.

Let's clear one thing first:

   8.10 will not remove support for tablets

now repeat that umpteen times.

There has been too much misinformation floating around lately, and + 
admit that the consequences of input-hotplug could have been informed 
better, but I'll take this opportunity to clarify things that confuse 
people the most.

First of all, things might work differently out-of-the-box, but that 
doesn't mean that input drivers couldn't be configured like before if need 
be. By default, the evdev-driver handles all input devices that HAL is 
aware of and which list input.keys/input.mouse as a capability of the 
device. Evdev might not be the best choice for example touchpads or 
tablets, and that's why there needs to be a driver specific HAL fdi-file 
that makes the device use the correct driver. This is true for synaptics 
touchpads, wacom tablets and (some) joysticks (WIP).

Serial devices (some tablets, touchscreens) are more problematic, since 
HAL doesn't know about them without some trickery (which I'm not an 
expert of). But in those cases you should be able to configure them via 
xorg.conf without too much trouble.

Now the workarounds:

-If you like to disable input-hotplug completely, add 'Option 
AutoAddDevices false' to the ServerFlags-section. Then you are on your 
own, and get to keep both pieces.

-If you like to just skip i-h for a single device you have, add an fdi 
file to /etc/hal/fdi/policy which matches your device and leaves 
input.x11_driver empty. Then you can configure that device in xorg.conf 
and prosper.


Note that the wacom driver doesn't fully support input-hotplug, since 
currently you need to initialize the driver multiple times to enable 
stylus/pen/foo, and that's not possible to do with HAL. The wacom fdi file 
configures the device as stylus..



--
Timo Aaltonen
Systems Administrator
IT Services, Helsinki University of Technology
tel. +358-9-4514317, mobile: +358-50-5918781
http://users.tkk.fi/~tjaalton

-- 
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: tablet-support in Ubuntu

[Timo Aaltonen]

On Tue, 30 Sep 2008, Vincenzo Ciancia wrote:

 On mar, 2008-09-30 at 11:04 +0300, Timo Aaltonen wrote:

 Note that the wacom driver doesn't fully support input-hotplug, since
 currently you need to initialize the driver multiple times to enable
 stylus/pen/foo, and that's not possible to do with HAL. The wacom fdi
 file
 configures the device as stylus..

 Sorry for much noise and thank you for clarification and documentation
 you provide here. Do you have a pointer with more explanations for the
 latter? Can't HAL be faked into using three different drivers which
 are just aliases for the same input driver so that it is reinitialised?

No problem.

It has been confirmed by upstream that what you propose is not possible to 
do with HAL, but instead the driver should use NewInputDeviceRequest() to 
accomplish the same. Unfortunately, that'll take some time, but here's 
hoping that the next six months are enough to have that in time for 
Jaunty. Someone needs to kick^H^H^H^Hask upstream :)

t

-- 
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: Touchpad issues

[Timo Aaltonen]

On Mon, 4 Aug 2008, Robert Easter wrote:

 Hello.

 What plans, does anyone know, are there for accommodating the Elantech
 touchpads?  The current Synaptics drivers  won't touch them, and the
 mouse drivers (only other option) leave the touchpad generally unstable

needs kernel support to make it work properly:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/123775


t

-- 
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: An example of how things should *not* be done

[Timo Aaltonen]

On Tue, 22 Apr 2008, Dylan McCall wrote:

 Ideally, couldn't the install script for xserver-input-wacom add the
 necessary stuff to xorg.conf itself?

The driver is installed on every system (due to x-x-input-all), so it 
wouldn't work.

The dexconf approach would only work for tablets, but not pluggable 
devices that aren't plugged in during install/reconfiguration. So, a 
possible approach would be to use the device manager (jockey) to add the 
necessary configuration. The problem with it is that it's only run on 
session startup, but Martin Pitt pointed out that gnome-volume-manager has 
some support for hotplugged tablets, so that could be used until jockey 
supported hotplug. This will be discussed at the next UDS, and might be 
implemented for 8.04.1 if all goes well :)

 I imagine that would lead to really ugly xorg configuration files,
 though, as we see with the old Screens  Graphics tool. I guess what
 we need is a magical, open-ended and centralized tool for configuring
 xorg.conf that everyone (including the end user) uses. Would help if
 this wasn't a single big file...

There's a proposal on Debian XSF wiki about having a xorg.conf.d directory 
which would hold configuration snippets from packages etc. that the server 
would read.

t

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