[00:01] <cjwatson> the geom member of PedPartition doesn't seem to have changed type in libparted itself
[00:03] <chrisccoulson> cjwatson - i can recreate with the current libparted
[00:03] <chrisccoulson> it's more likley a change in vala
[00:04] <chrisccoulson> but the language is so poorly documented ;)
[00:04] <cjwatson> that's a relief of sorts
[00:06] <james_w> bryceh: do you have a traceback for the wadllib bug you just reopened?
[00:07] <bryceh> james_w, no
[00:07] <bryceh> james_w, worked around the problem manually so can't easily repro it at the moment
[00:08] <james_w> the problem is that the error could come from passing the wrong thing in, or launchpad changes as well
[00:13] <james_w> bryceh: do you remember which values it was complaining about?
[00:13] <james_w> or the LP method call you were making?
[00:13] <bryceh> james_w, yep
[00:13] <bryceh> it was complaining about "Confirmed"
[00:14] <bryceh>   File "/home/bryce/src/Arsenal/arsenal/contrib/process-incomplete-bugs.py", line 88, in <module>
[00:14] <bryceh>     bugtask.transitionToStatus(status = new_status)
[00:14] <bryceh> ...
[00:14] <bryceh> ValueError: Invalid value '"Confirmed"' for parameter 'status': valid values are: "New", "Incomplete", "Invalid", "Won't Fix", "Confirmed", "Triaged", "In Progress", "Fix Committed", "Fix Released", "Unknown"
[00:14] <james_w> aha, thanks
[00:15] <bryceh> james_w, the code is in the arsenal branch if you want to poke at it.  Or I can gather more data if you'd like, but it'll be tomorrow before I can get to it
[00:15] <cjwatson> that looks like an over-quoting problem?
[00:15] <james_w> bryceh: no, that's enough to go on, thanks
[00:16] <james_w> cjwatson: yeah
[00:16] <james_w> no Idea why it just reared its head again
[00:16] <bryceh> cjwatson, bug #418802 near as I can tell
[00:16] <james_w> bryceh: checking apt-cache policy python-launchpadlib python-lazr.restfulclient python-wadllib would be good
[00:16] <bryceh> james_w, btw this is on a karmic machine
[00:16] <james_w> aha!
[00:17] <bryceh> I had been running the versions currently in https://edge.launchpad.net/~tsimpson/+archive/launchpadlib
[00:17] <bryceh> that's a backport of the lucid bits
[00:17] <bryceh> I also tried downgrading off that to the stock karmic versions 1.5.1, etc.
[00:18] <bryceh> but got the same errors
[00:19] <bryceh> james_w, what's weird is that this definitely went away for me for several months after upgrading to 1.5.1-0ubuntu1
[00:19] <james_w> and this was code that stopped working today?
[00:19] <kees> seb128: bug 525924 is an evince bug because the profile is in evince.  it's related to the profile though, yes.
[00:19] <bryceh> james_w, I've been having the problem since at least the start of the year
[00:20] <james_w> ok
[00:20] <seb128> kees, I though the browser list abstraction thing was in apparmor
[00:20] <kees> oh, er
[00:20] <bryceh> james_w, for a while I just procmailed the errors away.
[00:20] <kees> seb128: you are totally right.  :)
[00:20] <seb128> kees, ;-)
[00:21] <bryceh> james_w, if you're pretty sure this is solved in lucid maybe don't worry about it too much, I intend to upgrade this box soon and can follow up if it's still an issue on lucid.
[00:21] <james_w> bryceh: well, if you are using the backported bits then it may well be an issue
[00:22] <bryceh> james_w, *nod*
[00:22] <seb128> kees, in fact it seems that's fixed in lucid already
[00:22] <bryceh> james_w, and since I had been the one that marked it fixed, that's why I reopened it
[00:22] <kees> seb128: yeah, 488559
[00:22] <kees> I've dup'd it now
[00:22] <seb128> kees, thanks
[00:25] <slangasek> ccheney: openoffice.org is recommended by openoffice.org-hyphenation-af et al. in main; do you know why that is?
[00:25] <slangasek> ccheney: i.e., it's recommended as an alternative against openoffice.org-writer, but it seems it could just recommend the second of these
[00:27] <slangasek> asac: component-mismatches nominates the whole EFL stack for demotion to universe.  Are these packages required to be in main, and if so, what's supposed to hold them in?
[00:27]  * cjwatson digs into why he keeps getting "A volume with software packages has been detected" on the live CD
[00:43] <freinhard> Hi!
[00:43] <freinhard> does anybody know if atheros ar2427 will be supportet in the near future for lucid?
[00:44] <freinhard> got a asus 1005PE which ships that wireless chip
[00:49] <Kai_> I can't wait for Alpha 3. I'm going to see if it has a wiki page.
[00:50] <Kai_> No :-\
[00:52] <ccheney> Kai_: huh?
[00:52] <ccheney> Kai_: alpha 3 is this thursday
[00:53] <arand> Kai_: A3 will likely pretty much be what the dev is today, with a few bit maybe..
[00:53] <Kai_> ccheney: I couldn't find a wiki page for Lucid Alpha 3, but I found the blueprints
[00:53] <ccheney> Kai_: https://wiki.ubuntu.com/LucidReleaseSchedule
[00:53] <Kai_> ccheney: I know it's on thursday, it's always on thursday
[00:53] <Kai_> that doesn'
[00:53] <Kai_> that doesn't say much about alpha 3
[00:53] <ccheney> Kai_: once it is out the link to alpha 3 will be active
[00:53] <ccheney> Kai_: like how alpha 2 link is currently active
[00:53] <Kai_> okay
[00:54] <Kai_> hi jono!
[00:54] <jono> hey!
[00:59] <james_w> bryceh: I can't reproduce on either karmic or lucid.
[01:00] <james_w> bryceh: I think you can use task.status = "Confirmed"; task.lp_save() as well now
[01:00] <bryceh> james_w, ok I'll give that a shot
[01:04] <ArneGoetje> ccheney,slangasek: FYI, graphite is an alternative to the Truetype GPOS and GSUB tables, which has an extended rule set to describe in fonts how a particular glyph should be rendered in a specific situation. But since I don't know any open source editor for graphite code in fonts, I cannot see what's really inside those fonts, it's stored in a binary format. Graphite has been developed by SIL in order to improve rendering supportfor certain languages
[01:37] <twb> I'm having trouble installing daemons inside lucid chroots, due (I guess) to upstart start(8) ignoring policy-rc.d
[01:38] <twb> http://pastebin.com/fbb11bff <-- example
[01:40] <mneptok> twb: this is a development channel, not a support channel.
[01:40] <twb> Well, they're pbuilder chroots.
[01:41] <mneptok> that still does not make your issue related to the development of Ubuntu
[01:41] <cjwatson> twb: yes, start(8) pays no attention to policy-rc.d.  The way to handle this with upstart is to divert /sbin/initctl
[01:41] <cjwatson> for an example, see debootstrap, which does this
[01:42] <twb> Thanks.  I guess my debootstrap is too old, or I'm accidentally using cdebootstrap.
[01:43] <cjwatson> I didn't say debootstrap was responsible in this case
[01:43] <twb> (Oh, of course once the base debootstrap is done, the debootstrap stub package will get removed.)
[01:43] <cjwatson> debootstrap undoes the diversion when it's finished (nothing to do with a stub package); presumably pbuilder ought to put it back
[01:43] <twb> Yup.
[01:44] <cjwatson> so seems like a pbuilder bug
[01:45] <twb> I bet it has been fixed in Ubuntu's pbuilder but not resynced upstream :-/
[01:45] <cjwatson> you would lose that bet
[01:46] <cjwatson> I checked the pbuilder source in Ubuntu before commenting
[01:46] <twb> Darn, you beat me to it, then :-)
[01:46] <geser> twb: why do you need a daemon like rsyslog inside your pbuilder?
[01:46] <twb> geser: probably xvfb or something pulls it in
[01:46] <cjwatson> daemons often wind up getting installed inside chroots by accident
[01:49] <twb> cjwatson: have you also already found the existing BTS ticket? ;-)
[01:50] <cjwatson> no, I get bored easily at 2am ;)
[01:51] <twb> No worries :-)
[01:51] <twb> BTW, is there a CLI tool like bts(1) that can talk to malone?
[01:53] <cjwatson> there are various tools based on launchpadlib; at the lowest level, there's lp-shell in ubuntu-dev-tools
[01:54] <twb> Ah, that rings a bell
[01:54] <cjwatson> 'apt-cache rdepends python-launchpadlib' (on Ubuntu) will find others
[01:55] <twb> IIRC I got ran out of time last time trying to reroll the debs for my Debian laptop.
[02:00] <geser> twb: see also https://lists.launchpad.net/launchpad-dev/msg02590.html for a "textmode bug client"
[02:01] <twb> geser: thanks.
[02:03] <persia> slangasek: The EFL stack is supposed to be pulled for netbook-launcher-efl, which is in the netbook seed.
[02:19] <chrisccoulson> cjwatson - i can make gnome-format build with the latest version of vala now, so i will upload that tomorrow
[02:19] <chrisccoulson> i'm just wondering if anyone uses gnome-format though
[02:19] <cjwatson> chrisccoulson: cool, thanks.  no idea on that
[02:19] <chrisccoulson> it's unmaintained upstream now, and replaced by other tools
[02:20] <cjwatson> I was just looking at all libparted1.8-dev's reverse build-deps
[02:20] <chrisccoulson> it might be a good time to remove gnome-format from the archive
[02:31] <crypt-0> cjwatson, i would like to help add https://mknowles.com.au/wordpress/2009/12/02/ubuntu-karmic-koala-9-10-%E2%80%93-full-disk-encryption-with-usb-key-authentication-v2/#more-81  to the ubuntu wiki https://help.ubuntu.com/community/FeistyLUKSTwoFormFactor is outdated
[02:32] <cjwatson> crypt-0: it's a wiki, you don't need my help to add to it :)
[02:32] <cjwatson> editing is encouraged
[02:32] <crypt-0> well
[02:32] <crypt-0> what credits would i have to put?
[02:32] <crypt-0> "From https://mknowles.com.au/wordpress/2009/12/02/ubuntu-karmic-koala-9-10-%E2%80%93-full-disk-encryption-with-usb-key-authentication-v2/#more-81" ?
[02:32] <cjwatson> no idea
[02:33] <crypt-0> should mail the guy first
[02:33] <crypt-0> unless i redo some of it
[02:33] <cjwatson> that would be appropriate and polite
[02:33] <crypt-0> then mail him the changes
[02:53] <twb> cjwatson: FYI, #571054 and #571056 (in debbugs), re. diverting initctl
[03:00] <cjwatson> cool
[03:08] <twb> Ah, nice, simply referencing a debbugs URL in a malone comment causes it to auto-link.
[03:08] <twb> (I filed https://bugs.launchpad.net/ubuntu/+bug/523688/+index late the other night, when tired and very grumpy.)
[03:13] <persia> twb: You can also do tricks like "Debian bug #571054 " and the bot here will post links.
[03:13] <twb> Nod.
[03:14] <twb> I haven't played with ubottu enough to memorize his pattern matching heuristics
[03:30] <slangasek> persia: ah; does the netbook seed pod not have the equivalent of ubuntu supported's "Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj"?
[03:31]  * persia has no idea and branches the seed to look at it for the first time not over someone else's shoulder
[03:32] <StevenK> slangasek: No, netbook's supported seed is blank
[03:32] <slangasek> StevenK, persia: may I suggest adding the above line, for consistent handling of such packages?
[03:33]  * persia defers to someone with commit access to the branch and familiarity, like StevenK :)
[03:33]  * slangasek defers to someone who knows where the branch is
[03:34] <StevenK> Same place as platform, ubuntu, etc, just netbook.lucid ?
[03:34] <persia> lp:~ubuntu-core-dev/ubuntu-seeds/netbook.lucid
[03:34] <slangasek> ok :)
[03:35] <StevenK> Do we need to do anything more than have Extra-Include in supported?
[03:36] <slangasek> StevenK: and make sure it's included sensibly in STRUCTURE
[03:36] <slangasek> but no uploads needed, etc
[03:37] <StevenK> Yeah, we had a blank supported to help with livecd building, so it's already in STRUCTURE and everything, it was just empty.
[03:38] <slangasek> Riddell: I've done the kubuntu-meta upload to drop bluetooth, but kdebluetooth still depends on it rather than on the bluez-* bits it needs; I guess you may want an upload of kdebluetooth before a3 to get bluez-gstreamer off the CD?
[03:40]  * StevenK blinks. Why is it that if someone else uploads d-i, it builds on ppc, and if I upload it, it doesn't.
[04:05] <mdeslaur> lucas: do you have any idea why ruby1.9 won't build for i386 with the latest lucid gcc?
[04:05] <mdeslaur> lucas: bug #526144
[04:40] <micahg> ArneGoetje: ping
[04:42] <ArneGoetje> micahg: pong
[04:43] <micahg> ArneGoetje: about the language-support-translations bug, we're probably going to have a lot of people hit this on hardy->lucid upgrades...any ideas?
[04:43] <micahg> is a release notes mention enough?
[04:44] <ArneGoetje> micahg: I'm not sure... ideally the update-manager would deal with that...
[04:45] <micahg> ArneGoetje: that's an idea..I can ping mvo in the morning and ask
[04:45] <ArneGoetje> micahg: ok, thanks
[04:45] <micahg> ArneGoetje: thank you :)
[05:45] <nixternal> any archive tweakers around?
[05:46] <StevenK> Archive tweakers?
[05:47] <nixternal> someone who has some access to look at something for me
[05:47] <nixternal> someone who can tweak their way in and tell me what I need to know :)
[05:47] <nixternal> I want to know, what is your username and password so I can break into the archives? :p
[05:47] <StevenK> And what do you need to know?
[05:48] <StevenK> Right, so no serious question.
[05:48] <nixternal> no, for real, I am wondering why 'create-resources' isn't showing up in Packages.bz2...I am getting the good ol' "it's a virtual package moron" warning when building right now
[05:48]  * StevenK dumps IRC for something more interesting
[05:49] <StevenK> nixternal: In lucid?
[05:49] <nixternal> yes
[05:49] <nixternal> create-resources |  0.1.3-2.1 | lucid/universe | source
[05:49] <nixternal> missing the good ol' ', all' there
[05:49] <Kai_> Is the Me Menu a panel applet?
[05:49]  * Kai_ searches synaptic
[05:50] <StevenK> nixternal: Are you only building from main, since it's in universe?
[05:50] <nixternal> no, I am building koffice which is now in universe
[05:51] <StevenK> Can I see a build log?
[05:51] <nixternal> there are other packages in universe that koffice deps on that is fine, just that one package
[05:51] <nixternal> yeah, let me paste bin it for you
[05:52] <nixternal> http://paste.ubuntu.com/382057
[05:53]  * nixternal keeps forgetting about pastebinit
[05:55] <slangasek> does anyone here know why empathy's lib packages (and -dev packages) went away?
[05:56] <StevenK> slangasek: I seem to recall empathy being in NBS, but I didn't bin them
[05:56] <slangasek> StevenK: yah, am working NBS right now
[05:57] <StevenK> nixternal: I think the binary package has been eaten by a Soyuz bug, since it was demoted from main to universe 10 hours ago
[05:57] <nixternal> nom nom nom :)
[05:58] <nixternal> I take it you can fix that, or is there something I need to do?
[05:58] <StevenK> I can't, no, I need to talk to someone.
[05:59] <nixternal> you can talk to sabdfl, he is a nice guy, he doesn't bite, and his name is written all over soyuz :D
[05:59] <nixternal> alrighty, I just wanted to make sure that I wasn't any more crazy than I already am
[06:53] <wgrant> StevenK: It wasn't eaten by a Soyuz bug.
[06:54] <wgrant> StevenK: It was demoted, then slangasek deleted it. I see no bug.
[06:55] <wgrant> (there is still the bug where an arch-all package that is overridden then has the overrides reverted within one publishing cycle gets eaten, but it doesn't seem to be the case here)
[06:57] <wgrant> Oh, you were talking about create-resources.
[06:57] <wgrant> That one *was* eaten by the bug I mentioned.
[07:00] <wgrant> Since the issue is very difficult to fix, it is tempting to fix change-override to bail if it's going to get a binary into that situation.
[07:07] <StevenK> wgrant: Yeah, I was talking about create-resources.
[07:08] <wgrant> StevenK: It was just off the top of my screen :(
[07:26] <nixternal> wgrant: get a bigger screen :)
[07:26] <nixternal> or shrink your fonts
[07:26] <wgrant> Pfft.
[07:35] <pitti> Good morning
[07:39] <dholbach> good morning
[07:40] <nixternal> good morning
[07:40] <dholbach> hey nixternal
[07:41] <nixternal> howdy
[07:47] <stefanlsd> wgrant: heys, do u know whats happening with motu-swat team?
[07:48] <wgrant> stefanlsd: It's purpose in the new world has not been decided, AIUI.
[07:49] <persia> It's likely to be decided sooner if people who have active involvement join the discussion :)
[07:49]  * persia can talk a lot, but isn't actually MOTU SWAT, which makes it hard to reach a known good model
[07:58] <stefanlsd> wgrant, persia: just looking at the current workflow (i used to be a member, expired, applied a while ago (other applicants also pending)). I see that motu-swat is a member of ubuntu-security-sponsors. (i think you need that indirect membership to join that team)
[07:59] <persia> stefanlsd: That matches what I know.  It needs someone to vet and accept new members to MOTU SWAT, a clear definition for MOTU SWAT in the face of ArchiveReorganisation (which may become more clear after the TB meeting today), and (I think) some MOTU SWAT representation at the weekly security team meeting.
[08:00] <wgrant> Once it becomes clear what the responsibilities of the team are, we can work out membership and ownership.
[08:00] <wgrant> But its membership in u-s-s suggests that it may confer some kind of privileges, if only socially rather than technically.
[08:03] <stefanlsd> persia, wgrant: kk. lets wait till TB meeting and i'll try pick it up with the security team as to the plans and how we can get more motu involved with security. i wrote http://people.canonical.com/~ubuntu-security/d2u/ which is an awesome tool to help people with security patches already in debian. so there lots of fairly easy work :)
[08:04] <persia> wgrant: At least based on the Security Meeting last night, I had the impression that u-s-s was intended to be the focal group for people who were reviewing and uploading security stuff (although they may need to request pocket-copies from a smaller team).
[08:05] <wgrant> persia: Right, which hints that motu-swat's original membership of just about anybody interested in security work probably needs to change.
[08:05] <persia> Quite possibly.
[08:06] <stefanlsd> persia: my understanding is that we (non members of ubuntu-security) cant upload the patches, that people in motu-swat would be able to test and ack the patches that ubuntu-security would upload. also there was discussions about the security team being more flexible wrt universe / multiverse uploads (lower barrier to entry)
[08:08] <persia> stefanlsd: I'm not sure, but I had the impression yesterday that the security team would welcome non-embargoed stuff just being uploaded, with requests to pocket-opcy to -security.  Note that special models likely apply when there has already been a non-security SRU to the package in question.
[08:09] <wgrant> The process for non-embargoed uploads could be improved with some Soyuz work.
[08:10] <wgrant> At the moment, security uploads need to build in a non-virtual PPA before the copy, because Soyuz can't do builds directly in -security.
[08:10] <wgrant> This is pointless for unembargoed fixes, where they could just be uploaded to a normal PPA then source-copied.
[08:11] <wgrant> That means that ubuntu-security would just have to hit the Copy button, which makes it much easier for them.
[08:11] <stefanlsd> wgrant: cool. lets try and take it up at monday sec meeting
[08:11] <persia> wgrant: That's surely just a workflow thing, and could be enabled with a u-s-s PPA, no?
[08:12] <wgrant> persia: Sort of. Non-virtual PPAs need to be approved by IS, and they really don't like to do it.
[08:12] <wgrant> Giving a hoard of community people access to one would probably not happen.
[08:13] <persia> Right, but u-s-s could be a virtual PPA, and u-s could pocket-copy into the non-virtual one.
[08:13] <persia> (which also makes it easier for them)
[08:13] <wgrant> True, then there's just that one extra layer.
[08:13] <persia> Right, which is still annoying, but less so.
[08:13] <wgrant> Very true.
[09:04] <slangasek> StevenK: dunno who all from your quarter tracks such things, but I've armel out-of-date/uninstallable reporting to the main report now: http://people.canonical.com/~ubuntu-archive/testing/lucid_outdate.html
[09:06] <sebner> james_w: You were in charge yesterday for the archive, would you mind telling me why you rejected docky and zyn?
[09:06] <slangasek> sebner: https://lists.ubuntu.com/archives/ubuntu-archive/2010-February/033740.html, https://lists.ubuntu.com/archives/ubuntu-archive/2010-February/033739.html
[09:07] <tkamppeter> pitti, hi
[09:07] <slangasek> jdstrand: interesting; source rejects for not using dpkg v3?
[09:07] <persia> slangasek: Some of those appear to be FTBFS (which are being tracked with some effort), and the rest appear to be timing skew (in that the package appears in the archive).  I'll poke the FTBFS folk to try to hit those packages soonest.
[09:08] <slangasek> persia: ok - wasn't asking anyone to work on them Right Now, just making sure I pass the word so people aren't wondering where it's gone :)
[09:09] <phildini> hi. if I wanted to know the status of lucid support for intel core i* processors and graphics (and possibly contribute) where could I look?
[09:09] <persia> slangasek: From a quick investigation is appears that most of it is waiting for the gtk+2,0 build to finish and could be resolved with give-backs.
[09:10] <persia> Err, and there's a good chunk of DEPWAITS on all of KDE too :)
[09:11] <sebner> slangasek: oh, thx!
[09:12] <Riddell> persia: waiting on kdebindings I guess?
[09:13] <persia> Riddell: Did that get wedged again?
[09:14] <persia> Ugh.  segfault in code generation again.
[09:14]  * persia goes off to find a volunteer
[09:15] <Riddell> yeah, blows up building smoke
[09:15] <Riddell> which I doubt anyone on armel uses so we can alter the packaging not to build it as a work around
[09:19] <persia> What is "smoke"?
[09:19] <slangasek> "Scripting Meta Object Kompiler Engine"
[09:22] <persia> And why wouldn't it be interestng to armel folk?
[09:22]  * persia 's primary laptop when traveling is armel, which perhaps gives a different perspective
[09:38] <Riddell> persia: smoke is the tool and library to create bindings for ruby and c# for qt and KDE, there aren't many apps which use those bindings
[09:39] <Riddell> persia: obviously it would be nicer to fix the compile, we just shouldn't spend too long on it
[09:39] <Riddell> persia: let me know if you find a volunteer
[09:39] <persia> Riddell: Fair.  My most likely volunteer is in the US, so I'll probably know within the next 6 hours if something useful can be done.
[09:44] <Riddell> slangasek: apachelogger was pointing out that /usr/share/icons/oxygen/icon-theme.cache is on our live CD but is only used by gnome which isn't on our live CD, can we delete that before the livefs gets squashfs'ed?
[09:45] <pitti> hey tkamppeter
[10:10] <tkamppeter> pitti, for bug 141641 I have made a new debdiff to also address Jeff's comment, now the lsb package should be ready for upload.
[10:10] <pitti> tkamppeter: with "exit 255" now?
[10:10] <tkamppeter> Yes, pitti, thank you for this hint.
[10:11] <pitti> tkamppeter: okay, will upload ASAP
[10:12] <tkamppeter> pitti, having fixed this was important, as probably in a week or so the first manufacturer-supplied driver will be posted on OpenPrinting. So there will be soon also a key to be added to the key list of Lucid.
[10:14] <tkamppeter> pitti, Now I have another problem, with system-config-printer.
[10:15] <pitti> tkamppeter: I still have your mails; will answer ASAP
[10:20] <tkamppeter> The web application of the OpenPrinting web site was replaced by a completely new one (moved from CGI + XML database to PHP + MySQL databse => LAMP). This changed nearly all URLs, so I have done some URL redirecting in .htaccess, which means that when an old URL is requested (which s-c-p naturally does in all released distros) the server sends back error status 301 and the new URL, and the client is then supposed to request the new URL.
[10:20] <tkamppeter>  s-c-p uses some kind of primitive HTTP lib and tracebacks. I have a 10-line patch to fix s-c-p. WDYT should we better apply the patch to s-c-p upstream and SRU all distros and versions or should I try to make query.cgi on the server natively behaving as query.php, to avoid redirects?
[10:20] <tkamppeter> pitti ^^^
[10:22] <pitti> tkamppeter: ideally it could be fixed on the server side; updating all boxes out there is expenseive and takes a while
[10:22] <pitti> I wouldn't mind an SRU for this, but getting this through will take a while, and it won't help live systems, etc.
[10:52] <tkamppeter> pitti, I have fixed the server now, as OpenPrinting does not use the CGI concept any more I have told Apache that .cgi files are PHP and symlinked query.cgi to query.php.
[10:52] <pitti> heh, nice
[10:56] <c_korn> did someone kill this build ? http://launchpadlibrarian.net/39601964/buildlog_ubuntu-lucid-amd64.scilab_5.2.1-3_FAILEDTOBUILD.txt.gz
[10:57] <jpds> Build killed with signal 15 after 150 minutes of inactivity
[11:00] <c_korn> inactivity means no output to the shell ?
[11:01] <Laney> yes
[11:01] <cjwatson> yes (well, not the shell, just no output on stdout or stderr)
[11:02] <c_korn> well, there is still activity. it just takes some time: https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1517734
[11:03] <c_korn> Build needed 06:32:51, 1024900k disc space
[11:04] <c_korn> https://buildd.debian.org/fetch.cgi?&pkg=scilab&ver=5.2.0-7&arch=amd64&stamp=1266339679&file=log
[11:04] <c_korn> can this inactivity check be disabled for scilab ? as you can see it compiles fine in a PPA
[11:05] <c_korn> the i386 build also succeeded: https://launchpad.net/ubuntu/+source/scilab/5.2.1-3/+build/1525157
[11:10] <cjwatson> c_korn: just make it output something every so often
[11:13] <c_korn> well, I don' think you want something like: while true ; do echo hello ; sleep 60 ; done
[11:13] <c_korn> i is the parsing of the master document which takes so long
[11:13] <c_korn> s/i/it/
[11:13] <c_korn> and it is done by an underlying library
[11:14] <cjwatson> in fact there are some long-building packages that do something quite similar to that, as a watchdog process in the background
[11:14] <cjwatson> better that than having to mess around making exceptions at the buildd level
[11:16] <Laney> check out agda — I recently added a watcher to that as it was timing out on armel
[11:20] <tkamppeter> pitti, OpenPrinting server is fixed and Karmic downloads both packages and single PPDs without any patches, so you can do all tests described in the mails I sent to you and the problems are not caused by the server.
[11:20] <pitti> tkamppeter: thanks
[11:27] <Ixan> i'm having some problems with oem-config. when oem-config-firstboot runs, it exits after a couple of seconds with "error: the oem installer failed"
[11:28] <cjwatson> /var/log/oem-config.log would come in handy
[11:30] <c_korn> Laney: I don't see a watchdog in the diff.gz. did you implement it in the agda tarball ?
[11:31] <Laney> look harder
[11:33] <Ixan> cjwatson: http://pastebin.ubuntu.com/382190/
[11:34] <Ixan> this is 10.04 a2, but i got the same symptom on 9.10. warning,i've used preseed for unattended install
[11:34] <cjwatson> then I need to see your preseed file too
[11:35]  * c_korn was looking in the wrong diff.gz *cough*
[11:36] <tkamppeter> pitti, thanks for the upload of "lsb".
[11:36] <Ixan> http://pastebin.ubuntu.com/382192/ preseed-file
[11:36] <cjwatson> Ixan: actually if you could file a bug against ubiquity with all of this ...
[11:36] <Ixan> roger
[11:38] <cjwatson> Ixan: incidentally, you know that 'd-i passwd/user-uid string 1010' will have some very odd effects, don't you?
[11:38] <Ixan> no, i'll test with 1000
[11:38] <cjwatson> no, just leave it out!
[11:38] <cjwatson> you don't need to set it
[11:38] <Ixan> yeah, found it odd it was in the examples i saw
[11:39] <Ixan> i'll retest without it for 10.04 and 9.10
[11:39] <Ixan> before bug report
[11:40] <Ixan> took me a whiel to figure out it was oem-config which crashed. it started in terminal 8, but after boot i just got text login up in term 1. no note nor nothing that something had crashed
[12:05] <asac> slangasek: odd. let me check with desktop team
[12:17] <Ixan> cjwatson: got the same problem after removind uid 1010. filed a bug report. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/526405
[12:18] <cjwatson> Ixan: yeah, didn't say it had anything to do with this specific problem :)
[12:18] <cjwatson> I suspect debconf_ui is just broken
[12:18] <cjwatson> (again)
[12:19] <Ixan> i'll check 9.10 and see if it's the same there.
[12:26] <cjwatson> Ixan: debconf_ui was definitely known-busted in 9.10, wouldn't bother if I were you
[12:26] <cjwatson> I'd thought I'd got it fixed though
[12:27] <cjwatson> anyway, on my queue
[12:29] <Ixan> good shit
[12:30] <Ixan> i'll toss in a feature request for luks-ed /home with oem-config at the same time =)
[12:31] <cjwatson> not if you want me to get to your first request ;)
[12:32] <Ixan> hehe, sounds sensible ;)
[12:35]  * ogra arghs
[12:35] <ogra> so logging out and switching consoles, then switching back to gdm suspends my machine
[12:35] <jdstrand> slangasek: re dpkg v3> no? which made you say that?
[12:36] <ogra> 100% reproducable
[12:37] <jdstrand> slangasek: if there were rejectable items then I might also suggest improvements such as dep-5 and dep-3...
[12:40] <cjwatson> jdstrand: you can only use .orig.tar.bz2 with source format v3, and even then we don't yet recommend it because there are believed to still be some Soyuz bugs related to that
[12:40] <cjwatson> jdstrand: the historical practice is to recompress with gzip, even though this isn't optimal and requires coordination with Debian to avoid differing .orig.tar.gz files
[12:41] <persia> There are some recipes on the wiki for constructing get-orig-source rules that repack in a repeatable-checksum manner.
[12:41] <jdstrand> cjwatson: ah, I see
[12:41] <cjwatson> repeatable> gzip -n, basically
[12:41] <cjwatson> but of course that only works if the Debian maintainer uses the same recipe
[12:41] <persia> -nf actually, to deal with potential architecture or filesystem skew.
[12:42] <jdstrand> I'll follow up on that one-- I tried a gzip on my own, but it didn't work. I didn't try -nf
[12:42] <persia> Right, but it's been historically easier to file a bug attaching a get-orig-source snippet than a binary blob :)
[12:43] <persia> jdstrand: We usually recommend -9nf just for space savings, but the 9 doesn't actually matter.
[12:43] <apachelogger> cjwatson: hey, could you please approve jonathan thomas' mail to devel-permissions (should have been sent a week ago or so)
[12:43] <jdstrand> slangasek: nm
[12:44] <cjwatson> apachelogger: done
[12:44] <apachelogger> cjwatson: thanks :)
[12:44] <jdstrand> cjwatson, persia: thanks for the info
[12:45] <persia> jdstrand: That's why we have an IRC channel :)
[12:45] <jdstrand> :)
[12:45] <kvalo> hello. I'm having problems upgrading an old thinkpad t30 to lucid:
[12:46] <kvalo> (**) Option "xkb_layout" "fi"
[12:46] <kvalo> Failed to alloc memory
[12:46] <kvalo> http://paste.ubuntu.com/382225/
[12:46] <kvalo> and X segfaults
[12:46] <mdeslaur> slangasek: yesterday I uploaded ruby1.9, and it fails to build on i386 with the most recent gcc that was uploaded a week ago. So, currently the i386 archive has an older ruby1.9. I'm not quite sure how to handle this, any ideas?
[12:46] <kvalo> if I use failsafe mode from gdb, X works. problem related to 3d or what?
[12:47] <kvalo> s/gdb/gdm/
[12:47] <soren> Sometimes when I mkfs a loopback device and immediately afterwards run e.g. "blkid -sUUID -ovalue /dev/mapper/loop1p1" on it, it fails (exit code 2).
[12:47] <soren> blkid docs says that "If the specified token was not found [...] an exit code of 2 is returned".
[12:48] <soren> Will a "udevadm settle" in between the two solve it?
[12:48] <soren> Yes, I could just try it, but it only happens every one in 15-20 times, so it's hard to determine if it's actually fixed or I'm just lucky for a while.
[12:50] <persia> soren: It ought, assuming that there's not a timing gap between the event being "handled" and the device node being available.
[12:50]  * persia believes there not to be such a gap
[12:51] <soren> I /think/ udev is triggered by mkfs calling close() on the device node.
[12:51] <soren> The device node is already there (since I could call mkfs on it).
[12:51] <persia> In that case, `udevadm settle` won't do anything.
[12:52] <soren> So, assuming the inotify event reaches udev before my "udevadm settle" call does, I should be safe. That makes sense.
[12:52] <soren> persia: Well, it'll wait until udev is done handling it, surely?
[12:52] <soren> Or am I misunderstanding udevadm settle?
[12:54] <persia> I believe `udevadm settle` to hang until all udev events have been processed.  I don't believe that mkfs generates a udev event.
[12:55] <soren> persia: mkfs as such doesn't. However, opening a device node and closing it again, does. I /think/.
[12:56] <persia> Ah, I thought it didn't.  Maybe someone else actually knows :)
[12:57] <soren> Yeah. Where's
[12:57] <soren> Keybuk when you need him? :)
[12:57]  * soren runs vmbuilder and stares at "udevadm monitor"
[12:58] <soren> Err.. Something certainly happened :)
[12:58]  * soren adds some sleeps here and there to make sure.
[13:02] <soren> persia: Yup, there are certainly udev events to be handled after mkfs. Yay.
[13:03] <persia> Oh, cool.  In that case: "Yes, using udevadm settle will do precisely what you want" :)
[13:03] <Chipzz> kvalo: I'm sorry, I think you're mistaking this channel for a support channel :) pls read the topic
[13:11] <kvalo> Chipzz: so lucid regressions should be discussed in #ubuntu?
[13:12] <kvalo> btw, seems to be kms problem
[13:16] <cjwatson> kvalo: #ubuntu+1 specialises in support-type things for stuff that hasn't been released yet
[13:16] <kvalo> cjwatson: ok, thanks. I'll bring this up there
[13:19] <Chipzz> kvalo: no, #ubuntu+1
[13:20] <Chipzz> cjwatson: that did seem to get dropped from the topic though
[13:21] <cjwatson> Chipzz: *shrug* space constraints, and it doesn't matter all that much if the odd person comes in here
[13:22] <kvalo> Chipzz: thanks, I'll ask for help there. sorry for bothering you
[13:56] <RainCT> seb128: Hey. Can you still give Feature Freeze exceptions this cycle? If so, I'd like to sync gnome-activity-journal 0.3.3 (once I get it uploaded into Debian).
[13:56] <seb128> RainCT, I don't know but that one should be no issue even if I'm not the one granting it
[14:08] <RainCT> seb128: Yeah, just wondering if I need to file a bug (and if so, whom to subscribe? motu-release?)
[14:08] <seb128> dholbach, ^
[14:11] <dholbach> RainCT: slangasek is going to send out a process proposal later today - for now I'd just say follow the old process
[14:11] <persia> RainCT: file a bug and subscribe ubuntu-release.
[14:12] <dholbach> ScottK, iulian, nhandler: ^
[14:17] <RainCT> seb128, dholbach, persia: OK, thanks.
[14:50] <cjwatson> argh
[14:50] <cjwatson> what's the point of moving to source format 3.0 AND KEEPING DBS
[14:56] <persia> tradition?
[15:56] <Laney> which team grants access to upload source NEW packages to Ubuntu?
[15:57] <jpds> Laney: ~ubuntu-dev?
[15:57] <Laney> jpds: I don't know, as PPUs are members there AFAIK
[15:57] <cjwatson> er, *cough*, this is a bit of a process hole atm
[15:58] <cjwatson> technically, right now, the answer is motu
[15:58] <cjwatson> I think
[15:58] <Laney> yes, I was just thinking about the new set
[15:58] <Laney> whether CLI/Mono developers would be able to upload NEW packages for the set
[16:01] <cjwatson> Laney: so, at worst: upload to PPA (so that the sourcepackagename is valid in Launchpad), have TB add the name to the set, upload to archive
[16:01] <cjwatson> Laney: I don't recall just now whether the first step is needed
[16:01] <Laney> oh, that works?
[16:01] <cjwatson> we may be able to add arbitrary strings as package names, but I have a suspicion that the LP DB will want them to be SPNs
[16:01] <cjwatson> but uploading to a PPA is enough to make that work
[16:01] <Laney> It's not really a problem for us as we have MOTU
[16:04] <Laney> so LP will check for PPU upload rights even for source NEW, that's good.
[16:04] <cjwatson> Laney: I *think*.
[16:04] <Laney> well, we can see if this ever comes up
[16:04] <cjwatson> actually I think it may have come up with linux-backports-modules-2.6.32, now that you mention it
[16:04] <cjwatson> not sure
[16:11] <micahg> mvo: ping
[16:12] <jdstrand> ScottK: I'm working on clamav -backports to -security for hardy. All I should need it https://wiki.ubuntu.com/MOTU/Clamav correct?
[16:12] <jdstrand> ScottK: hi btw :)
[16:15] <mvo> micahg: pong
[16:16] <micahg> mvo: we had an issue with a deprecated package language-support-translations trying to pull in apps on a hardy -> lucid upgrade...is there any way for update manager to remove it on upgrade?
[16:16] <micahg> mvo: bug 525866
[16:18] <kees> micahg: I'm seeing this bug: http://superuser.com/questions/76625/unable-to-click-on-tabs-in-firefox-unless-i-press-command-q with all my extensions disabled.  do you have any idea what I can try next?
[16:19] <mvo> micahg: yes, let me read the bug
[16:19] <micahg> kees: --safe-mode or -ProfileManager
[16:19] <micahg> mvo: thanks
[16:21] <kees> micahg: both.
[16:21] <kees> micahg: it's crazy -- I have hit ctrl-Q several times before ff behaves correctly again
[16:21] <kees> micahg: it's like it's stuck prompting somewhere, but doesn't actually prompt
[16:21] <micahg> kees: can you get a backtrace when it sitcks
[16:22] <micahg> *sticks
[16:22] <kees> micahg: I can, but it still mostly works (i.e. I can click links on the current tab, sometimes I can ctrl-tab to new tabs, but clicking tabs doesn't work, can't pop new dialogs, etc)
[16:23] <kees> micahg: trivial to reproduce for me; you just want a gdb thread backtrace?
[16:25] <kees> micahg: http://paste.ubuntu.com/382349/
[16:25] <micahg> maybe an strace will be better...you don't have to load all the dbg libs
[16:25]  * micahg guesses it's an extension
[16:25] <kees> all my extensions are disabled.
[16:26] <kees> even the media plugins are disabled
[16:26] <slacker_nl> hello, will lucid convert grub-legacy to grub2? like debian testing does
[16:27] <cjwatson> not planning to at the moment; it's possible we may revisit this but currently not planning to
[16:27] <cjwatson> got enough to do :)
[16:28] <slacker_nl> mkay, too bad, it made my day when I upgraded to testing from stable :)
[16:28] <kees> micahg: any clue what to do next?  strace shows nothing, and gdb backtraces are identical before/after the ctrl-Qing
[16:29] <cjwatson> yeah, problem is dealing with the people whose days it ruins ;-)
[16:29] <slacker_nl> the FF bug sounds familiar, I cannot close tabs, it then closes my FF
[16:29] <slacker_nl> cjwatson: hehe :)
[16:30] <micahg> kees: mozilla 508738
[16:31] <directhex> slacker_nl, is nyu including my grub2 theme yet? i know he mentioned it
[16:32] <kees> micahg: I'm not sure if that's my bug, but I'll comment
[16:35] <slacker_nl> directhex: i do not follow
[16:35] <directhex> slacker_nl, does your debian grub2 have a graphical menu screen?
[16:35] <slacker_nl> yes
[16:36] <cjwatson> I don't see that in the package yet
[16:36] <cjwatson> I think it's just a graphical background
[16:39] <micahg> kees: maybe file a new bug upstream
[16:40] <Riddell> ev: seele is wondering why the "update the installer" button is needed?
[16:43] <ev> Riddell: can you expand on that?  It gives us a way to get a newer version of the installer to users on released CDs, in case things go horribly wrong at release.
[16:43] <ev> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-auto-upgrade
[16:44] <Riddell> ev: why is it a button rather than something it just does?
[16:45] <ogra> doko, do you happen to have any idea about bug 520465 ?
[16:46] <ev> Riddell: well, for one it requires internet access, which not everyone has at install time.  But cjwatson would be able to give you an exact answer (he did UI and code for this).
[16:46] <cjwatson> also don't want to block starting the installer on a network probe
[16:47] <cjwatson> don't want to phone home by default noninteractively
[16:47] <cjwatson> don't want to unconditionally break older working installers in the event that we release a broken installer (particularly the case during development cycles, but not exclusively)
[16:47] <doko> ogra: no, didn't look yet
[16:47] <cjwatson> don't want to impose the extra memory cost of installing a new installer package (it has to be entirely in RAM due to how the live CD works), which might render some systems unable to install Ubuntu
[16:48] <cjwatson> that's just what I can think of right now
[16:51] <cjwatson> bryceh,pitti: problem: ubuntu-desktop now transitively depends on grub-pc - ubuntu-desktop -> xserver-xorg-video-all -> xserver-xorg-video-nouveau -> linux-backports-modules-nouveau-lucid-generic -> [...] -> linux-image-* -> grub-pc (recommends)
[16:52] <bryceh> cjwatson, ew
[16:52] <tseliot> slangasek: is it ok if I upload the fix for bug #467490 after alpha 3?
[16:52] <cjwatson> bryceh,pitti: this is bad because it subverts the installer's logic for boot loader installation and causes bug 526422.  we've always tried hard to keep linux out of the desktop task for this reason.  what can we do about this?
[16:53] <pitti> cjwatson: (lagging, desktop meeeting going on)
[16:53] <bryceh> cjwatson > #ubuntu-x 2>&1
[16:53] <pitti> cjwatson, bryceh: would it be prudent to drop the video-nouveau -> lbm dependency?
[16:53] <pitti> the other video drivers don't depend on the kernel either
[16:53] <pitti> of course that'd require them to cleanly fail to load if the module isn't present
[16:53] <bryceh> pitti, but then would l-b-m-nouveau not be included in the cd?
[16:54] <pitti> bryceh: we'd need to seed it explicitly somewhere, I guess
[16:54] <cjwatson> but then that would have the same problem
[16:54] <pitti> or make it a recommends of linux-image in linux-meta
[16:54] <bryceh> as long as that's done it'd be fine.  afaik that's the only reason we put the dep on it in there
[16:54] <cjwatson> I don't see a clean way to do this, short of making the kernel image package *depend* on lbm-nouveau
[16:55] <cjwatson> a recommendation would be ineffective in this case
[16:55] <cjwatson> the installer ignores recommends when installing the kernel package, and has to do so because otherwise it would pick up boot loaders when doing so
[16:56] <pitti> cjwatson: so the actual linux-image-* -> grub-pc (recommends) should stay and is intended?
[16:56] <cjwatson> but I would expect that having the kernel image package depend on lbm-nouveau would cause a chicken-and-egg problem on ABI transitions
[16:56] <cjwatson> pitti: yes
[16:56] <cjwatson> it's recommends: grub-pc | <other boot loaders>
[16:56] <cjwatson> and it got lifted to that due to another bug, iirc
[16:57] <cjwatson> apw: ^- is there any chance that we could just have lbm-nouveau integrated into the main kernel package?
[16:57] <cjwatson> I wonder if there's any seed trickery I could do
[16:57] <pitti> short of that, the only way I see is to make it a dpeendency of -generic, but not of -server
[16:57] <c_korn> Laney: I think I did something wrong with the watcher :/ why is there another tick after the terminating message ? https://launchpad.net/builders/platinum/+index
[16:57] <pitti> which should amount to the same thing than integrating nouveau into -generic itself?
[16:57] <cjwatson> but lbm-nouveau can't be built until after the main package is built
[16:58] <pitti> but might be easier to maintain by the kernel team
[16:58] <apw> cjwatson, that is likely possible though pretty hard, but we may well be getting rid of it in favour of a bigger backport
[16:58] <apw> cjwatson, wahts the issue?  isn't lbm-nouveau a dep of the x-server?
[16:59] <Laney> c_korn: you have two watchers running
[16:59] <cjwatson> yes, the issue is that that dependency pulls in grub-pc indirectly at a point when the installer is not prepared to install a boot loader
[17:00] <cjwatson> (see scrollback)
[17:00] <apw> cjwatson, so lbm is recommending grub ?
[17:00] <cjwatson> no, linux-image recommends grub-pc
[17:01] <cjwatson> and should continue to do so, that's desirable for other reasons
[17:01] <apw> got ya
[17:01] <cjwatson> indeed I think there's a sabdfl bug on the subject
[17:01] <apw> hrm, tricky
[17:01] <cjwatson> I'm trying some seed madness
[17:01] <c_korn> Laney: any idea how this can happen ? I copied your watcher.sh and pasted this into the debian/rules http://pastebin.com/yBpggnva
[17:01] <cjwatson> the kernel's already installed, so in theory I just need to get it out of the task
[17:02] <cjwatson> actually there's another problem
[17:02] <Laney> c_korn: do "debcheckout agda" and use the version from there
[17:02] <cjwatson> x-x-v-nouveau depends specifically on linux-backports-modules-nouveau-lucid-generic
[17:02] <cjwatson> bryceh: ^- that will break if the user installed the PAE kernel
[17:02] <apw> cjwatson, i believe that just got fixed ... like today
[17:02] <bryceh> cjwatson, yeah fixed that yesterday
[17:03] <cjwatson> ah
[17:03] <apw>   * debian/control
[17:03] <apw>     + Add -pae as fulfilling dependency
[17:03] <apw>       (LP: #524792)
[17:03] <cjwatson> ok, although I don't think the installer will be smart enough right now to pick the right now
[17:03] <cjwatson> *right one
[17:04] <cjwatson> we might have to arrange for the lbm package to be installed explicitly when installing the kernel, or something
[17:06] <c_korn> Laney: ah, it uses a lock file I see. does "exit 1" mean that the compilation will fail if two watchers are spawned ?
[17:06] <Laney> no, the second watcher will exit
[17:06] <apw> cjwatson, damn ... i am not sure we'll be doing that for much longer ...
[17:07] <cjwatson> doing which?
[17:07] <c_korn> Laney: fine, I thank you
[17:08] <apw> cjwatson, necessarily doing the backport that way
[17:08] <cjwatson> right
[17:11] <cjwatson> I've worked around most of this at the installer level for now
[17:12] <cjwatson> but in general, direct kernel dependencies in the desktop seed are problematic, and we should try to avoid them
[17:12] <apw> ok
[17:15] <c_korn> Laney: but I don't quite understand why the second watcher does not terminate.
[17:16] <Laney> you should examine how it is invoked
[17:19] <c_korn> Laney: I would like to if I had the build log. is there a timeout for PPAs (even if output is still occuring) ? (although I do not see the watcher tick again in the build log. so it should be terminated already)
[17:20] <Laney> it will be terminated soon enough
[17:21] <c_korn> ok
[17:51] <cjohnston> mbudde: ping
[17:51] <randomaction> sgnb: there are 3 unfinished builds from round 2 (confluence, jocaml, ocamldsort), am I right in thinking that round 3 can start without waiting for them (i.e. no rdepends of these 3 packages are involved in round 3)?
[18:01] <porthose> Would a kind core-dev please have a look at bug #526587 thx :)
[18:32] <slangasek> Riddell: hmm, if the cache is removed from the livefs, will it be regenerated at install time?  If a user installs packages in the live environment that want it, will it be regenerated then?
[18:32] <slangasek> Riddell: (I guess this is a size issue?)
[18:32] <cjwatson> slangasek: I asked the same question on #ubuntu-release
[18:33] <Riddell> slangasek: still trying to work out what actually creates the cache in the first place
[18:33] <cjwatson> and there was a conversation there
[18:37] <slangasek> mdeslaur: have you checked with doko?  if toolchain changes uploaded at FF are causing build regressions, he may know why (and if not, he should be in the loop)
[18:37] <slangasek> mdeslaur: the particular error certainly looks like a toolchain regression to me...
[18:37] <slangasek> cjwatson: ok, will process that window next :)
[18:38] <doko> slangasek: which one is this?
[18:38] <slangasek> doko: ruby1.9/i386 FTBFS
[18:38] <doko> seen, but the report didn't have infos pointing to the toolchain
[18:41] <cjwatson> I'm reaching end-of-day; if anyone could help to track down bug 526391 in the meantime, I would be very grateful - d-i is very ugly right now
[18:42] <slangasek> seb128: that's the last gtk+2.0 upload for a3, right?  Because we kinda need gtk installable on armel if we're going to have it included in the milestone...
[18:43] <seb128> slangasek, yes, and I only uploaded -0ubuntu6 because -0ubuntu5 failed on armel
[18:43] <slangasek> doko: the error in the log says "<dummy toplevel>:17: unexpected throw"
[18:43] <slangasek> seb128: ah, ok
[18:43] <seb128> slangasek, well it didn't fix the build issue which was a random segfault but since a rebuild was needed anyway
[18:43] <slangasek> seb128: <nod>
[18:43] <seb128> slangasek, anyway no desktop changes coming now
[18:43] <seb128> or at least not lib ones
[18:43] <slangasek> seb128: ok, good :-)
[18:44] <doko> slangasek: hmm, I did interpret this as a ruby failure ...
[18:44] <seb128> I might squeeze an app fix later
[18:44] <slangasek> cjwatson: can't guarantee I'll get to 526391, but adding it to the list
[18:44] <slangasek> doko: but the commandline above it is a gcc call? :)
[18:45] <slangasek> oh, no, there's an intervening 'make'
[18:45] <slangasek> sorry
[18:45] <slangasek> mdeslaur: was this ruby1.9 FTBFS reproducible?
[18:45] <sebner> slangasek: I uploaded a new package before FF and it got now rejected because of md5sum mismatch, my understanding is that I don't need a FFe now because nothing is changed for a new upload, right? ;-)
[18:45] <lucas> you shouldn't care too much about ruby1.9
[18:46] <lucas> the plan for debian squeeze is to ship ruby1.8 and ruby1.9.1
[18:46] <lucas> we are currently dropping library packages for 1.9(.0) and providing them for 1.9.1 instead
[18:46] <lucas> that transition is almost done
[18:47] <lucas> I'd would be silly not to follow that in Ubuntu (you would end up with some libs with 1.9.1 binary packages, and some other with 1.9.0 binary packages)
[18:47] <lucas> s/I'd/it
[18:48] <lucas> mdeslaur/slangasek: ^
[18:51] <cjwatson> slangasek: so, bug 524439 - the fix involves migrating console-setup to upstart jobs.  I think this would be a good idea but I'm a bit wary of trying to do it for a3 now.  Should we move it to b1?
[18:54] <slangasek> sebner: yes, that should be ok
[18:55] <sebner> slangasek: great, thanks
[18:56] <slangasek> lucas: ehm, we're past feature freeze and currently have ruby 1.9 in main and ruby 1.9.1 in universe; someone would need to steer this transition on the Ubuntu side and come up with a plan of action quickly, are you in a position to work that out or do you know someone else on the Ubuntu side who would?
[18:56] <lucas> I could do that
[18:56] <lucas> why is ruby 1.9 in main?
[18:57] <slangasek> cjwatson: yes, I think deferring 524439 makes sense here
[18:57] <lucas> slangasek: (probably as a dep of something, but I'd need to know what that something is)
[18:57] <slangasek> lucas: according to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/all, it's rrdtool
[18:58] <lucas> slangasek: ah, ok
[18:58] <slangasek> lucas: though germinate only ever tells you first-match, so there could be other reasons
[18:58] <slangasek> lucas: rrdtool, libaugeas-ruby
[18:58] <slangasek> (EOF)
[18:58] <lucas> libaugeas-ruby? why do you have that in main?
[18:59] <slangasek> lucas: for puppet
[18:59] <lucas> anyway, both were already migrated to 1.9.1. rrdtool is a newer version, so the patch would have to be backported
[18:59] <lucas> ok
[19:00] <cjwatson> slangasek: I think it's probably something like http://paste.ubuntu.com/382441/, but I *know* there are subtleties here, like making sure dpkg-reconfigure saves the keymap
[19:01] <cjwatson> and IIRC Scott wanted setupcon to run as a udev rule, though perhaps an upstart job is an acceptable stopgap
[19:05] <slangasek> cjwatson: udev rule sounds non-trivial, since it also has to wait for /usr, doesn't it? (I assume - since otherwise it wouldn't need to be 'start on filesystem')  So would probably have to be an upstart job regardless
[19:08] <slangasek> mdeslaur: answer: yes, the FTBFS is reproducible
[19:31] <Cascade_> New programming forum! http://www.hackersrus.info JOIN!
[19:34] <apw> does anyone know if we expect plymouth fsck integration to work completly?  i think i just hit ESC on it and instead of stopping plymouth exited and the fsck continues (it looks like)
[19:35] <slangasek> apw: 'esc' isn't supposed to stop the fsck
[19:35] <apw> heh is anything?
[19:35] <slangasek> apw: did you have a '[C]' sitting on your screen before you hit esc?
[19:36] <apw> nope, i had the fsck and the red? progress bar
[19:36] <apw> so i hit escape, does that just kill plymouth?  have i been a wally?
[19:36] <slangasek> there are a number of completely opaque keys you're supposed to be able to press for various actions; you should get a line telling you what the keys are, but not what they do...
[19:36] <slangasek> apw: try hitting 'esc' again, see if it comes back :-)
[19:37] <cjwatson> slangasek: keyboard-setup doesn't necessarily, maybe console-setup does - personally I do tend to think that a udev rule may be more trouble than it's worth although it seems to be a sort of theoretical ideal
[19:37] <apw> slangasek, oh yeah it did.  what does the [C] indicate?  cancel?
[19:37] <slangasek> apw: I think so
[19:37] <slangasek> [C]ancel, [S]kip, [M]aintenance
[19:37] <apw> ahh ... thats not at all intuitive, and the semantic change for ESC is going to hurt peoples heads ...
[19:37] <apw> i suspect a release note may be in order
[19:38] <slangasek> well, I think we need to get that text fixed before release
[19:38] <slangasek> there's an open bug on mountall about it
[19:38] <apw> that would help a lot
[19:38] <apw> sorry for the noise
[19:38] <sebner> slangasek: what's the difference between Cancel and Skip?
[19:39] <slangasek> sebner: cancelling an fsck vs. skipping waiting for a filesystem
[19:39] <sebner> the same for me
[19:39] <sebner> nearly
[19:40] <slangasek> no, they're opposite
[19:40] <slangasek> cancelling the fsck will cause it to try to mount anyway, skipping waiting for the filesystem will cause the boot to proceed without mounting
[19:40] <slangasek> (I think)
[19:41] <sebner> slangasek: and what happens if that's the root partition you skip?
[19:41] <slangasek> you don't always get all the options :)
[19:42] <sebner> what a magic and intelligent system ;D
[19:46]  * ogra wishes mountall was that clever :)
[19:46] <ogra> ... and would learn to handle broken hwclocks :)
[20:02] <mdeslaur> lucas, slangasek: I've spent a lot of time trying to get ruby1.9 to compile with the -2ubuntu2 gcc revision, and failed
[20:02] <slangasek> mdeslaur: and if you roll back to the previous gcc, it works?
[20:02] <mdeslaur> lucas: if you can get 1.9.1 in main instead of 1.9, that would be great
[20:03] <mdeslaur> slangasek: yes, going back to -2ubuntu1 works fine
[20:03] <slangasek> mmk
[20:04] <xnox> mvo: your awesome! #ubuntusoftwarecentre
[20:06] <lucas> slangasek, mdeslaur: actually, it might be easier to get ruby1.9.* out of main. it only requires dropping the dependency in rrdtool and libaugeas-ruby, and the 1.9 binary packages don't have any other users in the archive.
[20:06] <lucas> slangasek, mdeslaur: given that 1.9.{0,1} are development branches of ruby, it's probably a good idea not to support them
[20:06] <mdeslaur> lucas: I agree
[20:06] <slangasek> lucas: no objection from me
[20:08] <mdeslaur> lucas: looks like libaugeas-ruby1.8 is in main, 1.9 is in universe already
[20:11] <lucas> mdeslaur: yeah, but I guess that the problem is that libaugeas-ruby build-depends on ruby1.9
[20:12] <mdeslaur> oh, I see
[20:12] <lucas> mdeslaur: (same for rrdtool, probably)
[20:12] <cjwatson> slangasek: I think I found a Debian bug matching the described screen corruption symptoms, with an analysis
[20:13] <cjwatson> yay Debian
[20:13] <mdeslaur> lucas: actually, libaugeas-ruby only builds libaugeas-ruby1.8 for lucid, so it's not a problem (libaugeas-ruby1.9 is not in lucid)
[20:14] <lucas> mdeslaur: ah
[20:14] <lucas> mdeslaur: it was forked, and not merged, so it's severely outdated in ubuntu
[20:15] <lucas> mdeslaur: it's probably a good idea to merge it from debian
[20:15] <lucas> (correction: it wasn't forked, it was introduced independantly in ubuntu by DktrKranz in jaunty time)
[20:16] <mdeslaur> nothing seems to depend on librrd-ruby1.9
[20:17] <lucas> mdeslaur: "and the 1.9  binary packages don't have any other users in the archive.
[20:17] <lucas> "
[20:17] <lucas> ;)
[20:17] <mdeslaur> lucas: die-ruby1.9-die-die-die
[20:18] <lucas> mdeslaur: do you want to patch rrdtool to drop the ruby1.9 package?
[20:18] <mdeslaur> lucas: I can do that, sure
[20:19] <lucas> mdeslaur: on my side, I'll prepare a list of syncs from debian for the ruby packages
[20:22] <mdeslaur> lucas: sounds good, as long as you remove libaugeas-ruby1.9.1 from the debian libaugeas-ruby package
[20:23] <lucas> mdeslaur: my plan was to patch that specific package in ubuntu, not in debian
[20:23] <mdeslaur> lucas: yes, perfect
[20:23] <mdeslaur> (that's what I meant)
[20:30] <cjwatson> superm1: you seem to have sent a reply to me to ubuntu-devel containing only quoted text?
[20:33] <superm1> cjwatson, reply should be below your text
[20:33] <cjwatson> superm1: https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030294.html doesn't show it.  Is this a list archives bug?
[20:34] <cjwatson> oh, it's failing to handle From-escaping correctly
[20:34] <cjwatson> poo
[20:34] <cjwatson> I think this is a known list-archives bug, I vaguely recall there being an RT ticket on it from ages back
[20:34] <superm1> in the interim should I just top reply instead?
[20:34] <cjwatson> no, it breaks any time you have "From" at the start of a line :)
[20:35] <superm1> oh :)
[20:35] <mdeslaur> slangasek: I'm about to upload rrdtool that removes the ruby1.9 main requirement, any objections? and, what's the next step to remove ruby1.9 from main? (that was the only dependency)
[20:35] <cjwatson> it's doing stupid mbox parsing somewhere
[20:36] <tremolux> mvo
[20:36] <tremolux> (woops, scuse me)
[20:36] <mvo> :)
[20:36] <mvo> no worries
[20:37] <cjwatson> slangasek: ok, so newt uploaded to fix the d-i screen corruption; will require a d-i upload once it's built everywhere
[20:39] <slangasek> mdeslaur: libaugeas-ruby was the other rev-build-dep, that will also need uploaded?
[20:40] <slangasek> cjwatson: ack, will follow
[20:40] <mdeslaur> slangasek: it's not a rev-build-dep on lucid
[20:40] <slangasek> mdeslaur: yes, it is
[20:40] <mdeslaur> slangasek: oh, yes it is, I'll fix that too
[20:41] <mdeslaur> it's not even building the binary packages for ruby1.9 anyway
[20:41]  * slangasek nods
[20:48] <mdeslaur> slangasek: packages uploaded
[20:50] <slangasek> mdeslaur: cheers :)
[20:50] <mdeslaur> slangasek: will the seeds correct themselves, or does someone need to move ruby1.9 to universe?
[20:51] <lucas> mdeslaur: have you took the opportunity to merge libaugeas-ruby from debian? there's probably not much point in keeping the older version in lucid.
[20:51] <mdeslaur> lucas: no, I haven't...I just wanted to get the ruby1.9 build dep out for now
[20:52] <lucas> slangasek: can I submit a bug with a list of sync requests, or should I file one bug per sync req?
[20:53] <slangasek> lucas: it's generally easier on the process to submit one bug per package; for one thing, you can use 'requestsync' that way
[20:54] <slangasek> (instead of having to open tasks by hand for each package)
[20:54] <lucas> slangasek: ok
[21:03] <mdeslaur> fyi, I have opened bug 526677 to get ruby1.9 moved to universe
[21:04] <mrenouf> Is it possible to make unattended-upgrade work like 'apt-get distupgrade' ? Specifically, permit it to install versions with new dependencies?
[21:05] <slangasek> mdeslaur: bug isn't needed, as soon as it no longer has revdeps it'll show up on component-mismatches and be processed semi-automatically
[21:05] <mdeslaur> slangasek: ah! thanks for the info!
[21:42] <sgnb> randomaction: right
[21:42] <sgnb> (basically everything in round 3 depend on findlib)
[21:57] <randomaction> sgnb: ok, I'll do some of the rebuilds tomorrow and will advertise this transition on #ubuntu-motu a bit
[22:02] <Laney> you should email the mailing list about it
[22:03] <randomaction> ok, will do
[22:05] <jdstrand> sbeattie: hey. fyi I fixed test-clamav.py in qrt so it should actually work now (verified on lucid as well as pending update for hardy)
[22:06] <jdstrand> sbeattie: I saw it on the qa-lucid-automated-server-testing bp and thought that its brokenness may have been why it was postponed
[22:07] <jdstrand> oh, that is actually for ara
[22:07] <sbeattie> jdstrand: I think there was something in the documentation about needing to wait for clamavd to start before running that had me not pursue it.
[22:08] <jdstrand> sbeattie: there is a sleep call waiting for clamd.ctl. I t*think* that was only needed on feisty, but I'm not sure
[22:08] <jdstrand> anyhoo, it works now...
[22:09] <sbeattie> okay, I wasn't sure, and I didn't want to fight races, I'll give it a go and see about enabling it.
[22:09] <jdstrand> cool
[23:39] <Laibsch> Hi, I know there are some people thinking about how distributions like Ubuntu and OpenSuse or Gentoo can collaborate better in packaging software (sharing patches is just one example).  Can you give me some names of people driving this?
[23:49] <superm1> slangasek, would it be OK to upload the fix for bug 526405 still so that it could make a3?
[23:58] <slangasek> superm1: if we got other ubiquity fixes in at the same time, maybe; otherwise, given the landscape for a3 I think that should go to errata
[23:58] <superm1> slangasek, got another one for bug 526496 in there too


[01:43] <JackFrost> for loops and wget++
[01:46] <arraybolt3> Got all the logs already, ended up working just fine. So now I can grep through the logs in a blink and profile you all MUAHAHAHAHA /s
[01:47] <el> don't worry, google's already done that
[01:47] <arraybolt3> lol, fair enough
[01:48] <JackFrost> Just don't forget who's nick is whos.
[23:18] <tomreyn> at least the data google lets anyone search about the logs is actually pretty limited, so the local copy could be useful.


[06:03] <blaze> what about kwin/wayland defaults for sddm? will this happen this release cycle?
[10:25] <RikMills> blaze: depends on how wayland testing with new plasma goes I guess
[11:40] <blaze> I've been thinking about this https://wiki.archlinux.org/title/SDDM#Wayland but yeah, it's not in the best shape atm
[12:04] <BluesKaj> Hi all
[16:19] <santa_> hi everyone
[16:20] <santa_> RikMills, tsimonq2: hi there I have found something that went under the radar for pkg-kde-tools: the architectures of the lintian dependency
[16:21] <santa_> I forgot to have a deeper look into this while reviewing Simon's merge, my apologies
[16:21] <santa_> so here's the thing: like I mentioned yesterday, I started to build fw 5.116
[16:22] <santa_> but e-c-m FTBFS for i386 in the staging ppa
[16:22] <santa_> that's new, it didn't happen before
[16:24] <santa_> we had in the previous pkg-kde-tools a dependency against lintian [!i386 !riscv64 !armhf]
[16:25] <santa_> in the current one they are no arch restrictions for the lintian dependency
[16:26] <santa_> the build failure: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-frameworks/+build/28418712
[16:27] <santa_> so I checked on git's history the origin of the arch restrictions mentioned above
[16:27] <santa_> more modern one: !armhf
[16:28] <santa_> https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools/commit/?id=129e5f1aa9ba642a224423968d07d1c32a005701
[16:28] -ubottu:#kubuntu-devel- Commit 129e5f1 in ~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools "Sync with archive ubuntu/0.15.38ubuntu4 kubuntu_staging"
[16:28] <santa_> ↑ this is suposed to be temporary so I guess we can actually drop it, if not right now, maybe later, that would be a good question for the guy whjo did that uploadç
[16:29] <santa_> * upload
[16:29] <santa_> another one !riscv64
[16:29] <santa_> https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools/commit/?id=f1d1d4534d31bdc0a1527ce23b1ad7074cdfa2e4
[16:29] -ubottu:#kubuntu-devel- Commit f1d1d45 in ~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools "sync with archive"
[16:29] <santa_> ↑ I guess we want to restore this one
[16:30] <santa_> third one: !i386
[16:30] <santa_> https://git.launchpad.net/~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools/commit/?id=c50b91c5f778505055944a921c9db83225e1f58f
[16:30] -ubottu:#kubuntu-devel- Commit c50b91c in ~kubuntu-packagers/kubuntu-packaging/+git/pkg-kde-tools "sync with archive kubuntu_jammy_archive kubuntu_impish_archive kubuntu_hirsute_archive"
[16:31] <santa_> ↑ no reason mentioned in the changelog, but I guess we want to restore it as well, since it's going to make everything FTBFS @ i386
[16:33] <santa_> RikMills, tsimonq2: any comments? what do you think, should we set the dependency to [!i386 !riscv64] (dropping the temporary !armhf restriction time_t transition)
[16:33] <santa_> ?
[16:36] <tsimonq2> santa_: Lintian is arch:all though?
[16:38] <santa_> tsimonq2: yes but apparently it's not installable on i386 as we can see in the FTBFS build log pointed above, maybe that's the reason why RikMills added the !i386 but I'm not sure
[16:39] <santa_> ... or maybe it's just a temporary installation problem with -proposed
[16:47] <santa_> indeed
[16:48] <santa_> ah, no nvm
[16:49] <santa_> I'm not sure if lintian is installable on i386
[16:49] <santa_> not sure if the thing is temporary or permanent
[18:34] <RikMills> santa_: our lintian thing is a delta we caried. no issue from me if we need to carry on doing so
[18:34] <RikMills> so lets see
[18:35] <santa_> so what's your vote on arch restrictions? :P
[18:35] <santa_> !i386 !riscv64 ?
[18:36] <RikMills> santa_: waht is needed at the time. there were times that lintian was uninstallable in proposed on certain archs. hence the changes
[18:36] <santa_> ok, so riscv64 is still slow
[18:37] <santa_> i386 uninstallable
[18:37] <santa_> therefore my vote is !i386 !riscv64
[18:37] <RikMills> santa_: I would agree with that, at least for now
[18:38] <santa_> and monday we ask the guy of !armhf in case he wants it back
[18:38] <RikMills> fair
[18:39] <santa_> RikMills: are you able to sponsor an upload of the fixed package? if so I can have the package today
[18:39] <RikMills> santa_: sure
[20:07] <valorie> my goodness, please let's put our heads together and not fight instead
[20:12] <valorie> as I heard sgmoore's plan, it was to push the packaging to Debian *first* and sync back
[20:13] <valorie> to save time for all of us
[20:13] <valorie> please let's hear her plans in more detail before making any big decisions
[20:14] <valorie> I imagine right now she is getting acquainted with her new GSoC student and getting him oriented, etc.
[22:02] <santa_> RikMills: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-frameworks/+sourcepub/16120014/+listing-archive-extra
[22:03] <santa_> RikMills: changes in kubuntu_oracular_staging, I have synced some other extra missing files in the _archive branch
[22:03] <santa_> it wasn't built yet for riscv, but so far we got i386 ecm fbtfs fixed
[22:04] <santa_> good night everyone, see you tomorroe


[06:08] <YoBoY> hum...


[10:16] <BluesKaj> testing Kubuntu (kde/plasma) 19.10 here, ssh refuses to connect from my laptop to the desktop and vice versa, /home is shared on both machines