[05:07] <twb> dch -i works fine for non-native packages, but for a (private) native package I'm maintaining, it is changing "2011031701" to "2011031701ubuntu1".
[05:07] <twb> Is there a way to make it update it to, say, "2011031702" or "2011032801" ?
[05:17] <ScottK> twb: dch -d will give you the Debian standard behavior which will, I think, do what you want.
[05:18] <twb> ScottK: can I put that in .devscripts somehow?
[05:19] <ScottK> No idea.
[05:19] <StevenK> alias dch='dch -d'
[05:19] <twb> StevenK: but that assumes I run dch directly, and from a shell.
[05:19] <StevenK> Just offering a suggestion
[05:19] <twb> Nod, OK
[05:19] <ScottK> twb: Just do dch -d instad of dch -i whereever you're doing it.
[05:20] <twb> Hm, I can't see a dch -d in the manpage...
[05:20] <twb> Is that a post-lucid feature?
[05:20] <twb> Hm, -d, --fromdirname -- Add a new changelog entry with version taken from the directory name
[05:20] <twb> --fromdirname won't work for me, because it'll always just be "foo" not "foo-1.0"
[05:21] <twb> I can just use -v, I just would've preferred to have something more magical
[05:21] <StevenK> I thought there was an environment variable to control it ...
[05:22] <twb> StevenK: DEBCHANGE_RELEASE_HEURISTIC=changelog ?
[05:22] <twb> StevenK: I have that, IIRC it makes Debian dch act list Ubuntu dch
[05:22] <StevenK> twb: I'm not certain, it's a vague thought and I'm trying not to context switch
[05:23] <twb> Sorry
[05:57] <hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
[05:58] <hyperair> whoops, forgot the / >_>
[06:06] <StevenK> RAOF: Can haz MPRIS? :-)
[07:38] <dholbach> good morning
[07:45] <cdbs> good morning dholbach !
[07:45] <dholbach> hey cdbs
[07:50] <pitti> Good morning
[08:16] <didrocks> good morning
[09:46] <pitti> cjwatson: should biosdevname be in main/installed by default? you integrated it in the installer, is it only needed to write the static udev rules? or at runtime as well?
[10:10] <cjwatson> pitti: yes, it should be added, I'll figure out where it belongs and sort out the seeds
[10:10] <pitti> thanks
[10:10] <hrw> morning
[11:45] <pitti> tseliot: for the nvidia-* bits we currently have add_modules=['glx'], remove_modules=['dri', 'GLcore']; I suppose we still need to keep the remove_modules, but do we still need to manually add glx?
[11:51] <doko_> pitti: intended?
[11:51] <doko_>  o ttf-sil-gentium-basic: ttf-sil-gentium-basic
[11:51] <doko_>    [Reverse-Depends: libreoffice]
[11:51] <pitti> doko_: no, only transitional; still working on fixing c-m
[11:55]  * Daviey shakes his fist at james_w for skewing the sponsorship stats... :)
[11:56] <pitti> ugh, WTH?
[11:58] <tseliot> pitti: I think we can safely comment out both add_modules and remove_modules in Jockey
[11:58] <pitti> tseliot: if dri and GLCore are loaded in xorg.conf that won't break the driver any more?
[11:58] <pitti> tseliot: (not even for 96?)
[11:59] <tseliot> pitti: we only need the defaultdepth option and of course  the option to set the driver to nvidia
[12:00] <tseliot> pitti: let me check what we do for 96
[12:00] <pitti> tseliot: I thought dropping the driver option was the main point of bug 522061
[12:00] <pitti> tseliot: as we now have 105_nvidia_fglrx_autodetect.patch
[12:01] <tseliot> pitti: right, the only thing I'm not sure (I should re-read the patch) is whether autoloading works also when a xorg.conf is available
[12:01] <pitti> tseliot: yes, was confirmed in https://bugs.launchpad.net/ubuntu/+source/jockey/+bug/522061/comments/18
[12:03] <tseliot> pitti: err, doesn't that say that nouveau is used instead of nvidia when the driver is commented out?
[12:03] <pitti> tseliot: ah, right
[12:03] <tseliot> pitti: oh, and we also need the nologo option
[12:03] <pitti> tseliot: I only have intel here, so I can't fully test any of this :/
[12:04] <pitti> tseliot: I'll keep the remove_modules (just to be sure), the AddARGBGLXVisuals quirk for 96, and NoLogo
[12:04] <tseliot> pitti: I can do it here, as I'll have to land a few fixes to nvidia anyway
[12:05] <tseliot> pitti: yes, keeping remove_modules definitely won't hurt
[12:05] <pitti> tseliot: ok, so I'll do the necessary changes in trunk first (support not writing Driver, that will cause a few disruptions), then update nvidia.py as I think it should be, and then ask you to test the current ubuntu bzr head?
[12:06] <tseliot> pitti: sounds good
[12:06] <pitti> tseliot: this will take me a couple of hours (I'll test it as far as I can in "dry mode" here)
[12:06] <pitti> tseliot: cheers
[12:07] <tseliot> pitti: no hurry, I'm working on other urgent stuff
[12:56] <tkamppeter> It is about bug 335662, don't we have a notification area any more? At least for some users HPLIP complains that there is no notification area for hp-systray.
[12:56] <ohsix> would be cool if ctrl+k or ctrl+e, or both; would jump to the search box in software center, where does one request such a thing?
[13:00] <pitti> tkamppeter: right, it's gone in general; we only have a backward compatible systray for java apps and skype
[13:01] <pitti> tkamppeter: however, there is a whitelist; so if you think it's important, you can file a bug against unity and ask for whitelisting it
[13:02] <tkamppeter> pitti, whitelisting hp-systray or the notification area?
[13:02] <pitti> tkamppeter: hp-systray for the notification area
[13:02] <seb128> they will probably say no
[13:03] <seb128> but you can still try ;-)
[13:03] <tkamppeter> seb128, why?
[13:03] <seb128> because things are supposed to be ported to indicator for 3 cycles
[13:04] <seb128> so they are giving increasing reasons to port those not ported now
[13:04] <seb128> they also think that it's harder to give something and drop it than to not give it
[13:04] <seb128> so they said they would not whitelist things that can be patched
[13:05] <tkamppeter> seb128, hplip-gui is made by HP and they are trying to cover a wide range of distros, probably therefore they do not switch their stuff.
[13:06] <seb128> well it's open source so we could distro patch it to use an indicator?
[13:07] <tkamppeter> seb128, pitti, is it a big change to patch a notification area app to indicator?
[13:07] <seb128> usually not
[13:07] <seb128> tkamppeter, https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[13:10] <pitti> tkamppeter: technically the change is trivial; it's a political/design issue
[13:11] <pitti> we now have consistent indicators in the default install, i. e. the entire top panel is a signle big menu
[13:11] <pitti> such whitelists break this behaviour
[13:15] <tkamppeter> pitti, seb128, the app in question is hp-systray (part of hplip-gui) which is written in Python and uses the Qt widget library. The app shows as an HP logo and right-clicking it shows a regular menu. Left-clicking it does nothing.
[13:16] <seb128> should be trivial to port to an indicator then
[13:16] <tkamppeter> pitti, seb128, it is also a D-Bus-based user daemon for handling fax queues.
[13:18] <tkamppeter> pitti, seb128, are there somewhere instructions or samples for that (above-mentioned site only handles GTK).
[13:20] <pitti> chrisccoulson: your nss uploads doesn't have bug references, is it ok to keep until after beta? or does it help with RC bugs?
[13:20] <chrisccoulson> pitti - oh, i forgot to add a bug reference
[13:20] <chrisccoulson> pitti - it's a security fix that's currently being deployed on other releases
[13:21] <pitti> chrisccoulson: oh, for the comodo stuff?
[13:21] <pitti> chrisccoulson: it looks pinpointed enough anyway
[13:21] <chrisccoulson> pitti - yeah, that's the one. the nss change is just to block those certs
[13:21] <pitti> chrisccoulson: ok, thanks; accepting now, please close the bug manually
[13:21] <chrisccoulson> thanks
[13:22] <tkamppeter> riddell, hi
[13:23] <Riddell> hi tkamppeter
[13:27] <seb128> tkamppeter, check with agateau or Riddell I guess
[13:29] <Riddell> tkamppeter: I think the only Qt implementation is KStatusNotifierItem which is a KDE class, so it would need changing from a QApplication to a KApplication
[13:31] <seb128> Riddell, there is no way for qt application to use the appindicator without using kde?
[13:32] <Riddell> seb128: no, it would need QSytemTrayIcon ported to the status notifier spec
[13:34] <seb128> Riddell, ok
[13:34] <NCommander>  /lastlog NComm
[13:34] <NCommander> bah
[13:50] <seb128> tkamppeter, <Riddell> tkamppeter: I think the only Qt implementation is KStatusNotifierItem which is a KDE class, so it would need changing from a QApplication to a KApplication
[13:50] <seb128> ups
[13:50] <seb128> tkamppeter, https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/497877
[13:51] <seb128> you had a patch there for hplip for a while
[13:55] <mvo> ev: on the system that you tested apt-clone on and that failed to upgrade, do you still have the state file? I would like to add it to the regression tess
[13:56] <ev> mvo: yup, one moment
[13:59] <mvo> thnx!
[14:02] <ev> mvo: http://people.canonical.com/~evand/tmp/apt-clone-state-ubuntu.tar.gz
[14:07] <mvo> ev: thanks!
[14:09] <ev> sure thing
[14:16] <hrw> pitti: hi, have a minute for a talk about pkg-create-dbgsym and cross builds?
[14:16] <pitti> hrw: what's up?
[14:17] <hrw> pitti: when pkg-create-dbgsym is installed cross build of ncurses is impossible to finish as it tries to generate lib32ncurses* packages (cross build on amd64 to armel target) which are not generated
[14:17] <hrw> pitti: when I uninstall it then build finishes fine
[14:18] <hrw> pitti: does it goes though debian/control and just tries to generate package for each entry?
[14:20] <pitti> hrw: yes, it does (just checking the code); it just ought to use @{$dh{DOPACKAGES}}, as all the other debhelper scripts, I guess
[14:21] <pitti> hrw: it needs to do a bit more though, i. e.  filter out the arch: all ones
[14:21] <hrw> pitti: http://pastebin.com/S3C4d8Es is output
[14:22] <seb128> tkamppeter, pitti: ok, open a bug about hplip whitelisting, they will likely do it
[14:22] <hrw> pitti: in debian/rules creation of 32/64bit packages are handled by separate variables rather then control file
[14:22] <pitti> hrw: hm, why is DEB_BUILD_ARCH==amd64 there? shouldn't that be armel?
[14:23] <hrw> pitti: build_arch is amd64, host_arch is armel
[14:23] <pitti> ah, that way around
[14:23] <pitti> so it should probably compare the Architecture: field to DEB_HOST_ARCH then, not DEB_BUILD_ARCH
[14:24] <pitti> I thought these were exactly the other way around
[14:24] <hrw> pitti: pkg-create-dbgsym is called after dh_strip but does not check it's arguments?
[14:24] <pitti> hrw: pkg-create-dbgsym wraps dh_strip
[14:24] <pitti> hrw: it does respect -p, -N, -s, etc.
[14:25] <pitti> but it defaults to all non arch: all packages from debian/control if no package is given
[14:25] <hrw> pitti: 10th line of pastebin calls dh_strip with -X entries
[14:25] <pitti> (minus architecture: <nonmatching>
[14:25] <hrw> "dh_strip -s -Xlibncurses5-dbg -Xlibncursesw5-dbg -Xlibncursesw5 --dbg-package=libncurses5-dbg"
[14:25] <pitti> hrw: that's wrong, though
[14:25] <pitti> that should be -N
[14:26] <pitti> -X blacklists file paths from stripping, not packages
[14:27] <hrw> let me check with -N then
[14:28] <hrw> pitti: http://pastebin.com/3atS38Hj shows same with -N instead of -X
[14:28] <pitti> hrw: I guess it'll still fail, as it doesn't -N the lib32 binaries; it's a separate bug, though
[14:28] <pitti> yes, as expected
[14:29] <pitti> hrw: what does debian/control say for lib32blah? Shouldn't that have Architecture: amd64?
[14:29] <hrw> Architecture: amd64 ppc64
[14:29] <pitti> hrw: ok, so the bug here is that pkg-create-dbgsym checks build arch, not host arch
[14:29] <hrw> thx
[14:30]  * pitti runs tests
[14:33] <hrw> pitti: BUILDARCH=`dpkg-architecture -qDEB_HOST_ARCH` == success here
[14:33] <pitti> hrw: ah, thanks! I was about to toss you a .deb for checking, but that's the gist of the change indeed
[14:34] <hrw> pitti: once you told build/host stuff I started checking files
[14:34] <hrw> ncurses pacakges created
[14:35] <hrw> now reverted -X -> -N changes and rebuilding packages
[14:35] <pitti> hrw: http://bazaar.launchpad.net/~ubuntu-core-dev/pkg-create-dbgsym/ubuntu/revision/194
[14:35] <pitti> hrw: no, -N is correct
[14:35] <pitti> hrw: -X is not the correct option for ignoring packages
[14:35] <hrw> pitti: sure, but this is a bug which I will report separatelly
[14:36] <pitti> tests pass
[14:36] <pitti> hrw: ok, will upload, thanks for pointing out!
[14:36] <hrw> pitti: you welcome. thanks for fixing
[14:37] <hrw> pitti: can you look at bug 711523 and tell me what do you think about patch?
[14:38] <hrw> pitti: I can explain why patch calls pkg_create_dbgsym on its own
[14:39] <pitti> hrw: pkg_create_dbgsym gets called by the wrapped dh_strip, so packages which don't use debhelper need to call it manually
[14:40] <pitti> doko_: FYI, pkg_create_dbgsym is not called by pkgbinarymangler, just from dh_strip
[14:40] <hrw> doko_: can you merge it now when it got explanation from pitti?
[14:41] <hrw> pitti: and thanks for this explanation - I did not know that before
[14:41] <pitti> hrw: hrw but why do you call $(STRIP) twice?
[14:41] <pitti> hrw: and note that this patch is missing a pkg-create-dbgsym build dependency
[14:41] <hrw> pitti: I copied stripping rules from other part of rules
[14:42] <hrw> pitti: binutils iirc already depends on it
[14:42] <pitti> ah, forget about the b-d, it's || true
[14:42] <hrw> pitti: this patch adds 6th call to it
[14:42] <pitti> hrw: it's installed in the buildd chroots already
[14:44] <pitti> doko_: ok, that's more like it: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[14:45] <pitti> doko_: pinyin-database already demoted
[14:45] <pitti> bryceh said that he'll add xserver-xorg-video-qxl
[14:45] <pitti>  to x-x-video-all, so that'll get sorted out as well
[14:45] <doko_> pitti: so you did approve a FFe for dbus-c++?
[14:46] <pitti> doko_: the changelog is just bug fixes, there's no real new features there
[14:46] <doko_> ok
[14:46] <doko_> TheMuso: ^^^
[14:47] <pitti> hrw: how urgent is the p-c-d fix? do you need it in beta-1?
[14:47] <hrw> pitti: not urgent
[14:47] <pitti> hrw: ok, keeping in the queue then
[14:48] <hrw> pitti: would be nice to have it in natty but no rush to have it asap
[14:48] <pitti> hrw: yes, will go in after beta-1, i. e. on Thursday
[14:48] <hrw> pitti: in archive cross packages are not affected (as I maintain all of them and do nearly daily builds of those)
[14:48] <mvo> ev: \o/ I can reproduce the bug
[14:49] <ev> yay
[14:49] <hrw> pitti: http://paste.ubuntu.com/586457/ would be ok debdiff for ncurses?
[14:49] <psusi> pitti: I was wondering if you had seen my patches to upower, g-p-m, and indicator-session ( merge request and posoted to devkit-devel ) and had any opinion on them?
[14:50] <pitti> hrw: looks fine; please forward to Debian, to avoid a permanent delta
[14:50] <pitti> hrw: I wonder if we really need to upload this -- does it work with -X as well?
[14:51] <pitti> hrw: it should work as long as package libfoox also has any file containing "libfoox", e. g. usually in /usr/share/doc/
[14:51] <psusi> doh... emacs crashed...
[14:51] <hrw> pitti: it works with -X too
[14:51] <pitti> psusi: hughsie said he'd look at them, so I didn't want to get in his way
[14:51] <hrw> pitti: it is rather kind of wishlist bug rather I think
[14:52] <pitti> hrw: yeah; I think you should send it to a Debian bug, and then declare it done
[14:52] <psusi> pitti: ok...
[14:53] <hrw> thanks pitti for help
[14:58] <hrw> bug reported to Debian/ncurses as minor + patch
[14:59] <doko_> hrw: now merged all change to -4.5, -4.6 and binutils
[14:59] <pitti> hrw: splendid, thanks
[14:59] <hrw> doko_: thanks a lot
[15:05] <hrw> doko_: can you merge changes to gcc-4.4 too?
[15:06] <hrw> debbug 619939
[15:06] <hrw> pitti:  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619939 was what I reported
[15:12] <Daviey> pitti, Hey... would you be able to re-look at bug 651875, from an SRU ack perspective?
[15:13] <MacSlow> popey, ping
[15:14] <popey> MacSlow: pong
[15:14] <MacSlow> Do you have a method of consistently triggering LP: #742091 you reported last thursday? Could you share that with me (or add to the bug). I have a fix and would like to put that to the test. Thanks in advance!
[15:15] <popey> well, i have updated since then, and it's been even less reliable
[15:15] <popey> i can crash it doing fairly basic stuff like moving windows
[15:15] <popey> but I am at work now, and pc is at home, i can try when i get home tonight
[15:15] <MacSlow> popey, we also have more fixes coming up :)
[15:15] <popey> \o/
[15:16] <popey> good to hear
[15:16] <MacSlow> popey, if you could add it to the bug as addional comment... that would already help
[15:16] <tkamppeter> seb128, thank you. Unfortunately, all patches presented to me in that bug report were immediate crashers.
[15:16] <popey> ok, will do
[15:16] <MacSlow> popey, thanks!
[15:17] <seb128> tkamppeter, can you open a bug against libunity asking for hplip to be whitelisted?
[15:18] <tkamppeter> I will do so, with reference to bug 497877, telling that several efforts were made to adapt hp-systray but no solution found.
[15:24] <pitti> Daviey: see comment 7 -- if we can reasonably QA this (test suite or manual testing), I'm fine with that; by and large needs an upload and a test plan now
[15:25] <doko_> hrw: done
[15:26] <hrw> thanks again
[15:27] <hrw> doko_: did you had a time to look at patch in bug 676454 - removal of u-a from cross builds of gcc
[15:28] <doko_> hrw: not yet, please ping me tomorrow
[15:28] <hrw> doko_: ok
[15:30] <ogra_> is there a reason why wpasupplicant is only in the high level seeds but not in something like ubuntu-standard ?
[15:30] <tkamppeter> seb128, I have reported the whitelisting request for hp-systray as bug 744308.
[15:30] <seb128> tkamppeter, tahnks
[15:31] <directhex> pitti, do you know if you'll get a chance this week to look at the webkit annotations issue shana brought up?
[15:32] <shana> oh, I found more
[15:32] <pitti> directhex: I hope so; I have a built upstream checkout now, that just didn't build the gir at all, so I need some prep for this
[15:32] <shana> pitti: there's no type annotation on signal parameters. the c:type entry is missing
[15:32] <Daviey> pitti, We don't have a decent test suite.  The best we can do is manual testing..  I was 'ok' with trying to cherry pick, but as upstream don't have an open VCS this is near impossible.  Debian maintainer (lamont), and security seem to prefer adopting a new upstream version (which we are supporting in Natty).
[15:32] <pitti> shana: oh, intersting
[15:32] <shana> and I didn't open the bug, darn it
[15:32] <shana> pitti: there is in the 1.2.5 version, but not in the 1.3
[15:33] <Daviey> pitti, it's currently in the unapproved queue.. I am happy to test it on my production dns servers, but i am quite close to the issue.  So will look to try and get more manual testing once t hists proposed, by hitting the server mailing list.
[15:33] <pitti> Daviey: ah, good
[15:33] <shana> unless annotations changed significantly between the two versions, I'm guessing it's a side effect of the lack of ownership perhaps?
[15:33] <shana> totally guessing ere
[15:33] <shana> *here
[15:34] <Daviey> pitti, if you are satisfied, can you add an ack please? :)
[15:34] <pitti> shana: "ownership" in the sense of "nobody at webkit cares about it"?
[15:34] <shana> pitti: was thinking more of the missing "transfer-ownership" thing :)
[15:34] <shana> or whatever the annotation is called
[15:35] <shana> :)
[15:35] <pitti> shana: ah; but trunk and package are built with the same g-i version, so that wouldn't make a difference
[15:35] <shana> the schema version in the gir files is different
[15:35] <shana> 1.2.5 is marked "1.1", 1.3 is marked "1.2"
[15:36] <shana> I have no clue if there's a difference
[15:36] <pitti> Daviey: followed up
[15:36] <shana> just throwing ideas, frankly, I stopped when I noticed the c:type missing and haven't investigated further
[15:36] <Daviey> pitti, thanks!
[15:41] <Daviey> pitti, So.. really wanted to get this new upstream version  in -updates by thursday.  Even with a call for testing, do you think this is unlikely?
[15:47] <pitti> Daviey: you mean -proposed?
[15:55] <Daviey> pitti, -updates!  We are going to have many unhappy people if it doesn't... It's sort of time senstive...  The rational in the url in the bug description explain why.
[15:55] <pitti> Daviey: no way
[15:55] <pitti> Daviey: even for a small focussed patch it needs to mature 7 days
[15:55] <pitti> Daviey: for a large new upstream update I expect something like two or three weeks
[15:56] <Daviey> Yup, i agree... but ideas for a resolution?
[15:56] <Daviey> pitti, note, there has already been a call for testing from a PPA... but not had feedback.
[15:56] <pitti> Daviey: as I said on the bug: upload a small backported patch, we'll get that into -updates next Monday, and then we can do the full release
[15:57] <pitti> Daviey: lucid sustained without the fix for a year now, why is it suddenly so urgent?
[15:57] <Daviey> pitti, March 31st, the internet changes...
[15:57] <Daviey> url on the way
[15:58] <Daviey> http://www.isc.org/announcement/bind-9-dnssec-validation-fails-new-ds-record
[15:58] <pitti> Daviey: then I'd say minimal patch and quick verification
[15:59] <pitti> and we'll cut the usual 7 day period, as in this case the impact if we don't do it is higher
[16:03] <YokoZar> Can a quilt patch Author field contain more than one person?
[16:03] <YokoZar> (what uses the data?)
[16:03] <Daviey> pitti, ack..
[16:03] <Daviey> mdeslaur, around?
[16:03] <Daviey> and lamont ?
[16:03] <mdeslaur> Daviey: yep
[16:04] <lamont> sorta
[16:07] <cjwatson> YokoZar: http://dep.debian.net/deps/dep3/ "This field can be used multiple times if several people authored the patch."
[16:07] <cjwatson> so Author: Some Person\nAuthor: Other Person, etc.
[16:08] <YokoZar> cjwatson: thanks, exactly what I was looking for.
[16:08] <YokoZar> I didn't find that page cause I kept searching for "quilt" and it's not listed there :/
[16:10] <doko> pitti, TheMuso: I think I'll just merge dbus-c++, upload and then start the test rebuilds
[16:11] <pitti> doko: ah, Debian still doesn't have symbols files?
[16:11] <tgardner> if you'd like 802.11n high-speed wireless support re-enabled in your modern Intel wifi adapter, then please review the patch at https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/630748/comments/64
[16:12] <doko> pitti: no
[16:13]  * JackyAlcine will be right back.
[16:13] <cjwatson> YokoZar: right, it's not quilt-specific
[16:14] <YokoZar> cjwatson: Yeah, but I didn't think to do a more generic search ;)
[16:19] <u-foka> Hy! Should that overlay scrollbar stuff work in an "Ubuntu Classic" session with compiz?
[16:27] <doko> ev: is python-mock b-d only?
[16:28] <ev> doko: build-dep for ubiquity? Yes.
[16:29] <doko> ok, promoting. should use dh_python2 for packaging at some point
[16:32] <doko> pitti: dbus-c++ waiting for approval
[16:32] <pitti> doko: accepted (still universe)
[16:33] <doko> hmm, I think, then I'll have to wait with the promotion?
[16:33] <pitti> doko: fine for me to promote it right now, more consistent archive
[16:33] <doko> ok, done
[16:34] <pitti> doko: (note I reopened the bug as the package upload didn't do the promotion)
[16:34] <pitti> doko: let's hope that won't confuse the current upload :)
[17:15] <slangasek> chrisccoulson: how well do you understand nss's build system?
[17:16] <chrisccoulson> slangasek, not very well, it's fairly hideous ;)
[17:16] <chrisccoulson> i take it you want to convert it to multiarch?
[17:17] <cjwatson> watch out for its perversion of "build" and "host" (IIRC)
[17:17] <slangasek> chrisccoulson: precisely :)  I have everything except finding where in the system it decides on the /usr/lib/nss path
[17:17] <cjwatson> in fact and possibly "target" too
[17:18] <slangasek> cjwatson: I'm hoping to just pass a path in via make or whatnot, and ignore its worldview entirely :)
[17:23] <tgardner> slangasek, you seem kind of busy. is there someone else that you'd suggest to have a look at my module-init-tools patch at https://bugs.launchpad.net/ubuntu/natty/+source/module-init-tools/+bug/630748/comments/64 ?
[17:24] <cjwatson> didrocks: what's happening with compiz/unity/nux/etc. for beta-1?
[17:25] <didrocks> cjwatson: nothing planned for now, the release we did last Thursday still stand
[17:25] <slangasek> tgardner: hi there - sorry, I hadn't had time to pull the tarball you pointed me to on chinstrap, but a patch in LP works fine :) couple questions I have:
[17:25] <cjwatson> tgardner: needs Pre-Depends: dpkg (>= 1.15.7.2)
[17:25] <tgardner> cjwatson, so thats required for natty?
[17:26] <tgardner> I read about it in the man page
[17:26] <slangasek> tgardner: 1) what's the expected behavior here if a user tries to boot an older kernel where iwl3945 is not split? (is this such a thing?  I don't remember 3945 ever being in iwlagn, but that's what the changelog suggests)
[17:27] <tgardner> slangasek, an older kernel is likely to re-exhibit the original bug.
[17:27] <cjwatson> tgardner: yes, because otherwise direct upgrades from 10.04 LTS to 12.04 LTS may fail
[17:27] <slangasek> tgardner: 2) not so much a question... if you use dpkg-maintscript-helper, you're supposed to call it in all of the preinst, postinst, and postrm
[17:27] <tgardner> slangasek, I was a bit confused by that, hence me bugging you for a review. I'll add those other calls.
[17:28] <slangasek> tgardner: yes, it is confusing - the reason for having it in all of preinst, postinst, and postrm is to completely handle certain upgrade rollback scenarios (i.e., if you only call it in prerm, dpkg leaves bits around on the filesystem that are only needed for rollback and which you want to have cleaned up)
[17:29] <tgardner> slangasek, OK. Is an older kernel a realistic scenario?
[17:30] <slangasek> tgardner: it's something that might come up when a user is trying to debug / recover an upgrade; I guess there's not really much we can do there after the fact unless you want to SRU the iwlagn module to have a built-in default of 11n_disable for iwl3945 chips only?
[17:30] <slangasek> but whether or not it's worth doing an SRU for the old kernels, it makes me wonder if this same default should be changed for the iwl3945 module /now/
[17:30] <cjwatson> it's in debhelper as of 8.1.0, FWIW, so if you're already relying on that or don't mind doing so, you can just stick 'rm_conffile /etc/modprobe.d/intel-5300-iwlagn-disable11n.conf 3.12-1ubuntu4' in debian/module-init-tools.maintscript and not worry about the details.  (Not that I'm suggesting you necessarily need to do that here, it's just for information since maybe not many people know about that yet)
[17:32] <tgardner> slangasek, there isn't an easy way to disable 802.11n for just 3945 in older kernels.
[17:32] <slangasek> yep, understood
[17:33] <tgardner> ok, I'll respin and annoy you guys later today.
[17:33] <slangasek> I'll be here :)
[17:43] <pitti> Riddell: recent kdebase-workspace introduced a dep to nodm, which is in universe? is that intended (-> MIR)?
[17:44] <Riddell> pitti: Recommends: kdm (>= ${source:Version}) | nodm    nodm is for kubuntu-mobile which is built from universe
[17:45] <pitti> Riddell: ah, so perhaps that's only temporary because of i386/amd64 desync
[17:45] <Riddell> if it remains a problem I can just remove the recommends for both there
[18:09] <ScottK> Alternate depends in Universe should be fine.
[18:11] <pitti> SpamapS: woudl you have some time this week for an SRU training session? there's enough fodder in the queues now
[18:12] <SpamapS> pitti: definitely! Wed or Thu would work
[18:13] <pitti> SpamapS: nice
[18:14] <directhex> bah
[18:32] <pitti> dpm: you still have a WI "Talk to Mozilla people about using user provided translations from Launchpad"; I'm curious, did you already talk to them? what did they say? would be great to have a more direct translation flow to them
[18:36] <dpm> pitti, hm, no, unfortunately I didn't get to talk to them yet. I started on this a while ago by writing the e-mail and getting it past through a couple of people, and I needed to add their feedback. I just left it at "oh, I'll do this later", but now that chrisccoulson has started moving the FF translations topic forward I need to look at it again. Let me come back to you tomorrow.
[18:36] <pitti> dpm: ah, thanks
[18:36] <pitti> dpm: so I keep this open; no worries, just cleaning up WIs
[18:37] <dpm> no worries, thanks for the heads up
[18:50] <highvoltage> 7/win 21
[18:57] <nigelb> highvoltage: fail? try 42 ;)
[19:46] <ari-tczew> james_w: I guess you're not looking for sponsorship? http://reports.qa.ubuntu.com/reports/sponsoring/index.html
[19:47] <micahg> ari-tczew: did you see there's a comment in the merge proposal?
[19:48] <ari-tczew> micahg: do you mean field Description of the Change ?
[19:48] <micahg> ari-tczew: yes
[19:49] <ari-tczew> micahg: ok what;s the conclusion?
[19:49] <micahg> ari-tczew: they need to be analyzed if they're necessary merges, did you read the description?
[19:50] <ari-tczew> micahg: yes but I don't need to be a mastermind to understand everything
[19:55] <cody-somerville> ari-tczew, Are you saying you don't understand the merge proposal descriptions or that you do?
[19:55] <cody-somerville> ari-tczew, (or are you saying something completely different there?)
[19:56] <ari-tczew> cody-somerville: your first suggestion
[19:59] <cody-somerville> ari-tczew, Are you familiar with the UDD (Ubuntu Distributed Development) work? Basically, the idea is to manage packages in bzr branches. It looks like James has a script that detects when the packages actually in the archive become out of sync with the bzr branches. The script move the old branch out of the way, pushed a new branch that *is* in sync, and created a merge proposal for the old branch to be merged into the new t
[19:59] <cody-somerville> o make sure no changes that hadn't been uploaded get lost.
[19:59] <cody-somerville> *moved
[20:00] <ari-tczew> cody-somerville: ok, what we have to do with these branches? sponsor it?
[20:02] <cody-somerville> ari-tczew, Not necessarily. What needs to happen is for interested individuals to go through those MPs, analyze the diff, and merge + sponsor in any changes to the new branch if appropriate.
[20:03] <ari-tczew> cody-somerville: so it means a lot of work to do, Total requests: 102
[20:04] <bdrung_> popey: funny bug report :)
[20:04] <cody-somerville> ari-tczew, I imagine a lot of them can just be rejected if there is no diff.
[20:05] <cody-somerville> ari-tczew, I'd ask james_w for more details though before going through and closing them based on that criteria.
[20:06] <ari-tczew> cody-somerville: ok :)
[20:49] <Cheery> hi, did ubuntu switch window system already?
[20:49] <Cheery> or was the whole thing just a really nasty rumor?
[20:52] <m4n1sh> Cheery: Wayland?
[20:53] <Cheery> m4n1sh: yes
[20:53] <m4n1sh> will take time
[20:53] <m4n1sh> probably 3-4 releases for sure
[20:53] <broder> Cheery: as sabdfl said in his blog post, wayland is almost certainly at least 2 years off
[20:54] <m4n1sh> Cheery: it wasnt a rumour. Check Mark's blog
[20:56] <Cheery> you probably know there's very good reason to get further with it.
[20:56] <ogasawara> cjwatson: just fyi, we've uploaded a linux-backports-modules-2.6.38 for Natty (it's still in the new queue).  it can wait until after beta to move out of new, but apw mentioned we should also ping you so that it gets added to some uploaders list?
[20:59] <Cheery> heh. I put nvidia + wayland into google and there is a forum fost at nvidia forums first..
[20:59] <Cheery> then there's bunch of 'news' after quoting the "no plans to support"
[21:04] <psusi> I still don't understand wayland.. the last I read about it, it sounded like it was just for switching between multiple X servers...
[21:05] <broder> wayland replaces the x server and protocol, and (at a high level that is clearly pro-wayland) gets rid of all the legacy code and functionality that the x server and protocols have to support but nobody cares about
[21:05] <micahg> er, rather that casual desktop users don't care about
[21:06] <broder> like i said, clearly pro-wayland :)
[21:06] <Cheery> I think I'll look into that a bit.. searching wayland API now.
[21:11] <Cheery> egl + gles2 since libGL has been mutilated with GLX
[21:14] <psusi> broder: it doesn't replace it though, it just exists outside it.. you still need an X server to have the functioning desktop we have now... all qt and gtk apps require X
[21:15] <broder> psusi: only because the toolkits haven't been ported to the wayland backend
[21:15] <broder> which will happen
[21:15] <broder> just as they've been ported for carbon/cocoa/win32 backends
[21:15] <psusi> broder: as far as I can see, there isn't a "wayland backend"; it's just a DRI backend
[21:16] <Cheery> if there were nvidia driver for wayland without EGL/GLES2, I think I'd be already using wayland
[21:16] <Cheery> and I'm writing software too :)
[21:16] <psusi> and if you build gtk to use a dri backend, then you can run just a single app... there's no windowing and soforth
[21:16] <broder> psusi: i only have a very high-level understanding of wayland, but i find it hard to believe that that's the end of the story
[21:17] <Cheery> psusi: that's one of the things I wonder too
[21:18] <Cheery> haven't really seen "wayland documentation" which actually tells what it does and what it doesn't
[21:18] <Cheery> my opinion to this is that input + visuals should be dealt separately as possible.
[21:18] <Cheery> I'd allow mouse + keyboard multiplexing only, as long as there's no further multiplexers.
[21:19] <Cheery> the whole thing should have higher granularity than X, anyway.
[21:20] <psusi> I mean, the x protocol may not be pretty, but it sounds like wayland does almost nothing and expects the toolkits to reinvent most of what X handles
[21:22] <Cheery> psusi: which may be the whole point in it.
[21:22] <Cheery> except that you shouldn't end up to toolkits
[21:22] <Cheery> that toolkit will become just an another X
[21:23] <psusi> exactly... so if the toolkits just end up becoming another X, why bother?
[21:23] <Cheery> maybe.. because you're not interested about doing a toolkit but something slicker.
[21:28] <Cheery> psusi: say one defines a clear API, like opengl4 has, to access window manager which provides bunch of basic elements that you can't implement otherwise, then toolkits take on from that.
[21:29] <Cheery> ..if we'll ever need toolkits again.
[21:29] <Cheery> the window manager API at this point would only handle things that require interaction with windows.
[21:30] <Cheery> and that's about it.
[21:34] <Cheery> psusi: the benefit in that is you could create a desktop app with lot less effort than now. It'd make SDL look like bloat
[21:34] <Cheery> but.. I'm getting to sleep now
[21:35] <tgardner> slangasek, another version of the module-init-tools patch. https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/630748/comments/65 - Please add comments to the bug as I'm outta here for the day.
[21:59] <lifeless> kees: ping
[22:09] <barry> slangasek: ping
[22:10] <slangasek> barry: hey there
[22:10] <barry> hi slangasek.  so, i think multiarch breaks from-source builds of python
[22:11] <slangasek> barry: if you mean unpatched upstream source, I'm afraid that's true; we've patched the packages in natty to address this, I don't know doko's thoughts on upstream fixing
[22:12] <barry> slangasek: python itself builds, but a handful of modules break
[22:12] <barry> slangasek: okay, i guess it's time to bring it up on the relevant mailing lists ;)
[22:13] <slangasek> yes, was reported in LP as bug #738213
[22:13] <barry> slangasek: cool, thanks for the reference
[22:15] <cjwatson> ogasawara: right, thanks - I'll try to remember to sync up the ACLs
[22:31] <RAOF> @pilot in
[22:32] <kees> lifeless: I'm vacationing until Wed, but send me an email if it's low-urgency. for high-urgency, check with the other security folks. :)
[22:39] <lifeless> kees: ah
[22:39] <lifeless> kees: it was about the cve page on lp
[22:39] <lifeless> kees: I think its rather specific to you :P - do you need the inline-edit widgets for the listed bugtasks
[22:40] <lifeless> kees: e.g. on https://launchpad.net/bugs/cve/2009-0834/+index
[22:40] <lifeless> kees: (mailing this now)
[22:40] <kees> lifeless: cool
[22:40] <lifeless> kees: but I'm hoping your answer is 'no, I don't'
[22:41] <kees> lifeless: hah. OOPS-1913Q1097 on that url. :P
[22:41] <lifeless> kees: yes, thats why I want to remove the edit widgets
[22:41] <lifeless> and just make it a task listing like e.g. a milestone page
[22:41] <kees> heh
[22:41] <kees> that's fine; it's a summary page as far as I'm concerned.
[22:42] <lifeless> great, thanks