[01:52] <sbalneav> Not sure if anyone's been working on the firefox 3.6 "no start" problem, but I've narrowed down the problem, I think....
[01:52] <sbalneav> the compatibility.ini file seems to be what's stopping it from starting
[01:53] <sbalneav> Specifically, the LastVersion=3.6_20100125074043/20100125074043
[01:53] <sbalneav> line
[01:54] <sbalneav> I'll have a look at the code, see if I can find out what's parsing it.  Buffer overrun, maybe?
[01:58] <hggdh> sbalneav: you might have better response on the #ubuntu-mozillateam channel
[01:59] <sbalneav> ah, ok!  Super.
[02:04] <micahg> what's the q?
[02:04] <micahg> oh.hmm...
[02:06] <micahg> sbalneav: I'll be back on in there in a couple hours if you want to discuss
[02:07] <sbalneav> Sure.
[02:07] <sbalneav> I can make it start reliably now by editing the file.
[02:08] <sbalneav> Ping me when you get in there.  I'm idling there now.
[03:15] <Toa_Vakama> hi
[07:26] <dholbach> good morning
[08:54] <pitti> Good morning
[08:55] <pitti> zul: pastedeploy> saw your response, will process today
[08:55] <pitti> kees: lxc> ack
[09:13] <ogra> pitti, so with my newly upgraded lucid laptop gdm is up after 10seconds after BIOS ... as you can see on http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png X is up after 3.5 and gdm-simple-greeter after about 5.5, is there still any work going on to make the greeter map faster here ? the time from X to greeter mapping *feels* quite long
[09:14] <ogra> s/is up after/is starting after/
[09:15] <pitti> ogra: hm, isn't that just the period when you enter your password?
[09:15] <ogra> nope
[09:15] <pitti> there is no CPU and IO at that time
[09:15] <ogra> i see the greeter after 10sec
[09:15] <ogra> i stopwatched it
[09:15] <ogra> so half the time i'm waiting for the greeter to map on the screen
[09:16] <ogra> i typed my password here in this bootchart at about 15sec
[09:16] <pitti> strange
[09:17] <ogra> the drumroll also comes when X comes up already, that might add to the impressions of the greeter being slow
[09:17] <pitti> I don't see that on my box (http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100122-2.png)
[09:17] <pitti> 3 secs between gdm and g-session, that's the time I need to pick user/enter pwd
[09:19] <ogra> no, i'm talking about the mapping from the greeter starting to seeing it on screen
[09:19] <pitti> do you bring this laptop to the sprint?
[09:19] <ogra> yes
[09:19] <ogra> its just that the whole bootprocess feels incredibly fast ... somehow the greeter bringup doesnt feel right in that whole scheme
[09:19] <ogra> wow, you got a slow disk !
[09:20] <pitti> well, "incredibly fast"
[09:20] <pitti> yes, your disk is crazily fast
[09:20] <pitti> however, there's this looooong udev-configure-/dk-power-manager/modprobe hang
[09:21] <pitti> with the current kernel, I'm seeing something similar on the dell mini (http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-1.png)
[09:21] <pitti> that 5 second block wasn't there with -10)
[09:21] <ogra> intresting
[09:22] <ogra> thats autoligin on the mini, no ?
[09:22] <pitti> yes
[09:22] <ogra> *login
[09:22] <ogra> i should try that on mine for a test
[09:22]  * pitti tries with -12 kernel
[09:24] <ogra> oh
[09:24]  * ogra just notices he modified his cmdline in karmic
[09:24] <ogra> though i guess usbcore.autosuspend=1 doesnt change anything in the bootprocess
[09:25] <pitti> worth trying, though
[09:27] <ogra> hmm, why is update-grub not doing anything
[09:27] <ogra> oh, its just slower than the old one
[09:27]  * ogra reboots ... lets see
[09:31] <ogra> god, freenode gets annoying with the broken autojoin
[09:31] <ogra> pitti, no change without usbcore.autosuspend=1
[09:32] <ogra> still sitting there on the xsplash wallpaper for about 5 sec
[09:34]  * ogra tries autologin
[09:37] <ogra> wow !
[09:37] <pitti> ogra: 15 seconds now? :-)
[09:37] <ogra> 9sec to desktop if i didnt miscount (some app should emit a "mapped" signal that shows up in bootchart)
[09:38] <pitti> ogra: bootchart draws a red line when it's "done"
[09:38] <ogra> sadly the chart doesnt really reflect how fast everything was up
[09:38] <ogra> yes, when *bootchart* is done
[09:38] <pitti> no, when the session stops using IO and CPU
[09:38] <ogra> it was up for way over 10 seconds already and i didnt even see a tgz in /var/log
[09:38] <pitti> yes, that takes a while
[09:39] <pitti> it continues to measure way after the desktop is done
[09:39] <ogra> the red line is at 30sec here
[09:39] <ogra> but thats definately 20 sec longer than it took to map all apps on my screen
[09:39] <pitti> hm, the red line usually works fine here, odd
[09:39] <ogra> i had to type my keyring PW
[09:39] <ogra> probably it waits until thats done
[09:40] <ogra> since that still produces IO
[09:40] <ogra> dhclient starts at 20sec on the bootchart
[09:43] <ogra> http://people.canonical.com/~ogra/osiris-lucid-20100128-2.png
[09:44] <seb128> urg
[09:44] <ogra> urg ?
[09:44] <seb128> your dkpower uses disk for 6 seconds
[09:44] <pitti> ogra: wow, that's by and large a 10 second boot
[09:45] <pitti> ogra: even with ubuntuone taking CPU like mad
[09:45] <ogra> yes
[09:45] <pitti> seb128: modprobe/udev-configure/dk-power hang
[09:45] <ogra> bootchart totally doesnt reflect when i see the desktop though
[09:45] <pitti> looks similar to the delay that we get on the mini
[09:46] <pitti> that's just I/O wait, though, not actually doing I/O
[09:46] <ogra> right
[09:47] <ogra> note though that this SSD costed nearly 300€ (i decided to upgrade RAM and disk insteads of buying a new lappie last year) :) but it didnt gain me *any* speedup in karmic
[09:47] <ogra> after the upgrade yesterday i nearly fell off my chair
[09:47] <pitti> :-P
[09:48] <ogra> (and i didnt even buy it for speed butu for battery life :) )
[09:48] <ogra> *but
[09:49] <seb128> weird that it didn't make any difference in karmic
[09:49] <ogra> yeah, i thought so too
[09:49] <ogra> but i have one odd device that the karmic kernel had issues with (touchscreen) so my modprobe looked like pitti's
[09:50] <ogra> somehow modprobe looped over the device for like 10 secs, without it i might have seen speed improvements
[09:53] <lool> cjwatson: Hi, since a recent upgrade of the ssh client on lucid, I get warnings in logcheck from auth.log; the following lines now appear everytime I close a ssh connection:
[09:53] <lool> Jan 28 10:52:51 fox sshd[26563]: Received disconnect from 192.168.0.119: 11: disconnected by user
[09:53] <lool> (before pam session is closed)
[09:54] <lool> cjwatson: I don't know whether this is expected or not, in which case I'll update the logcheck rules
[09:54]  * lool goes to Paris hand over some hardware and will be back in the afternoon
[09:54] <lool> +to
[09:54] <lool> didrocks: Leaving now
[09:54] <didrocks> lool: ok, I'll leave in 20 min approximately
[09:55] <lool> didrocks: Shoot for 12:15 rather than 12:00; transport takes forever here
[09:55] <didrocks> lool: ok, see you :)
[10:00] <pitti> mvo: rejecting your metacity karmic-proposed upload; no bug reference
[10:20] <tseliot> slangasek: are you around?
[10:20] <slangasek> yes
[10:20] <tkamppeter> pitti, thanks for putting up my CUPS SRU
[10:23] <tkamppeter> pitti, I have seen a bug report somewhere that CUPS does not start when booting an up-to-date Lucid, can it be that the upstart switchover is the culprit? Will you update the CUPS package to also start through upstart?
[10:24] <pitti> tkamppeter: I believe Scott already has an upstart script, but it still causes problems
[10:24] <pitti> tkamppeter: however, init scripts ought to work; if not, that's a bug in the upstart init script integration
[10:25] <tkamppeter> pitti, OK.
[10:25] <tkamppeter> pitti, to which package do I have to assign the CUPS-not-starting bug then?
[10:26] <pitti> tkamppeter: I don't know, without seeing the bug
[10:36] <Riddell> mvo: is it right that you can't have two packages doing a dpkg-diverts on the same file?
[11:01] <slangasek> Riddell: yes
[11:26] <apachelogger> asac: ping
[11:31] <asac> apachelogger: ?
[11:34] <apachelogger> asac: can you please make the firefox package replace kubuntu-firefox-installer http://bazaar.launchpad.net/~kubuntu-members/kubuntu-firefox-installer/trunk/revision/22
[11:34] <apachelogger> following https://bugs.edge.launchpad.net/ubuntu/+source/kubuntu-firefox-installer/+bug/439431/comments/4
[11:46] <apachelogger> ccheney: ^
[11:48] <asac> apachelogger: sure
[11:48] <apachelogger> thx :)
[11:52] <cjwatson> lool: it appears to be intentional
[11:52] <cjwatson> lool: from what I can tell it was part of the preparation for roaming support
[12:20] <StevenK> pitti: I'm going to promote EFL and related bits and close the MIR bugs tomorrow morning
[12:29] <ogra> pitti, hmm, looking at /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules it should be possible to assemble something similar for evtouch devices based on bug 317094
[12:29] <ogra> just needs someone with a lot of time to look at all the lshal files
[12:40] <pitti> cjwatson: thanks for fixing simple-scan ACLs!
[12:46] <hdon> any idea how to deal with this kind of warning from gcc? warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64’
[12:47] <hdon> i guess i could cast it
[13:18] <cjwatson> hdon: C99 defines a macro PRId64 which expands to whatever string is required to printf int64_t
[13:18] <cjwatson> it's not pretty, but nor is a cast, and that's the best you can portably do
[13:19] <cjwatson> hdon: you need to #include <inttypes.h> for that
[13:20] <cjwatson> hdon: oh, and you need to supply the "%" yourself, so e.g. printf("%" PRId64 "\n", i);
[13:56] <Sonne> hello there
[13:56] <Sonne> is this the right place to ask about a problem with making an usplash theme?
[14:00] <Sonne> in doubt, i'll try and ask: i have made a 256 colors 640x480 png, used pngtousplash, and compiled into .so, but when trying to load it usplash says "No usable theme found for 640x480"
[14:21] <vmlintu> Are there known bigger problems with current Lucid packages? It seems like all my kvm based lucid virtual machines just stopped bootin. fsck shows up on console and then it dies with different errors like "mountall: fsck /boot [596] terminated with status 1"
[14:22] <vmlintu> fsck seems to complain at every boot about unclean shutdown and often checks also fail
[14:22] <vmlintu> All other kvm virtual machines boot fine and these broke with some apt-get dist-upgrade
[14:30] <EtienneG> hello all - does someone know the fate of Moonlight in lucid?  I checked, it has not been packaged in Debian, was wondering if someone has been working on it
[14:30] <EtienneG> err, I mean Moonlight *2*
[14:35] <cyphermox> EtienneG, if it can be of any help, here's why 2 is not in Debian yet, it seems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530251 the last comment is especially of interest ;)
[14:35] <EtienneG> cyphermox, that is very useful indeed
[14:35] <EtienneG> thanks!
[14:36] <cyphermox> especially useful since think I know exactly why you're interested in moonlight ;)
[14:38] <EtienneG> cyphermox, or so you think (hint: it has *nothing* to do with Radio-Canada)
[14:39] <cyphermox> EtienneG, aww
[14:39] <seb128> directhex, Laney: is anybody working on getting the new gnome-sharp2 in lucid?
[14:39] <EtienneG> cyphermox, in any case, I need to telegraph to this Riku Voipio guy
[14:39] <EtienneG> err, I mean, to telegraph *a beer*
[14:39] <seb128> directhex, Laney: the debian changes to put the .pc in the new binaries at least
[14:39] <directhex> seb128, not until someone works out why mono isn't migrating it. it's been synced twice & LP eats it
[14:39] <Laney> seb128: I reckon we could be persuaded
[14:39] <directhex> s/it/in/
[14:40] <Laney> mono needs hax to be synced
[14:40] <seb128> directhex, I can sync mono
[14:40] <Laney> seb128 knows the magic
[14:40] <seb128> somebody told me to not do it
[14:40] <seb128> !!!
[14:40] <directhex> as a warning about the subsequent FTBFS, i guess
[14:40] <directhex> we're mostly done with that though
[14:41] <Sonne> has anyone read my question about usplash? :)
[14:41] <seb128>  <seb128>      do you need mono to be synced?
       I think that requires more discussion
[14:41] <Laney> let's discuss
[14:41] <seb128> directhex, Laney: should I sync it or not?
[14:41] <seb128> I want to get moving with those changes
[14:41] <seb128> the earlier the transition is done the better
[14:41] <Laney> the state in debian is good
[14:42] <seb128> good to know but I'm asking about Ubuntu there ;-)
[14:42] <mathiaz> slangasek: kees: is it a standard (best?) practice in Debian/Ubuntu that if you don't wanna have a daemon running the package should removed?
[14:42] <seb128> I'm fine dealing with rdepends
[14:42] <seb128> or build issues
[14:42] <seb128> I just want to know if there a reason to delay that transition
[14:42] <mathiaz> slangasek: kees: see bug https://bugs.launchpad.net/bugs/513749
[14:43] <Laney> not really, not if you understand the issues
[14:43] <seb128> the issues is just that build-depends need to be updated?
[14:43] <Laney> yeah, just what to look out for
[14:43] <directhex> more or less, yes, that's the issue
[14:43] <seb128> or do I miss something not obvious there?
[14:43] <seb128> is just seems to me to be a "go through rdepends and change them for the new binaries"
[14:43] <directhex> and there are very few packages remaining to be updated in sid. obviously merges in ubuntu are a second job on top of that
[14:43] <mathiaz> slangasek: kees: and bug 513135
[14:43] <Laney> seb128: that's right
[14:43] <seb128> ok
[14:44] <seb128> doing that now
[14:44] <Laney> and if there are any ubuntu specific packages it would be cool to do those too
[14:44] <seb128> directhex, Laney: anybody wanting to do the gnome-sharp2 change this afternoon?
[14:44] <seb128> Laney, I've already been doing some bug I will need to do those again since we did get half of the changes
[14:44] <directhex> anything in italic on http://wiki.debian.org/Teams/DebianMonoGroup/Mono-devTransition is definitely fine in sid. anything in bold is likely broken
[14:44] <seb128> Laney, that's why it's better to do everything now in once
[14:45] <seb128> and not changing build-depends every weeks because we get part of the new binaries
[14:45] <seb128> directhex, where broken is failing to build right?
[14:45] <seb128> no runtime issue for users
[14:45] <directhex> seb128, right
[14:45] <seb128> ok, really a non issue
[14:45] <seb128> you guys are overcautious there
[14:45] <Laney> we just wanted to get a significant chunk done
[14:46] <Laney> but it seems like some stuff got pulled over anyway
[14:46] <seb128> right
[14:46] <Laney> throw the switch if you like, we'll have your back
[14:46] <seb128> which means we fix several times the same source
[14:46] <directhex> seb128, for full-on bullet biting, pull in anything which is green in the left column  of that wiki link - those are all the things with rdepends which are in sid and need those rdepends to be tweaked
[14:46] <seb128> it turns to be extra work rather than win
[14:46] <seb128> directhex, can you do the gnome-sharp2 merge now?
[14:46] <seb128> or should I do that one too?
[14:47] <Laney> i'll do it if it's just the changelog change
[14:47] <directhex> just the changelog change as far as i can see
[14:47] <seb128> Laney, it is afaik
[14:47] <seb128> Laney, thanks
[14:48] <directhex> seb128, i was also kinda waiting for the archive reorg, as new mono will basically need all extraneous libs to go into main using the old archive layout
[14:48] <directhex> seb128, although evidently that's not happened yet
[14:48] <seb128> right, let's not block on that
[14:48] <seb128> it could take a while ;-)
[14:48] <directhex> okay then, fine by me
[14:49] <seb128> didrocks, Laney: the mono sync is done btw
[14:49] <seb128> ups
[14:50] <seb128> didrocks,-> directhex
[14:50] <directhex> seb128, actually published? it keeps dying at that point
[14:50] <Laney> it requires manual changesfile hax
[14:51] <Laney> because of a \n
[14:51] <Laney> (afaik)
[14:51] <directhex> o_o
[14:52] <Laney> http://packages.qa.debian.org/m/mono/news/20091214T162012Z.html that one there
[14:52] <directhex> Laney, the line's too long so it gets cut up?
[14:53] <directhex> how odd
[14:53] <seb128> directhex, Laney: yes, the issues is the new lines in the .changes, I've acked that before sending it to the queue
[14:53] <directhex> is this more sbuild crud? the changes file from a (pbuilder) mono build is fine on my desktop
[14:53] <seb128> hacked that rather
[14:54] <Laney> the soyuz parser should be more robust
[14:54] <seb128> directhex, soyuz is pickier than pbuilder apparently
[14:54] <seb128> there is a soyuz bug open about that
[14:55] <Laney> wow
[14:55] <directhex> seb128, is there any value in a list of syncables, a list of mergables, and a list of TODO?
[14:56] <Laney> bzr merge-package is GREAT!
[14:56] <directhex> Laney, ?
[14:56] <directhex> Laney, is there a tutorial? i'm kinda pretending it doesn't exist as new workflow scares the bejeesus out of me
[14:56] <Laney> oh, no, hahaha
[14:56] <Laney> I thought it made a really awesome changelog...
[14:56] <Laney> but it looks like slangasek has already done the work
[14:57] <Laney> seb128: seems like the merge is done in bzr
[14:57] <seb128> directhex, yes
[14:57] <seb128> Laney, oh nice, I will sponsor that then, thanks
[14:58] <Laney> you will get depwait, but I guess that's ok
[14:58] <seb128> right
[14:58] <directhex> righty then, time to generate a list. i love lists
[14:59] <Laney> directhex: bzr branch lp:ubuntu/lucid/cats ubuntu; bzr branch lp:debian/sid/cats debian; cd ubuntu; bzr merge-package ../debian; ...; profit
[14:59]  * kjyu is Sherlock Holmes
[15:11] <directhex> okay, 78 packages in debian updated for transition. now to cross-reference against ubuntu
[15:42] <directhex> seb128, analysis complete
[15:43] <directhex> seb128, http://paste.ubuntu.com/364641/ is a list of packages which are fixed in sid, and should be syncable (i.e. they were already ubuntu==debian)
[15:44] <directhex> seb128, http://paste.ubuntu.com/364642/ is the complete list of things which need to be merged (or ubuntu delta dropped if appropriate)
[15:45] <directhex> which leaves a list of 25 things which are held up in debian NEW or not yet checked in either distro by me. or in 2 cases, we plan on dropping entirely
[15:45] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 15 minutes in #ubuntu-classroom (first: Adopt-An-Upstream)
[15:46] <directhex> frankly, the whole thing is *far* further along than i expected, so thanks lots to i assume mostly you
[15:47] <seb128> directhex, ok thanks
[15:47] <akgraner> kirkland, ping
[15:48] <akgraner> do you have 2 mins or should I find you laters
[15:52] <seb128> doko, is that normal that openjdk is still building or is it stucked?
[15:53] <seb128> doko, the i386 build log doesn't seem to be moving and usually it takes some 7 hours and it's over 10 hours now
[16:06] <doko> seb128: the test build did pass locally without problems. maybe ask lamont to have a look on the machine?
[16:06] <seb128> lamont, ^
[16:10] <lamont> meh
[16:18] <sikor_sxe> hello, i am trying to do some customizations for the network-manager-openvpn plugin
[16:18] <sikor_sxe> so i downloaded the tar.gz from "http://packages.ubuntu.com/source/karmic/network-manager-openvpn"
[16:19] <sikor_sxe> ...built and installed it w/ "./autogen.sh" "make" and "make install"
[16:20] <sikor_sxe> is this the correct way to do stuff?
[16:47] <jdstrand> bryceh, slangasek: hey. so mdeslaur and I were discussing bug #507148. It is a pretty serious regression and will likely affect LTS upgrades significantly. I marked it 'regression-potential', but it is unassigned, unmilestoned and the importance is unset
[16:48] <jdstrand> bryceh, slangasek: I don't feel comfortable setting those items, so wanted to discuss it
[16:48] <dpm> pitti, a translator is asking this: <kelemengabor> Hi all, does anybody know, why are the mo files of ubuntu-docs shipped in the language packs?
[16:48] <dpm>  like this: http://people.ubuntu.com/~kelemeng/udocs.txt
[16:48] <dpm> pitti, is this a side effect from the move of the ubuntu-docs translations to the language packs?
[16:48] <dpm> if I understand it correctly, those mo files are not used at all
[16:49] <dpm> (i.e. only the xml files are)
[16:50] <pitti> dpm: well, it's not a side effect, it's the entire purpose :)
[16:50] <pitti> dpm: oh, we shouldn't ship the .mo for the xml files
[16:50] <dpm> pitti, yes, that's what I mean
[16:50] <pitti> dpm: but we do ship the translated xml files in langpacks
[16:50] <dpm> the mo files are superfluous
[16:52] <pitti> dpm: do we even need to import them into rosetta?
[16:53] <pitti> well, I guess we're using LP to translate those
[16:53] <pitti> dpm: so I guess we should blacklist them in langpack-o-matic then
[16:55] <pitti> dpm: too bad that they don't have a proper ubuntu-docs-* domain prefix
[16:55] <pitti> like that they are so utterly generic (bah namespace trampling)
[16:55] <dpm> pitti, I can change that
[16:55] <pitti> a gettext domain named "internet" or "hardware" is not nice
[16:55] <dpm> I mean, I can prepend ubuntu-docs- to the domain in LP
[16:56] <dpm> in fact, we renamed the templates not so long ago to include this
[16:57] <pitti> dpm: that would be very helpful indeed
[16:58] <dpm> pitti, let me check with mdke first, so I don't break the workflow of the docs team before changing anything...
[17:01] <dpm> mdke, ^ it seems that unnecessary .mo files are being exported for ubuntu-docs translations along with the xml files in language packs. We are talking of changing the domain name for the templates in LP, which would make it easier to blacklist those files. In principle, this should not affect the docs team, but I'm letting you know just to make sure. The only difference I can see is that the exported files would be named e.g. 'ubuntu-docs-internet.mo'
[17:01] <dpm> instead of 'internet.mo', but as you are exporting them as PO files, you wouldn't even notice
[17:03] <dpm> (the first '.mo files are being exported' should have been 'are being shipped')
[17:06] <pitti> that domain change should be done either way
[17:06] <pitti> for clean namespacing
[17:06] <doko> lamont, seb128: there is definitely progress in the openjdk-6 build on i386.
[17:07] <seb128> doko, ok, it seemed stucked for a while and as said usually build takes 7 hours not > 11 hours
[17:07] <seb128> it's annoyed that all the buildds got busy for over 10 hours at the same time
[17:07] <ogra> probably the buildd has the handbrake stuck
[17:07] <seb128> which means nothing else is building
[17:08] <seb128> and lucid has installability issues due to the timing
[17:08] <lamont> seb128: well, there are the dozen or so copies of java running from the build, but load avg is .47
[17:08] <seb128> lamont, can we get a ppa buildd to build lucid for an hour? ;-)
[17:09] <lamont> oh, uh... that could be painful
[17:09] <seb128> oh, seems the issue is solved
[17:09] <lamont> even the 1 min load on vernadsky hasn't been over 2 in the last 8 hours
[17:10] <seb128> lamont, don't bother, openoffice failed to build
[17:10] <lamont> before that, 'twas much higher
[17:10] <seb128> we have a buildd back ;-)
[17:10] <doko> yes, OOo failed to build. wonder who tested the build before upload ...
[17:15] <lamont> good thing these packages are nice and modular and all... :-(
[17:20] <kirkland> akgraner: yo
[17:21] <kirkland> akgraner: sorry, back-to-back-to-back meetings this morning
[17:21] <kirkland> akgraner: what's up?
[17:21] <kirkland> akgraner: question for you ... where are the UDS Dallas videos published?
[17:42] <Aissen> hi ubuntu-dev :-)
[17:44] <Aissen> What's happening with linux-firmware package?
[17:46] <Aissen> apparently quite a few firmwares were lost during the switch to http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git in lucid
[17:49] <kees> why is sendmail in mail, and can we please remove it?
[17:59] <apparle> how much time does it take for a package to be updated in the repos once it is released by original developer?
[17:59] <apparle> I mean when new version is released
[18:02] <Riddell> kees: on bug 503774 can you explain what you mean by "Config files (*.cfg) are all out of the local directory."?
[18:05] <kees> Riddell: I mean that the config files have no path associated with them when they're opened.  it's literally open("whatever.cfg"), so the current directory needs to be well-controlled by whatever launches it.
[18:14] <sladen> apparle: versions of software in already-released versions of Ubuntu do not generally get updated.... it can take 1 day - 6 months for newer software releases to get into an upcoming Ubuntu release---what is the software that you're interested in?
[18:14] <apparle> sladen: I am interested in eagle...
[18:23] <jcastro> kirkland: http://ubuntudevelopers.blip.tv/posts?view=archive&nsfw=dc
[18:23] <Riddell> kees: nepomuk always starts it with config in /tmp/ presumably that isn't good enough?
[18:25] <kees> Riddell: ew, no, there are some mildly sensitive config settings (like the "allow system() call")
[18:26] <Riddell> kees: so nepomuk should be changed to put the config file in ~ ?
[18:26] <jelkner> with whom does one talk to get an irc channel auto logged to http://irclogs.ubuntu.com?
[18:27] <jelkner> specifically, #ubuntu-sugarteam
[18:27] <Riddell> jussi01 ^^
[18:27] <tsimpson> jelkner: rt@ubuntu.com (/whois ubuntulog)
[18:28] <jelkner> tsimpson, thanks!
[18:28] <maco> jelkner: we have a new channel! #ubuntu-us-dc
[18:28] <micahg> pitti: for thunderbird-locales, what do we do with the locales that didn't have new upstream .xpis?
[18:29] <jelkner> maco, cool
[18:29] <jelkner> maco, is rt@ubuntu.com person or machine?
[18:29] <maco> email address
[18:29] <jpds> jelkner: Neither.
[18:29] <jelkner> lol
[18:29] <maco> it posts a ticket to RT which is the ticket tracker
[18:29] <kees> Riddell: yeah, I'd recommend something like ~/.cache/nepomuk/ or something
[18:29] <jelkner> ok, but i write to her/him in English
[18:29] <jelkner> not some formal language
[18:30] <jpds> jelkner: Plain English is fine.
[18:30] <jelkner> cool
[18:30] <jelkner> i can do that ;-)
[18:30] <maco> jelkner: it's like posting a bug in launchpad via email
[18:43] <Caesar> slangasek: is it fair to say that lucid is going to have eglibc 2.11.1, or is it still in a state of flux?
[18:59] <kirkland> jcastro: hmm, i was specifically looking for the interview I did with akgraner, which isn't there
[19:00] <bryceh> jdstrand, got your bug
[19:00] <bryceh> jdstrand, looks to me like it's a fault deep down in the kernel drm memory code.
[19:01] <jdstrand> bryceh: I am highly motivated to get this fixed (as is mdeslaur). I've got users that will be affected by this (besides my primary laptop) when upgrading to lucid
[19:02] <bryceh> jdstrand, I've added the kernel team to the bug.  I also re-sent the bug upstream to the radeon folks (the bug had been linked to a -nouveau bug, but I don't think the nouveau bugs are looked at very well)
[19:02] <jdstrand> bryceh: I can do whatever to try to work on it, as well as bring it to the sprint next week
[19:02] <jdstrand> bryceh: if that would be helpful
[19:03] <mdeslaur> I can prepare bribes
[19:03] <jdstrand> bryceh: on of those users is my wife-- if she hits this, my productivity will seriously decrease :P
[19:03] <bryceh> jdstrand, mdeslaur, heh well it looks like it's pretty far outside my area of grokkage
[19:04] <bryceh> jdstrand, mdeslaur, I can suggest workarounds, but kernel coding is a bit beyond me :-)
[19:05] <bryceh> jdstrand, mdeslaur, for workarounds, I'd suggest turning off KMS
[19:05] <bryceh> if that doesn't do it, there are some video parameters you can set in xorg.conf, although I doubt they'd have much effect in this case.  Easy enough to test though.
[19:05] <superm1> bryceh, does "safe graphics mode" turn off KMS right now on lucid live media?
[19:06] <mdeslaur> I wonder if disabling compiz would help
[19:06] <bryceh> jdstrand, mdeslaur, also not sure if you re-tested today but I updated -ati to a new version yesterday.  Since I suspect this is a kernel drm issue it probably won't help, but likely can't hurt to try it
[19:06] <jdstrand> bryceh: I tried some xorg.conf hacks over the break, but I still had KMS on
[19:06] <bryceh> mdeslaur, jdstrand, right I was going to mention #3 to shut off compiz
[19:07] <mdeslaur> bryceh: I can't find how to disable kms in the debugging wiki...
[19:07] <bryceh> superm1, pretty  sure it doesn't
[19:07] <jdstrand> bryceh: how does one disable kms?
[19:07] <bryceh> I should fix that
[19:07] <bryceh> jdstrand, mdeslaur, there's a couple ways to do it - see https://wiki.ubuntu.com/X/KernelModeSetting
[19:08] <jdstrand> mdeslaur: you are on up to date lucid, right?
[19:08] <mdeslaur> jdstrand: yes
[19:08] <bryceh> basically you want "radeon.modeset=0" as a kernel parameter
[19:09] <mdeslaur> ok, trying now
[19:09] <bryceh> if that works, sticking it in /etc/initramfs-tools/modules will be a good way to make it permanent
[19:09] <bryceh> syntax is different there though.  "radeon modeset=0"
[19:10] <mdeslaur> so, turning off kms worked. It's not even using compiz in my case.
[19:10]  * bryceh nods
[19:10] <bryceh> I sort of wonder if we should just blacklist your hardware from using kms entirely
[19:11] <mdeslaur> bryceh: that's what I was about to suggest
[19:11] <mdeslaur> at least until upstream does something
[19:11] <jdstrand> bryceh: with a couple of xorg.conf tweaks, 3d worked well on jaunty
[19:11] <bryceh> mdeslaur, jdstrand, ok so for that we need apw
[19:11] <bryceh> jdstrand, right that was pre-KMS
[19:12] <bryceh> jdstrand, probably worked ok on karmic too
[19:12] <apw> bryceh, bring that to the sprint ... the problem ... i want a round table on graphics with you anyhow
[19:12] <jdstrand> bryceh: without KMS, I login but I get horrible screen garbling (compiz is enabled)
[19:13] <bryceh> mdeslaur, jdstrand, ok you heard it from the man - bring your laptops to the sprint and apw and I will puzzle over them
[19:13] <jdstrand> apw, bryceh: by 'bring that' would actual affected hardware that I can let you use during the sprint be helpful?
[19:13] <apw> if its not going to get you in trouble with the airlines and break your back perhaps yes
[19:14] <apw> but more the issue at hand so we cna discuss solutions
[19:14] <jdstrand> bryceh, apw: that is great! I've been quite worried that this would be a serious regression for all those radeon 7500 users out there (being so popular in laptops from a few years ago)
[19:14] <mdeslaur> I can't bring my T30, jdstrand, will you be bringing yours?
[19:15] <bryceh> well the general issue of "kms fails on old hardware" is an important one we should at least understand and have a plan for
[19:15] <bryceh> er "old ati hardware"
[19:15] <jdstrand> mdeslaur: yeah. I'll bring it and my mini 9 so people can fiddle with mine without me
[19:15] <bryceh> jdstrand, your system works ok with both kms and compiz disabled?
[19:16] <jdstrand> bryceh: I'll disable compiz and see
[19:17] <apw> yeah if you are considering bringing extra h/w do coordinate with someone (bryceh?) so we only get one of each
[19:17] <jdstrand> bryceh: it seems to in general, but notifications are a solid black box
[19:17] <bryceh> jdstrand, with the corruption bug, take a photo or two of the screen, then ssh into it and do 'ubuntu-bug xserver-xorg-video-ati', reboot, file the bug in LP, and subscribe me to it, and I'll make sure it gets processed and upstream.
[19:18] <bryceh> jdstrand, ok good
[19:18] <superm1> bryceh, if you do get it so it's turned off in safe graphics mode, don't forget that you also need to find a way to make sure that kernel command line option gets populated over to the installed system too
[19:18] <superm1> probably via a casper ubiquity hook
[19:18] <bryceh> jdstrand, re:notifications - that might not be a driver issue, but check with mirco
[19:18] <jdstrand> bryceh: with kms and compiz, notifications were almost correct, but not quite: http://people.canonical.com/~jamie/notify-osd.png
[19:19] <bryceh> superm1, ok noted.  I probably won't get a chance to look into it until after the sprint, but it's in my gtg todo file
[19:19] <apw> jdstrand, whats wrong with it?
[19:19] <jdstrand> apw: which it? the notification?
[19:19] <apw> yeah
[19:20] <jdstrand> apw: did you see the png? the green bar and the orange lines. that doesn't happen on my desktop
[19:20] <apw> isn't that normal at this stage of the release.  that it always shows those, they are debug arn't they?
[19:21] <jdstrand> oh, is it? I only have lucid on that machine
[19:21] <jdstrand> forgive me if that is normal for lucid at this point
[19:22]  * apw checks
[19:24] <bryceh> jdstrand, yeah I see the same thing on a couple of my boxes
[19:24] <apw> i think it may have recently changed too, as in turned off
[19:25] <bryceh> jdstrand, didn't bother to file a report but I assume it to be a notifications-specific bug rather than a driver issue
[19:25] <bryceh> kind of looks like a cellpadding goof
[19:26] <jdstrand> I've seen it for 4-6 weeks or so (ie, when I upgraded to lucid)
[19:27] <apw> i seem to remember it was something they do in the alphas so you can see the underlying data from the client and stuff and check things are placed right
[19:27] <apw> and then they hide it again
[19:29] <jdstrand> bryceh: is the notifications as a black box with no kms and no compiz a known bug?
[19:30] <chrisccoulson> jdstrand / apw, during the early phase of the cycle, notify-osd is run in debug mode, which is what is shown in the png
[19:30] <jdstrand> ah, ok
[19:30] <jdstrand> chrisccoulson: thanks
[19:30] <chrisccoulson> but debug was turned back off again a couple of weeks ago, so you shouldn't see it anymore
[19:30] <apw> yeah i see its changed back on my lucid box
[19:36] <bryceh> jdstrand, it's not one I've heard before
[19:36] <jdstrand> bryceh: ok I'll file a bug then
[19:37] <bryceh> jdstrand, I do know that notifications work differently with compiz than without though.
[19:37] <jdstrand> bryceh: I tried enabling compiz again, to show the garbledness and file a bug as you requested, and X locked up. I can ssh and have not logged out. shall I ubuntu-bug it from ssh?
[19:38] <bryceh> yep
[19:44] <pitti> micahg: drop them?
[19:47] <jdstrand> bryceh: crash filed as bug #513950
[19:51] <micahg> pitti: yeah, that's what I did (i.e. they're not in the control file), but do I need to do anything else?
[19:51] <pitti> micahg: they will appear in NBS and be removed, so I don't think so
[19:51] <micahg> so the users with those locales that upgrade have the old packages removed?
[19:54] <pitti> micahg: usually these should have strict dependencies to a compatible version
[19:54] <pitti> so they should conflict to never tbirds which doesn't support their format any more
[19:54] <micahg> pitti: yep, they do, so that'll remove it then and I don't have to worry?
[19:59] <jdstrand> bryceh: garbling filed as bug #513956
[19:59] <Caesar> Is there a way to link to an upstream bug, when upstream is SourceForge?
[19:59] <pitti> micahg: that, or hold it back
[19:59] <micahg> pitti: hold back the release until they all catch up?
[19:59] <pitti> micahg: hm, ISTR that in ancient times I added some "obsolete-packages" list there, which would generate empty transitional packages for the dropped locales
[19:59] <pitti> (until the next LTS)
[20:00] <pitti> micahg: no, hold back the thunderbird upgrade
[20:00] <micahg> pitti: asac remembers something similar, but I don't see it...maybe I should pull the hardy package?
[20:02] <pitti> micahg: hm, maybe that was never done for tbird-locales, only for firefox-locales
[20:02] <qense> pitti: bug 509283 was reported 10 days ago and has got the need-amd64-retrace tag but Apport still hasn't left a comment. Is CoreDump.gz broken?
[20:03] <pitti> DistroRelease: Ubuntu 9.04
[20:03] <pitti> sorry, no retracer right now for Jaunty
[20:03] <pitti> micahg: yep, that was it; hardy's mozilla-firefox-locale-all, debian/unavail.txt
[20:04] <pitti> micahg: debian/rules has a snippet which builds control snippets from debian/templates/unavail.template
[20:04] <pitti> micahg: perhaps just copy that to tbird-locales?
[20:04] <micahg> pitti: should I add that to thunderbird-locales, we're going to update to 3.0.1 shortly after 3.0, but asac wants to get 3.0 as is into archive first
[20:04] <micahg> and I think 3.0.1 picked up the locales, but not sure
[20:06] <qense> pitti: Does that mean no Jaunty retracer for the first few months, or will there never be one anymore?
[20:06] <pitti> micahg: with unavail.txt you keep teh package installed, so as soon as it's available again it'll come back
[20:06] <micahg> pitti: k, I'll add that then, thanks
[20:06] <pitti> qense: well, they aren't really that interesting any more
[20:07] <qense> ok, shall I close the bug then?
[20:07] <pitti> qense: and it's quite some maintenance
[20:07] <qense> pitti: I understand, thanks for your time!
[20:07] <pitti> qense: unless it already has something useful in it, sure
[20:07] <qense> ok!
[20:07] <pitti> this doesn't look very precious/interesting, though
[20:08] <qense> no
[20:12] <jdstrand> bryceh: I filed bug #513968 against notify-osd for the unreadable black box notifications with both KMS and compiz disabled. Do you want me to subscribe you to that one?
[20:12] <bryceh> jdstrand, no, not unless it's determined to be an X issue
[20:12] <jdstrand> k
[20:14] <jdstrand> bryceh: as you've probably already seen, I did subscribe you to the other two
[20:14] <jdstrand> bryceh: you aren't subscribed to
[20:14] <jdstrand> bryceh: bug #507148-- is that intended or no?
[20:15] <bryceh> jdstrand, I'm subbed on the upstream bug so will see when they reply
[20:15] <jdstrand> cool
[20:15]  * jdstrand stops bugging bryceh for now
[20:15] <bryceh> jdstrand, you can sub me to the lp one; I've got it noted in gtg so I'll follow up next week
[20:16] <jdstrand> bryceh: thanks for helping with this! :)
[20:16] <bryceh> jdstrand, yep, glad you at least got a working system again.  Hope the underlying issue can get sorted.
[20:18] <jdstrand> bryceh: me too-- I've got several radeon 7500 users that will be disappointed otherwise
[20:28] <jdstrand> bryceh: well, I lied. Seems I'm having display problems with no KMS and no compiz. Can you look at http://people.canonical.com/~jamie/ooo-display-problem.png?
[20:30] <jdstrand> bryceh: the rectangle around 'Default' shouldn't look like that-- at first it doesn't, but if I move another app window over it, then click oo.o to bring it to the foreground, I got that.
[20:35] <bryceh> jdstrand, that looks sort of familiar.
[20:37] <bryceh> jdstrand, I'm not going to worry about it since it's just a cosmetic issue and I've got many bigger fish to fry, but you might look through the Low priority -ati bug reports as there's several artifact/corruption bugs for older ati cards there
[20:37] <jdstrand> k
[20:38] <jdstrand> bryceh: thanks again, I really will stop bugging you now :)
[20:43] <Riddell> bug 503774 updated, let me know if anything else is needed
[20:43] <Riddell> kees ^^
[20:54] <mdke> pitti: don't see any issue with what dpm proposed - we don't create or use .mo files in ubuntu-docs
[20:54] <pitti> mdke: ah, good to know
[20:54] <pitti> mdke: so we can prefix the domains, and then blacklist them from the langpacks
[20:55] <mdke> pitti: will the po files exported from LP also be changed?
[20:55] <mdke> I guess they will have the usual cc.po format?
[20:55] <pitti> mdke: don't think so; just their name might change
[20:55] <pitti> they are usually prefixed with the domain, aren't they?
[20:56] <pitti> the last export that I got contained files like apport_de.po
[20:56] <mdke> I can't remember, but yes - I think so
[20:56] <mdke> the templates are already prefixed I believe
[20:56] <mdke> anyway, we can work around whatever happens
[20:57] <mdke> pitti: got to log out for now but happy to follow up by email if necessary
[20:57] <pitti> likewise, /me -> off for the night
[20:58] <mdke> bon nuit
[20:58] <pitti> mdke: thanks, and good night!
[21:38] <slangasek> mathiaz: 513749> best practice is to not install the daemon if you're not using it, yes; second option is to turn start links in /etc/rc.? into stop links; some packages provide /etc/default/foo, but that's horrible; worst case is to remove all the links from /etc/rc.? and expect them to stay that way
[21:40] <seb128> hey slangasek, you can upload your gnome-sharp2 merge if you want the new mono version is in lucid
[21:40] <seb128> slangasek, I expect you were waiting on that one to upload?
[21:41] <slangasek> mathiaz: as for 513135, I think that's a bug in the logrotate script
[21:41] <slangasek> seb128: ah, how did you get the new mono in?  I was getting oopses from LP trying to sync it
[21:42] <seb128> slangasek, I deleted the new lines chars in the binaries list in the .changes
[21:42] <slangasek> ah
[21:42] <seb128> slangasek, that's a known soyuz bug
[21:42] <slangasek> bug #?
[21:43] <seb128> slangasek, launchpad bug #435315
[21:43] <slangasek> ta
[21:43] <seb128> ups that's the duplicate
[21:43] <seb128> in any case you get the other bug number there too ;-)
[21:44] <slangasek> Caesar: I'm not expecting any further bumps to eglibc in lucid
[21:56] <Caesar> slangasek: ok thanks
[21:56] <Caesar> slangasek: there's also the case of pam and that upstream bug in pam_access
[21:57] <Caesar> I've just filed a bug in launchpad for it
[21:57] <slangasek> yeah, saw :)
[21:57] <Caesar> I can provide a patch with a backport of the fix if that is the desired outcome
[21:57] <slangasek> I'll follow through next week
[21:57] <Caesar> Cool thanks
[21:57] <Caesar> We're just starting to ramp up on Lucid stuff now
[21:57]  * slangasek nods
[21:57] <Caesar> Had a bit of a distraction
[22:17] <mathiaz> kees: jdstrand: mdeslaur: does it make sense to demote openssl-blacklist and openvpn-blacklist to universe?
[22:18] <kees> mathiaz: they're Suggests from openssl already, but I don't see any reason to move them around.  is it causing a problem in main?
[22:18] <kees> mathiaz: and do you know why sendmail is in main?
[22:19] <mathiaz> kees: because of the extra seed
[22:19] <mathiaz> kees: I don't see it as problem in main - we dropped openssh-blacklist to universe
[22:20] <mathiaz> kees: may be I extrapolated and though openssl-blacklist *and* openvpn-blacklist should also be demoted
[22:20] <mdeslaur> hmmm...I'm not sure I like that very much
[22:20] <mathiaz> kees: if not I'm happy to keep them in main
[22:20] <mathiaz> mdeslaur: that = ?
[22:20] <mdeslaur> if, in the future, we need to add keys to that
[22:20] <kees> mathiaz: we should keep the blacklists in main (all of them)
[22:21] <mdeslaur> then we'll ask that people install stuff from universe
[22:21] <kees> mathiaz: how do I remove sendmail from main?
[22:21] <mdeslaur> if they don't have the universe repo enabled...
[22:21] <mdeslaur> it gets _real_ complicated _real_ quick if we need to use them again for new blacklisted keys
[22:22] <mdeslaur> I don't see why they need to be demoted...it's not like anyone's wasting time updating them or anything
[22:22] <mathiaz> kees: ah ok - we can keep them in main
[22:22] <mathiaz> kees: I may have misinterpretaded the thread then
[22:22] <mathiaz> kees: I'll add openssh-blacklist back into main
[22:22] <kees> mathiaz: what caused sendmail to be in extras?
[22:22] <kees> mathiaz: cool
[22:22] <mathiaz> kees: it's in an extra seed somewhere
[22:23] <mdeslaur> thanks mathiaz
[22:23] <mathiaz> kees: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/ <- complete list of dependency for each package
[22:23] <mathiaz> kees: in main
[22:23] <kees> wheee
[22:23] <mathiaz> kees: and then you may also need to check the other *.lucid/rdepends/
[22:24] <mathiaz> kees: I usually grep on people.canonical.com
[22:24] <kees> mathiaz: okay
[22:33] <mathiaz> kees: ok - so open{ssl,ssh}-blacklist-extra were shipped on the -server iso
[22:33] <mathiaz> kees: should these be brought back on there - on seeding them in main is enough
[22:33] <mathiaz> kees: I guess the question is wether they should be installed by default on a server install
[22:42] <kees> mathiaz: if there is room on the CD, put them on the CD.  :)
[22:42] <mathiaz> kees: hmmm
[22:51] <mathiaz> kees: have you found where the Extra seed is?
[22:52] <seb128> slangasek, if,when you upload gnome-sharp2 could you new the binaries to main too, quite some things depwait on those
[22:52] <cjwatson> extra is synthesised
[22:52] <seb128> slangasek, thanks ;-)
[22:52] <cjwatson> it consists of those binary packages that are produced by source packages that are in main, but binaries that are not themselves otherwise seeded
[22:52] <cjwatson> so if libfoo is in main, then libfoo-utils might end up in extra if it's not seeded
[22:52] <slangasek> seb128: can do
[22:53] <mathiaz> cjwatson: ok - I'm looking at elinks
[22:53] <mathiaz> cjwatson: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/elinks/elinks
[22:53] <mathiaz> cjwatson: according to http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, elinks is a binary only demotions
[22:53] <mathiaz> cjwatson: what should be done to kick the source out of main as well?
[22:53] <cjwatson> mathiaz: elinks-lite is in the same source and is seeded: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/elinks/elinks-lite
[22:54] <cjwatson> or not seeded directly but build-depended-on
[22:54] <mathiaz> cjwatson: ahhh
[22:54] <cjwatson> (I just went up a level and looked through each file in turn until I found something interesting)
[22:54] <Caesar> Is rmadison being busted a known issue?
[22:55] <mathiaz> cjwatson: thanks - I'll investigate more then
[22:56] <cjwatson> Caesar: busted how?  it seems to work for me
[22:57] <Caesar> Hmm, it's been timing out for days
[22:57] <Caesar> (for me)
[22:57] <Caesar> I eventually get back a 503
[22:57] <Caesar> From people.ubuntu.com
[22:57] <Caesar> Let me try from home
[22:57] <Caesar> Interesting, it works there
[22:58] <Caesar> Have we gotten ourselves blacklisted?
[22:59] <Caesar> Actually that was Debian
[22:59] <cjwatson> Caesar: version of devscripts?
[23:00] <Caesar> 2.10.39ubuntu2
[23:00] <cjwatson> thought so
[23:00] <Caesar> URL changed?
[23:00] <cjwatson> you need 2.10.48ubuntu2 or better
[23:00] <Caesar> Doh
[23:00] <cjwatson> but if that's tedious, then rmadison -u http://people.canonical.com/~ubuntu-archive/madison.cgi
[23:01] <Caesar> Couldn't put in a redirect, eh?
[23:01] <cjwatson> we did
[23:01] <cjwatson> it broke with the people.ubuntu.com -> people.canonical.com move that was to make way for people.ubuntu.com being an SFTP thing open to Ubuntu members
[23:01] <cjwatson> unfortunately:
[23:01] <cjwatson>   * Update rmadison's Ubuntu URL to cope with people.ubuntu.com ->
[23:01] <cjwatson>     people.canonical.com; invoke curl in such a way as to follow redirects
[23:01] <cjwatson>     by default (LP: #399891).
[23:01] <Caesar> hah
[23:01] <Caesar> Oh well
[23:02] <cjwatson> you can just edit your local rmadison if that's convenient
[23:02] <Caesar> Yeah
[23:03] <Caesar> Profit!
[23:03] <Caesar> Thanks
[23:03] <Caesar> I must have missed the memo
[23:03] <geser> do packages from a source in main but which are currently in universe a MIR to get moved to main? libmono-cil-dev depends on several packages in universe (but build from mono)
[23:04] <slangasek> geser: no
[23:04] <geser> a bug? or do I just ask an archive admin politely?
[23:06] <slangasek> geser: it's part of the daily archive admin duties to reconcile these things; if no one else gets to it I can have a look, but not until after I finish pushing 8.04.4 out the door
[23:06] <cjwatson> geser: I'll look
[23:06] <seb128> geser, which ones?
[23:06] <seb128> geser, I did try to new things to main but I might have overlooked one
[23:07] <cjwatson> gosh, what a lot of binary promotions
[23:07] <cjwatson> seb128: I'm on it
[23:07] <seb128> cjwatson, ok thanks
[23:07] <seb128> things will fail untill slangasek upload gnome-sharp2 anyway
[23:07] <geser> seb128: the list is longer: sudo apt-get --print-uris install libmono-cil-dev | grep universe
[23:07] <seb128> new binaries from it are required for most of the mono updates
[23:08] <cjwatson> it's done
[23:08] <geser> thanks
[23:08] <seb128> cjwatson, thank you