[01:25] <thiblahute> Hi, I am trying to make ubuntuone working since I upgraded like 1 month ago, but impossible. Here is the status, it is always like it  http://pastebin.com/utw1pewf
[01:26] <jpds> thiblahute: Try: #ubuntuone
[01:26] <thiblahute> jpds: Thanks will go see there!
[02:28] <crypt-0> is Lucid stable enough to build packages on?
[02:29] <lifeless> crypt-0: I'd surely hope so:)
[02:30] <psusi> that's like asking if air is safe to breathe... if it weren't you wouldn't be there to ask the question ;)
[02:33] <crypt-0> what i meant is am i likely to encounter any bugs that i wouldn't with lets say 9.10 while making a package
[02:34] <RAOF> Lucid has been *extensively* tested for building packages on :)
[02:36] <jdong> lol that's probably its most tested usecase ;-)
[02:36] <crypt-0> and the wiki for creating them?
[02:36] <jdong> and for me, apport's report dialog is very extensively tested too *grumble grumble grumble* ;-)
[02:37] <crypt-0> and can u just use diff to make the patch?
[02:51] <GrueMaster> crimsun: around?  Any new ideas on bug 528524?
[02:53] <crypt-0> since lucid is in a freeze will it make much difference oh how soon i get my package in?
[02:54] <crypt-0> IIRC using release candidate cryptography software that is in the *main* reops and is the core package for disk encryption is a bad idea
[03:39] <psusi> wow.... adding the largefile4 profile to ext4 on mke2fs to reduce the number of inodes on a 1.5 tb drive added almost 22 gb of usable space that otherwise would have been consumed by inodes
[03:40] <psusi> ( and would have to be written to during mkfs without lazy_itable_init )
[03:43] <psusi> say, didn't we used to have apps on the system menu by default to manage the gnome keyring, and to configure remote vnc access?  what happened to those?
[06:07] <micahg> directhex: around?
[06:26] <twb> What does the BC in XSBC-Original-Maintainer stand for?
[06:26] <ebroder> XSBC refers to where to put the field. S means .dsc, B means .deb, C means .changes
[06:27] <twb> Ooooh.
[06:27] <ebroder> Err, well, let me start over. The "X-" means "dpkg, you don't know about this field, but don't barf and deal with it anyway"
[06:27] <twb> (I'd only ever seen the old XS-VCS-* before it lots the XS)
[06:27] <ScottK> S = Source and B = Binary.
[06:27] <twb> The X- is obviously an RFC822 convention.
[06:27] <ebroder> For fields dpkg knows about, it also knows where to put them, but for fields it doesn't know about, you have to tell it
[06:47] <pitti> Good morning
[06:47] <pitti> slangasek: no, I'll sync it from Debian
[06:49] <pitti> oh, we are still frozen?
[06:57] <RAOF> Argh.  Whoops!  Could I have an archive admin sync gnome-keyring-sharp for me?  Bug #557038
[07:00] <ScottK> pitti: We are, but slangasek told seb128 he could go ahead with syns.
[07:00] <ScottK> syns/syncs
[07:00] <pitti> ah, great; then I'll do a few, thanks
[07:01] <ScottK> He said there were some things in the queue he still wanted to look at.
[07:03] <ScottK> pitti: It'd be great if you could do Bug 558933 as one of them.  It'll help with NBS and it needs binary New and then another sync after ...
[07:03] <ebroder> pitti: If you're already doing syncs, could you look at bug #555620? :)
[07:04] <ScottK> ebroder: That one isn't approved yet.
[07:04] <ScottK> He's doing the syncing, not reviewing candidates.
[07:16] <dholbach> good morning
[07:22] <damascene> hello, I've sent a message to ubuntu-devel-discussion but got spam problem
[07:22] <pitti> ScottK: done
[07:22] <damascene> https://wiki.ubuntu.com/Mlterm
[07:22] <damascene> the link is about the subject
[07:23] <damascene>  pitti , I've been told you can help, message title was Mlterm installed with RTL languages
[07:23] <damascene> may you help me?
[07:33] <pitti> damascene: I have no idea about either of those, I'm afraid
[07:33] <damascene> pitti, you can't help with the mail list nor with mlterm install for rtl languages?
[07:44] <pitti> damascene: what's with the ML? what did you try to do?
[07:46] <pitti> damascene: are you subscribed to ubuntu-devel-discussion?
[07:46] <pitti> damascene: otherwise you can't send there
[07:46]  * pitti -> doctor appointment, bbl
[08:12] <dholbach> can everybody have a quick look at http://qa.ubuntu.com/reports/sponsoring/ and see if there's stuff that should still be going in? I get the feeling there's still a bunch of important fixes on there
[08:26] <directhex> micahg, i am now
[08:27] <micahg> directhex: I was about to sign off, but I fixed the using xul 1.9.3. issue and now I get the same results as you that it crashes before launching
[08:28] <micahg> directhex: I was wondering if there's an easy way to add all the dbg symbols for it as the backtraces are mostly ??
[08:28] <lifeless> apport-retrace can do that for you, I think
[08:29] <directhex> is it a managed or unmanaged crash?
[08:30] <micahg> lifeless: apport's not catching this
[08:30] <micahg> directhex: when I launch ./foo.exe it shows me  a backtrace and crashes
[08:30] <directhex> can i see the output? sounds unmanaged, so a ddeb would do the job
[08:32] <micahg> directhex: http://pastebin.com/e3vk3vsj
[08:33] <directhex> actually, i have an idea
[08:36] <directhex> hm, trying to grab upstream, she's usually awake by now
[08:36]  * micahg is normally asleep by now :)
[08:38] <joaopinto> mvo, I am getting the wrong message on update manager during partial upgrades, on my translation, is it likely to be a translation error, or there could be something else picking the wrong string ?
[08:38] <joaopinto> When it should display "Downloading packages" it shows "Error while downloading packages", this in portuguese
[08:39] <mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:128
[08:39] <mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:141
[08:39] <mvo> #: ../UpdateManager/DistUpgradeFetcherKDE.py:143
[08:39] <mvo> msgid "Downloading additional package files..."
[08:39] <mvo> msgstr "A descarregar pacotes adicionais..."
[08:39] <mvo> is what i have here
[08:40] <joaopinto> that is now what is shown
[08:40] <mvo> joaopinto: if that is incorrect it needs to be fixed in rosetta
[08:40] <joaopinto> that one is correct, but that is not what I am getting
[08:40] <mvo> what is the (translated) message you see?
[08:41] <directhex> micahg, well, until miguel notices & shouts, she runs ubuntu with a suse theme anyway, so if you can throw your patch somewhere i can ask her to take a look
[08:41] <joaopinto> "Erro ao transferir os novos pacotes"
[08:41] <mvo> msgid "Getting new packages"
[08:41] <mvo> msgstr "Erro ao transferir novos pacotes"
[08:41] <joaopinto> ouch :P
[08:41] <mvo> that does not look right
[08:42] <mvo> :)
[08:42] <sgnb> can someone here confirm my diagnostic of https://bugs.launchpad.net/ubuntu/+source/ocamlnet/+bug/257524 ?
[08:42] <micahg> directhex: I think all I did was modify the GRE...I'd like to know where it crashes so I can start patching :)
[08:42] <mvo> joaopinto: do you have the needed privs/group memberships to fix it in rosetta? or will we need a bug against language-pack-pt ?
[08:43] <joaopinto> I don't deal with translations, I will file a bug, a just hope it lands in time, this bug has been visible for months so I guess there isn't much activity on the pt translation team
[08:43] <joaopinto> unless they did like me and forgot to report it :P
[08:43] <mvo> what is the correct translation?
[08:44] <joaopinto> "Transferindo novos pacotes"
[08:45] <joaopinto> hum, maybe I should check other strings, "Obtendo" instead of "Transferindo" would be a better verb
[08:45] <joaopinto> can you show me some other "get package" string ?
[08:45] <mvo> https://translations.edge.launchpad.net/ubuntu/lucid/+source/update-manager/+pots/update-manager/pt/+translate?batch=10&show=all&search=Getting+
[08:45] <mvo> sure :)
[08:45] <mvo> see above
[08:45] <micahg> directhex: I have to head to sleep, will you be available in 6-7 hours?
[08:45] <directhex> micahg, yes
[08:46] <mvo> joaopinto: noce you have the bugnumber, please let me know and I target it to lucid
[08:47] <hunger> My netbook edition box started to "flicker" after rebooting today (last upgrade yesterday). Looks like some window is covering the whole screen, gets killed, starts again, ... after logging in. Is that a known issue or did I break something myself yesterday? It did not do this yesterday evening.
[08:48] <hunger> Must be something in the startup scripts... Maximus is not there, the ubuntu logo does not trigger the app start view and Alt-F2 does not work either:-(
[08:49] <joaopinto> mvo, done, bug 559018
[08:51] <mvo> thanks joaopinto
[08:51] <joaopinto> I am going to send a mail to the ubuntu pt ml, there should be someone from translation there
[08:53] <slangasek> mvo: what's the status of bug #552542?  was that fixed for beta-2?
[08:56] <seb128> slangasek, hey, do you review each uploaded queue during the freeze before accepting those?
[08:59] <mvo> slangasek: fixed with subject: [ubuntu/lucid] translations_main_20100408.tar.gz - (Accepted)
[08:59] <mvo> slangasek: so it should be in the archive and fixed now, I updated the bug
[08:59] <slangasek> seb128: at least briefly; some people have been uploading packages to the queue assuming that FFe review will happen there, which is not what's *supposed* to be done, but better to spot these than to leave people thinking there was an FFe when there wasn't
[08:59] <slangasek> mvo: great, thanks
[09:00] <seb128> slangasek, is there anything we can do to avoid having things landing on tonight and break while everybody is away like it happened for beta1?
[09:01] <slangasek> seb128: the queue isn't frozen now
[09:01] <seb128> ok, I note for next time to not upload during freezes but queue locally and upload after
[09:01] <seb128> thanks
[09:02] <mvo> seb128: was a new gnome uploaded during the freeze? I assume it is, I get some upgrade calculcation errors that look transient to me
[09:03] <seb128> mvo, not a new GNOME but quite some updates yes
[09:03] <seb128> I was counting on the queue to be flushed after beta2 yesterday so things could build overnight and be tested today
[09:03] <seb128> but instead seems queue is slowly reviewed and things will land again in time to break when everybody is in weekend
[09:03] <seb128> *shrug*
[09:04] <seb128> sorry for the rant, it's pretty annoying
[09:04] <seb128> mvo, you shouldn't have too many errors, at least on i386
[09:04] <mvo> seb128: its a bit unfortunate indeed. I will just wait a bit and see if the upgrader is more happy in ~2h or so
[09:04] <mvo> seb128: heh :) one error is enough ;)
[09:04] <seb128> mvo, other archs might hit arch all,any mismatch in gtk
[09:05] <mvo> seb128: maybe its something new, I just don't want to start debugging to figure out its transient
[09:05] <seb128> mvo, ok, so wait a few hours and try again before looking at the issue
[09:06] <mvo> thanks seb128
[09:12] <seb128> pitti, btw did you raise the unfreeze time and beta1 breakage at r-t meeting for discussion?
[09:12] <seb128> pitti, we mentioned it early next week but I didn't follow up on that
[09:12] <pitti> seb128: we discussed it during the meeting, but the "postpone thawing to Monday" strawman didn't find much agreement
[09:13] <seb128> can you raise it again today?
[09:13] <seb128> cf backlog there
[09:13] <pitti> since it would just lead to more jamming
[09:13] <seb128> this over half a day delay for nothing put us in the same situation
[09:13] <pitti> seb128: but this time we thawed much earlier
[09:13] <seb128> can we work on a way to avoid that?
[09:13] <seb128> pitti, well, ideally we would have flushed the queue and would be testing things today
[09:14] <seb128> pitti, but half of things are still blocked for no visible reason and time they are built will lead to after end of week...
[09:14] <pitti> seb128: slangasek still wanted to look at some things in the queue; but I accepted some "obvious" ones, and I'll do some further cleanup
[09:14] <seb128> bah
[09:15] <seb128> pitti, thanks, still it puts us half a day later with build which should have happened over night and updates be tested now...
[09:15] <pitti> right :/
[09:15] <seb128> pitti, I just note to not upload during freezes again
[09:15] <seb128> I will queue locally and upload when we unfreeze from now on
[09:15] <seb128> so at least things go through when they should
[09:16]  * hunger mumbles that the opensync-syncml plugin is not installable on lucid.
[09:16] <seb128> I still would like to see the issue raised during the meeting today
[09:16] <seb128> pitti, ^
[09:16] <pitti> seb128: ok, can do
[09:16] <seb128> thanks
[10:02] <slangasek> pitti: this system-config-printer looks to me like it's missing an FFe; could you follow up on this with tkamppeter today?
[10:02] <pitti> slangasek: we discussed that yesterday
[10:02] <slangasek> pitti: ah, so it had an off-line FFe? :)
[10:02] <pitti> slangasek: so although our current package says 1.1.17+, it's actually 1.2.0~git...
[10:03] <pitti> slangasek: (git pull from wrong branch)
[10:03] <slangasek> yeah, read the bug report
[10:03] <pitti> slangasek: so I asked him in which direction the delta was smaller, towards 1.2.0 final or back to 1.1.17
[10:03] <pitti> slangasek: I didn't give a blanket FFE, no
[10:04] <pitti> but I'm happy to review the pacakge and see whether there's new features or UI changes, or just bug fixes
[10:04] <slangasek> ok, thanks
[10:04] <slangasek> aside from that one, the queue is now flushed
[10:04] <seb128> slangasek, thanks
[10:04]  * wgrant prepares to wake up to a broken world tomorrow morning :P
[10:08] <pitti> slangasek: I went through the diff, it's not actually that big; couple of bug fixes and translation updates; the only thing that can be regarded as UIF/FF is bug 542975
[10:08] <pitti> slangasek: (i. e. changing the printer test page to the Ubuntu one)
[10:09] <pitti> slangasek: if that's alright with you (fine for me), I'll accept it
[10:10] <slangasek> pitti: yes, go ahead
[10:10] <sebner> pitti: regarding your poll about syncing from testing was right. I'm curious how many syncs after DIF were processed and how many of them were from unstable :)
[10:10] <slangasek> if the docs team is putting photos of the printer test page in their docs, they have too much time on their hands ;)
[10:10] <pitti> heh
[10:11] <pitti> sebner: uh, interesting question; not sure whether it's possible to answer that
[10:11] <pitti>  I don't think LP records the origin of a sync anywhere
[10:12] <pitti> sync-source.py is by and large "download from debian, craft a _source.changes, upload"
[10:12] <pitti> sebner: you could count the "Fix released" sync request bugs, though
[10:13] <sebner> pitti: oh, kk. I just have the feeling that most of the syncs where from from Unstable after DIF which means we could sync from Unstable
[10:15] <pitti> sebner: well, I'd fully expect most manual sync requests to be for unstable
[10:15] <pitti> after all, the testing ones were already done :)
[10:15] <pitti> sebner: but a manually requested sync had some human eyes on it, which isn't the same than importing everything wholesale and leaving us with the pieces that break
[10:20] <apw> anyone know what just got dumped on the PPA buildds ?
[10:20] <apw> amd64	10	 9104 jobs (four days)
[10:20] <apw> i386	12	 16358 jobs (four days)
[10:20] <apw> lpia	7	 2 jobs (31 minutes)
[10:21] <apw> rebuild test?
[10:25] <slangasek> apw: yes
[10:26] <primes2h> tkamppeter: Hello, thanks a lot for the fix (s-c-p). Will new pot/po be imported automatically in Launchpad now?
[10:26] <cjwatson> pitti: sync-source shoves in an Origin field that might be Debian/testing, Debian/unstable, etc.
[10:26] <cjwatson> so it should be possible to mine that data
[10:27] <damascene> pitti, I'm subscribed yes
[10:28] <exco> unmounting a USB drive also removes it from /dev (e.g. /dev/sdc) ... bug or feature?
[10:30] <pitti> exco: I'm sure what you actually did was to eject it
[10:31] <pitti> exco: "umount /dev/sdb1" wouldn't remove it, but the nautilus eject symbol is meant to remove the entire device, yes
[10:31] <pitti> (or "safe removal")
[10:36] <apw> slangasek, dare i ask what time it is for you
[10:40] <slangasek> apw: what's the worst that could happen if you did? :)
[10:40] <apw> slangasek, heh ... i might find you are in london and at my door asking for a bed ?
[10:40] <apw> (which is covered in test kit)
[10:41] <slangasek> haha
[10:41] <slangasek> nope, in Portland
[10:41] <slangasek> and it's bedtime
[10:41] <slangasek> so - 'night, all :)
[10:41] <apw> its been bedtime for some hours ... night
[10:45] <exco> pitti: yes, you're right. so it's a feature ;-)
[10:50] <damascene> do I have to cry to make my mail inside any mail-list? I've this problem with ubutnu-desktop too
[10:50] <damascene> I had to be in there channel for 4 days to get my e-mail message in.
[10:54] <damascene> *their
[10:56] <pitti> damascene: well, until you tell us some details about the problem, nobody will be able to help you..
[10:56] <pitti> "it doesn't work" isn't helpful, since it works for everyone elase
[10:56] <pitti> "else"
[10:57] <damascene> pitti, my message was identified as spam 3.7
[10:57] <damascene> my message to ubuntu-devel-discussions
[10:57] <pitti> hm, we don't have spam filtering on most lists
[10:58] <damascene> this is problem 2. the problem 1 described in the message.
[10:58] <damascene> are  you sure?
[10:58] <pitti> yes, since I manually weed out the spam on ubuntu-de, ubuntu-devel-announce, and some others
[10:58] <pitti> damascene: perhaps you can put the full error email somewhere, including headers
[10:59] <damascene> I can show you about 10 spam replay I got
[10:59] <pitti> http://paste.ubuntu.com, for example
[10:59] <damascene> I was going to do it
[11:00] <damascene> pitti, http://paste.ubuntu.com/411533/
[11:01] <damascene> and I wonder what do you prefer should I mention your name when I write you a message or not? you do it sometimes and you don't in another
[11:01] <pitti> damascene: right, so the moderator needs to review/accept it
[11:02] <pitti> but I'm not an u-d-d moderator
[11:02] <damascene> well I think it's a general problem. I've tried more than 5 times with ubuntu-desktop I got the same message
[11:02] <pitti> ev: ^
[11:02] <pitti> damascene: SpamAssasssin might get confused about the Arabic letters in your name :/
[11:03] <pitti> damascene: ev is a moderator, he'll get to it
[11:04] <damascene> ok thanks. if there is Arabic it would be from evolution. my name is written in English in the message
[11:05] <pitti> damascene: your paste shows quite a lot of Arabic headers, though
[11:05] <pitti> Which is kind of weird
[11:06] <pitti> those look like "Received:" headers
[11:06] <pitti> headers should not be translated into any language..
[11:06] <damascene> I'm using localize evolution
[11:06] <pitti> ah, then evo probably just invalidly translate those
[11:06] <exco> looking at ~80000 open ubuntu bugs and only ~300 per series ... there should be a call for tagging bugs to releases, not?
[11:07] <pitti> exco: no
[11:07] <damascene> maybe, I'll check with evolution people
[11:07] <pitti> exco: moving 1000 new bugs to lucid won't magically create the manpower to actually fix them
[11:07] <pitti> and would destroy our means to manage the bugs which we want to fix in a particular release
[11:08] <damascene> by the way do you thing it's acceptable to install mlterm when a user chose to install rtl support, like installing Arabic support for example
[11:08] <exco> pitti: you're right about the manpower ... though it does give a wrong impression of the state of the OS
[11:09] <pitti> exco: why?
[11:09] <pitti> those bugs are open, after all
[11:09] <pitti> (not that those would give an accurate impression, since many are obsolete, duplicates, no bugs, etc.)
[11:09] <joaopinto> damascene, are you refering to bug 263822 ?
[11:10] <damascene> joaopinto, yes
[11:10] <exco> sure, 300 bugs ... does look a lot better than xxxxxx ;-) ... quantity doesn't say much ofc
[11:11] <pitti> exco: 300 bugs isn't the number of bugs in lucid that exist
[11:11] <pitti> it's the bugs which we plan to _fix_ for lucid
[11:11] <pitti> (well, very roughly anyway)
[11:14] <exco> I'm atm trying to get some guys interested in Ubuntu here at HP ... UNR is looking quite nice on the slate ;-)
[11:14] <exco> so maybe that'll one day shift some manpower towards Ubunto *dreaming*
[11:19] <damascene> pitti, I've saved the message and opened it in gedit. no Arabic there.
[11:19] <damascene> only evolution showing it translated
[11:19] <pitti> damascene: ok, thanks
[11:20] <damascene> for what. sorry for disturbing
[11:20] <cjwatson> damascene: if you think it's a general problem, #canonical-sysadmin runs lists.ubuntu.com in general
[11:20] <cjwatson> at best, people here only moderate individual lists
[11:21] <damascene> ok thanks
[11:47] <tkamppeter> primes2h, yes, the import of the translations into LP goes automatically AFAIK.
[11:53] <primes2h> tkamppeter: ok, thanks.
[12:15] <ev> pitti, damascene: approved
[12:16] <damascene> ev, thanks
[12:44] <ogra> pitti, no need to assign bugs to canonical-mobile, the armel bugs should all be subscribed to ubuntu-armel instead
[12:46] <ogra> pitti, btw, i just filed bug 559144, any idea what to do about Error: command ['lspci', '-vvnn'] failed with exit code 1: pcilib: Cannot open /proc/bus/pci ?
[12:56] <cjwatson> ogra: another SIGBUS; I see a pattern ...
[12:59] <ogra> cjwatson, i suspect its the same one ... partman calls udisks-part-id, no ?
[12:59] <ogra> to determine the partitions
[13:00] <cjwatson> no, it doesn't
[13:01] <ogra> i thought i saw udisks-part-id in the syslog
[13:01] <ogra> uevd-work[921]: 'udisks-part-id /dev/sda1' unexpected exit with status 0x0007
[13:02] <cjwatson> udisks-part-id is not available in d-i, and therefore partman does not call it
[13:02] <ogra> ah, thats long before partman
[13:02] <cjwatson> I am quite certain
[13:02] <ogra> yeah
[13:02] <ogra> i got confused because its in the syslog in various places
[13:03]  * ogra will wait for the in-archive built kernel, all the sigbus could come from building the kernel with codesourcery 
[13:03] <ogra> thats what you get for using older toolchains :P
[13:05] <sebner> didrocks: grr, it seems new metacity wants to remove compiz (pretty old our version), who cares for compiz?
[13:06] <pitti> ogra: hm, /proc not mounted? or doesn't ARM have a pci bus?
[13:06] <didrocks> sebner: the new compiz package is built and published now
[13:06] <ogra> pitti, arm doesnt have pci
[13:06] <ogra> at least not publically exposed
[13:06] <pitti> ogra: ok, so that part of the package hook is irrelevant then
[13:06] <didrocks> sebner: (at least on {,fr,us}.archive.ubuntu.com
[13:07] <pitti> ogra: any chance to get a backtrace for that?
[13:07] <pitti> ogra: sudo gdb --args /usr/lib/udisks/udisks-daemon --replace
[13:07] <pitti> then reproduce
[13:07] <sebner> didrocks: just checked the main mirror though
[13:07] <ogra> pitti, well, as cjwatson pointed out seems to be a sigbus ... the kernel was cross built, i'll wait for the proper build that should hit the archive later today
[13:07] <pitti> ogra: ok
[13:08] <ogra> pitti, partman seems to expose something similar so it might well be kernel caused
[13:09] <sebner> didrocks: hrm, ok. It's here now :) Thx for the info
[13:09] <didrocks> sebner: y/w :)
[13:12] <cjwatson> ogra: alternatively, they do both link to libparted, so it could be a bug there
[13:13] <ogra> cjwatson, well, we dont see it on other amrel platforms, i'll wait until i have a real kernel before making more noise
[13:13] <ogra> *armel
[13:14] <ogra> the kernel binary is built with gcc 4.3 codesourcery while the modules in the squashfs are gcc 4.4 from the archive, that can cause all sort of issues ... new omap kernel sits in the build queue
[13:25] <DktrKranz> james_w: wrt launchpadlib, I haven't upload privs for it, mind sponsoring it for me? You can branch it from lp:~dktrkranz/ubuntu/lucid/python-launchpadlib/1.6.0
[13:25] <james_w> not at all
[13:26] <james_w> propose the merge, request the review from me, and I'll do it after lunch
[13:30] <DktrKranz> ok
[13:38] <NCommander> ccheney: ping
[13:40] <pitti> chrisccoulson, tjaalton: do you have any useful information about bug 507062 already? if not, I'll forward it upstream and dive into the code a bit
[13:41] <chrisccoulson> pitti - well, it's not a race between threads, as synaptic is not doing any xlib calls outside the main thread
[13:41] <chrisccoulson> that was my first thought
[13:42] <pitti> chrisccoulson: this would happen if you call _XAllocID() twice
[13:42] <pitti> without _XIDHandler() in between
[13:42] <chrisccoulson> pitti - yeah, that would cause it
[13:42] <chrisccoulson> but i can't see that happening in synaptic
[13:42] <pitti> but so far I have no idea why that would happen
[13:42] <pitti> chrisccoulson: all dupes I looked at went though XCreatePixmap()
[13:42] <chrisccoulson> pitti - could be a clue ;)
[13:43] <pitti> chrisccoulson: it affects all kinds of programs, though
[13:43] <pitti> synaptic just happens to have gotten the master bug
[13:43] <chrisccoulson> i was going to spend some time to look at it bug haven't got round to it yet
[13:43] <pitti> chrisccoulson: ok, thanks
[13:43] <pitti> chrisccoulson: I'll start forwarding it upstream and do some brain dumping then
[13:43] <lamont> dammit  WTF DOES UPDATE-MOTD KEEP GETTING ALL THOSE DAMN SYMLINJKS
[13:45] <lamont> when I remove a conffile, it's supposed to STAY GONE
[13:46] <lamont> kirkland: ^^??
[13:46] <chrisccoulson> pitti - also, synaptic never calls XInitThreads anyway (and dpy->lock->user_lock_display is a NULL pointer)
[13:47] <chrisccoulson> iirc from when i ran synaptic in gdb
[13:47] <kirkland> lamont: i'm having multiple conversations right now; file a bug, assign it to me
[13:47] <lamont> ta
[13:47] <lamont> kirkland: which package?
[13:47] <lamont> meh . update-motd, ofcourse
[13:47] <kirkland> lamont: which symlink
[13:47] <kirkland> lamont: there is no update-motd package
[13:47] <kirkland> lamont: pam handles update-motd now
[13:47] <lamont> update-motd.d/9*
[13:47] <kirkland> lamont: other packages drop symlinks into /etc/update-motd.d
[13:47] <kirkland> lamont: those are probably update-notifier
[13:48] <lamont> and then I dist-upgrade, and presto, they're all back
[13:48] <lamont> update-motd package is 3.5-0ubuntu1 in lucid...
[13:48] <lamont> mind you , it just delivers the directory
[13:50] <Aquina> I started using Bazaar with launchpad. Can someone tell me whether I makes sense to upload for e.g. a KDevelop-project (directory structure *as is*) or rater create a packages and store them in a ppa? I must admit that I've got no clue about packaging though.
[13:51] <lamont> ah, that's it - they're not listed as conffiles
[13:53] <lamont> 559194 assigned
[14:01] <tjaalton> pitti: yeah please forward upstream, and I'll see that the relevant people are notified
[14:01] <pitti> tjaalton: I'm at it; thanks
[14:02] <pitti> tjaalton: freedesktop bug 27552 now, I'll link it
[14:06] <tjaalton> pitti: ok, moved to Lib/Xlib :)
[14:09] <pitti> tjaalton: hm, did you commit the bug change? still "other" here
[14:10] <tjaalton> pitti: yep, looks fine here
[14:26] <cwillu_at_work> trying to rebuild dpkg from apt-get source; debian/rules binary fails with dpkg-shlibdeps: error: no dependency information found for /lib/libc.so.6 (used by debian/dpkg/usr/sbin/install-info).  Is this bogus, or did I forget a step?
[14:27] <cwillu_at_work> (testing a fix for debian bug #575891, which may have left this system in an inconsistent state re: triggers and such)
[14:29] <joaopinto> mvo, do you know any python library provide a class to handle debian control files ? I don't see such type of class listed on python-apt
[14:31]  * cwillu_at_work reinstalls libc6
[14:32] <cwillu_at_work> yep, bogisity
[14:32] <mvo> joaopinto: what use case do you have in mind?
[14:32] <joaopinto> hum, there is a apt.debfile.DscSrcPackage, not sure that would correctly handle .changes files
[14:32] <mvo> joaopinto: you can use a TagFile() for this
[14:32] <joaopinto> mvo, I just want need to read data from *changes and *dsc files
[14:33] <superm1> hi mvo, would you mind taking a look at bug 558956?  I'm unsure of what the proper solution is to help this
[14:34] <joaopinto> mvo, TagFiles is what I was looking for, thanks
[14:34] <pitti> tjaalton: hm, I wrote a test program which does 10.000 XCreatePixmap() calls in a row, but it works fine; I guess it's not that simple :/
[14:35] <mvo> superm1: hm, I need to ask for the full log
[14:35] <superm1> mvo, which log?  i'll see if mrand has it
[14:36] <mvo> superm1: main.log please
[14:36] <superm1> mvo, okay, thanks
[14:37] <mvo> superm1: hm, unless its the same as in the other report he send
[14:37] <superm1> it's a little different
[14:37] <superm1> that other report showed a problem with the usplash theme, and so we did a c/r/p for that usplash theme package from the plymouth theme package
[14:38] <cwillu_at_work> mvo, do I point dpkg patches at you?
[14:40] <mvo> cwillu_at_work: you can, cjwatson is doing most dpkg work these days though
[14:40] <cwillu_at_work> ah, k
[14:42] <cwillu_at_work> mvo, don't suppose you know of any bugs where /var/lib/dpkg/info files go missing mysteriously?
[14:45] <mdeslaur> pitti: It appears cups in lucid is still affected by CVE-2010-0302. I don't know if kees already mentioned this to you or not. Are you planning on fixing in debian and syncing?
[14:45] <pitti> mdeslaur: yes, I already committed the fix to Debian bzr
[14:45] <mdeslaur> pitti: oh, great, thanks!
[14:46] <pitti> mdeslaur: I kind of hoped that the previous version would go to testing at some point, but libkrb5 is stuck :(
[14:46] <pitti> so I'll just do another upload
[14:49] <mdeslaur> pitti: ok
[14:51] <mvo> cwillu_at_work: no, but that sounds pretty scary
[14:52] <cwillu_at_work> mvo, silly people were using readdir wrong :)
[14:52] <cwillu_at_work> only seems to affect btrfs roots, was curious if anyone else had tripped over it
[14:52] <superm1> mvo, he won't be able to attach it until later today, would you mind subscribing and responding at your convenience then?
[14:53] <mvo> superm1: sure, thanks for pointing me to it
[14:53] <cjwatson> mvo: bug 518856 - it's been "fix committed" for ages, but I'm guessing that's not accurate given how long it's been open.  I've moved its milestone to final for now, but what's its correct state?
[14:54] <mvo> superm1: that reminds me, I should create a profile for mythbuntu
[14:54] <mvo> superm1: a upgrade test profile I mean, then it gets tested automaticaly
[14:54] <superm1> mvo, ooh, yes that would be spectacular :)
[14:55] <superm1> mrand has been doing it painfully by hand currently and finding all of these problems
[14:55] <mvo> cjwatson: I close it now, sorry
[14:55] <Daviey> mvo: that is awesome, would it be possible to provide some user data?  Perhaps not this time, but for future?
[14:55] <Daviey> ie, mysql tables?
[14:55] <cwillu_at_work> mvo, cjwatson, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 is the bug I was talking about;  just tested the patch, and at the very least it no longer loses files from /var/lib/dpkg/info
[14:56] <mvo> Daviey: for a upgrade test you mean? sure
[14:56] <Daviey> mvo: I am a happy boy, need to depreciate mrand now. brb
[14:56] <mvo> superm1: ok, I can add a profile, it will still be painful to fix the bugs, but finding is easier at lest :)
[15:01] <ScottK> cjwatson: When I was reviewing your debconf update in the queue yesterday, I noticed it also needs to be updated for python3.1 versus python3.0.
[15:04] <ScottK> jdstrand: Is it your archive admin day today?  If so, I'd appreciate it if you would accept libqinfinity out of binary New as there's another sync waiting on it that we need for NBS resolution.
[15:08] <jdstrand> ScottK: done
[15:08] <ScottK> jdstrand: Thanks.
[15:08]  * jdstrand nod
[15:08] <jdstrand> s
[15:08] <ScottK> ;-)
[15:10] <cjwatson> mvo: ah, thank you
[15:10] <cjwatson> ScottK: do you happen to know whether 3.0 should still be there?
[15:11] <ScottK> cjwatson: It should not.  We only have 3.1 in Lucid.
[15:11] <cjwatson> ok
[15:11] <cjwatson> cwillu_at_work: I'd consider it once it's in the dpkg git repository - I don't think we can regard it as RC for lucid though given the general state of btrfs support right now
[15:12] <ScottK> cjwatson: That's also true for debian/unstable.
[15:12] <cwillu_at_work> cjwatson, absolutely
[15:12] <cwillu_at_work> cjwatson, if I'm not mistaken, the dpkg maintainer is reviewing the patch as we speak
[15:13] <cjwatson> ScottK: uploaded
[15:14] <ScottK> Thanks.
[15:14] <cwillu_at_work> cjwatson, that's actually why I asked before if there were any outstanding mysterious bugs with similar behaviour;  the consensus was that dpkg was simply lucky that the filesystems it was commonly used on didn't have this issue
[15:15] <cwillu_at_work> er, rather: had behaviour which didn't trigger this issue
[15:18] <pitti> tkamppeter: cups 1.4.3 update is in bzr now, works well
[15:18] <pitti> tkamppeter: I upload this now
[15:19] <cjwatson> mvo: how about bug 518866 - we're after UI freeze now, shall I bump that to post-lucid?
[15:19] <cjwatson> mvo: and bug 540790
[15:19] <mvo> cjwatson: yes please for #518866
[15:20] <mvo> cjwatson: 540790> I want to have a look if it can be improved without new strings, but it may have to be defered
[15:20] <tkamppeter> pitti, great. I am too busy with s-c-p.
[15:27] <ccheney> NCommander: hi whats up?
[15:27] <pitti> tkamppeter: you're going to LF summit next wek?
[15:29] <NCommander> ccheney: was going to ask you an OOo question but looks like the current ARM breakage is a gcc bug
[15:30] <ccheney> NCommander: ok
[15:32] <cjwatson> mvo: bug 522225 is still feasible, isn't it?
[15:32] <cjwatson> (he says hopefully ...)
[15:35] <mvo> cjwatson: dosn't that only affect lucid -> lucid?
[15:43] <directhex> micahg, i patched up gluezilla so it doesn't crash, but doesn't display anything either. andreia will look into it at the weekend
[15:44] <micahg> directhex: ok, thanks, feel free to ping me if I can help with any xul related stuff
[15:45] <zyga> mvo: hi
[15:48] <cjwatson> mvo: yes; it's milestoned because we still have to mention it in the lucid technical overview, and it'd be nice if we didn't
[15:48] <pitti> mdeslaur: cups uploaded now (with 2010-0302 fix)
[15:49] <cjwatson> mvo: also interested if you know what's happening with bug 553369 (sorry, I seem to be hassling you a lot today)
[15:50] <directhex> micahg, basically, i think your gre version patching is wrong (since that's what i fixed to stop the crashing), but some behaviour needs some love to make it actually work
[15:51] <mvo> cjwatson: 522225> its a bit problematic as the release upgrade is usually what is tkaing care of this
[15:51] <mdeslaur> pitti: thanks!
[15:51] <mvo> cjwatson: we can add something, thats for sure
[15:52] <mvo> cjwatson: I check the nvidia bug out
[15:52] <mvo> cjwatson: and no worries, at this time of the release we tend to look at upgrade issues :) so all good
[15:52] <mvo> zyga: hi
[15:53] <mvo> zyga: lots of churn in trunk, you may wan tto upgrade
[15:53] <zyga> mvo: sorry I was not of much help yesterday, my kids have a nasty cold and I'm babysitting them
[15:53] <zyga> mvo: pulling now
[15:53] <mvo> zyga: I'm also in the process of making the updates smoother
[15:53] <mvo> zyga: no worries
[15:58] <cjwatson> lool: have you looked at bug 555330 yet (or do you expect to be able to, soon)?
[15:59] <mvo> ogra: every time I read orca I think of you, can't help it (just fixed some a11y bug)
[16:00] <ogra> mvo, :/ i would have thought i'm more colorful
[16:00] <mvo> ogra: a bit of a mechanical voice too :P
[16:00] <ogra> heh
[16:01] <mvo> ohh, commit r699
[16:07] <tkamppeter> pitti, yes, I am organizing the OpenPrinting Summit.
[16:10] <asac> tkamppeter: on hardy is it safe to just download the hplip.run thing from HP and run it?
[16:10] <asac> or will that cause issues?
[16:10] <pitti> tkamppeter: ah; good luck, and safe travels!
[16:10] <pitti> tkamppeter: where is it this time? SF again?
[16:10] <asac> tkamppeter: or is there a backport package somewhere?
[16:31] <lool> cjwatson: pitti had pinged me, but after your ping I actually reviewed the new deps again and wrote up my MIR comments in the bug
[16:31] <lool> ttx: Would you please look at LP #555330 when you have some time and tell me whether it's an issue to pull these new (very small) packages on the server radar for logcheck?
[16:32]  * ttx looks
[16:34] <ttx> lool: I don't have objections, but your latest comment seems to answer the question already ?
[16:35] <lool> ttx: Yeah, first I thought it was on the ISO; but because logcheck is a server package, I wanted to make sure you had no objection to the new deps
[16:36] <lool> since in the end you might have to look at logcheck bugs
[16:36] <ttx> lool: if I object new perl libraries in main, I get fired :)
[16:36] <lool> ttx: haha
[16:36] <lool> Right, I should ask Jos next time
[16:36] <ttx> heh
[16:55] <cjwatson> mvo: also just a reminder that your support-timeframe-information branch had some comments from noodles that seem to still need to be addressed?
[16:57] <slangasek> lool: logcheck is too on an ISO, it's on the DVD
[16:57] <slangasek> lool: FYI :)
[16:58] <chrisccoulson> hi persia, would you mind adding me to ubuntu-sponsors please? (my u-u-s membership expires soon)
[16:59] <persia> chrisccoulson: Done.  thanks for sponsoring.
[17:00] <chrisccoulson> persia - thanks :)
[17:00] <mvo> cjwatson: thanks
[17:02] <jcastro> mvo: also don't forget debian squid guy. :D
[17:09] <cwillu_at_work> cjwatson, the dpkg patch just hit debian's git
[17:10] <cwillu_at_work> http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=18b12083b5fee4e7e26e1382e50321e7956fcdb9
[17:12] <lool> slangasek: Oh right, I only checked the Tasks field
[17:20] <wcGary83> hi all! does anybody know how to currently add a sound applet in Lucid?
[17:22] <ScottK> wcGary83: Help for Lucid is in #ubuntu+1
[17:22] <jcastro> sound applet should run automatically, ensure sound-indicator is installed
[17:24] <wcGary83> no luck... thanks though i will go to ubuntu+1!
[17:35] <kirkland> cjwatson: slangasek: could one of you guys trigger a new eucalyptus build?
[17:35] <kirkland> cjwatson: I'd like to verify the tasksel change we made yesterday (which didn't land in the over night build)
[17:36] <slangasek> kirkland: eucalyptus build> you mean a CD build?
[17:37] <kirkland> slangasek: sorry, yes
[17:38] <kirkland> slangasek: server iso build
[17:38] <kirkland> slangasek: sorry, euca on the brain
[17:38] <slangasek> I have a salve that will help with that
[17:39] <kirkland> slangasek: heh
[17:39] <slangasek> yes, let me finish walking through the beta-plus-one-day checklist and I'll fire one off
[17:40] <kirkland> slangasek: ack, thanks
[17:57] <kirkland> lamont: hi
[17:57] <slangasek> kirkland: running, ETA: 30 min
[17:57] <kirkland> lamont: vvv
[17:57] <kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-reboot-required etc/update-motd.d/98-reboot-required
[17:57] <kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-updates-available etc/update-motd.d/90-updates-available
[17:57] <kirkland> update-notifier-common.links:usr/lib/update-notifier/update-motd-cpu-checker etc/update-motd.d/20-cpu-checker
[17:58] <kirkland> lamont: I would think that these should be considered conffiles by dh, since they're installed by dh_installlinks
[17:58] <kirkland> (dh_link, rather)
[17:58] <kirkland> lamont: is my understanding wrong?
[18:02] <lamont> kirkland: dunno
[18:03] <kirkland> lamont: okay, i'll do some testing
[18:03] <lamont> I just know that if you dist-upgrade after removing the symlinks, they magically reappear
[18:04] <kirkland> lamont: dist-upgrade from lucid->newer_lucid, or karmic->lucid?
[18:05] <lamont> lucid -> newer lucid
[18:07] <jdong> how does ureadahead detect the root filesystem? On btrfs, ureadahead refuses to create a pack for root.
[18:14] <Darxus> What's the easiest way to get the debugging symbols for the empathy package on Karmic?  empathy-dbg exists on Lucid but not Karmic.  Mine's segfaulting on startup.
[18:16] <ScottK> Darxus: http://ddebs.ubuntu.com
[18:18] <Darxus> Sweet!
[18:22] <Darxus> Yay!  empathy-dbgsym
[18:22] <Darxus> So why is there an empathy-dbg un lucid?
[18:23] <ScottK> Usually we either get -dbg from Debian packaging or they are added by devs that forget/don't know about ddebs.
[18:23] <Darxus> Ahh.
[18:24] <Darxus> Yeah I've seen -dbg packages mentioned all over the place and never noticed ddebs.
[18:28] <Darxus> Damn.  Bit by package pinning again (to karmic, when the new package was in karmic-updates).  Current empathy package doesn't crash.
[18:30] <apw> pitti, does the work items tracker now understand postponing an item in one milestone and copying it to the next?
[18:30] <kees> mvo: I have a question about update-manager on hardy, are you still around?
[18:30] <cjwatson> kirkland: symlinks into /etc don't get to be conffiles
[18:30] <kirkland> cjwatson: even if i add them manually to debian/conffiles ?
[18:31] <cjwatson> it's not a good idea anyway IMO!
[18:31] <cjwatson> it involves the user editing stuff in /usr indirectly
[18:31] <cjwatson> I'd strongly recommend some different approach
[18:31] <kirkland> cjwatson: okay, thanks
[18:31] <kirkland> lamont: ^
[18:31] <cjwatson> for example you could write trivial conffile scripts in /etc that exec the programs in /usr
[18:31] <kirkland> cjwatson: yeah, that's what i'll have to do
[18:31] <kirkland> cjwatson: shell scripts that exec, rather than symlinks
[18:34] <lamont> ah. makes sense
[18:34] <lamont> ta
[18:36] <kees> kirkland: what are you trying to have happen?
[18:36] <kees> kirkland: I'm seeking to make sure that cpu-checker always runs.  :)
[18:36] <kirkland> kees: update-notifier-common installs symlinks in /etc/update-motd.d
[18:36] <kirkland> kees: but lamont wants to make sure that it doesn't run
[18:37] <kirkland> kees: so he wants to break that symlink, and not have it come back on upgrade
[18:37] <kees> "it"?
[18:37] <kirkland> kees: cpu-checker, updates-available, phone-home, whatever
[18:37] <kees> maybe update-motd needs a /etc/default file?
[18:38] <kirkland> kees: hmm, i think we should just move away from symlinks
[18:38] <kirkland> kees: use a simple shell script that execs instead
[18:38] <kirkland> kees: and lamont can rm that file, comment out the contents, or chmod -x it
[18:44] <kees> kirkland: post-lucid, though.
[18:44] <kirkland> kees: that's fine with me;  lamont?  is this lucid-release-critical?
[18:45] <lamont> that depends... you gonna ever update it in lucid?
[18:45] <lamont> it offends me greatly, dunno if it properly qualifies as RC though
[18:46] <kirkland> lamont: would you be willing to carefully review a debdiff and test it?
[18:46] <kirkland> lamont: b/c i have one ready
[18:47] <lamont> sure - it'll be later today though
[18:47] <kirkland> lamont: http://paste.ubuntu.com/411714/
[18:49] <lamont> there were others scattered around as well, of course
[18:49] <lamont> but yeah, I'll review in a while
[19:09] <kirkland> slangasek: i'm fixing a motd bug in mountall ... is it bzr managed?
[19:10] <slangasek> yes
[19:10] <slangasek> lp:ubuntu/mountall
[19:10]  * kirkland doesn't see any uri in debian/control
[19:10] <kirkland> slangasek: thanks
[19:13] <kirkland> slangasek: http://paste.ubuntu.com/411728/
[19:15] <kirkland> slangasek: pretty trivial fix, i'm going to push that up, if you don't have any objections
[19:17] <slangasek> kirkland: I agree that the current behavior is buggy; but is there any reason we would care about having motd populated before the first login?
[19:17] <kirkland> slangasek: i don't think so ... MOTD is about communicating with users upon login, right?
[19:18] <kirkland> slangasek: and specifically text/console/tty/ssh logins
[19:18] <psusi> pitti: I'm not sure you understood me in bug #558926.  There is no USB this is just a cdrom.  In a terminal cd /media/cdrom ( while you have a cd mounted ) and press the eject button.  The drive vanishes from the computer in nautilus.  Is this not a udisks problem?
[19:23] <xhaker>  /q crimsum
[19:23] <xhaker> :/
[19:25] <kirkland> slangasek: elmo might be able to answer that question better than me
[19:25] <kirkland> elmo: <slangasek> kirkland: I agree that the current behavior is buggy; but is there any reason we would care about having motd populated before the first login?
[19:25] <elmo> I don't care much about motd at all ;-)
[19:25] <elmo> but if I were forced to, I can't imagine why I'd care pre first login, no
[19:26] <kirkland> elmo: heh, cool, thanks for the input
[19:27] <sabdfl> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/base-files/+bug/555916I was raised with me by the reporter, could you ask someone appropriate to take a view on it for Lucid?
[19:31] <evarghese> question: has compiz been taken out of ubuntu by default?
[19:31] <evarghese> it looks like it was taken out yesterday and put back in today without coverflow
[19:31] <evarghese> is that right?
[19:31] <hyperair> i haven't heard of anything of that sort.
[19:32] <ScottK> There was a compiz upload yesterday.  You can check the changelog on launchpad.
[19:32] <evarghese> ah ok gotcha
[19:49] <slangasek> kirkland, elmo: ack, no objections to that change then
[19:49] <kirkland> slangasek: thanks
[19:50] <soren> Are the actual packages in Debian's NEW queue available somehow? I was about to submit a sync request for http://ftp-master.debian.org/new/python-cloudservers_1.0~a5-1.html, but can't seem to find a link to the actual .dsc and such.
[19:50] <slangasek> sabdfl: adding 'wins' to nsswitch.conf is a very bad idea, WINS simply does not have the semantics Unix systems expect for host lookups; we have avahi for this - I'll follow up to the bug
[19:52] <Laney> soren: no
[19:53] <soren> Laney: Figures.
[19:53] <Laney> however, there are one or two Ubuntu friendly ftp assistants who could help you out :)
[19:54] <soren> Well, I can get the .dsc, I suppose. That's not really the problem.
[19:55] <soren> I just wanted to give the authoritative reference to the .dsc in the sync request.
[19:55] <soren> I don't have it myself since my sponsor apparantly re-"dpkg-buildpackage -S"'ed it.
[19:56] <joaopinto_> hi
[19:56] <Laney> soren: you can just upload it yourself as long as you get the orig.tar.gz identical to the one in Debian
[19:56] <joaopinto_> is there a bug reported about a loop on the file system check when / is corrupted ?
[19:57] <joaopinto_> I had to fix it so I can't report much more than this :\
[19:57] <soren> Laney: That would unnecessarily upset my sense of correctness :)
[19:58] <Laney> heh
[20:01] <Laney> well you don't really have a guarantee that it won't be rejected from Debian
[20:01] <Laney> so uploading -1 before it clears NEW is risky anyway ;)
[20:10] <antivirtel> hello all
[20:12] <antivirtel> can I ask someone to fix it plz: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/177929 ? it is a very important thing for INTERNATIONAL use, and this is a very old problem, it reported and confirmed in december 2007
[20:12] <persia> antivirtel: That's a *very* hard bug, and lots of work towards fixing it has been understaken, but there exists no reliable or good solution still :(
[20:14] <antivirtel> persia but what can I do, there are a lot of important files in these zips... :S ?
[20:14] <joaopinto_> hum, is there some easy way to cause a non severe ext4 fs corruption :P ?
[20:16] <nemo> so I was reading: https://launchpad.net/~francesco-marella/+archive/unstable-evolution
[20:16] <nemo> "3) Evolution-mapi: still not packaged, it needs more dependencies (openchange) to be packaged first. no way."
[20:16] <nemo> That's the main reason I wanted to shift to 2.30, due to bug fixes for MAPI on the that branch
[20:17] <nemo> Wondering what Francesco means - are there packages that aren't in package management?
[20:17] <nemo> I'd like to avoid getting in a situation where I have to restore all my old evolution builds and maybe have forgotten which ones were which - I recall evolution has a lot of deps
[20:17] <persia> antivirtel: It needs a reliable way to detect the encoding of the contents of the archive.  To the best of my knowledge, there is no metainformation guaranteed to be stored in zip files that would give the right information (I may be mistaken),  Some of the work in this area in the past has used a successive unpack model attempting different encodings based on a list from the user's current locale.  But it needs someone to dig through in detail
[20:17] <persia> , and find something that works for all users.
[20:18] <antivirtel> :S hmm... is it some other zip opening program ? like in windows: winrar ?
[20:19] <evarghese> nemo, that makes it sound like an actualy mapi client implementation... is that correct?
[20:19] <evarghese> or are we not still scraping exchange web
[20:19] <evarghese> i.e owa
[20:20] <persia> antivirtel: tar works slightly more sanely.
[20:20] <nemo> evarghese: Unfortunately I've had a lot of issues w/ OWA at work, possibly due to sucky web gateway, possibly due to sheer size of GAL and number of e-mails
[20:21] <nemo> evarghese: so. yeah. I've been building the MAPI (native) client for 2.28
[20:21] <evarghese> same here :(
[20:21] <evarghese> WOAH!!
[20:21]  * evarghese hugs nemo 
[20:21] <nemo> http://ftp.acc.umu.se/pub/gnome/sources/evolution-mapi/0.28/
[20:21] <antivirtel> persia "sanely"?
[20:21] <nemo> evarghese: also helped track down a bunch of bugs :)
[20:21] <nemo> evarghese: but now I need to be on http://ftp.acc.umu.se/pub/gnome/sources/evolution-mapi/0.30/
[20:22] <nemo> evarghese: esp since devs can't help me much w/ test builds unless I'm running 2.30
[20:22] <antivirtel> persia it is installed
[20:22] <evarghese> ah hmm
[20:22] <nemo> sooo. wanted to try out Francesco's package, just thought I'd check to see if there'd be some major issue before I tried it
[20:29] <antivirtel> so, please try to fix it: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/177929 I go to win to open this fcking zip:S i leave BNC, bye
[20:31] <nemo> hm. still unable to access keyserver.ubuntu.com, so I guess this is all purely abstract.
[21:02] <crimsun> GrueMaster: I'll look in an hourish when I'm back from work
[21:03] <GrueMaster> ok, I'll be here.
[21:12] <cody-somerville> cjwatson, Is plymouth suppose to be in the minimal task?
[21:19] <cjwatson> cody-somerville: yes
[21:20] <cjwatson> cody-somerville: in lucid, it's critical to multiplex I/O during boot
[21:27] <ccheney> http://www.engadget.com/2010/04/09/webos-port-of-xorg-in-the-works-openoffice-support-the-inevitab/ <- lmao
[21:44] <rohan> is there any reason why the ubuntu lucid ISOs are not hybrid ISOs (which can directly be dumped to a usb stick)?
[21:46] <cjwatson> rohan: there's a wishlist open for it.  just hasn't been done yet.
[21:46] <cjwatson> (certainly won't change for lucid at this point, though!)
[21:48] <rohan> cjwatson, thank you.. i thought there was a technical reason to it.
[21:49] <rohan> and yes i understand it won't be changed for lucid now :)
[21:50] <zyga> (if only ubuntu could make one disc for both x86 and x86_64 ... ahh dreams)
[21:50] <ccheney> zyga: yea called DDCD :)
[21:51] <cjwatson> I know, we'll weld two CDs together
[21:52] <zyga> ccheney: DDCD?
[21:52] <ccheney> zyga: http://en.wikipedia.org/wiki/Double_Density_Compact_Disc
[21:52] <ccheney> zyga: old dead Sony tech
[21:52] <zyga> cjwatson: jokes aside it's a big technical challenge
[21:52] <zyga> cjwatson: and a cool idea (at least for me personally)
[21:53] <ccheney> zyga: afaik it wouldn't be possible other than increasing storage space as the cd is too full to even fit a minimal difference of only the binary code parts
[21:53] <zyga> ccheney: true, but it would be possible for a DVD edition
[21:53] <ccheney> separating all binary code out and switching to xz for all packages might get us close, but that would be hard in itself, and very slow for older pcs
[21:53] <rohan> zyga, opensolaris does have same ISO for both archs. but then it's because their kernel is made that way, to adapt to 32bit or 64bit on the fly.
[21:53] <cjwatson> the DVD is full too
[21:54] <cjwatson> at least in terms of a single-sided single-layer DVD
[21:54] <ccheney> BDXL 128GB ftw :)
[21:54] <zyga> cjwatson: I know both are full
[21:54] <zyga> cjwatson: I just think that having one 'medium' (either CD or DVD) in some stripped fashion that can boot and install on both is cool
[21:55] <cjwatson> it's a neat trick, and it's been done in Debian, but I don't think it's practical for Ubuntu images the way the world currently is
[21:55] <zyga> and functional - apart from being cool
[21:55] <rohan> cjwatson, debian has a multiarch disk?
[21:55] <zyga> cjwatson: oh, debian has something like this?
[21:55] <cjwatson> google
[21:56] <cjwatson> nearly the entire top page of google hits for "debian multiarch cd" is relevant
[22:08] <jibel> cjwatson, could you have a look at bug 557023 ? it appeared with the latest initramfs-tools.
[22:08] <jibel> cjwatson, only 4 users are affected, maybe it's nothing maybe not.
[23:05] <crimsun> GrueMaster: has PA worked correctly in Lucid for ARM boards prior to -0ubuntu11?
[23:06] <crimsun> GrueMaster: I believe I've bisected the commit, but I would like to confirm before I dig into the asm.
[23:06] <GrueMaster> I don't know.  I don't think so.  When was that release made?
[23:07] <crimsun> GrueMaster: the upstream commit in question is 0d1154 (rework how stream volumes affect sink volumes), which landed in Lucid's 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu11
[23:07] <crimsun> Mon, 22 Feb 2010 00:22:50 -0500
[23:07] <GrueMaster> Ok.  Let me see if I can load the older version and test it.
[23:10] <GrueMaster> I don't have any images earlier than 3/1, so I need to see if I can get it another way.
[23:18] <GrueMaster> Looks like I will have to roll a new version.  This sucks.
[23:23] <crimsun> GrueMaster: hmm, you shouldn't have to; you could forcibly downgrade to -0ubuntu10 using the version on LP (https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10)
[23:24] <crimsun> GrueMaster: just have to remember to manually toggle 'Line HP Swap'
[23:24] <crimsun> anyhow, offline for a bit
[23:24] <GrueMaster> I'll try it.
[23:31] <slangasek> superm1: I'm uploading a new fglrx-installer to fix a FTBFS on i386; where should I send the debdiff so that it gets merged into the git repo/
[23:34] <superm1> slangasek, email it to both me and tseliot, one of us can commit it
[23:34] <slangasek> superm1: okie
[23:52] <GrueMaster> crimsun: No luck there.