[15:01] <sil2100> o/
[15:01] <waveform> o/
[15:01] <bdmurray> #startmeeting Weekly Ubuntu Foundations team
[15:01] <meetingology> Meeting started Thu Aug 20 15:01:44 2020 UTC.  The chair is bdmurray. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:01] <meetingology> Available commands: action commands idea info link nick
[15:02] <bdmurray> #topic Lightning rounds
[15:02] <bdmurray> echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity mwhudson juliank waveform slyon)
[15:02] <bdmurray> mwhudson sil2100 bdmurray vorlon tdaitx doko waveform juliank infinity rbalint xnox slyon
[15:02] <bdmurray> sil2100: you win!
[15:02] <sil2100> OH NO
[15:02] <sil2100> Ok
[15:03] <sil2100> - Was off on Monday
[15:03] <sil2100> - SRU reviews and releases
[15:03] <sil2100> - Kernel SRUs
[15:03] <sil2100> - Last week: 18.04.5 and 16.04.7, UC18
[15:03] <sil2100> - Building UC16 candidates, preparing appliance images for promotion
[15:03] <sil2100> - Tweaks on the delivery system for gadget snaps
[15:03] <sil2100> - Interviews
[15:03] <sil2100> - Pi desktop-related discussions
[15:03] <sil2100> - Eoan EOL
[15:03] <sil2100> - Investigating UC18 kassel image issues, no luck so far
[15:03] <sil2100> (done)
[15:03]  * juliank is near real-town Kassel
[15:03] <bdmurray> updated metarelease files for point releases
[15:03] <bdmurray> helped testing nodejs packages for -proposed migration
[15:03] <bdmurray> reported juju bug LP: #1891561
[15:03] <bdmurray> uploaded new upstream version of python-gmpy2 to Ubuntu and Debian
[15:03] <bdmurray> reviewed and merged fix for LP: #1611737
[15:04] <bdmurray> reported friendly-recovery bug LP: #1891952
[15:04] <bdmurray> sync'ed pycairo from debian to fix FTBFS issue
[15:04] <bdmurray> uploaded zope.interface fixing FTBFS
[15:04] <bdmurray> investigation into LP: #1798369
[15:04] <bdmurray> uploaded apt-clone fix for LP: #1858326
[15:04] <bdmurray> updated cleanup-NBS-for-EOL for new britney output
[15:04] <bdmurray> Eoan EOL work
[15:04] <bdmurray> putting out fires 🔥
[15:04] <bdmurray> ✔ done
[15:04] <bdmurray> vorlon:
[15:04] <vorlon> hmm move me to the end please
[15:05] <vorlon> tdaitx: ?
[15:05] <tdaitx> - tested binaries and ran autopkgtest for xz-utils stuck in focal-proposed; rerun failed apt/armhf autopkgtest
[15:05] <tdaitx> - local setup for running jck snap in a lxc container
[15:05] <tdaitx> - reviewed need for remote agent as docs & config have ambiguous descriptions
[15:05] <tdaitx> - fixing scilab: rebuilding deps, backporting patches from groovy
[15:05] <tdaitx> (done)
[15:05] <juliank> 620335
[15:05] <juliank> 256388
[15:06] <juliank> bad yubikey
[15:06] <xnox> bug #256388
[15:06] <xnox> bug #620335
[15:06] <juliank> I think doko is off, so it's waveform's turn
[15:06] <xnox> waveform:  ?
[15:06] <waveform> * Investigated eth dhcp issue on core20; unable to reproduce (LP: #1878640)
[15:06] <waveform> * Bluetooth testing on core (re LP: #1890817)
[15:06] <waveform> * Fixed EGL/GLES issue in pending userland package (LP: #1891613)
[15:06] <waveform> * Investigated lapack migration (unsuccessfully)
[15:06] <waveform> * ubuntu-image work for devices and pi image building
[15:06] <waveform> * pi-gadget work
[15:06] <waveform> * Testing USB boot modes on pi4
[15:06] <waveform> (done)
[15:07] <juliank> aug 20:
[15:07] <juliank> * sponsored python-gmpy2 NMU to Debian for bdmurray (debian bug 965001)
[15:07] <juliank> * grub bug triage
[15:07] <juliank>   - booting 32-bit kernels on 64-bit UEFI is no-no
[15:07] <juliank>   - a laptop that can't find our grub -> firmware broken, can't find nvme device
[15:07] <juliank> * SRUed grub to focal (not gonna list the bugs again)
[15:07] <juliank> * fixed memtest86+ in groovy, and SRUed to focal: Close FD 3 when invoking update-grub (LP: #1876506)
[15:07] <juliank> * talked with Laney about OEM stuff
[15:07] <juliank> (done)
[15:08] <bdmurray> rbalint is out
[15:08] <bdmurray> xnox:
[15:08] <xnox> progressing with needrestart work on cloud/server
[15:08] <xnox> microcode-initrd source-new accepted! hooray, now waiting for bin-new
[15:09] <xnox> started libffi 8.1.0 abi snapshot builds in bileto ppa with cet enabled
[15:09] <xnox> uploaded secureboot-db into unapproved for all the series
[15:09] <xnox> followed up on tlp MIR
[15:09] <xnox> progressing with safer grub-install with built-in rollbacks
[15:09] <xnox> positive test feedback for finalrd for core16 (needs finalrd backports)
[15:09] <xnox> done
[15:09] <bdmurray> lucas is out
[15:09] <bdmurray> #topic Release incoming bugs
[15:09] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-gg-incoming-bug-tasks.html#foundations-bugs
[15:10] <vorlon> oh ok I won't give my status then, it was boring anyway ;)
[15:10] <bdmurray> that's your perogative
[15:10] <bdmurray> bug 1891952
[15:11] <bdmurray> I ran into this when my laptop wouldn't boot with the new systemd
[15:11] <bdmurray> Well I couldn't get an x-session
[15:12] <bdmurray> I should retest this with the old systemd so will
[15:13] <mclemenceau> I will card this
[15:13] <bdmurray> bug 1892040
[15:13] <bdmurray> Is this a duplicate of the card we took the other day?
[15:14] <vorlon> https://bugs.launchpad.net/bugs/1875062
[15:14] <vorlon> L?
[15:14] <vorlon> ?
[15:15] <bdmurray> That's the one of which I'm thinking
[15:15] <cpaelzer> mclemenceau: hi I made it out of the other calls - if I might interrupt in which section do I want to talk about mine?
[15:16] <mclemenceau> it's coming soon cpaelzer
[15:16] <bdmurray> well let's card this and comment in the existing card about this bug
[15:17] <mclemenceau> ok carded!
[15:18] <bdmurray> bug 1891623
[15:18] <bdmurray> I guess we should take this
[15:19] <Laney> Heather's trying to reproduce
[15:20] <bdmurray> Okay so can we let it wait Laney?
[15:20] <Laney> would be good if d_oko or whoever and Heather could work together
[15:20] <bdmurray> d_oko is out for a while
[15:20] <Laney> ah ok
[15:20] <xnox> Laney:  yeah, ideally we'd want preprocessed source of a "small" binary (if there is any), the binary, and the coredump / traceback?
[15:20] <Laney> I know
[15:20] <Laney> but the first step is reproducing it at all
[15:20] <xnox> and yes d o k o is out for 2 weeks =/
[15:20] <Laney> come back to it next week
[15:20] <bdmurray> Will do thanks
[15:20] <bdmurray> Okay cpaelzer its your turn
[15:21] <cpaelzer> hehe
[15:21] <cpaelzer> thanks
[15:21] <mclemenceau> I tagged this one this morning bug 1892358 not showing on the report yet
[15:21] <cpaelzer> I was this morning trying to catch rbalint for systemd autopkgtest fail-rate
[15:21] <cpaelzer> but learned that he's unavailable atm
[15:21] <cpaelzer> thanks mclemenceau for the bug
[15:22] <cpaelzer> I only wnated to ask if someone here could take a look so that we have a second opinion
[15:22] <xnox> cpaelzer:  that looks like a normal / good pass rate
[15:22] <xnox> i mean, it used to be way worse
[15:22] <cpaelzer> xnox: 10/10 last tests failed
[15:22] <cpaelzer> if that is normal I maybe should change expectations :-)
[15:22] <cpaelzer> I just want to avoid retrying on aveagre ~20 times per test per arch
[15:23] <xnox> at one point i spent more than a year with migrating systemd based on a superset of multiple test runs.
[15:23] <xnox> i.e. there tests passed in this run, that test pasted in that run, and that one i will try to fix next time.
[15:23] <xnox> and next time something else regressed.
[15:23] <xnox> i agree with the sentiment.
[15:23] <cpaelzer> yeah, but for now in groovy we have to do something
[15:23] <cpaelzer> "tests-in-lxd" and "systemd-fsckd" droped below an acceptable rate
[15:23] <xnox> however we just landed new upstream release, and it usually does regress a lot.
[15:24] <cpaelzer> I remember xnox last time you worked on itit was fsckd as well and boot-smoke or something like that
[15:24] <xnox> fsckd one is being fixed in bileto already, that was assigned and was worked last week / this week.
[15:24] <cpaelzer> xnox: yes 246 seems to have made it worse
[15:24] <xnox> lxd => is related to snapd & networkd regressions that are being fixed in snapd
[15:24] <xnox> so there are things that are known and worked on too.
[15:24] <cpaelzer> fsckd of the last three days are all bad, does this fix need to land first?
[15:25] <cpaelzer> do you have a bug on the snapd/network bug I could track?
[15:25] <juliank> g
[15:25]  * juliank typo
[15:25] <cpaelzer> initially all I asked was "are these knowns and are there bugs I could track" to if you know them let me know the urls
[15:25] <xnox> cpaelzer:  please stand by whilst i try to find those two fixes
[15:26] <bdmurray> cpaelzer: if xnox gives you bugs / something to watch will you be happy?
[15:26] <xnox> cpaelzer:  https://bileto.ubuntu.com/#/ticket/3801 has fixes for fsckd & networkd
[15:27] <xnox> cpaelzer:  see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-3801/2020-08-20_11:08:36/groovy_systemd_packaging_changes.diff
[15:27] <xnox> which should improve/fix/resolve the lxd & fsckd tests.
[15:27] <xnox> bug 1886886
[15:27] <xnox> and
[15:27] <cpaelzer> bdmurray: for now yes, if this takes too long we all will want some interim fixes - but for now I'm fine
[15:27] <xnox> bug 1891716
[15:28] <bdmurray> cpaelzer: okay, then we will move on and leave your bug open for next week
[15:28] <xnox> cpaelzer:  i mean i could tag them "update-excuse" but that will not make them pop up on the test results of reverse deps?
[15:28] <cpaelzer> thanks bdmurray and xnox
[15:28] <bdmurray> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html#foundations-bugs
[15:29] <bdmurray> bug 1891641
[15:29] <juliank> duplicate
[15:29]  * juliank searches bug
[15:30] <juliank> https://launchpad.net/bugs/1627564
[15:31] <bdmurray> that's that for FF then
[15:31] <bdmurray> so next
[15:31] <bdmurray> #topic FTBFS with gcc-10
[15:31] <xnox> re FTBFS bugs in GG
[15:31] <xnox> klibc	2.0.7-1ubuntu5	✓	i386 (F) → Log	amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	doko	N
[15:31] <xnox> hfsplus	1.0.4-15	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	juliank	N
[15:31] <xnox> nfs-utils	1:1.3.4-2.5ubuntu5	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	juliank	N
[15:31] <xnox> golang-1.13	1.13.8-1ubuntu1	✓				arm64 (F) → Log				PTS BTS	mwhudson	RM
[15:31] <xnox> golang-1.14	1.14.4-1ubuntu2	✓				arm64 (F) → Log				PTS BTS	mwhudson	N
[15:32] <xnox> syslinux-legacy	2:3.63+dfsg-2ubuntu9	✓		amd64 (F) → Log						PTS BTS	mwhudson	RM
[15:32] <xnox> glibc	2.31-0ubuntu10	✓			armhf (F) → Log	arm64 (F) → Log			1714514 1571684	PTS BTS	rbalint	N
[15:32] <xnox> logrotate	3.14.0-4ubuntu4	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	rbalint	N
[15:32] <xnox> pexpect	4.6.0-3	✓		amd64 (F) → Log					1891193	PTS BTS	slyon	N
[15:32] <xnox> efivar	37-2ubuntu4	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log				PTS BTS	tdaitx	N
[15:32] <xnox> pyparted	3.11.2-11.1build1	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	tdaitx	N
[15:32] <xnox> lapack	3.9.0-2	✓					ppc64el (F) → Log		1708735	PTS BTS	xnox	N
[15:32] <xnox> netkit-ftp	0.17-34.1build1	✓		amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	xnox	N
[15:32] <vorlon> make it staaaaahp
[15:32] <xnox> db5.3	5.3.28+dfsg1-0.6ubuntu2	✓	i386 (F) → Log	amd64 (F) → Log	armhf (F) → Log	arm64 (F) → Log	ppc64el (F) → Log	s390x (F) → Log		PTS BTS	xnox	N
[15:32] <xnox> not what i wanted!
[15:32] <xnox> klibc
[15:32] <xnox> hfsplus
[15:32] <xnox> nfs-utils
[15:32] <xnox> golang-1.13
[15:32] <xnox> golang-1.14
[15:32] <xnox> syslinux-legacy
[15:32] <xnox> glibc
[15:32] <xnox> logrotate
[15:32] <xnox> pexpect
[15:32] <xnox> efivar
[15:32] <xnox> pyparted
[15:32] <xnox> lapack
[15:32] <xnox> netkit-ftp
[15:32] <xnox> db5.3
[15:32] <xnox> are still to do
[15:33] <tdaitx> libstd was fixed on debian, already synced to groovy
[15:33] <tdaitx> I have a backport for a gcc-10 for pyparted
[15:33] <tdaitx> have a broad look at efivar
[15:34] <xnox> tdaitx:  tah
[15:35] <xnox> and we have assignees to fix those, please do that.
[15:35] <xnox> bdmurray:  next?!
[15:35] <bdmurray> Are there people that need to hand things off given schedules next week?
[15:35] <juliank> i don't know!
[15:35] <juliank> I'm 50% gone
[15:35] <xnox> juliank:  you have
[15:35] <xnox> hfsplus
[15:35] <xnox> nfs-utils
[15:35] <juliank> It sounds ok, I suppose
[15:35] <juliank> we'll see
[15:35] <juliank> :)
[15:36] <bdmurray> okay moving on
[15:36] <bdmurray> #topic Team proposed-migration report
[15:36] <vorlon> [LINK] https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#foundations-bugs
[15:36] <vorlon> looking much better this week :)
[15:37] <vorlon> lapack, blocked by an autopkgtest on a revdep
[15:37] <vorlon> sil2100: would you like this?
[15:37] <sil2100> Sure!
[15:37] <vorlon> google-compute-engine-oslogin is rbalint's
[15:37] <waveform> I've got lapack at the mo
[15:37] <sil2100> ...then I guess not!
[15:38] <sil2100> ;)
[15:38] <xnox> but there is also lapack ftbfs
[15:38] <vorlon> oh was this carry-over?
[15:38] <xnox> so it's all three of us?
[15:38] <sil2100> waveform: continue working on it then, thanks o/
[15:38] <vorlon> sil2100: you're off the hook
[15:38]  * sil2100 won for the second time today
[15:39] <vorlon> pam is mine because assigned to me for ftbfs, but I'm not messing with the autopkgtests on the current version in -proposed because I'm prepping a new upstream version for Debian
[15:39] <vorlon> dnspython: sil2100: you can have this one
[15:40] <vorlon> gdbm: autopkgtest failure on i386, this one's never been investigated since we made i386 compat-only
[15:40] <vorlon> would anyone like to take a look at this or is it going to default to me like all the i386 stuff? :)
[15:40] <vorlon> oh I uploaded it
[15:40] <vorlon> so it defaults to me anyway ;)
[15:40] <xnox> i was gonna say.....
[15:41] <sil2100> vorlon: okay!
[15:41] <vorlon> ok gdbm is mine
[15:41] <vorlon> sensible-utils: bdmurray?
[15:41] <xnox> on slyon? the sync was his request to fix ftbfs
[15:41] <vorlon> plymouth vs systemd, rbalint already has a fixed staged for that AIUI
[15:41] <bdmurray> inconceivable!
[15:41] <vorlon> xnox: which one?
[15:41] <xnox> autodep8 was mine, but i am failing to comprehend why ti's failing.
[15:41] <xnox> vorlon:  slon => sensible-utils
[15:42] <vorlon> ok, sensible-utils to slyon, not bdmurray
[15:42] <vorlon> xnox: do you want to keep it or hand it off?
[15:42] <xnox> so i want to give up autodep8 to someone else please
[15:42] <vorlon> autodep8: bdmurray?
[15:42] <bdmurray> okay
[15:42] <vorlon> libgitlab-api-v4-perl: tdaitx?
[15:43] <tdaitx> ok
[15:43] <juliank> (that's a merge of bash-completion FWIW)
[15:43] <vorlon> lintian: juliank?
[15:43] <juliank> (libgitlab-api-v4-perl)
[15:43] <juliank> yeah
[15:43] <juliank> I need to talk to lintian folks about that anyway
[15:43] <vorlon> dput: xnox?
[15:43] <juliank> it also fails in normal lxd containers
[15:43] <xnox> ok
[15:43] <vorlon> actually
[15:44] <vorlon> that's really setuptools
[15:44] <vorlon> xnox: you ok to take setuptools?
[15:44] <xnox> i thought +1 was bootstrapping lintian to be fair
[15:44] <xnox> vorlon:  sure
[15:44] <vorlon> sqlite3
[15:44] <juliank> dput is .. just a timeout
[15:44] <Laney> I am bootstrapping lintian, I am not dealing with the autopkgtest failure or the component-mismatch atm
[15:44] <xnox> ah, ok, thanks.
[15:44] <juliank> (in some cleanup hook)
[15:45] <vorlon> juliank: ok if lintian is no work for you because Laney, can you take sqlite3?
[15:45] <Laney> noooo, please keep the autopkgtest at least :p
[15:45] <vorlon> oh :)
[15:45] <vorlon> then who wants sqlite3?
[15:45] <vorlon> I think everyone's been assigned one
[15:45] <vorlon> so who's hungry for seconds
[15:45] <juliank> So lintian is fine, but sqlite3 is that a gcc-10 bug?
[15:45] <Laney> (the MIR you can reply to my question in #-release to determine if there's work required)
[15:45] <juliank> /tmp/autopkgtest.4tqIue/build.vxn/src/debian/tests/run-unit-tests: line 29:  1275 Illegal instruction     (core dumped) hyphy "$i"
[15:46] <xnox> hyphy is a pile of code that is fragile, it could be hyphy buggy too
[15:47] <juliank> move on?
[15:47] <vorlon> and that's the list
[15:47] <vorlon> bdmurray:
[15:48] <bdmurray> #topic AOB
[15:48] <juliank> I'm mornings-mostly next week
[15:48] <juliank> And DebConfing
[15:48] <juliank> I don't how distracting DebConf online will be
[15:48] <xnox> and LinuxPlumbers
[15:48] <bdmurray> So bug 1798369 I've heard some comments that we should get rid of this and I'd like some reasons
[15:49] <juliank> There are bugs every release cycle about it and nobody really gives it much testing
[15:50] <bdmurray> which it though? The restore packages option or the whole reinstall option?
[15:51] <juliank> restore packages
[15:51] <juliank> I want to keep $HOME, but not try to reinstall packages that were installed
[15:51] <xnox> so, restoring packages indeed doesn't quite make sense
[15:52] <juliank> maybe save an apt-clone tarball in /var/log
[15:52] <xnox> restoring snaps might, but i don't know if we preserve /var/lib/snapd
[15:52] <bdmurray> hey let's not make new features!
[15:53] <bdmurray> Okay, I'll discuss with the desktop team about removing the restore packages option.
[15:54] <bdmurray> anything else?
[15:54] <bdmurray> okay, thanks everybody
[15:54] <bdmurray> #endmeeting
[15:54] <meetingology> Meeting ended Thu Aug 20 15:54:33 2020 UTC.
[15:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2020/ubuntu-meeting.2020-08-20-15.01.moin.txt
[15:54] <juliank> o/
[15:54] <sil2100> o/
[15:55] <vorlon> thanks!


[00:02] <CarlFK> pitti: I was told to bug you (don't you feel lucky) - i'm trying to do 'this' https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/212073
[00:02] <CarlFK> I see the changes in lshal, but 0 effect on X
[00:03] <CarlFK> the problem I am trying to fix: when I move my finger to the left, the mouse cursor moves to the right
[00:04] <ScottK> I suppose turning the machine upside down won't do it?
[00:04] <ScottK> ;-)
[00:05] <CarlFK> don't laugh - I was considering that
[00:05] <CarlFK> but then the up/down will have problems
[00:11] <Hobbsee> kirkland: that's fixed it, thanks.  I'll upload the change, if you like.
[00:13] <Hobbsee> hrm, it's in bzr.  damn.
[00:17] <Guest49220> argh
[00:21] <Hobbsee> kirkland: blah, it's done already.  Who said fixes in ubuntu weren't fast?  ;)  Thanks!
[00:28] <NCommander> hey Hobbsee
[00:29] <directhex> NCommander, i did it, i got an arm system booted in qemu
[00:29] <NCommander> score :-)
[00:30] <directhex> NCommander, if i might make a suggestion... could someone DOCUMENT the fact that the default kernel cmdline includes "mem=32M"?
[00:30] <Hobbsee> hey NCommander
[00:30] <directhex> hair was torn out over that
[00:30]  * NCommander didn't know that
[00:30] <NCommander> Hobbsee, how goes it
[00:30] <directhex> NCommander, i got the screenshot i wanted - http://www2.apebox.org/wordpress/wp-content/gallery/00-single/armless.png
[00:31] <NCommander> lol
[00:31] <NCommander> Xubuntu!
[00:31] <Hobbsee> NCommander: fighting matlab :)
[00:31] <NCommander> FTW!
[00:31] <directhex> NCommander, MID was uninstallable this morning due to python transition
[00:31] <NCommander> Hobbsee, have you prepared the scarifies in the necessary order?
[00:31] <NCommander> directhex, the python transition has/had most of the archive broken :-/
[00:31]  * StevenK is kicking python-hildondesktop now
[00:32] <Hobbsee> NCommander: no.  I think that might be my problem...
[00:32] <directhex> StevenK, well, i'm not moaning, fixing lp-integration made xubuntu installable :p
[00:32] <NCommander> Yay for installable xubuntu
[00:32] <directhex> matlab? :|
[00:32]  * NCommander just installed Alpha 5 on his new machine :-)
[00:32] <NCommander> StevenK, what's wrong with it
[00:32] <StevenK> NCommander: Python 2.6
[00:32] <directhex> NCommander, i wasn't going to push my luck & try a full-on gnome on arm in qemu with 256M
[00:33] <NCommander> I mean is it FTBFSing?
[00:33] <NCommander> directhex, 256 is the max you can run. GNOME runs slowly, but it does work
[00:33] <directhex> NCommander, at any rate, silverlight on ARM, complete with media support! :p
[00:33] <NCommander> nice!
[00:34] <StevenK> NCommander: It's uninstallable, I'm looking at fixing it.
[00:34] <NCommander> StevenK, would you like some help?
[00:35] <directhex> NCommander, mostly i was documenting the procedure, to allow novell to produce one of those optional licensed binary codec downloads for arm. in case ffmpeg ever loses the required abilities for any reason.
[00:54]  * TheMuso kinda wished that the python transition happened earlier in the cycle...
[00:54] <TheMuso> IMO transitions should only be before feature freeze.
[00:55] <directhex> started, certainly. sometimes they can drag on a bit, depending on size
[00:55] <ScottK> Major ones anyway.
[00:58] <NCommander> But python2.6 was uploaded past FF?
[00:58] <NCommander> s/?/.
[00:59] <ScottK> It was, but it was spec'ed and approved.
[01:00] <directhex> bam, i have now entered the debian web o' trust
[01:01] <NCommander> What's the point of FF if we break everything post it :-/
[01:01]  * NCommander is reminded of libbluetooth last cycle, although that was kinda an exception cirmstance.
[01:03] <StevenK> NCommander: It wasn't python2.6 that was the issue, it's python-defaults.
[01:30] <andersk> Is there a main sponsor available to look at the one-line patch in bug 336436?
[04:22] <redvamp128> okay quick question-- I need to find out what version of oss is installed on someones computer -- is there a quick command to find that?
[04:27] <maco> apt-cache policy or dpkg -l will both tell you package versions
[04:28] <maco> i assume you mean either alsa-oss or oss-compat
[04:28] <redvamp128> oss-compat
[04:30] <redvamp128> thanks
[04:32] <maco> np
[04:35] <redvamp128> he can hear system sounds but they are distorted and he is using oss
[04:36] <redvamp128> so I fount 4.1 and 4.0 is the installed version and according to their page they fixed a few issues with his sound card
[04:36] <CarlFK> for jaunty, did alsamixer get replaced?  (or, how do I adjust volume levels in a script)
[04:37] <redvamp128> this one I am afraid is for hardy-- and I think it fixed his issue before just too many people -- too many configurations -- plus my 3 here at the house and 2 linux ones at work and 10 computers at work and 2 servers
[04:38] <redvamp128> and that does not count the 25 laptops
[04:50] <maco> CarlFK: no, alsamixer's still there
[04:50] <maco> this isnt really the place to be asking such support questions though....
[04:54] <CarlFK> maco: oh yeah - the oss stuff distracted me
[08:08] <pitti> Good morning
[08:09] <pitti> EtienneG: yes, although there's probably little I can do about it :/
[08:09] <pitti> jdong_: we should get dbgsyms for -updates/-security
[08:10] <pitti> CarlFK: 212073> let's discuss that in the bug, please subscribe me
[08:11] <pitti> CarlFK: oh, you mean you don't have this particular problem? can you please describe the problem more specifically? does it happen after removal/reinstert, or always, and what's lshal output?
[09:06] <asac> anyone knows if there is precendence of adding libs to ia32 as an SRU?
[09:06] <asac> \sh: ^^?
[09:13] <slangasek> asac: I would be very cautious in accepting such an SRU - why is it needed?
[09:18] <asac> slangasek: two things:
[09:19] <asac> slangasek: i got complain from NSPR/NSS/chrome developer that libnss3-1d needs libsqlite ... but only libnss3-1d is in intrepid ia32
[09:20] <asac> slangasek: 2. also they would love to see those in the LTS, as it would allow amd64 users to build chromium
[09:25] <asac> its a bit strange that it was added there without sqllite ... in jaunty libnss3-1d explicitly depends on libsqlite3-0 (>= 3.5.9)
[09:31] <slangasek> asac: if it were the case that we were shipping nss in hardy ia32-libs already and it was broken, that would be a good reason for an SRU.  I don't think we should add more libs to ia32-libs in hardy simply because they'd be nice to have.
[09:37] <mvo> doko: what do you think about writing a mail to ubuntu-devel-announce that explains to the developers that all packages that use python and distutils needs to get the "--install-layout=deb" added? I just did it for command-not-found and unattended-upgrades, but there are much more that need love. its funny, a simple rebuild puts everything in /usr/local now
[09:38] <asac> slangasek: yes. thats what i thought. intrepid ok, hardy not
[09:38] <asac> i will provide those in some ppa maybe ... so they can add something more official to their build instructions
[09:39] <mvo> doko: or at least the scripts and i18n stuff (that is build via python-distutils-extra)
[09:39] <slangasek> asac: if this is just for building... why not use an i386 chroot?
[09:39] <asac> slangasek: its also for running ;)
[09:39] <slangasek> ok
[09:58] <asac> james_w: bzr-builddeb --merge seems to be broken in jaunty
[09:59] <james_w> asac: how?
[09:59] <asac> (still i guess) ... i have debian/ only branches and the top level dir from the tarball ends up in the build tree
[09:59] <asac> james_w: http://paste.ubuntu.com/125187/
[09:59] <asac> (ignore the aclocal.m4 ... that was created in pre-build)
[10:00] <james_w> and what do you expect?
[10:00] <asac> james_w: i expect the content of NetworkManager.git directory to be in toplevel
[10:01] <james_w> asac: can you do a find for me?
[10:01] <james_w> what are the entire contents of that directory?
[10:01] <asac> james_w: inside NetworkManager.git?
[10:01] <asac> ok
[10:02] <asac> james_w: http://pastebin.com/f26d95ae4
[10:02] <asac> let me get a tar tzf of the tarball too
[10:02] <asac> james_w: http://pastebin.com/f33d9b4d7
[10:03] <PecisDarbs> pitti: in Jockey, there are 'DeprecationWarning: the sets module is deprecated' string all over gui, making mess out of it
[10:04] <james_w> asac: do you still have the Intrepid version pinned?
[10:05] <pitti> PecisDarbs: do you use 0.5-0ubuntu2 ?
[10:05] <asac> james_w: ii  bzr-builddeb          2.1~0ubuntu1          bzr plugin for Debian package management
[10:05] <pitti> PecisDarbs: I did some python 2.6 fixes there
[10:05] <pitti> PecisDarbs: over the gui? do you have a screenshot?
[10:06] <cjwatson> lsb_release output perhaps?
[10:06] <cjwatson> (bug 336436, about to sponsor now)
[10:07] <PecisDarbs> pitti: 0.5-0buntu1 or 2
[10:07] <PecisDarbs> pitti: screenshot comming, one min
[10:07] <pitti> PecisDarbs: well, the 'or' matters :) ubuntu2 has the 2.6 fixes
[10:07] <PecisDarbs> pitti: ubuntu2
[10:08] <asac> james_w: maybe builddeb expects the top level directory name now to be of a certain format?
[10:09] <james_w> asac: no
[10:10] <asac> strange
[10:11] <james_w> asac: can you let me have your branch and tarball?
[10:11] <PecisDarbs> pitti: http://imagebin.ca/9L_dWXk.html
[10:11] <james_w> it was working fine for me on Saturday, so I'd like to look at what you are using
[10:11] <pitti> PecisDarbs: that's 404
[10:12] <asac> james_w: sure: http://people.ubuntu.com/~asac/tmp/network-manager_0.7.1~rc2+1git7f1c86e3.orig.tar.gz
[10:12] <PecisDarbs> wait, I will copy&paste :)
[10:12] <PecisDarbs> pitti: http://imagebin.ca/view/9L_dWXk.html
[10:12] <asac> james_w: bzr branch lp:~network-manager/network-manager/ubuntu.0.7.1
[10:13] <pitti> PecisDarbs: right, that's the bug cjwatson mentioned
[10:13] <directhex> 0.7.1, eh? does it actually save a default static ip yet, rather than ignoring you & re-creating a default dhcp link?
[10:14] <PecisDarbs> ok, nice to know that you are informed already :)
[10:14] <cjwatson> pitti,PecisDarbs: fix just uploaded
[10:15] <cjwatson> pitti: why is jockey displaying lsb_release's stderr in its UI though?
[10:15] <james_w> asac: wfm, "bzr plugins -v | grep builddeb -A2" please?
[10:15] <PecisDarbs> cjwatson: thanks man :)
[10:15] <cjwatson> pitti: and it might make sense to only call it once ...
[10:15] <pitti> cjwatson: stderr> just fixed in bzr
[10:16] <cjwatson> heh, ok
[10:16] <pitti> cjwatson: once> that's what I did initially, but on other platforms "lsb_release -sir" is not predictable wrt. line breaking/spacing
[10:16] <pitti> cjwatson: longer-term I just want to move this to a build-time check
[10:17] <asac> james_w: http://pastebin.com/f6d45ce69
[10:17] <cjwatson> line breaking/spacing> I don't get it. I just meant to call it once up-front and then you could still substitute it into a string and line-wrap that as normal
[10:18] <pitti> cjwatson: but if it uses space instead of newline as separator, where do I break if there is more than one space?
[10:18] <james_w> asac: it is odd that it is dist-packages
[10:18] <pitti> of course that's slightly pathological (if the distro name has a space in it)
[10:18] <james_w> unless that change was made a little while ago
[10:19] <asac> james_w: i think before weekend doko did pythong 2.6 transition
[10:19] <james_w> asac: yeah, but this was built almost 2 weeks ago. I guess it's not a problem, I just didn't expect it
[10:19] <cjwatson> pitti: the UI shown in the screenshot above only uses "Ubuntu"
[10:20] <cjwatson> pitti: so you could use -si called just once for those, and call -sr separately if you need the release version number
[10:20] <pitti> cjwatson: yes, I could do that
[10:20] <cjwatson> pitti: I didn't mean "just once, absolutely, for the whole program" - I meant "collapse multiple identical calls into one"
[10:20] <james_w> asac: I don't understand though, I do a "bzr bd --export-only" and it creates the layout you desire
[10:21] <asac> let me check
[10:21] <asac> james_w: not for me :(
[10:21] <asac> james_w: ls ../builds/network-manager-0.7.1~rc2+1git7f1c86e3/
[10:21] <asac> debian  NetworkManager.git
[10:22] <james_w> I can see that
[10:22] <james_w> I just need you to do a bit more digging, as I can't reproduce it
[10:22] <pitti> cjwatson: it's quite an intrusive change, though (changing all occurrences of using the variables to a function call which lazily calls lsb_release if it wasn't used yet), so I don't want to change it right now
[10:22] <asac> james_w: i am here - and since i am kind of stuck because of that i will be here ;)
[10:23] <james_w> asac: can you branch to a fresh area
[10:23] <james_w> put the tarball in the parent dir
[10:23] <asac> james_w: my builddeb conf is: [BUILDDEB]
[10:23] <asac> build-dir = ../builds/
[10:23] <asac> result-dir = ../results/
[10:23] <pitti> cjwatson: (it doesn't call "lsb_release -sr" multiple times ATM either)
[10:23] <asac> oops
[10:23] <asac> damn paste ;)
[10:23] <james_w> and run "bzr bd --export-only" and pastebin the output?
[10:23] <asac> james_w: yes let me check
[10:24] <asac> james_w: http://paste.ubuntu.com/125199/
[10:25] <asac> james_w: oh fresh area
[10:25] <asac> sorry
[10:26] <asac> james_w: http://paste.ubuntu.com/125200/
[10:28] <james_w> hmm
[10:28] <asac> james_w: i branched from the local branch. i can try the remote branch too if that can make any difference
[10:30] <james_w> it shouldn't
[10:30] <james_w> asac: do you have any aliases for "tar"?
[10:30] <james_w> do you have a ~/.bazaar/builddeb.conf?
[10:31] <doko> mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html
[10:32] <asac> james_w: yes. i pasted the builddeb a few lines above
[10:32] <james_w> ah
[10:32] <asac> (just build-dir = ... and result-dir = ..:)
[10:32] <james_w> do you have a .bzr-builddeb in this branch?
[10:32] <asac> james_w: no alias for tar
[10:32] <asac> james_w: if i have it, its committed
[10:32] <asac> let me check
[10:32] <james_w> the one I have is merge = True in default.conf
[10:32] <asac> james_w: yes, but you should hav eit too
[10:32] <james_w> do you have anything else?
[10:32] <asac> right
[10:32] <asac> no
[10:32] <james_w> no local.conf?
[10:33] <asac> local.conf?
[10:33] <asac> in .bzr-builddeb? no
[10:33] <james_w> .bzr-builddeb/local.conf
[10:33] <james_w> ok
[10:33] <asac> note: i just did a clean branch ;)
[10:33] <james_w> true :-)
[10:33] <asac> james_w: is there kind of "verbose" mode?
[10:34] <james_w> asac: you can look in ~/.bzr.log
[10:34] <mvo> doko: fair enough, I was just thinking that ubuntu-devel-announce might be a good place too, especially since a rebuild without changes may now move stuff into /usr/local
[10:34] <doko> mvo: it does work for simple packages, python-support, python-central and cdbs are patched to move these files around
[10:35] <asac> james_w: http://pastebin.com/f6966bbbc thats what i get on --export-only run
[10:35] <asac> james_w: line 22.
[10:35] <asac> what do you run there?
[10:35] <doko> mvo: do you see any additional, or grave update failures?
[10:36] <mvo> doko: I just updated command-not-found and unattended-upgrades (they use debhelper) and I suspect gdebi needs a update too
[10:37] <asac> webkitgtk python is broken ;)
[10:37] <mvo> doko: maybe more, I need to check my devel tree. most of my python stuff does not use cdbs :/
[10:37] <doko> mvo: btw, why does update-manager install into /usr/lib/pythonX.Y? Is this used by any other package?
[10:37] <mvo> doko: but you know better whats doing on in python land, so its up to you where to announce
[10:38] <doko> mvo: it's a feature not to use cdbs
[10:38] <james_w> asac:       tempdir = tempfile.mkdtemp(prefix='builddeb-', dir=build_dir)
[10:38] <james_w> subprocess.call(['tar','-C',tempdir,'-xf',tarball])
[10:38] <mvo> doko: it installs stuff with nomove for improved stability (if that is what you mean)
[10:38] <mvo> doko: just like python-apt
[10:38] <mvo> doko: its one of the things that should be as robust as possible
[10:39] <mvo> doko: oh, you mean computer-janitor
[10:39] <doko> mvo: well, using a private libdir would be even more stable (if you don't have dependencies on update-manager)
[10:39] <mvo> doko: that is fallout from the merge with liw, let me check
[10:40] <asac> james_w: ok, that would give NetworkManager.git inside of builddeb-XXXX i guess
[10:40] <glatzor> doko, mvo: packagekit-backend-apt depends on update-manager
[10:40] <mvo> doko: the computerjanitor stuff is meant to be used by other packages so it needs to be public, but its in the wrong place
[10:40] <doko> ahh
[10:40] <liw> mvo, in the wrong place?
[10:42] <mvo> liw: I see stuff in site-packages here on my system from computerjanitor that should be in dist-packages, but let me rebuild to actually verify that
[10:42] <asac> james_w: are you running latest jaunty?
[10:42] <liw> mvo, ah
[10:44] <geser> doko: a quick question: for the use of py_libdir_sh the (loop) variable should be named python, right?
[10:44] <james_w> asac: no, not updated over the weekend?
[10:44] <asac> james_w: do you have python 2.6 as default?
[10:45] <james_w> asac: nope
[10:45] <doko> geser: no, the value that you pass should either be pythonX.Y or X.Y
[10:45] <glatzor> doko, what should I do to improve my python packages which use cdbs?
[10:45] <asac> james_w: i would think thats the reason then ;)
[10:45] <asac> james_w: any trick how i can bzr to use 2.5?
[10:46] <geser> doko: I've "Package bitbake version 1.8.12-1 has an unmet dep:
[10:46] <asac> james_w: so yeah ;)
[10:46] <geser>  Depends: python2.4-pysqlite2
[10:46] <asac> james_w: python 2.6 booooo
[10:46] <doko> glatzor: I don't know which packages you do maintain, and I won't look at those suggesting improvements ;) what exactly do you want to know?
[10:46] <geser> doko: bad paste :(
[10:46] <asac> james_w: python2.5 /usr/bin/bzr bd --export-only works!
[10:47] <doko> geser: nothing should depend on pysqlite2 anymore
[10:47] <glatzor> doko, you mentioned that not using cdbs would be feauture. so what does it wrong?
[10:48] <doko> glatzor: I won't start a cdbs discussion. some like it, some not.
[10:49] <geser> doko: I've "for py in $(PYVERS); do ..." in a rules file, so I use "$(py_libdir_sh)" instead of the hardcoded site-packages. I'm no makefile expert so I don't know from looking at the python.mk if it will work with the variable being named "py".
[10:50] <james_w> asac: thanks, I'm trying to update now
[10:51]  * asac alias python python2.5
[10:51] <asac> ;)
[10:51] <doko> geser: $ grep 'Call as' /usr/share/python/python.mk
[10:51] <mvo> doko, liw: it looks like I was just confused by the fact that 2.6 stuff goes into dist-packages and 2.5 goes into site-packages. so update-manager should now be ok and install into the right locations
[10:51] <doko> mvo: yes, I didn't want to change existing locations
[10:52] <mvo> sure
[10:53] <asac> james_w: let me know when its fixed ...  i repointed my python link to 2.5 now
[10:53] <mvo> could we do anything to make builds fails that have the lcoation not updated on the buildds? or add some sort of check to fail if stuff ends up in /usr/local at the end of the build?
[10:53] <mvo> I mean, packages that have no "--install-layout=deb" but get rebuild
[10:54] <mvo> (e.g. because the maintianer overlooked the required change or because of control.in vs control file confusion etc)
[10:54] <pitti> mvo: I think that already happends, in pkgbinarymangler (pkgsanitychecks)
[10:55] <doko> mvo: these should fail, yes.
[10:55] <mvo> pitti: aha, great.
[10:55] <pitti> mvo: but I found most of my packages FTBFS much earlier, because of wrong *.install files
[10:55] <doko> but we only check for /usr/local/lib/pythonX.Y, so maybe I just add a check for /usr/local
[10:56] <mvo> pitti: yeah, me too. unattended-upgrades does not have one, so having this additional check is certainly good
[10:56] <mvo> doko: sounds good, e.g. for stuff that is just a python-script with a private dir
[10:57]  * mvo leaves for lunch
[11:02] <slangasek> mr_pouit: I see that there are quite a few xfce4-related sync requests; do these have a FFe somewhere?
[11:08] <slangasek> doko: how's python 2.6 going? the extra python has caused a bit of a jump in CD size. :)
[11:09] <slangasek> doko: should I expect that to clear up soon, or should I offload some more langpacks in the meantime?
[11:09] <doko> slangasek: isn't this called collateral damage? ;)
[11:09] <slangasek> heh
[11:10] <seb128> slangasek: we have one extra python version so extra use is expected no?
[11:10] <slangasek> seb128: yes - but it's not supposed to stay that way for release, is it?
[11:10] <doko> well, the gnome bindings were only built for 2.5 before alpha-5, so python-gnome-*, gtksourceview and deskbar-applet did increase in size
[11:11] <doko> I'm not aware of other packages going up in size after alpha-5
[11:11] <slangasek> the main difference was that python2.6 wasn't on the CD before, and is now
[11:12] <seb128> slangasek: well we don't plan to drop python 2.5 do we?
[11:12] <doko> ouch, 1MB compressed larger ...
[11:12] <slangasek> seb128: I would assume that we plan to only have one version of python on the CD
[11:13] <directhex> why would you want more than one version of ANYTHING on the cd?
[11:14] <doko> slangasek: ahh, the static lib is in python2.6. will fix this
[11:15] <slangasek> doko: but that's still two versions of python on the CD, which is mainly what I was asking about...
[11:15] <doko> slangasek: which packages depend on 2.5 on the CD?
[11:16] <slangasek> dunno, checking
[11:17] <geser> if vim is on the CD then vim at least
[11:17] <doko> looking at vim ...
[11:18] <slangasek> doko: hmm - evolution
[11:18] <slangasek> vim isn't on the CD, only vim-tiny
[11:18] <doko> slangasek, seb128 : this should be fixed with the next upload. seb128, do you plan one?
[11:19] <pedro_> james_w: may you have a look to bug 336067 later? it's broken since the update to python 2.6
[11:19] <seb128> doko: yes, new GNOME versions due today
[11:19] <james_w> pedro_: sure, please assign it to me
[11:19] <pedro_> james_w: will do, thanks you :-)
[11:19] <pitti> seb128: if you upload a new evo, can you include the screen size patches, or do they need more work/discussion?
[11:20] <seb128> pitti: I can try, there is just a zillion of those in a tarballs which is going to take a while to review, not to mention that I hate those "add scrollbars everywhere" changes, but shrug
[11:21] <pitti> seb128: yeah, they are ugly; I only sponsor fixes which are reported/discussed upstream, though
[11:21] <pitti> seb128: still, ugly is better than broken on netbooks
[11:21] <seb128> right
[11:21] <seb128> if they don't add frame one normal desktop case
[11:21] <seb128> which some of those changes do
[11:21] <seb128> one -> on
[11:23] <seb128> grrrr at kubuntu
[11:23] <seb128> we are getting a zillion of ""gnome-appearance-properties crashed with SIGSEGV in QGtkStyle::drawControl()"
[11:23] <seb128> gtk-qt-engine is really a crappy crashing thing
[11:27] <ogra> since it exists :)
[11:27] <Riddell> seb128: I'd drop it if gtk had a sane default style
[11:28] <james_w> it would have been nice to have python.mk available well before the transition so that I can actually build a source package containing the needed fixes for me to be able to upgrade past the transition
[11:29] <seb128> I think I will add an apport hook to refuse any crasher if that thing is installed and display a warning "you installed that crappy kubuntu hack uninstall it if you want stability"
[11:34]  * pitti arghs at pidgin ftbfs (libtoolish); Keybuk, seb128, you don't happen to know what http://people.ubuntu.com/~pitti/tmp/pidgin_2.5.4-2ubuntu2_i386.build wants to tell me?
[11:34] <seb128> pitti: run autoreconf
[11:35] <pitti> seb128: right, I could update the 70autoconf.patch, but it built correctly just 7 days ago..
[11:35] <seb128> pitti: it will not ftbfs on the buildds, the issue is that it runs automake locally
[11:35] <pitti> oh, I see
[11:35] <seb128> pitti: that's a timestamp issue I never bother trying to fix it correctly, it only fails if automake is installed
[11:36] <liw> tkamppeter, do you happen to know about Brother QL-550 label printer support?
[11:40] <pitti> seb128: weird, pidgin b-deps on automake through intltool
[11:42] <tkamppeter> liw, I know about a third-party driver which is linked from the appropriate printer and driver pages on OpenPrinting, but I did not test it.
[11:42] <liw> tkamppeter, ok, thanks
[11:42] <seb128> pitti: dunno but some autotools don't get installed and run on the buildd but do locally
[11:43] <pitti> ah, apparently I had automake1.9 installed
[11:51] <geser> if a main sponsor has some time: bug #336601
[11:59] <ogra_> slangasek, on http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/alpha-5/images/ixp4xx/netboot/ there is some discrepancy between the file creation dates
[12:00] <ogra_> vmlinuz has a stap from 27th while the other two are from 25th
[12:00] <ogra_> *stamp
[12:00] <directhex> ta pitti
[12:00] <ogra_> i think something went wrong here
[12:01] <slangasek> ogra_:  well, I see the same in te 20081029ubuntu21 dir it was copied from...
[12:02] <ogra_> weird
[12:02] <ogra_> http://ports.ubuntu.com/ubuntu-ports/dists/jaunty/main/installer-armel/20081029ubuntu22/images/ixp4xx/netboot/ has the same dates on all files
[12:02] <slangasek> ogra_: so I'm not sure what went wrong, but it went wrong somewhere upstream from the copying I did
[12:04] <directhex> ogra_, did i mention "woo, i got an arm qemu system booting"?
[12:04] <pitti> geser: will you forward bug 336601 to Debian as well? It should work with python 2.5, too
[12:05] <ogra_> directhex, no, you didnt, congrats :)
[12:06] <directhex> ogra_, think you could be a sweetheart & document the "mem=32M" bit in the default cmdline? i kept having oom issues until i actually read the kernel config & spotted that
[12:06] <ogra_> hmm, i wasnt aware of that and all my docs say -m 256 and append "mem=256M"
[12:07] <ogra_> (see https://wiki.ubuntu.com/ARM/RootfsFromScratch )
[12:08] <directhex> still... http://www2.apebox.org/wordpress/wp-content/gallery/00-single/armless.png
[12:08] <slangasek> e
[12:10] <ogra_> directhex, i dont build the kernels (our kernel team does) but i'll talk to them to drop that default with the next upload
[12:10] <directhex> ogra_, it'd make it easier for qemu, since you can just use the -m flag
[12:10] <ahasenack> hey guys, is the python upgrade in jaunty mostly over?
[12:11] <ogra_> directhex, yeah, understood ... i didnt even notice since as i said i ude append everywhere anyway
[12:11] <ogra_> *use
[12:11] <directhex> ogra_, d-i is sad with only 32M ^_^
[12:12] <ogra_> depends :)
[12:12] <slangasek> ahasenack: I would say we're still somewhere towards the middle of the end
[12:12]  * ogra_ just made it work with the NSLU2 port on 30M
[12:12] <ahasenack> sladen: cool, thanks
[12:12] <geser> pitti: sure, will do so now
[12:13] <pitti> geser: thanks; will sponsor in a minute
[12:16] <slangasek> doko: python-pqueue is in main because it's seeded (ubuntu.jaunty/development); do you want to remove it from the seed or shall I?
[12:16] <slangasek> (once it's out of the seed, there'd be no need for a bug report, it would just get picked up via component-mismatches...)
[12:17] <doko> slangasek: please do
[12:20] <pkern> Could someone upload my debdiff (with the version and suite target corrected) out of LP: #222532 to intrepid-proposed, please?
[12:30] <seb128> doko: how do you debug issues similar to bug #332799?
[12:33] <doko> seb128: try to run it with python-dbg, I suspect it's a missing Py_INCREF somwhere ... see /usr/share/doc/python2.6/SpecialBuilds.txt.gz
[12:33] <seb128> doko: ok thanks
[12:36] <ogra> ogra@osiris:/var/build/versatile$ grep physical /var/log/Xorg.0.log
[12:36] <ogra> [    4.131326] (II) intel(0): Setting screen physical size to 261 x 163
[12:36] <ogra> ogra@osiris:/var/build/versatile$ xdpyinfo |grep dimensions
[12:36] <ogra>   dimensions:    1280x800 pixels (339x212 millimeters)
[12:36]  * ogra doesnt get whats sets this
[12:36] <ogra> seb128, does gnome influence my dpi settings in any way to set screen dimensions ?
[12:36] <seb128> ogra: screen dimensions?
[12:36] <ogra> yeah
[12:37] <seb128> ogra: the screen dimension is a physical thing
[12:37] <ogra> xorg detects my display right at  261 x 163 mm
[12:37] <seb128> it doesn't change when tweaking software
[12:37] <ogra> but in my desktop is end up with settings for 339x212 millimeters
[12:37] <ogra> and i cant find out what resets that
[12:38] <seb128> you probably forces the dpi?
[12:38] <seb128> and the resolution?
[12:38] <ogra> well, my gnome capplet has 100dpi in the entry box
[12:38] <ogra> i cant remember ever having set that though
[12:38] <ogra> (it used to be 96)
[12:39] <seb128> ok so that's the xorg detected value
[12:39] <seb128> dunno about the physical screen but that should not be revelant
[12:39] <seb128> you have the dpi value from xorg and the resolution you set
[12:39] <ogra> well, 1280x800 on 261 x 163 would be 124dpi
[12:39] <seb128> which is what should matter for what you get on screen
[12:39] <ogra> and 261 x 163 is the right value (i used a ruler :) )
[12:39] <doko> slangasek: the python2.6 package gets 1.4MB smaller (compressed)
[12:40] <slangasek> doko: ok :-)
[12:40] <seb128> ogra: dunno then, try a non GNOME session and see if you get the same issue
[12:40] <ogra> will do, good suggestion :)
[12:41] <ogra> oh, unsetting the dpi value in gconf-editor suddenly gets me huge fonts :) so i apparently have touched it before
[12:42] <ogra> hrm, and calling the capplet forces it to 96 ...
[12:42] <ogra> weird
[12:42]  * ogra tries an xterm session
[12:44] <ogra> seb128, hmm, seems gnoe actually sets it
[12:44] <ogra> in the xterm session i have matching values
[12:44] <seb128> ogra: do you have a .config/monitor.xml?
[12:45] <ogra> yes
[12:45] <seb128> ogra: can you move it somewhere else and try restarting your session and see if that's still an issue?
[12:45] <ogra> yep
[12:47] <ogra> seb128, ok, removing it *and* unsetting the gconf key gets me the right kes
[12:47] <ogra> *key
[12:48] <seb128> ok good
[12:48] <seb128> so know you need to figure what you do to get a buggy config ;-)
[12:48] <ogra> seb128, its a bit tricky, if you once touched the advanced font settings before in a former release or with the monitors.xml in place it will enforce 96dpi
[12:48] <seb128> I guess using the xrandr capplet once to get a config.xml and restarting the session is enough to get the issue
[12:49] <seb128> hum, it should not write the gconf key if you don't change the dpi value
[12:49] <ogra> i seemingly had used the advanced font settings before
[12:49] <seb128> I think there is a bug about the config forcing 96 dpi
[12:54] <slangasek> jelmer: your debian/copyright on bzr-fastimport omits exporters/svn-archive.c and exporters/svn-fast-export.c
[12:55] <jelmer> slangasek: Hi
[12:55] <jelmer> slangasek, Thanks, I'll fix that; fwiw those files are not part of the binary package
[12:55] <ogra> wow
[12:55]  * ogra wasnt aware how crisp his display can be
[12:55] <jelmer> slangasek, I thought bzr-fastimport was rejected though, because it wasn't processed before the FF?
[12:55] <slangasek> jelmer: ok - I was going to accept it anyway, that's why it was a throw-away comment on IRC instead of a mail ;)
[12:56] <slangasek> jelmer: it's being revisited following a discussion with motu-release the other day
[12:58] <jelmer> slangasek, ah, cool
[13:11] <ogra> hmm, what the heck starts notify-osd
[13:11] <seb128> dbus
[13:11] <seb128> that's a dbus service
[13:11] <ogra> hmm
[13:11]  * ogra would like to get it to not popup *under* the panel
[13:12]  * NCommander wonders if he was the only one who thought the disappearing update manager icon was a bug, and not a feature.
[13:12] <ogra> so i can actually read the notifications :)
[13:12] <seb128> there is a bug open about that
[13:12] <seb128> it seems to depend of the start order
[13:12] <seb128> restart notify-osd
[13:14]  * ogra did that and waits for a notification now
[13:14] <seb128> you can use notify-send txt
[13:15] <ogra> i just uninstalled libnotify-bin yesterday in a cleanup spree :)
[13:15] <cody-somerville> slangasek, bug #336180 acked
[13:16] <ogra> hmm, i got a mail, but no notification
[13:16] <slangasek> cody-somerville: there's a bunch of others related to xfce 4.6 - are they acked collectively, or do you want me to subscribe you to each for review?
[13:16] <cody-somerville> slangasek, acked collectively
[13:16] <slangasek> cody-somerville: ok, thanks
[13:16] <cody-somerville> slangasek, no problem.
[13:17] <ogra> aha, it pops up in front now (with notify-send) but not on the edge of the screen anymore
[13:19] <ogra> but no mail notification at all
[13:50] <james_w> shutil.move completely changed semantics in python2.6, fantastic
[13:51] <directhex> james_w, yay for python?
[13:51] <james_w> indeed
[13:52] <directhex> james_w, given recently published numbers (was it by jdong? i think it was jdong) i'm gonna have to stop jokingly suggesting ironpython as a replacement, tho
[13:53] <james_w> so it was actually fixing a bug: http://bugs.python.org/issue1577
[13:53] <james_w> "I'd rather not do this. It might cause disasters for code that expects
[13:53] <james_w> the old semantics. If you want a way to do the "mv" semantics, propose
[13:53] <james_w> a new API.
[13:53] <james_w> "
[13:55] <doko> james_w: which package was broken?
[13:55] <james_w> bzr-builddeb
[14:09] <nags> doko, http://pastebin.com/d1864c445
[14:09] <nags> doko, based on discussion with mvo on #ubuntu-testing, pasted the above link to you :)
[14:11] <ogra> Keybuk, seems we have a prob with ltspfs in jaunty, to me it looks like the rules dont fire the scripts anymore (bug 335767) did anything change in recent udev that could cause that ?
[14:15] <doko> nags, mvo: it's a bug in ropemacs, the substvars are wrong (s/Python/python). see the warnings in the build log. apparently nobody checked the binary before upload/sync request
[14:21] <Keybuk> ogra: lots of things changed
[14:21] <nags> doko, ok
[14:22] <ogra> Keybuk, well, i would assume the rules should still fire if a matching device is plugged in, probably the script arguments arent right anymore, could you tale a look ? i attached the currently used runes to the bug
[14:22] <Keybuk> ogra: no, I don't have LTSP here
[14:22] <Keybuk> start debugging using udevadm monitor -e to see what's firing and what environment are available
[14:23] <Keybuk> use udevadm test to make sure your rules are being run correctly
[14:23] <Keybuk> use udevd --debug to really get in depth
[14:23] <ogra> err s/runes/rules indeed
[14:23] <ogra> Keybuk, ok, i'll add that to the bug to get info out of the user
[14:24] <ogra> (i dont run ltsp myself anymore either)
[14:24] <Keybuk> actually I quite like runes
[14:24] <Keybuk> we should rename it upstream to /etc/udev/runes.d
[14:25] <ogra> hehe
[14:28] <ogra> yippie, i got working notifications again, seb128 thank for the pointer, adding a wrapper script that makes notify-osd sleep for 5 secs seems to help
[14:28] <ogra> *thanks even
[14:28] <seb128> you're welcome
[14:37] <superm1> james_w, gah that's probably what started causing crashes in mythbuntu-common (shtuil.move  stuff changing)
[15:16] <vadi2> ops
[16:17] <sistpoty|work> Mithrandir, StevenK: mind taking a look at bug #331973 (and eventually taking over handling this ffe?)
[16:25] <sistpoty|work> seb128: I've also got a universe FFe for you: bug #334813. mind taking a look?
[16:25] <seb128> sistpoty|work: granted
[16:25] <sistpoty|work> thanks seb128
[16:25] <seb128> you're welcome
[16:28] <sistpoty|work> Riddell: and one universe FFe for you at well (i.e., at least one, I'm just going through the list): bug #334121... mind taking a look there?
[16:32] <phomes> would a core-dev help me by updating mobile-broadband-provider-info? Current version (20081015) lacks one of the major danish providers and support questions for this are frequently popping up. #motu told me to go hunt for a core-dev. Bug 317860
[16:35] <sistpoty|work> Riddell: FFe's at bug #334690 and bug #335031 also look KDE related, mind taking a look at these as well?
[17:06] <sianis-devel> asac, bug #279365 please review it
[17:12] <kees> Keybuk: is there anything we can do to make AppArmor start faster?  sounds like it's eating 1 second at boot?
[17:14] <Keybuk> kees: I haven't looked at it
[17:14] <Keybuk> it looks like it's the parser though
[17:14] <kees> Keybuk: hrm, yeah.  too bad -- that's the part that got speed-ups between 2.1 and 2.3 (i.e. we have the fast version already)
[17:15] <kees> Keybuk: also, yay http -> https for merges.  :)
[17:15] <Keybuk> could it be done in the background alongside something else?
[17:16] <kees> Keybuk: possibly -- though it needs to be started ahead of any processes it's going to confine.
[17:16] <kees> Keybuk: we've already run into issues with that for dhcp client.
[17:16] <asac> sianis-devel: done
[17:16] <kees> Keybuk: do you have any bootcharts handy that shows it?
[17:18] <Keybuk> kees: http://people.ubuntu.com/~scott/boot-performance/mini9_jaunty-20090218-7.png
[17:19] <kees> Keybuk: we could run it in parallel to the fsck
[17:19] <kees> that's the sleep just above it?
[17:20] <Keybuk> I want to get rid of that sleep too ;)
[17:20] <Keybuk> does it have to be complete before anything in particular happens?
[17:21] <kees> Keybuk: basically, before any daemons it confines start up
[17:21] <kees> dhcp client is already protected to wait for AA to start up
[17:21] <kees> is that sleep from the fsck script or from procps?  I can't quite read that
[17:23] <Keybuk> fsck
[17:23] <Keybuk> hmm
[17:23] <Keybuk> doesn't that give you a deadlock?
[17:23] <Keybuk> udev waits for ifup which waits for dhclient which waits for apparmor which waits for udev ?
[17:24] <Keybuk> can what it parses not be precompiled?
[17:24] <kees> Keybuk: I don't think it deadlocks -- we can check with jdstrand
[17:24] <Keybuk> udev calls ifup, remember
[17:24] <kees> Keybuk: precompiled -- possibly, but it'd need features from AppArmor
[17:25] <kees> right, but isn't dhclient spawned (i.e. not waited on)?
[17:25] <Keybuk> can't remember
[17:25] <kees> and aa doesn't wait for udev
[17:25] <kees> it just reads files, parses them and shoves them into kernel space
[17:25] <Keybuk> its parser does seem very expensive
[17:25] <Keybuk> what is it? XML?
[17:26] <jdstrand> Keybuk, kees: udev calls idup as a daemon
[17:26] <kees> no, it's just reading the /etc/apparmor.d/* files, and making a kernel-space DFA out of them, AFAIU
[17:26] <jdstrand> ifup
[17:26] <jdstrand> Keybuk: it will not deadlock
[17:26] <Keybuk> so, err
[17:27] <Keybuk> if things udev calls depend on apparmor
[17:27] <Keybuk> why do you call it after udev?
[17:27] <Keybuk> do you need /usr mounted?
[17:27] <kees> we don't need /usr (parser is in /sbin)
[17:27] <kees> I'm happy to relocate aa
[17:27] <jdstrand> Keybuk: basically, I thought adding an intelligent ifup-pre.d script would be easier to get in and be less expensive than moving apparmor
[17:27] <kees> I've just not be entirely certain where to put it
[17:28] <Keybuk> how often do the things it parses change?
[17:28] <jdstrand> kees: all we should need it securityfs mounted and /sbin/apparmor_parser
[17:28] <kees> Keybuk: rarely
[17:28] <kees> jdstrand: right
[17:28] <jdstrand> Keybuk: very seldom
[17:29] <calc> Keybuk: have the boot changes made it into the stock image yet?
[17:30] <Keybuk> could you put it in the initramfs and run it while we're trying to find the root filesystem ? <g>
[17:30] <Keybuk> calc: there are a lot of changes, some of them have, some of them are still pending
[17:30] <calc> Keybuk: ok
[17:30] <kees> Keybuk: we'd need to check where the securityfs is mounted from, but yeah, probably.
[17:30]  * calc wonders how fast his laptop will boot with all the changes, it can do 100MB/s to disk :)
[17:30] <jdstrand> Keybuk: I may have missed something-- is the dhclient pre up script causing a problem/slowdown?
[17:30] <kees> Keybuk: it'd need to copy the entire contents of /etc/apparmor* into the initramfs
[17:30] <Keybuk> calc: do you have an SSD?
[17:31] <kees> jdstrand: no, just aa itself.
[17:31] <calc> Keybuk: no, a 7200rpm hdd
[17:31] <jdstrand> I see
[17:31] <kees> jdstrand: it's taking 1 second for itself.
[17:31] <Keybuk> calc: then you are doomed for a slow boot forever <g>
[17:31] <kees> jdstrand: but could be run in parallel somewhere
[17:31] <calc> Keybuk: lol :)
[17:31] <calc> Keybuk: i was getting ~ 20s boots with my old laptop before i got this new one
[17:31] <calc> of course that was 20s to gdm
[17:31] <Keybuk> calc: 20s to a full, logged-in desktop?
[17:31] <Keybuk> FAIL
[17:31] <Keybuk> :p
[17:31] <calc> heh
[17:33] <calc> unless the seeks eat too much time it should be close to as fast as the netbook, my cpu is 50% faster and hdd is > 100% faster than my old laptop
[17:33] <calc> at least for sequential reads
[17:33] <jdong_> anybody know of software/strategies for scraping points off a graph image?
[17:33] <jdong_> ugh wrong channel
[17:34] <Keybuk> calc: boot is all about how fast your disk is
[17:34] <Keybuk> and your seek time is SLOW
[17:35] <calc> Keybuk: true but doesn't readahead fix that? or is it not being used anymore?
[17:35] <Keybuk> readahead partially fixes it
[17:35] <Keybuk> but our gathering has been pretty poor for it in the past
[17:36] <calc> ok
[17:36] <Keybuk> so it appears to be quite pessimal compared to sreadahead
[17:36] <kees> Keybuk: in the bootchart you gave, where is the root fs mount happening?
[17:36] <Keybuk> kees: before where "rc" starts
[17:37] <Keybuk> ie. run alongside the udevd that's there
[17:37] <kees> okay, gotcha
[17:37] <Keybuk> though that part is probably too CPU contended :-/
[17:37] <Keybuk> would be worth testing though
[17:37] <kees> my /etc/apparmor* is well over 320K...
[17:38] <kees> a relatively stock install is about 260k
[17:38] <Keybuk> is there really no way to compile that down to something smaller and easier to read?
[17:38] <kees> there is no existing way that I know of.
[17:39] <kees> (this is one down-side to "dynamic label" MAC)
[17:39] <kees> we might be able to write a parser that only includes files that are included (which could avoid some of the stuff in /abstractions)
[17:40] <jdstrand> I doubt that would save much
[17:40] <jdong_> lol glad I'm not the only one with oversized apparmor.d :)
[17:41] <kees> jdstrand: yeah.
[17:41] <kees> Keybuk: is bloating the initrd really worth it?
[17:43] <jdstrand> kees: what if you loaded profiles on demand? or at least, load most profiles after login?
[17:43] <ogra> Keybuk, looking at the end of http://launchpadlibrarian.net/23302773/udevadm_test_dev_sdb.txt it seems udev actually calls "ltspfs_entry add sdb" as it should, do you know if anything wrt environment handling in udev changed ? the script expects to find LOCALDEV=True in the global environment to actually do something
[17:44] <Cool_Guy> Im not sure if this is the place to ask, but does anyone have experience with distcc/pump? I have it semi working and feeling its now working correctly
[17:44] <Cool_Guy> *not
[17:44] <kees> jdstrand: hm, as part of the target process's init script?
[17:44] <jdstrand> kees: possibly
[17:45] <jdstrand> kees: just OTOH we could have a really lean apparmor initscript that just mounts securityfs
[17:45] <Keybuk> kees: no idea without testing
[17:45] <kees> jdstrand: I think we could just move it earlier and have it run in parallel during the fsck bit
[17:45] <Keybuk> kees: I'll probably try it at some point
[17:45] <Keybuk> kees: but given the security issues, I've generally just left it alone
[17:45] <ScottK> slangasek: If you have a moment to put your archive-admin had back on to finish the clamav backport to Dapper, I've uploaded all the source backports and the input for syncbugbot is at https://bugs.launchpad.net/dapper-backports/+bug/335724/comments/2
[17:46] <Keybuk> ogra: does udevadm monitor show that LOCALDEV is in the environment?
[17:46] <Keybuk> ogra: your test does not appear to include it
[17:46] <ogra> oh, good question
[17:46]  * ogra looks
[17:46] <kees> jdstrand, Keybuk: how about this: two part init: one starts at like S01 and backgrounds itself, then the S37 just blocks until the S01 component is finished?  we already have the logic for it in the dhclient scripts
[17:47] <Keybuk> kees: possibly, though I'm wary that the CPU is fairly bound up until that point
[17:47] <ogra> Keybuk, hmm, i dont even see PATH
[17:47] <Keybuk> such things can actually make things slower
[17:47] <Keybuk> ogra: PATH is inherited by udev
[17:47] <ogra> (http://launchpadlibrarian.net/23299761/udevadm_monitor-e.txt)
[17:47] <jdstrand> kees: so S01 mounts securityfs?
[17:48] <kees> jdstrand: S01 would do everything S37 does now.  S37 would just block until apparmor_parser was finished
[17:48] <kees> Keybuk: there's a ton of CPU time available during the fsck phase
[17:48] <ogra> Keybuk, so did that change recently ? it seems it only stopped working recently
[17:48] <kees> Keybuk: like right after procps
[17:48] <jdstrand> oh I see-- that wouldn't help the boot time would it? or am I missing something?
[17:49] <Keybuk> kees: note that the fsck ends well before the sleep
[17:49] <kees> jdstrand: it should help boot time because the CPU load would happen earlier
[17:49] <Keybuk> in fact the fsck takes virtually no time
[17:49] <Keybuk> so you should consider that sleep to be a bug that will be fixed ;)
[17:49] <kees> Keybuk: oh.  :)  heh
[17:49] <Keybuk> ogra: did what change recently?
[17:49] <ogra> (the same user did an ltsp test at the beginning of the jaunty cycle and didnt report issues, ltspfs didnt change apart from teh install target for the rules)
[17:49] <ogra> Keybuk, the environment handling
[17:49] <kees> Keybuk: well, even when it's only AA loading, it's only at 50% cpu
[17:49] <kees> Keybuk: so it seems like moving it earlier could help
[17:49] <Keybuk> kees: you mean "using an entire core" ? :)
[17:50] <Keybuk> ogra: I could read the changelog for you
[17:50] <Keybuk> ogra: but I'm not going to :)
[17:50] <kees> Keybuk: d'oh, is that a dual core?  heh
[17:50] <ogra> :P
[17:50] <Keybuk> kees: I think it pretends to be
[17:50] <Keybuk> not sure
[17:50] <Keybuk> there's enough "exactly 50%" stuff there
[17:50] <kees> $ grep sleep /etc/init.d/* | wc -l
[17:50] <kees> 63
[17:50] <kees> *cry*
[17:51] <jdstrand> kees: you, since it is dynamic labeling, what would be most cool is for apparmor to not actually load the profile until the protected binary is called
[17:51] <jdstrand> s/you/you know/
[17:51] <kees> jdstrand: yeah, have the kernel call out for it.
[17:51] <jdstrand> kees: exactly
[17:52] <Keybuk> . o O { binfmt module ? }
[17:52] <Keybuk> no
[17:52] <Keybuk> evil
[17:52] <Keybuk> BAD
[17:52] <Keybuk> BAD
[17:53] <Keybuk> BAD
[17:53] <kees> :)
[17:53] <kees> it would need to be lighter than that: i.e. user space tells AA what to call out for, then when one of those executes, user space loads the DFA.
[17:54] <kees> seems like a lot of engineering for this "problem".
[17:54] <kees> Keybuk: out of morbid curiosity, which sleep is that in your bootchart?
[17:55] <Keybuk> I don't know
[17:55] <Keybuk> I haven't found it yet
[17:55] <Keybuk> that's why it's still there ;)
[17:55] <Keybuk> it's an insidious hiding sleep
[17:55] <Keybuk> I don't quite understand why the script only appears as "sh" either
[17:56] <ogra> hmm, i cant seem to find anything environment related
[17:56] <Keybuk> or why logsave runs for so much longer afterwards
[17:58] <kees> Keybuk: well, I assume it's related to the trickiness pitti created for the usplash-integration-and-skipable-ness.
[17:58] <kees> though there aren't any long sleeps in there.
[17:58] <Keybuk> that's my guess
[17:58] <Keybuk> but as I said, I can't quite find it yet
[17:58]  * kees nods
[17:59] <Keybuk> it vexes me
[17:59] <pitti> Keybuk: hm?
[17:59] <pitti> Keybuk: scripts in /lib/init/ perhaps? (they are sourced)
[18:00] <kees> pitti: the longest sleep in there is the 0.5 in the progress loop.
[18:00] <kees> doesn't seem likely.  *scratch head*
[18:01] <Stskeeps> udev? :P
[18:01] <Stskeeps> nm
[18:03] <kees> Keybuk: seems crazy but, could stuff like "exec 9<&0 </etc/fstab" make bootchart lose the cmd name?  I can't imagine how.  hrm
[18:03] <RainCT> (btw, someone has just asked me why rsync runs by default at boot on Jaunty)
[18:05] <Keybuk> RainCT: it doesn't
[18:05]  * kees holds onto his hat while apt-get dist-upgrade runs
[18:06] <savvas> rsyncd ?
[18:07] <ogra> Keybuk, hmm, but each of these not run scripts still spawns a subshell to check for the default value
[18:08] <ogra> not that it would be much time, but it still costs some
[18:08] <Keybuk> ogra: ?
[18:08] <ogra> rsync
[18:09] <ogra> rsync is installed on every ubuntu system, on boot it spawns a /bin/sh, sources /etc/default/rsync and exits
[18:10] <ogra> Keybuk, so these actions take time
[18:10] <ogra> nanoseconds likely, but they do
[18:11] <Keybuk> correct
[18:12] <ogra> so its not a totally unreasonable question why we do include these off-by-default scripts
[18:13] <ogra> its one useless fs access at least to read the defaults
[18:15] <jdong_> ogra: I don't get why rsync isn't separated into a client and server...
[18:15] <jdong_> I mean the rsync command is very useful IMO
[18:15] <jdong_> but rsyncd has less of an average user usecase
[18:16] <ogra> yeah, especially since you can use a daemon like mode through ssh
[18:19] <jdong_> right. That's my #1 usecase for rsync.
[18:19] <jdong_> #2 would be for long local copies where its progress indication is helpful
[18:37] <RainCT> mpt: Btw, on a dual head setup notify-osd doesn't show up on the same screen as gnome-panel. Should I file a bug about it?
[18:38] <mpt> RainCT, any new bubble should appear on whichever display the mouse pointer is on at the time. If that's not happening (or if that's a horrible design for someone reason), please do report a bug.
[18:40] <RainCT> mpt: Oh. Just tried moving the cursor around and it's always on the same screen. (And yesterday it was on the other one.. :P).
[18:40] <RainCT> (I'm on Intrepid, though, not sure if that makes any difference..)
[18:40] <mpt> ok, that's a bug then :-)
[18:40] <mpt> I don't think that makes a difference, that's core notify-osd behavior
[18:44] <asac> anyone here with a huawei 3g stick that uses the "normal" option driver?
[18:45] <RainCT> asac: I used to use one :P. What's the "normal" option driver?
[18:45] <asac> RainCT: the not normal option driver is "hso" ;)
[18:45] <asac> RainCT: if you dont have it anymore it doesnt matter ;)
[18:46] <RainCT> I don't see anything like that in nm-applet
[18:48] <RainCT> mpt: Alright, filed bug #336848
[18:48] <mpt> thanks
[18:49] <kees> Keybuk: it is the usplash sleep -- it's just showing up as a single process when it's multiple sleeps.  (I see the same from the dhclient sleep 0.1)
[18:49] <kees> Keybuk: my boot chart is silly slow
[18:49] <Keybuk> hmm, interesting
[18:50] <Keybuk> why is it even sleeping
[18:50] <Keybuk> fsck has no progress to report
[18:50] <kees> Keybuk: from looking at the loop, I think it leads with a sleep instead of ending with a sleep.
[18:51] <kees> but it's got 0.5 granularity, so dropping it to 0.1 would probably make the bulk of it go away
[18:51] <kees> my bootchart is ALL io bound.
[18:51] <kees> it seems like readahead-list isn't backgrounded?
[18:52] <Keybuk> could it just not sleep at all?
[18:52] <Keybuk> kees: readahead isn't backgrounded deliberately
[18:52] <kees> ah, cool.
[18:52] <kees> Keybuk: check with pitti, the scripts are pretty sensitive there
[18:59] <BUGabundo> apw: ogasawara ping
[18:59] <BUGabundo> any of you guys (or anyone else from kernel debug team) here?
[19:00] <apw> BUGabundo, ?
[19:00] <BUGabundo> so that vbgunz can find help with his SATA disk prob on resume?
[19:00] <BUGabundo> hi apw... meet vbgunz
[19:00] <BUGabundo> vbgunz: please describe your prob
[19:00] <BUGabundo> do you have a LP bug too?
[19:00] <apw> is it a kernel problem?
[19:00] <vbgunz> hello everyone. Been on Jaunty for a while and everything is great. honest. just great. *but* no matter what I try, I can never suspend to ram or disk whether S1 or S3 in bios, BIOS or OS wakeup. everything comes back from resume after about 1 minute *but* the sata disk is dead :(
[19:00] <apw> if so do it over on #ubuntu-kernel
[19:01] <apw> and how do you know the disk is dead?
[19:02] <vbgunz> apw: I cannot read or write to it, and somewhere in the terminal I always get a I/O denied to /dev/sda which is my sata disk
[19:02] <ogra> (using a multimeter ? :) )
[19:02] <BUGabundo> heeheheeh
[19:02] <vbgunz> heh
[19:02] <BUGabundo> ogra: just can't "shock" it to life...
[19:02] <apw> are you able to run dmesg?
[19:02] <apw> specifically if you run dmesg before you suspend
[19:03] <apw> so its caches first
[19:03] <ogra> BUGabundo, cold water might ...
[19:03] <vbgunz> I cannot run any sudo commands at all what-so-ever ... e.g., sudo mount -a ... that disk is dead when I resume :(
[19:03] <apw> yep, you would need the command to be already loaded
[19:03] <vbgunz> well, after about 1 minute after resuming  everything appears on screen the way I left it
[19:03] <vbgunz> it sleeps in seconds. wakes up after about a minute. cannot do anything
[19:03] <apw> so run dmesg, suspend, resume, run dmesg
[19:04] <apw> and see if that at lest lets you see the kernel logs from the suspend/\resume
[19:04] <BUGabundo> apw: do you think a serial link could help debug it too?
[19:04] <apw> if they can see the dmesg output we'd be ok
[19:04] <vbgunz> I tried the 2.26.29 kernel from ppa. I read the resume/suspend was solved in that version *but* no matter what. I get the same results :/
[19:06] <vbgunz> apw. even if I could see the anything, I wouldn't know what to do with it... I thought I would be slick the other day but no matter, so much reading and writing is supposed to happen on my sata that I cannot do anything... I tried creating a file on MS and the file protocol died
[19:06] <apw> you got a digital camera?
[19:06] <apw> photos is a common way to get the information to us
[19:07] <vbgunz> heh, believe it or not, sent it in for repair :/
[19:07] <apw> always the way
[19:07] <apw> well you can give us a feel for whats in there if it comes out
[19:07] <Codd> I tried asking this in the ubuntu channel and google but It might be a bit advanced of a question.  Is there a way from the kernel arguments on start up to make a live session automatically use restricted drivers over the OSS ones?
[19:07] <vbgunz> I've got 2 sonys, both died at the same time. worse ever :/
[19:07] <apw> anything relating to the disk
[19:08] <vbgunz> well. I have other disk... Cant I just reroute these messages or logs to my IDE drives? I think they come back *but* I am not absolutely sure... I cannot do anything from the desktop about it :(
[19:12] <BUGabundo> vbgunz: $dmesg > /mountpoint/otherdisk/log.txt ?
[19:13] <BUGabundo> or $ pastebinit -i /var/log/kernel.o.log
[19:14] <apw> so can you switch to VT-1 ?
[19:14] <apw> something else to try
[19:14] <apw> sounds like BUGabundo can talk you thought it all :)
[19:14] <BUGabundo> me ? noo lol
[19:15] <apw> then get a bug filed with all the info
[19:15] <apw> agaainst the linux package
[19:15] <apw> we do need that dmesg output i recon
[19:16]  * BUGabundo vbgunz you can always zero absolute the machine and dump the contents of the memory while in resume eeheh
[19:16] <vbgunz> man anything to get a better log
[19:17] <vbgunz> I dont want to break anything. everything is fantastic. godforbid I suspend though. nightmare :(
[19:19] <vbgunz> damn. I thought I saw a command in here. dmesg, sleep, resume, dmesg or something
[19:20] <vbgunz> ok can someone provide the command to keep my logs or dmegs going to my MS *after* resume?
[19:20] <vbgunz> I'll try it now just to bork it all *but* hopefully I can save a log
[19:27] <LaserJock> cjwatson: absolutely brilliant blog post, thanks so much for that
[19:28]  * highvoltage fires up liferea
[19:33] <mr_pouit> slangasek: why would my sync requests need a FFe? It updates xfce* from 4.6rc1 to 4.6, which is bugfix-only, and thus doesn't require a FFe (and this was described in the sync requests...).
[19:36] <vbgunz> the second dmesg was never written. My bios though was using S1.  I got the second dmesg
[19:46] <vbgunz> in it are the I/O errors I was talking about
[19:46] <vbgunz> do you guys want the one *before* and *after* or just after?
[19:47] <vbgunz> http://dpaste.com/4775/
[19:47] <vbgunz> thats after
[19:49] <vbgunz> IntuitiveNipple: I managed to save a dmesg after a failed resume, can you check it out http://dpaste.com/4775/ ?
[19:51] <IntuitiveNipple> vbgunz: That's better! Add it to the bug report
[19:51] <vbgunz> ok
[19:52] <vbgunz> I think the hell starts at line 1283
[19:52] <vbgunz> sda is my sata disk that keeps dying on resume
[19:53] <IntuitiveNipple> vbgunz: Let's switch this conversation to #ubuntu-bugs
[19:53] <vbgunz> ok there
[19:57] <slangasek> mr_pouit: hmm, I don't see any mention in bug #336180 that this was bugfix only... anyway, approved by cody-somerville, so all done now :)
[19:57] <mr_pouit> "This is the final release (jaunty ships the rc1 for the moment). There's no Ubuntu delta."
[19:58] <mr_pouit> I don't know lots of upstream developers that add new features between a RC and the final release. ;)
[19:58] <ScottK> slangasek: Did you see my earlier ping about clamav?
[19:58] <slangasek> ScottK: yep, was just grabbing it now
[19:58] <ScottK> slangasek: Great.  Thanks.
[20:02] <maxb> mr_pouit: Oh, you're so trusting! :-)
[20:03] <mr_pouit> maxb: I'm subscribed to svn commits, so, kind of :P
[20:04] <maxb> ah, fair enough. If you can truthfully state "I have verified the changes between rc1 and final are bugfix-only in nature" then you should definitely do so in the bug - then there's no ambiguity regarding the need for a FFe
[20:07] <maxb> So... I have a perplexing problem. Recently, in Jaunty, one of my partitions (and only one, out of three ext3 partitions on the disk) has suddenly started getting the wrong uuid in /dev/disk/by-uuid/ - it's not even the right format - rather than being a true UUID, it's just 16 hex digits. Any prods towards where I should be debugging?
[20:08] <maxb> btw, blkid is still reporting the true uuid
[20:28] <slangasek> zul_: fyi, I'm planning to request a FFe for samba 3.3.1 and handle the merge on it
[20:29] <slangasek> (there's a bit of cruft I want to get pulled out of the Ubuntu delta...)
[20:29] <zul_> slangasek: what cruft?
[20:29] <slangasek> zul_: changes to every one of the .po files; plus some winbind changes that are obsolete because they were done in Debian in a different way (but the patch still applies)
[20:30] <zul_> slangasek: sounds good to me
[20:38] <vbgunz> fellas. the pci=nomsi solution worked. I could actually resume from a suspend... I am just curious. is this a good idea or what? I feel it could be hackish or not wise. would like any input on solving the real problem if one exists
[20:39] <vbgunz> im excited. I need to try suspending one more time. brb hopefully without rebooting
[20:40] <vbgunz> no way. this is just great :D
[20:41] <calc> pitti: followed up to the email
[20:41] <vbgunz> wow. my second resume. its working for me :)
[20:42] <calc> pitti: looks like OOo schedule is going to slip yet again, so i'm glad we stick with the version released at feature freeze :)
[20:42] <calc> pitti: the first rc looks like it will be released march 19 and possibly 6 or more rc's will be needed (like with 3.0)
[20:49] <mrooney> 6 or more RC's? O_o
[21:05] <emgent> calc: ping
[21:10] <kirkland> where might i find someone to help with an lpia build error?
[21:10]  * kirkland sees no #ubuntu-lpia channel
[21:11] <cody-somerville> kirkland, lpia is just i386 really
[21:11] <cody-somerville> kirkland, whats your build problem?
[21:11] <Mithrandir> kirkland: #ubuntu-mobile, possibly?
[21:11] <kirkland> cody-somerville: http://launchpadlibrarian.net/23315733/buildlog_ubuntu-jaunty-lpia.kvm_1%3A84%2Bdfsg-0ubuntu6~ppa1_FAILEDTOBUILD.txt.gz
[21:11] <kirkland> Mithrandir: thanks.
[21:13] <kirkland> cody-somerville: nevermind
[21:13] <kirkland> cody-somerville: found my problem, sorry to bother
[21:14] <cody-somerville> :)
[21:16] <kirkland> Keybuk: around?  did you get a chance to read my comments on https://bugs.launchpad.net/bugs/71418
[21:19] <alex-weej> cjwatson: thanks for saying something about expiring bugs on planet today. that has really annoyed me as the list of minor bugs i have reported over the years has constantly been chomped at by karma hunters...
[22:06] <mathiaz> james_w: hi - do you have a workaround/patch for bug 336686?
[22:06] <james_w> mathiaz: in a branch
[22:06] <james_w> I'm trying to prepare an upload now
[22:06] <mathiaz> james_w: great - mysql-dfsg-5.1 will be happy again after that :)
[22:06] <james_w> if can tell you what to edit if you need it to work right now
[22:07] <james_w> though I will need to get an FFe for this upload, perhaps I should upload the fix for that directly
[22:07] <mathiaz> james_w: that would be helpful
[22:07] <mathiaz> james_w: I've --export-only and then debuild -S
[22:07] <james_w> good idea :-)
[22:08] <mathiaz> james_w: hm - expect the dsc file is not there
[22:09] <mathiaz> james_w: oh - nevermind
[22:27] <cjwatson> LaserJock,alex-weej: glad you liked it
[22:28] <LaserJock> cjwatson: you nicely articulated exactly what I've been thinking
[22:28] <LaserJock> made my day
[22:31]  * ScottK gives a big +1 for cjwatson's blog post too.
[22:31] <ScottK> Definitely much more diplomatic than I'd have managed too.
[22:33]  * ogra wants a t-shirt "Bugs are not like fruit" :)
[22:34]  * directhex hands ogra an apple with some bugs in it
[22:34] <ogra> :P
[23:03] <vbgunz> yeah. after walking away and leaving the system suspended in ram for 30+ minutes. I turn it on and all is well *but* I am not prompted for a password :(
[23:03] <vbgunz> should I just make a script that'll lock up the system *then* suspend?
[23:32] <Caesar> So, EOL for Dapper on the desktop, June 1 or June 30?
[23:32] <Caesar> Is there anything authoritative in writing anywhere?
[23:33] <Nafallo> https://wiki.ubuntu.com/DapperReleaseSchedule <-- looks like June 1st, but I can neither confirm, not deny.
[23:33] <Nafallo> s/not/nor/
[23:34] <Caesar> Nafallo: yeah, that's far from really clear on it
[23:34] <slangasek> the support cycle is generally measured from the actual release date.  I haven't heard otherwise from anyone regarding dapper.
[23:34] <Caesar> That would imply it's June 1 though
[23:35] <Caesar> slangasek: nowhere (that I've found) really spells out how support will continue for servers for the remaining two years
[23:35] <Caesar> Presumably a subset of packages will still receive security support
[23:36] <slangasek> yes, that's the intent; I don't know the details of what will or won't be included in the server security support
[23:36] <slangasek> nijaba: is that your department?
[23:36] <Caesar> I'm just looking for something vaguely authoritative to point my management at
[23:39] <kees> Caesar: check this script: https://launchpad.net/ubuntu-maintenance-check
[23:39] <nijaba> slangasek: https://code.launchpad.net/ubuntu-maintenance-check will tell you which packages are maintained for how long on any given system.  Seeds have been reorganized so that we can tell.
[23:41] <slangasek> nijaba: the historical dapper seeds have been reorganized?
[23:41] <nijaba> Caesar: http://www.ubuntu.com/products/whatisubuntu/serveredition/benefits/lifecycle should be considered authoritative by your management
[23:41] <nijaba> slangasek: yep
[23:42] <slangasek> ok, great
[23:42] <nijaba> slangasek: that's what I started with, then moved up to current
[23:42] <nijaba> slangasek: I am glad Colin helped though :-)
[23:43] <Nafallo> :-)
[23:45] <Caesar> nijaba: there are exactly zero precise dates at that URL
[23:45] <Caesar> So I have to operate on the assumption that it's the release date + n months
[23:45] <Caesar> Which is fine
[23:45] <nijaba> Caesar: oh, you want precise dates. then your assumption is right
[23:46] <Caesar> That URL also doesn't clarify what goes on in the 3-5 year life of an LTS
[23:46] <nijaba> Caesar: but you are right, I think we should start an EOL announcement page
[23:46] <Caesar> \o/
[23:46] <nijaba> slangasek: that would be more in your field, but I'd gladly start something
[23:46] <ScottK> nijaba: Are past-EOL packages going to be moved to old-releases?
[23:47] <elmo> scottk: that'd be mad crazy difficult
[23:47] <LaserJock> how'd that work?
[23:47] <elmo> (so I really hope not)
[23:47] <slangasek> nijaba: I'd be happy if you could get it started.  Previously the EOL announcements have all followed the same pattern, so there wasn't much need to draft
[23:48] <nijaba> slangasek: what I thought was more of a summary page with release and EOL dates
[23:48] <ScottK> elmo: I have no idea, but leaving them in place leaves an odd catagory of packages that hasn't previously existed.
[23:49] <ScottK> Generally not supported means community supported.
[23:49] <slangasek> nijaba: hrm, ok
[23:49] <ScottK> As a community dev, am I still expected to care about these packages?
[23:49] <Tonio_> slangasek: hi, I just commented out about skrooge in NEW.
[23:49] <nijaba> slangasek: what did you have in mind?
[23:49] <LaserJock> ScottK: I think those packages are EOL
[23:49] <ScottK> If not, that makes clamav backports for Dapper much easier after June.
[23:49] <LaserJock> not community-supported
[23:49] <Tonio_> slangasek: also as promissed I fixed kdesudo packaging properly and fixed the seeds so that the dvd depends on kdesudo and not kdesudo-kde4...
[23:50] <ScottK> It seems odd to have them there, but not there so to speak.
[23:50] <LaserJock> they're there, but the just have no support whatsoever, as far as I can tell
[23:50] <LaserJock> *they
[23:51] <slangasek> nijaba: I assumed you were talking about how to properly communicate the dapper EOL when it's announced.  I don't know that a wiki page to track what's EOLed should be necessary, shouldn't it be enough for the website to state the release dates + the support length? (don't we have this already?)
[23:51] <slangasek> Tonio_: ok, thanks :)
[23:52] <nijaba> slangasek: I just thought that it might be clearer if, instead of the algorythm to compute the date, we actually write them down so that people don't have to be guessing
[23:53] <Caesar> +1
[23:54] <nijaba> slangasek: but I'll start a draft of the dapper desktop EOL, as it might need more details than the usual one
[23:54] <nijaba> anyway -> really bed time for me now