[00:12] * ogra_cmpc sighs about fedora === cjwatson_ is now known as cjwatson [00:33] hrm [00:36] ogra_cmpc: hm? [00:37] soren, ach ... endless discussions with the fedora people about the --arch option in ltsp [00:37] they never heard about amd64 :P [00:39] and somethimes the attitude between the lines "there is no linux apart from fedora" is a bit well ... [00:40] ... tiring ? [00:42] maddening? exasperating? pity-inspiring? :) [00:43] :) [00:43] Gah... Is that really the time? [00:43] *headdesk* I have work tomorrow you know! [00:43] no, you're reading it upside-down [00:44] geser: ah good, i'm not going mad (w.r.t dpkg-gencontrol: failure: cannot read -) [00:44] soren, lol [00:44] it's actually hh:01 [00:44] sorry, hh:10 [00:45] Oh... good? [00:45] it's always good when it's the hour of the hardy heron [00:45] \o/ === emgent is now known as enJoy === enJoy is now known as emgent [00:49] soren: oh dear. i told you that you broke it :) [00:52] Hobbsee: You did. [00:52] You actually did. [00:52] I was bound to happen sooner or later. [00:52] * jdong reads scrollback [00:52] Bwahaha [00:52] sounds like fun, folks [00:52] :) [00:53] anyone else notice stuff FTBFSing on Hardy? (kidding :D) [00:53] "I was bound to happen sooner or later." <- sounds like the sage words of someone crazy enough to merge dpkg [00:53] Impossible! [00:53] StevenK: he is inevitable [00:54] That's me. Inevitable. === emgent is now known as enJoy [00:56] The best part about uploading dpkg? Knowing that your crack will be built *right* *now*. [00:56] soren: and your crack seeds all other crack too :) [00:57] Yeah, that's the not so best part of it. === enJoy is now known as emgent [00:58] * soren goes to bed [00:58] LS:10 is way too late for me to still be up. [00:59] I completely stopped making sense at hE:10. === emgent is now known as enjoy === greeneggsnospam is now known as jsgotangco [01:03] soren: do try not to break it again, OK? :) === enjoy is now known as enJoy [01:04] soren: Knowing that your crack will be built *right* *now*. <-- sounds like you should apply to be a buildd admin. [01:04] there are priorities for a reason! [01:04] Hobbsee: It's ironic, really. I was trying to be a good boy and even added a new test case to dpkg with this upload. Did it help? Nooooo.. [01:04] soren: your upload is done and built and didn't break the world now, i tkae it? [01:05] https://edge.launchpad.net/ubuntu/+source/dpkg/1.14.16.6ubuntu2 [01:05] I guess it needs to be published before the buildd's pick it up. [01:05] After that, it's give-back galore. [01:06] * Hobbsee looks [01:06] soren: No, it's built already. [01:06] yeah, just as i'm going on VAC. great. [01:06] soren: http://imgs.xkcd.com/comics/insomnia.png ;) [01:06] soren: I'll do mass-give-backs once it's published. [01:06] infinity: who really cares about ia64 anyway [01:06] * cjwatson hopes he didn't just break all the seeds [01:07] cjwatson: it's the day for breakage. why not? [01:07] * cjwatson HIGHLY recommends not merging the seeds any more [01:07] cjwatson: Just fix them before FF, otherwise we'll have to live with broken seeds. :( [01:07] unless you feel like a really fun resolution pass [01:07] cjwatson: so, uh, how does one merge seeds, or do that equivalent, now? [01:07] * soren decides to stop trying to be funny and *really* goes to bed. [01:07] or am i missing something obvious? [01:08] cjwatson: btw, are you responsible for consolekit integration? [01:08] Hobbsee: largely, the idea is that we should stop needing to, because common things are in a single common place [01:08] soren: you'll probably break dpkg between now and then anyway, so the seed point will be moot. *g* [01:08] Chipzz: no [01:08] Hobbsee: we're not quite at that ideal yet, but a lot closer than we were [01:08] cjwatson: oh good! i'd wondered why they weren't previously [01:08] hrrrm then I must be mistaken; nevermind then. who is though? [01:08] Chipzz: pitti [01:09] err, and if you just updated your seed branches, you might have to force it a bit - I just made a mistake and uncommitted [01:09] cjwatson: is it possible that I recall you having a discussion about sudo and ck integration a couple of weeks ago? [01:10] Chipzz: yes [01:10] Chipzz: doesn't mean I'm responsible for it though, I was just playing with it and trying to improve a few things [01:10] cjwatson: ah, because that actually was a reason for concern for me [01:11] haven't played with ck yet, so I may be totally mistaken [01:12] but integrating ck with sudo and/or login rang a couple of very loud alarmbells here [01:12] do you mean ssh rather than sudo? [01:12] no, sudo [01:12] I wasn't integrating it with sudo [01:13] all I was trying to do was make policykit applications not break hopelessly when invoked via sudo [01:13] anyway, I'll be better off voicing my concerns with pitti maybe? [01:13] sure [01:13] but your input would be nicetoo I guess ;) [01:14] well, I don't know what your concerns are [01:14] but it's also 1:15am [01:14] basically my concern is that adding ck as a dependency may complicate recovering a broken system [01:14] (ie booting in rescue mode) [01:14] death to all evil keyboard bugs111 [01:15] Chipzz: well, nobody AFAIK was talking about making sudo register a CK session === enJoy is now known as emgent [01:16] Chipzz: and rescue mode uses sulogin, not login, and therefore does not create a PAM session, so that would not involve CK either [01:16] any sane implementation of CK integration lets the login manager continue if CK isn't available, anyway [01:16] for instance if you use the PAM module you make it optional [01:17] that's what I figured [01:17] I think there's an argument (though it's still debatable) that sudo should forward CK credentials, but having it pretend to be a new console session seems rather a stretch [01:19] but I shall ask pitti about it tomorrow. imho care should be taken not to complicate such scenarios (though one might argue that when your system is broken, well, it's broken...) [01:19] I don't really think it would [01:21] cjwatson: anyway, since this is pitti's stuff anyway, I'll bother you no more and let you get some sleep ;) [01:21] thanks ;) [01:22] good night (in case you're hitting the sack ;)) [01:27] * infinity manually shoves dpkg through the publisher... [01:31] * lamont waves [01:33] hi lamont === Pici` is now known as Pici === lando_ is now known as lando === lando_ is now known as lando === lando_ is now known as lando === asac_ is now known as asac [05:11] Does anybody know how to create their own kernel derivitive using the binary-custom folder? Mine seems to continually fail === \sh_away is now known as \sh === \sh is now known as \sh_away [06:05] Good morning! [06:22] im assuming the answer's no, but if I trigger a kernel panic, that stack trace wont be present anywhere on disk, right? [07:22] Good morning [07:23] hi pitti [07:23] geser: ugh; due to the new dpkg, I assume? I'll have a look soon [07:24] LaserJock: I just accepted the packs in -proposed [07:24] LaserJock: today I'll care for getting dapper to feisty langpacks synced, and then do an announcement on -translators@; if all goes well, I'll move them in a week [07:26] soren: compat level 1 in pkg-create-dbgsym> yes, unfortunately we have packages which are *that* old and crappy :/ [07:28] soren: that sounded like fun; thanks for fixing it, is there anything I still need to do? [07:29] pitti: k, awesome [07:30] Chipzz: so, what exactly are your concerns with sudo and CK? [07:31] morning pitti! [07:32] pitti: more like login and CK [07:33] hrrrm wait :P sudo too actually [07:34] my concern is that in case something breaks, that having CK in the mix would make it harder to fix things [07:36] basically the way it is now, recovering a broken system (or rather: getting to a state where you can attempt to recover it) is not too complex [07:36] FSVO "not too complex" [07:36] ie [07:37] booting with init=/bin/bash [07:37] lets say the sudo <-> CK integration breaks [07:38] atm sudo setup is not too complex, and little is required to say, reboot, log in as user, and use sudo to gain root [07:38] little is required -> from a technical pov [07:40] my concern (and I don't know if it's a valid concern) is that complicating sudo (and login) config may make it more error-prone, and increase the chances of you being unable to for example gain root access at all when stuff goes haywire [08:04] good morning [08:04] dholbach: the "good" part still is missing. But I hope you are having one. :) [08:05] thanks simira [08:05] * dholbach hugs simira [08:06] :) [08:12] simira! [08:13] moin === \sh_away is now known as \sh [08:13] hi Hobbsee [08:14] * simira is at school, with a terribly bad teacher.... (he is french, and not totally comfortable with Norwegian...) [08:15] erk! [08:23] pitti: I think it's under control. infinity said he'd be giving back all the stuff that broke because of it. [08:24] good [08:25] soren: you didn't disable NO_PKG_MANGLE yet, right? [08:25] pitti: Right. I'll do that later today. [08:25] cool [08:25] soren: the joys of dpkg :) [08:26] * pitti hugs soren [08:26] StevenK: oooh, promising changelog on libosso! :) [08:27] Why is latest daily alternate CD for i386 so small (491MB)? [08:28] seeds are probably botched [08:29] Hobbsee: looks like that is the case. Many important packages are missing [08:30] hey Hobbsee pitti soren [08:30] hello mvo [08:30] soren: so the fixed dpkg has built? [08:30] hey seb128 [08:30] seb128: Yes, around 2AM last night. [08:30] good morning mvo, seb128 [08:30] * soren is sleepy eyed. [08:30] hey seb128 [08:31] soren: 2am is a great bedtime! [08:31] * soren hugs pitti back [08:31] Hobbsee: It would have been, yes. [08:31] * mvo hugs Hobbsee [08:31] hey pitti [08:31] around the time I stopped working then [08:31] * Hobbsee hugs mvo. morning! [08:31] * seb128 is tired still and need coffee [08:31] * Hobbsee inserts the caffeine drip [08:32] * mvo needs tea [08:32] hum, tea? [08:32] no, need coffee first this morning [08:33] ah, and builds have been retried during the night [08:34] mvo: hmm... good suggestion [08:34] Hobbsee: by the way, it is not i386 problem. All the CDs are very small [08:35] slytherin: it wouldnt' surprise me. cjwatson should know why [08:49] pitti: i saw usplash... hm. there really was some dumb mistakes... [08:51] pitti: Do you think my libosso hack is too gruesome? [08:52] gaspa: working fine now :) ; however, it's still not quite what I need, so I added another command (INPUTCHAR); will upload today [08:52] StevenK: haven't looked at it yet (will do in a few), but it sounds like a great hack :) [08:53] (in the *sniff* "good crack" sense) [08:53] pitti: ok... so you're not angry with me, isn't it ? :D :D [08:53] gaspa: no, why should I? :) [08:53] wtf... [08:53] :P [08:53] It's *Tuesday*?!? [08:53] pitti: there's something other that should be done in usplash? [08:53] soren: does that come as a big surprise for you? === DrPepperKid is now known as MacSlow [08:54] pitti: Yes! [08:54] gaspa: there are tons of bug reports... [08:54] ( someone's going to fosdem, this month? ) [08:54] pitti: This is awesome! I just got an extra day until FF! [08:54] good morning macd [08:54] good morning MacSlow [08:54] good morning Pi"I'm a lazy tab key user"tti [08:54] pitti: yes, but much of them seems arch-dependent... [08:54] hi pitti [08:55] odd... I thought I shut down xchat yesterday [08:55] so i wasn't able to reproduce them. [08:55] MacSlow: Shut down xchat? But that would log you off irc, wouldn't it? [08:55] znc FTW! [08:56] znc? [08:56] soren, yes... in the evening before going to bed this makes sense :) [08:56] soren: apt-cache show znc (I have used this for some weeks now, it works great) [08:57] MacSlow: But, but... You'd be logged off irc!!!11!!!one! [08:57] seb128: I'm about to look at MacSlow's sponsor request, or did you already? [08:57] pitti: feel free, there is new upstream versions [08:58] pitti: so if you want to do the update in the same time you are welcome [08:58] soren: you'd take IRC through a drip feed directly into your brain if you could. :-P [08:58] pitti: the libwnck one should be easy [08:58] soren: still better than wasting power over the night :) (but with a proxy you can have both) [08:58] seb128: erm, I was just going to upload them [08:58] seb128: *sigh*, ok, will do [08:58] pitti: ok, do it, I'll pick those when I do the update [08:58] pitti: no, don't bother, I'm fast at doing those updates ;-) [08:59] pitti: You turn off your computer too?! [08:59] heh [08:59] Good thing I'm sitting down already.. [08:59] soren: sure, whenever I don't need it for at least an hour [09:01] MacSlow: just a nitpick for the future: can you please use patch tags (https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines) for future patches, to record upstream bugs and descriptions, etc.? [09:03] MacSlow: and please put the source.changes there, too (rebuilding locally now, so don't worry for now) [09:04] pitti, oh... sorry didn't knew about the comments [09:04] pitti, I only knew about stating the LP-bug entry in the changelog [09:05] hate cupsys and apparmor [09:05] MacSlow: no need to be sorry, it's a relatively new thing [09:05] MacSlow: that's why I'm pointing it out, we want to try to establish it a bit [09:05] seb128: --verbose? [09:05] pitti: still the broken update for a week, I didn't take time to investigate but it's getting annoying [09:05] Loading AppArmor module: Failed. [09:05] invoke-rc.d: initscript apparmor, action "force-reload" failed. [09:06] so cupsys can't be configured [09:06] pitti, so the suggested comments in the patch itself is newer than the (LP: #12346)-thing? [09:06] ugh, I thought apparmor was working again on current kernels? [09:06] MacSlow: yes, much newer [09:07] MacSlow: in the desktop team we want to add some metadata to patches to record description, whether it's ubuntu specific, and various bug tracker links [09:08] MacSlow: g-c-c> any particular reason why you hcanged the function names? [09:09] MacSlow: wouldn't it be enough to just change the called programs? [09:11] pitti, I like consistency and predictability [09:11] ok [09:12] pitti, and since it's not a public API-call I felt save changing it [09:13] pitti, thanks for the uploads! [09:28] good morning [09:34] persia: I tried to clarify the "situation" with UME-handled packages in #188130; I'm around to chat about them if you need further clarifications [09:34] MacSlow: you're welcome *hug* [09:34] hi geser [09:35] StevenK: hah, nice patch! [09:36] StevenK: I take it you verified that using the same pointer doesn't lead to double-free() or other crashes when the session terminates? [09:37] StevenK: I wait with the promotion until it gets built everywhere [09:46] Hi pitti [09:53] StevenK: could you look at the gimp update sponsor request? getting the new version before the freeze would be nice [09:53] pitti: I've found where it disconnects. It doesn't free them, it calls dbus_bus_release_name() -- as long as that copes, I think it should be fine. [09:53] seb128: Yeah, in a little while. [09:53] thanks [09:53] * StevenK runs off to buy part of dinner. [10:06] can someone fix the locobot? [10:06] slytherin: ok, I'm sure it's my fault, I'll look at it shortly [10:14] soren: no, it's really monday. [10:15] Mithrandir: do they do those drips now? that'd be nice! [10:16] Hobbsee: he's in transit I believe [10:17] oh. [10:17] yay for backscroll, and irc proxies [10:17] he's on in a few mins [10:17] :) [10:17] just demand he comes on now :P [10:18] I don't need him, I'm in class :) [10:20] simira: i thought you were supposed to listen in class? [10:20] and not be on irc? :) [10:20] that being said, i've been on irc during uni too. [10:20] Hobbsee: yes, when my french lecturer learns Norwegian properly, maybe... [10:21] oh, this is *still* the french lecturer? [10:21] sheesh, how long is he giving a lecture for? [10:21] yes, we mostly got only him :p [10:21] four hours today [10:21] five yesterday, and three tomorrow, I believe [10:22] ew. [10:22] mm [10:22] what's he attempting to teach? [10:22] a norwegian standardization system for archive management for official purposes [10:24] pretty much like ISO 15489, just made and adjusted to Norwegian standards [10:25] lucky for me, it's very easy to understand from an IT/developer perspective [10:25] * mpt orders a copy of ISO 15489 to keep on his bedside table [10:26] mpt: you'd need a bad French lecturer to have any use of it. The standardization itself is somewhat interesting [10:26] (if you are interested in archive managment, that is) [10:28] yay, seems I sufficiently convinced usplash to do what I want it to do \o/ [10:28] sane fsck integration into usplash! [10:28] pitti: DO those recent usplash changes affect themes at all? [10:28] with pressing Esc to skip routine checks [10:28] pitti: ooooo shiny! [10:29] pitti, cool [10:29] TheMuso: no, they don't; I just fixed the input handling [10:29] ! [10:29] pitti: Right. [10:29] I currently hijack the progress bar to show the fsck progress [10:29] which means that it'll jump around a little [10:29] (i. e. used for init script progress, then fsck progress, then again init script progress [10:30] I'd like to use a different colour for fsck, but usplash currently doesn't allow that [10:30] Better than nothing. [10:30] it's probably good enough for a first upload [10:30] hrm [10:30] mpt: WDYT? should I use the progress bar or output some text [10:30] pitti: ooh, congratulations [10:30] (like percentage) [10:30] pitti: which fsck backends does it support? [10:30] cjwatson: only ext3 actually provides progress reading [10:30] pitti, how soon in the progress bar do/can you find out that you need to do fsck? [10:31] I'll check it in a bit how it looks with reiser and xfs [10:31] rcS.d/S30checkfs.sh [10:31] should be fairly early [10:31] I didn't run a complete boot yet [10:31] but only when fsck actually starts [10:31] pitti, I mean, do you know that you'll have to do a fsck before the progress bar begins? [10:31] I just start usplash and checkfs. manually [10:32] right, what cjwatson said [10:32] mpt: let me test this with a real boot and come back to describe how it looks like in the entire boot sequence [10:32] ok [10:35] cjwatson: thanks for looking into it. :-) [10:39] pitti: next step is a kernel ooops... i want to see it in a usplash screen... :D :D [10:39] heh [10:39] Hobbsee: I'm sure you could get one if you paid enough.. [10:40] mpt: so, it actually looks a bit ugly [10:40] pitti, my usual suggestion is to retain one progress bar for overall progress of the task (in this case, starting up), and using text for subtasks [10:40] init script progress starts from 0 to 30%, then checkfs kicks in and does 0 to 100, then init script continues from 30 to 100 [10:40] So it's ok if the progress bar gets stuck for a few minutes, as long as there's a line of text changing regularly underneath [10:40] mpt: ok, I I should rather output the percentage? [10:40] where "regularly" > 1/second [10:41] pitti, is there anything more fine-grained you can report than the percentage? [10:41] simira: fun [10:41] For a large disk, a single percentage could take many seconds [10:41] mpt: fsck has 5 stages, and reports a percentage for each of the stages [10:41] but they are fairly meaningless [10:41] Is there a MB measurement, for example? [10:42] or disk blocks, or something? [10:42] no [10:42] well, blocks maybe [10:42] it outputs some numbers 'cur' and 'max' [10:42] Mithrandir: heh [10:42] pitti, do they represent a fraction? [10:42] i.e. progress = cur/max? [10:42] I can output the numbers (stage X/5, cur, max) directly instead of percentages [10:42] mpt: yes [10:42] mpt: that's the percentage withing a stage [10:42] and max > 100? [10:43] for a small disk, max < 100 [10:43] hrm [10:43] for a large one I suppose it's much bigger [10:43] I have a 6 GB test partition, where it's 94 [10:43] How long does it take overall? [10:43] actually, sorry, wrong question [10:44] How long does the slowest stage take? [10:44] for that 6 GB [10:44] oh, stage 1: 46 (70% of time), stage 2: 473 (20% of time), stages 3 to 5 are very quick [10:44] 473 seconds? [10:44] no, that's the 'max' number reported [10:44] oh [10:44] an absolute number of files or blocks to check, or so [10:44] a different number for each stage [10:45] I have a conversion function which accumulates stage, cur, and max to a single percentage [10:45] (adapted from fsck.ext3) [10:45] The reason I'm asking this, is that it's good for the text to update at least every couple of seconds [10:45] so that it never looks frozen [10:45] As a (very) last resort we could include the time elapsed, I'm just trying to work out whether that's necessary [10:46] mpt: what about including all? [10:46] mpt: you don't have any meaningful output that changes every couple of seconds by default, at least. [10:46] Checking disc..... 23% (stage 1, 234/437) [10:46] well, maybe on a 6G disk, but not on a 1TB disk or thereabouts. [10:46] Mithrandir, "by default" as in the existing text display? [10:46] mpt: yes. You have a text throbber and a progress bar. [10:47] yes, I'm familiar with it [10:47] but not familiar with how bad it gets on huge disks [10:47] s/bad/sullen/ [10:47] (I currently mimic that text mode progress bar behaviour in usplash) [10:47] it just throbs slower. [10:47] I think the numbers (cur/max) will get higher, so I could output those [10:48] fsck seems to update progress several times a second [10:48] What makes it spin the throbber? [10:48] mpt: the text mode has a certain threshold for the percentage [10:48] I mean, what has it finished when it rotates one segment [10:48] e. g. if one "=" represents 2.3%, it updates the progress bar every 2.3% [10:49] oh, it has that rotating thingy, too [10:49] pitti: "throbber". :-) [10:50] Mithrandir: I think I just learned a new word :) [10:50] So, if we can assume that (a) fsck will usually take more than a couple of minutes, and (b) for most disks max > 100, then I think it's better to show cur & max [10:50] mpt: maybe the percentage in addition, to give a feeling for an ETA? [10:50] throbber, I think comes from Netscape 1.1, where it actually throbbed [10:50] since stage 1 takes 70% and stages 2 to 5 together 30%, it would look less intimidating [10:51] pitti, you're right [10:51] mpt: WDYT about "23% (stage 1/5, block 234/437)" [10:51] Your suggestion above is perfect [10:51] except three dots, not five :-) [10:51] pitti: where do you get the cur and max numbers from? [10:51] sure :) [10:52] Mithrandir: fsck -C [10:52] Mithrandir: rather, -C3 [10:52] (output progress to fd 3) [10:52] -C == -C0 is magic, it uses the text mode progress bar [10:52] but for an fd you get three numbers (stage cur max) per line [10:52] one line for each cur [10:53] ah [10:53] http://en.wikipedia.org/wiki/Throbber [10:53] max for a 2.6T volume is ~21k, so a percentage would be good [11:02] lool: Thanks for the clarification on MIC. Sounds like a bit of a mess. I'd like to wait to hear back from smagaoun about it, but will push pre-FF if nobody else hits it. [11:03] persia: see my comment in -motu [11:04] Longer term, I'd think setting maintainer to UME, and granting UME access to the VCS might be a sensible solution, to avoid tracking multiple debian/ directories. Alternately, one of the two repos can be the master, and the other can merge/sync as Ubuntu does with Debian. [11:04] slytherin: OK, I see the problem - the code that generates the "master task" for cdimage doesn't cope with following more than one level of seed dependencies [11:04] Hobbsee: I refuse to accept anything as "crack" that can be fixed. Mortar is cheap :p [11:04] slytherin: the upshot being that required, minimal, standard, and desktop-common go missing [11:07] cjwatson: That is almost everything one would need to use Ubuntu. ;-) [11:07] desktop I mean. [11:07] persia: Thanks [11:09] lool: On an extended note, aside from other things, doesn't it make sense for someone in UME to be sponsoring UME stuff, rather that UUS? My comfort level for uploads when wearing a UUS hat goes down significantly when the resulting maintainer is not MOTU. [11:11] persia: There are little uploaders for UME at the moment; most people aren't MOTU and we only have a couple of core dev while the packages are being promoted to main [11:12] lool: Makes sense. I remember when myth was that way. UUS works until it gets resolved (although it may soon require UMS) [11:12] persia: While folks started the MOTU process and will probably be core dev in the next weeks or months when they will have demoed some experience, I fear it would be too hard to sponsor everything internally ATM [11:15] persia: sure, but sanity is not. [11:51] Hrm. Is it known that one doesn't get a /dev/cdrom symlink in /dev? [11:52] Running latest updates, from my local mirror. [11:54] hello everybody [11:54] one question [11:54] How often the maintainers checks the original projects for new releases? [11:55] sucotronic: "from time to time" [11:55] mmm [11:55] some maintainers are subscribed to announcement lists and see them immediately; some just check every so often; some only update when prodded [11:56] there isn't any mechanism to notify maintainers? [11:58] or is more easy to become a maintainer? [11:59] sucotronic: subscribing to upstream announcement lists is the preferred mechanism for diligent maintainers, though they can also create a debian/watch file and use uscan --report --verbose regularly [12:00] then, I've to contact with the maintainer to ask him? [12:08] sucotronic: filing a bug would be the usual method [12:10]