=== asac_ is now known as asac === Quintasan_ is now known as Quintasan === MobileMyles6o7 is now known as TwoToneSpirit [02:57] why is my / ext3? [02:57] ~$ cat /etc/fstab |grep ext4 [02:57] UUID=10f59859-5e33-4277-a7d2-323447f54df7 / ext4 defaults,errors=remount-ro,relatime 0 1 [02:57] UUID=b574cf52-432a-4c2a-8742-effe21dbf760 /home ext4 defaults,relatime 0 2 [02:58] ~$ cat /proc/mounts |grep ext3 [02:58] /dev/disk/by-uuid/10f59859-5e33-4277-a7d2-323447f54df7 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0 [03:09] /c/c [07:30] urgh, wha there a decision in debian to use /srv by default across the board ? [07:30] *was [07:30] ogra: For what? [07:31] well, tftpd-hpa defaults to it for tftp serving with the latest release [07:31] i was wondering if there is a general change [07:31] which would surprise me [07:32] ah ok [07:32] that sounds like an excellent question for #debian-devel :) [07:32] gah, bug 84615 [07:32] Launchpad bug 84615 in tftp-hpa "Uses /var/lib/tftpboot instead of /srv/tftp" [Wishlist,Confirmed] https://launchpad.net/bugs/84615 [07:34] Good morning [07:34] the evil thing in tftpd-hpa is that they changed *both* defaults, it runs standalone now *and* not from inetd anymore ... [07:35] given that it doesnt carry a config file but was configured in inetd.conf thats pretty bad [07:40] ogra: /srv == win [07:40] no [07:41] StevenK, so apache should use /srv/www now ? [07:41] I prefer /srv/http, but I also think it's a local admin decision; http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM [07:42] ogra: Well, I actually configure Apache to pull from directories underneath /srv [07:42] * ogra wonders what all the admins out there would say if it suddenly did, breaking all the setups that use the default config :P [07:42] But yes, what liw said. It's a local admin decision. [07:42] right [07:42] and the directory should stay clear from defults [07:42] *defaults [07:43] ogra: I'm unsure about if the default should be somewhere under /var, or what it currently has, under /srv [07:44] var is variable system data, isnt it ? [07:45] "However /srv should always exist on FHS compliant systems and should be used as the default location for such data." [07:45] ogra: And /srv is data that is served by the system, so ... [07:45] srv is a nice concept to give admins more freedom, but essentially i think system default setups shuld stay out of it [07:45] the FHS is clear that /srv should be the default location [07:46] "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done." [07:46] * ogra doesnt find that clear or even thought to the end [07:47] I'm sure the FHS committee would accept reasonable arguments for change [07:47] an you think i would move people to a consensus ? [07:47] certainly [07:47] looks to me like it was argued on before and there simply was no agreement [07:48] if nothing else, you could push them all to dislike you and so have a consensus to vote against you? :) [07:48] Hah [07:48] which reads to me like "no real *standard* could be defined" [07:49] I haven't studied the history /srv, but I assume this happened the way fhs and similar standards are developed [07:49] well, to me a standard means there is "agreement how we all do it" ... [07:49] i.e., people felt that /var was a bad location for things like http web roots (read: not easily shareable between hosts) and proposed a change [07:50] so as a first step, /srv was invented and then the committee will wait a few years to see if it gets popular and if so, how it gets used [07:50] before they make further changes [07:50] right, i dont say thats bad ... as long as there is a clear definition how /srv has to look like [07:50] else you end up with per distro chaos ... that defeats the purpose of easy portability [07:51] and given that there is no such definition yet it should not be used for default setups imho [07:52] *shrug* the standard won't (and shouldn't) encode a structure before it has been tried in practice [07:52] heh, catch 22 ? [07:53] not really, as long as people don't insist the FHS tell them in detail the location of every file and distros have a little bit of courage to try new things occasionally :) [07:53] i dont want to be told about files in detail ... but a rough definition about the substructure would be helpful [07:54] I'm sure you'll find it in a future version of the fhs [07:54] meanwhile, you can help decide what is the best substructure :) [07:55] well, the by protocol approach is fine with me ... [07:55] in my specific case i'm just running into a prob with tftpd-hpa which changes two setups at the same time [07:56] it ignored the former configuration (inetd.conf) and at the same time switches its default path [07:56] that'd probably be a bug in that package [07:56] *ignores === tkamppeter_ is now known as tkamppeter [08:31] X really doesn't handle two monitors of different aspect ratios well, does it? [08:32] gdm keeps throwing itself against the wall when you try [08:32] it does fo my monitor [08:32] Hobbsee: that may have more to do with gdm [08:32] X might. gdm perhaps doesn't. [08:32] hm, could well be gdm [08:32] Hobbsee: is it similar to https://bugs.freedesktop.org/show_bug.cgi?id=22580 ? [08:33] (1900x1200 plus 1280x800 if i attach it to my laptop) [08:33] Freedesktop bug 22580 in Server/general "defaults to non-native screen resolutions (mode change from KMS)" [Normal,New] [08:33] (and 1024x768 looks painful on a 21.5 inch 16:9 monitor, incidently) [08:33] no, it's recent X trying to be too clever [08:34] pitti: ah yes, i see that too [08:34] I have an internal LVDS (docked, closed, ignored) and an external TFT [08:34] and X comes up at 1024x768 on both now [08:34] (when mirroring the display) [08:34] yep [08:35] turning off mirror mode lets you select the higher resolutions, though [08:35] sure, in my X session I can do the right thign (disable LVDS, use native resolution on DVI) [08:35] just when you actually log out and back in to use them, gdm blows up [08:35] doesn't blow up here, but keeps switching modes [08:36] * ogra can use his 24" monitor just fine with the laptop, but X dies horribly if i attach my 42" TV [08:39] Argh, now the blocking on ocaml transition is causing headaches for the rpm transition [08:40] Riddell, pitti, bug 190905says dnsmasq is in main, i dont see it there ? [08:40] Launchpad bug 190905 in dnsmasq "Main inclusion report." [High,Fix released] https://launchpad.net/bugs/190905 [08:41] dnsmasq | 2.49-1 | karmic | source [08:41] oh, ok [08:41] ogra: The source is, the binary isn;t [08:41] ogra: dnsmasq-base is in main, the full dnsmasq binary isn't [08:41] s/;/'/ [08:41] nothing needs it [08:44] Oh, bah, it's worse. [08:45] Anything requiring dose2 can't be built since libdose2-ocaml can't be installed since librpm4.4 and librpm0 conflict, and I can't sync dose2 since it's blacklisted since the Debian ocaml maintainers don't want karmic transitioning. [09:13] Hobbsee, depends on how your graphics driver decides to present them [09:13] Hobbsee, at work i have a 1600x1200 secondary and 1920x1200 primary. gdm displays only on the primary [09:14] pitti: So, would it be a bad thing to merge ekiga from Debian? (They have 3.2.5, and we have 3.2.0) [09:24] directhex: right. It dosent' seem to be having a problem displaying only on one monitor - just both resolutions are wrong [09:24] i don't have that issue [09:25] vertical res matches though, if that makes a diff [09:33] <\sh> moins [09:34] <\sh> evand: WTF is a "Ubiquity Contributor Agreement"? (And I think you mean Ubiquity as in live cd installer) [09:40] <\sh> and why should someone sign this when the source is GPL2 and all contributions to this source are falling under that license, too? [09:41] * ogra points \sh to http://vdict.com/ubiquity,7,0,0.html [09:42] "omnipresent" :) [09:43] <\sh> ogra: and what does it have to do with a) licensing a software and b) signing another document which grants the same rights? (minus this very strange patent paragraph) [09:43] it means that you agree this license applies *across the board* [09:43] i would say [09:44] (some native speaker may correct me) [09:45] s/license/agreement/ [09:46] \sh: yes, ubiquity the live CD installer. It's a requirement per http://www.canonical.com/contributors . My understanding of the reasons we require people to sign it are the two I outlined in that email. I can put you in touch with a lawyer who can better elaborate on the details if you don't find my explanation sufficient. [09:47] oh [09:47] * ogra didnt know we had that [09:47] (for ubiquity) [09:48] <\sh> evand: so what you are saying is: if someone is using the software, which I contributed to, not according to the GPL2 license, you will hunt them down like gplviolations? [09:48] <\sh> s/you/Canonical/? [09:49] Hi, can i discuss Ubuntu package development here? [09:49] \sh: I think that's a question better put to our legal counsel. I have a very limited understanding of the law and the plans of our legal department. [09:50] <\sh> evand: please...would you forward this to your legal department? I really don't understand the usecase behind such an agreement :) [09:52] \sh: If you could ask specific questions to Amanda (who's email address I'm about to private message you), I'd greatly appreciate it. If I just send her an email myself saying your confused on why this is necessary, that leaves having to formulate an unnecessarily broad answer. [09:52] that leaves her* [09:52] kamaln: You can, but be aware that this channel is primarily concerned with packages in the 'main' component - For 'universe' packages, including new packages, #ubuntu-motu is more appropriate [09:52] <\sh> evand: will do [09:53] \sh: Thanks, and apologies for the confusion. [09:53] Legal issues are not my strong suit. [09:53] <\sh> evand: no problem...:) [09:54] maxb: what is meant my 'main' component..? Infact, I am developing a new package..so is it better to approach #ubuntu-motu [09:54] StevenK: not at all [09:55] kamaln: All new packages start out in 'universe', so yes, #ubuntu-motu is the right place [09:56] kamaln: https://wiki.ubuntu.com/UbuntuDevelopers should help to explain the difference between motu and core-dev (this channel). [09:57] evand: thanks..:-) [10:01] \sh: the FSF does exactly the same thing for contributions to GNU projects, FWIW [10:06] copyright assignment? [10:09] cjwatson: I believe the FSF explicitely says it will only license the assigned copyright under FLOSS licenses/GPL [10:09] well, yes, that's true. I meant copyright assignment in general [10:10] directhex: only for a few projects that we started, not for the whole of Ubuntu or anything, don't worry [10:10] (just mentioning, because you said "exactly the same thing" [10:10] ) [10:10] <\sh> cjwatson: so, I could give my copyrights to another entity (which is the FSF), why should I do that? [10:11] i believe a common alternative is to allow non-assignment as long as contributions are MIT/X11 [10:11] the usual reason for copyright assignment is that it means that in case of violation it's actually possible to pursue violators; in many jurisdictions one cannot bring a case unless one has standing [10:11] \sh, essentially because it makes it easier for them to fight legal battles, as they cal claim to be the infringed party in disputes. [10:12] \sh, or you can have severe problems when you DON'T, e.g. parts of scummvm are unrelicensable as their author died [10:12] \sh, as it happens, your reasoning is why the Go-OO patchset for OpenOffice.org exists [10:14] <\sh> directhex: well, for that I have a last will where I can state what will happen to my copyrights, software or IP... [10:15] can, or do? [10:16] mm. I've actually had that problem myself in the past, I didn't really want to contact a developer's widow and say "excuse me, exactly what pedantic things can I do with your late husband's code" [10:16] <\sh> directhex: I have ... I just need to add things every year I survived [10:16] seems ... tasteless somehow [10:16] cjwatson, very. but what's the alternative? [10:17] <\sh> cjwatson: actually it's that situation companies do with people taking over someones property [10:17] cjwatson, the scummvm case is significant as it prevented proper resolution of a gpl violation problem [10:18] fortunately in the case at hand it basically worked out that I didn't need to worry about it for various reasons [10:18] afaik apache requires assignment too [10:18] a housemate received legal paperwork from the foundation when we were undergrads [10:18] <\sh> actually most of the software which are in our archives and we contributed some self-made patches needs such an assignment then [10:19] depends where the patches go, but you'll certainly find that many upstream contributions require assignments, yes [10:19] * cjwatson is in the process of getting assignments sorted out for findutils, parted, grub2, and something else I've forgotten [10:20] i think there's some generally held legal minimum patchiness level required to say "this patch counts as a proper contribution and needs proper licensing" [10:20] i'm pretty sure i'm not in MythTV's AUTHORS file [10:20] it's subjective, I have seen such things stated but never a clear legal opinion on it [10:21] sounds like something waiting for case law [10:21] I've seen people say "this isn't a patch, but if you go to foo.c and change the comparison on line 95 this bug will go away. Can I avoid signing a copyright assignment please?" [10:23] technically that statement is true [10:24] the threshold for what is copyrightable (and what is too trivial to be copyrightable) varies betwen jurisdictions, and sometimes within them too [10:24] on the whole, copyright law is screwed up all over the world [10:25] <\sh> well, if those assignments has a paragraph like: "A company/organization which violates the authors/contributors license will be sued by Us [where "Us" is someone else company/organization] to enforce the given license of the author/contributor. Any monetary solution to this charge will be shared among the Law Company, the author of the software and all contributors" this would make sense to me (not that I want any blood money) === dpm_ is now known as dpm [10:26] <\sh> btw..I just had a karmic problem unlocking the screensaver...it just waited there forever [10:27] me too last night, I was wondering if it was due to not having restarted after an upgrade [10:27] I had to kill gnome-screensaver [10:28] <\sh> it was after todays update...and there was no restart required according to non-existent "Restart required notifier" :) === yofel_ is now known as yofel [10:33] StevenK: regarding fbreader, I'd like to reply to upstream. Seeing that it will not be promoted to main, I'm guessing that the i18n work will not be done? === ogra_ is now known as ogra [11:20] <\sh> hmm...what does "You have N broken packages on your system. Please use the "broken" filter to detect them"? (Dialogbox of update-manager, without any hint where to set the "broken" filter) [11:21] maybe that's a message from synaptic [11:22] <\sh> azeem: as it follows the "Install updates" of update-manager...I can't tell...but this message is very strange and will confuse people, at least it confuses me [11:23] <\sh> and now, update-manager won't close after updating all selected packages..hmmm [11:24] <\sh> now it's gone...after 1:30 mins [11:40] does sync blacklist block even manual syncs? I thought it was just for autosync [11:41] only autosyncs [11:41] err, wait, maybe not [11:41] or is autosync just a loop over the manual procedure? [11:41] no, manual syncs too actually. But anyone who can do a manual sync can edit the blacklist ... [11:41] sure [11:42] Laney, if you were me, would you 0ubuntu1 xsp and mono-tools? [11:42] getting emails from bug 387943 [11:42] Launchpad bug 387943 in ocaml "Karmic: please do NOT synchronize following packages" [Undecided,Fix released] https://launchpad.net/bugs/387943 [11:42] basically just a loop with a bit of extra reporting [11:42] directhex: what's the delay? [11:42] Laney, binary NEW [11:43] I'd wait [11:43] binary NEW isn't too slow, is it? [11:43] but in that case the blacklist is there for a reason and removing it does seem to merit some discussion [11:43] binary NEW in Debian? [11:43] james_w, aye [11:43] I didn't think they had one? [11:43] it's probably just that ftpmasters are at debconf :) [11:43] they do [11:43] james_w, binary NEW in ubuntu requires only beatings and/or beer [11:44] james_w, the ftp-master page doesn't distinguish - the ftpmasters actually do though [11:44] and that would indicate that the source was published, and so we could sync. Or do I misunderstand the process? [11:44] james_w, you may not access files uploaded to NEW [11:44] if the new binary packages went together with a source upload, then the whole upload stays in NEW [11:44] yeah [11:44] james_w, as some kind of defence against undistributable source. or somesuch [11:45] an "new-binary NEW" [11:45] the queue never splits up .changes [11:45] "ah", I mean [11:45] I get it now [11:46] short version: long wait time [12:06] if openprinting-ppds contains an obsolete ppd-drop from a printer vendor, what's the best way to get it updated? === lamont` is now known as lamont [12:08] \sh: uh, that is indeed confusing - could you mail me your /var/log/apt/term.log please? === MacSlow is now known as MacSlow|lunch [12:13] * directhex dances in circles, goes to file a bug, notices it just goes to tkamppeter anyway [12:39] directhex, which PPDs are obsolete? [12:40] tkamppeter, kyocera. i can get a precise list of models if you give me a few mins [12:41] directhex, OK. [12:41] directhex: Unfortunately, I did not get Kyocera PPDs for years, so there are probably missing a lot. [12:42] how odd, there are more PPDs on here than in Kyocera's download [12:43] directhex, can you tell me where I can find Kyocera's download? [12:43] It can be that Kyocera does not have arbitrary old models in their download and the oldest models on OpenPrinting are perhaps older. [12:44] +Kyocera_FS-1118MFP_en.ppd [12:45] +Kyocera_FS-C5015N_en.ppd [12:45] +Kyocera_FS-C5025N_en.ppd [12:45] +Kyocera_FS-C8100DN_en.PPD [12:45] +Kyocera_KM-1820_en.ppd [12:45] +Kyocera_KM-C2520_en.PPD [12:45] +Kyocera_KM-C3225_en.PPD [12:45] +Kyocera_KM-C3232_en.PPD [12:45] those are the additions [12:45] cjwatson: I did verify the debian-cd change you merged for me fixed the background problem on the Kubuntu Netbook ISO. Thanks agian. [12:46] directhex: are you listing the models which are missing in Kyocera's download or the ones which are missing on OpenPrinting? [12:46] tkamppeter, the latter [12:47] So these are the newest models which need to get added? [12:47] directhex: And where can I download the PPDs? [12:47] seems there are also some minor changes to old ones [12:47] ScottK: oh good [12:47] tkamppeter, bottom of http://www.kyocerasupport.co.uk/index/download_center.false.driver.FS1118MFP._.EN.html has a link [12:48] cjwatson: Well, I'd like to remove dose2 from the blacklist, just so I can get this librpm4.4 mess cleaned up. [12:49] but won't it basically pull in the whole ocaml mess? [12:49] I thought that was the point of blacklisting all that stuff [12:49] I'm just about to check that [12:49] I think we should go ahead with the transition anyway [12:49] i.e. I thought there were source changes in there that relied on the new ocaml [12:49] (OCaml) [12:50] cjwatson: My other thought was doing -3~ubuntu1 which is -3, without the new ocaml [12:50] god, thses gpm popups are annoying [12:50] *these [12:50] it doesn't seem so bad, and there's a nice tool for helping with it [12:50] ogra, hm? [12:51] liw, i get "your battery is fully charged" or "... discharging" as popunders since some days [12:51] ogra, ugh [12:51] *huge* popunders with three buttons in a row [12:52] Well, I wonder if Debian has completed the transition. [12:52] It's been a month, after all. [12:52] If they have, compiling a list of stuff to sync should be fairly simple. [12:53] directhex: The PPDs are under MIT license, so I can update OpenPrinting ... [12:54] tkamppeter, i wouldn't have bugged you if they weren't Free :po [12:54] :p [12:55] directhex, with OpenPrinting updated, Ubuntu Jaunty and higher would simply directly get them from OpenPrinting. [12:55] StevenK: They have, apart from one sourc epackage (see mail to u-d-d) [12:56] directhex, about free licenses of PPDs, you can inform me about all PPDs offered for use with Linux, independent whether they are free or not, as in some cases I can contact the manufacturer. [12:56] Laney: Ah, but it seems like they want to keep 3.11.0 in Karmic, and have 3.11.1 in Karmic+1 [12:56] Which makes me go argh [12:57] tkamppeter, i don't generally look at this stuff, unless an engineer appears out of nowhere to take my laserjet away & put an unsupported-in-jaunty kyocera 1118 in its place [12:57] well he asked if we should do the transition, and I said that I think we probably could and should [12:58] I agree that we should, it makes headaches like the one I just found go away [12:58] If the PPDs are redistributable but not free software (only vernatim redistribution) I can at least put them up on OpenPrinting, in the foomatic-db-nonfree package, and that is enough for Ubuntu auto-downloading the PPDs. If they are free, they get into foomatic-db and so also into Ubuntu. [12:58] StevenK: would be good if you could say as much in that thread then [12:58] tkamppeter, the only other printers i have access to generally are a Brother (so i get that frustrating ERROR problem on most print jobs) and a Toshiba (which works fine) [12:59] tkamppeter, i did get to tell a Canon salesperson they were smoking crack once, though, thanks to their laughable loonicks support [13:01] seb128, is ssh support in gvfs known to be broken atm ? my nautilus crashes if i try to sftp mount people.canonical.com [13:02] ogra, do you have ubuntuone-client-gnome installed? [13:02] WFM (tm) [13:03] ogra, ubuntuone is known to make nautilus crash at the moment so if you have it yes it's known [13:04] well, could i not ? its seeded :) [13:04] so yes, i have [13:04] thanks [13:04] ogra, you're welcome [13:05] ogra, nobody force you to have ubuntu-desktop installed, I don't ;-) [13:05] i want to eat our own dogfood ;) [13:21] kirkland, around ? [13:25] ogra: (ubuntuone's only a recommendation, you can remove it and still have ubuntu-desktop installed) [13:26] cjwatson, yeah indeed [13:26] given that my invite timed out anyway, i should probably do that === MacSlow|lunch is now known as MacSlow === The_Company is now known as Company [13:43] ScottK: I think you tried pinging me over the WE but I forgot to go back to you [14:04] I know suspend / hibernate is fragile generally... it was working find on this laptop running jaunty. Now, with karmic, suspend and hibernate don't work. The screen goes dark for a while when I ask it to suspend then a minute or so later I get the "enter password to close the screensaver" screen. [14:04] should I file a bug? against what package? [14:04] likely the kernel [14:18] is anyone here familiar with gdk_window_get_frame_extents? [14:20] hmm no wait, that's not the problem here. [14:28] hmm for some reason my panel isn't a dock. [14:30] is there someone else doing NEW at the moment? [14:33] jdstrand: you perhaps? [14:33] james_w: I was trying to get to a few before slangasek came online, yes-- are you doing mondays now? [14:33] yeah, myself and slangasek split the day [14:34] I've no problem with you doing some though :-) [14:34] I'm just not sure what danger there is of collisions [14:34] james_w: I plan to do ltsp-cluster-lbagent, moovida* and qemu-kvm [14:34] great, thanks [14:34] I'll go for lunch [14:35] give me a shout once you're done and I'll do the rest [14:35] james_w: ok [14:35] thanks [14:35] np [14:37] does the i386 buildd call build-indep directly? [14:39] Laney: IIRC it calls build while the other call build-arch (but better look at a build log to be sure) [14:41] window splitv [14:42] sry [14:45] hey stvo [14:45] stvo: trying weechat? :-) [14:46] pitti, is stvo who i think he is ? [14:47] * pitti engages long-distance brain reader [14:47] haha [14:47] ogra: confirmed with 89.234 probability [14:47] lol [14:47] lol [14:47] hi stvo, great to see you here [14:47] thx [14:48] ogra I'm testing your arm chroot [14:48] environment [14:49] nice :) [14:49] note that its not 100% reliable but good for poking around ... some syscalls are likely missing === pace_t_zulu_ is now known as pace_t_zulu [14:52] ogra: howdy! [14:53] kirkland, lool told me you migh be working on a spec that implements something like https://wiki.ubuntu.com/ARM/BuildEABIChroot [14:53] if thats true, is there any chance we see it in karmic ? [14:54] ogra: No, kirkland is working on getting us qemu updates though [14:54] (i'm referring to the binfmt setup by default) [14:54] ah [14:54] 11:49 < lool> I'm sure this can all be done when we refresh our qemu [14:54] 11:49 < lool> I think kirkland has a spec on this [14:55] then i misunderstood the "all" in that sentence :) [14:55] lool: ogra: hmm, i'm working on getting the new qemu-kvm project into karmic [14:55] this project is the merger of the qemu and kvm code [14:55] kirkland: Is this based on qemu 0.11? [14:55] qemu plus the kvm acceleration bits [14:56] lool: that's the target [14:56] lool: 0.11 just hit Release Candidate [14:56] Cool [14:56] cool, that at least gets us the eabi patches [14:56] lool: that will make it into karmic [14:57] lool: it was targeted at alpha3, but upstream slipped a little === epuzarne1 is now known as epuzarne [15:03] james_w: I'm done [15:03] hah, fighting for sync karma? :-) [15:04] who me? nah, I just couldn't get to archive much on Friday [15:04] thanks jdstrand [15:04] sure :) [15:15] yay for james_w, one step closer to mono 2.4.2 in karmic === mbiebl_ is now known as mbiebl [15:31] lool: Thanks for checking back, it got taken care of already. [15:38] hi there. whom should I poke when a NBS' dependencies is zeroed? In that case it's libgnokii3 where all dependencies on that are eliminated now. [15:38] or is there some kind of automagic NBS removal? [15:41] Ampelbein: manual-automatic :-) [15:43] james_w: so I poke you and you do it? sweet! ;-) [15:44] I've not done it yet [15:44] we'll see if I get down that far on the list today [15:45] no worries... thank you for the info. [15:48] kirkland: Ack I heard that during the release meeting [15:49] kirkland: (ogra was rolling his own qemu 0.10 + patches to get some better ARM EABI support and was interested in having that in ubuntu which is why I pointed him at you) [15:49] I'm using tip + patches [15:50] lool: for tip, are you aware of https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream ? [15:50] well, there is more than the patches ... but if our qemu-arm could support eabi that would be a major step forward [15:50] i would still like to have a package i can easily install that enables binfmt [15:51] and disables it on package removal respectively [15:52] ogra: lool: any reason why these patches aren't upstream in qemu? we have a friendly qemu maintainer, we sponsored him to barcelona uds [15:53] kirkland, the patches are apparently [15:53] just not in our package [15:53] ogra: oh, great [15:53] ogra: then this will sort itself out very shortly [15:53] ogra: in the mean time, see: https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream [15:53] ogra: 0.11.50 is building there [15:54] nice [15:54] i'll try it out soon [15:57] do we have an ubuntu java or eclipse channel? [15:58] lool, kirkland, though for the chroot bits i would still need a statically build binary [15:58] just strikes me ... [15:58] kirkland: I am aware of the PPA; thanks; I build tip by hand because I apply some non-mergeable patches on top of qemu [15:58] *built [15:59] kirkland, do you think it would be possible to roll a qemu-arm-static into our package ? [16:00] lool: gotcha, good to know [16:00] ogra: hrm, i don't see why not ... do you have a diff that does this? [16:01] ogra: curious, just wondering... why do you need a static build of that binary? [16:01] no, my package is totally badly built with its own copy of the qemu source and the patch inline [16:01] ScottK: Cool, so these perl libs should soon be installable? [16:02] kirkland, what i do is: apply the eabi patches, build it statically, enable the interpreter in binfmt-support to match the magic of any armel binaries ... then i roll an armel chroot ... to exec armel binaries *inside* that chroot i need the x86 qemu ... [16:03] kirkland, which indeed wouldnt find its libs *in* the chroot [16:03] ogra: right [16:03] with the static version i can just chroot into my bootstrapped root and move on [16:04] lool: Right. Thanks for the reminder (ugh). No, it was another issue. [16:04] its extremely convenient [16:04] * ScottK looks into it. [16:04] Eh :) [16:04] ogra: agreed [16:05] So it's libcompress-raw-zlib-perl which I can't upgrade due to the dep of libio-compress-zlib-perl === WelshDragon is now known as Fluffles [16:07] kirkland, in my package i essentially just do "./configure --prefix=/usr --target-list=arm-linux-user --static" in debian/rules, but i guess thats not proper enough for the actual package in the archive [16:08] ogra: right, let me think on this some [16:08] ogra: i'll talk to upstream too [16:09] thanks :) [16:09] ogra: i might be able to add a binary package to the source package [16:09] ogra: qemu-arm-static or something [16:09] ogra: or qemu-static [16:09] ogra: and just publish that one to universe? [16:09] that would be cool since it could also carry the proper postinst and prerm bits for binfmt [16:09] universe is totally fine [16:10] ogra: would you open a wishlist bug against qemu to capture this? [16:10] yeah [16:10] ogra: i'm tracking down a nasty ecryptfs right now [16:10] ogra: so i guarantee i'm going to forget this otherwise :-D [16:10] no hurry [16:20] kirkland, bug 401782 is yours [16:21] Launchpad bug 401782 in qemu "please build a static version of qemu-arm 0.11.x in a separate binary deb" [Wishlist,New] https://launchpad.net/bugs/401782 [16:21] ogra: thank you sir! [16:21] no, thank you ! :) [16:22] ogra: thank me when I finish the work :-) [16:23] heh [16:23] well, until then my hackish ppa package will do :) [16:39] lool: They've combined several perl modules into one. This is non-trivial. === RainCT_ is now known as RainCT [17:25] Keybuk: Hey. How does this look? http://revu.ubuntuwire.com/~rainct/mom.html [17:26] cute [17:28] RainCT: I'm sure it's not the point, but your data is perplexing - you seem to be using the primary UID on the signing key for "Last Uploader", rather than, say, Changed-By if it matches one of the UIDs on the key ... [17:30] cjwatson: Seems like it's just running gpg and looking at the "Good signature from X" line. But hey, that's not my code! :) [17:30] cjwatson: patches welcome [17:31] cjwatson: in fact, I think you may have _written_ this patch in the first place ;-) [17:31] Keybuk: oh, I didn't think current MoM acted this way ... [17:32] I don't remember doing so? but that doesn't mean a whole lot [17:32] Keybuk: The (new design) code is up on lp:~rainct/merge-o-matic/redesign for your merging pleasure :) [17:33] Jo Shields [17:33] Uploader: Colin Watson [17:33] (e.g. from current MoM output) [17:34]