[00:09] hi, I've made a small program that fixes the numeric keypad functionality on laptops. I think it could be of interest for someone else so I made a .deb package, is there anything useful I can do with it? [02:10] something seems really wrong with the way the kernel is handling pipes... tar -cf - > /dev/null takes 15 seconds... tar -cf - | cat > /dev/null takes 3 minutes, 15 seconds [02:21] are .desktop for mozilla (e.g. Thunderbird) bet translated in Rosetta? or Suspended in Rosetta? or is it manual? [02:21] s/ bet / get [02:22] xnox: manual right now [02:22] ok so I'll get the patch in then =) [02:23] micahg, manual as in usuall mozillateam branches, right? [02:24] xnox: yes, I need know though if we need a UIFe or FFe for it [02:24] micahg: my bet is neither [02:24] we have some requests pending and I'd like to commit them if an exception isn't needed [02:24] it's translation of a desktop file and it's not translation freeze yet AFAIK [02:26] robert_ancell: can you review the patch in bug 501054 and if not going to be integrated add your comments so I can reject the patch? [02:26] Launchpad bug 501054 in gcalctool "gcalctool 5.29 hides switch for display format in its settings window" [Low,New] https://launchpad.net/bugs/501054 [02:41] micahg: If you're just adding translations, but not changing strings, you don't need a UIFe. If you're changing strings, you need approval from the docteam. [02:45] nigelb, looking now [02:47] robert_ancell: thank you :) [02:51] persia: so new ones are ok even though it displays something new in a foreign language? [02:52] micahg: Yes, because the *meaning* of the string hasn't changed. [02:52] persia: ah, ok, great [02:52] micahg, https://code.edge.launchpad.net/~dmitrij.ledkov/thunderbird/desktop.es/+merge/21824 [02:52] For example, if a program is based in French, and someone adds a new English translation, that might change the screenshots for English documentation, but few people will complain, because they can now read it in their preferred locale. [02:53] *but* if the original French changed and broke all the translations, this annoys the docteam (who has to change) and annoys all the translators (who have to update). [02:53] and annoys all people where docs talk about one thing and it's actually called something else in the software =) [02:54] persia: what about adding to categories in Software Center? [02:54] I suspect that's enough of a change that you'd want to contact the docteam. [02:55] translations are a special case, and the langpacks get continually updated post-release, which leads me to believe that even post-release translations are acceptable (but take great care, as rebuilding code can change behaviour in unexpected ways). === tlp` is now known as tlp [03:27] Anybody from ubuntu-release that could look at bug #543888? [03:27] Launchpad bug 543888 in open-vm-tools "FFe: New upstream release of open-vm-tools" [Undecided,New] https://launchpad.net/bugs/543888 [03:54] so I burn a CD, and it ejects, and keeps on trying to eject until it says "oh, sorry. I couldn't eject it - you'll need to do it manually" shortly after I finish labeling the disk that I removed when it initially ejected it... known bug? and against what do I file it? [03:56] * lamont guesses wodim [04:01] I recall a discussion in #u-kernel (?) about not locking the CD drive during normal use, and that cd writers would need to explicitly lock the drive. [04:02] lamalex, https://lists.ubuntu.com/archives/kernel-team/2010-March/009315.html [04:02] er lamont [04:02] Maybe wodim or whatever burning software you're using is confused? [04:04] superm1: well, the burn finished fine, it says it's ejecting, ejects, and keeps on trying until it eventually decides that it has failed. closing the tray during that time results in a re-eject, and still eventually gets to failure [04:05] not particularly happy that the laptop locked up during the do-release-upgrade, either [04:06] RAOF: almost certainly [04:08] It might be... interesting... to try ejecting the CD while it's being written. No responsibility for superpowers gained by being hit by CD writing lasers is accepted. [04:12] heh [04:25] I wonder if I can get it to spit out the tray 4 times [04:39] Isn't not locking the drive when a disk is mounted unsafe, in terms of copying data from the disk? [04:40] although on the other hand, it does make sense. [04:41] The read will just fail, surely? [04:43] I think it's on;y unsafe for hardware that makes assumptions. [04:44] So for hardware that is either open or locked, there will be bugginess. For everything else, it's probably better. [04:44] And I think there's only a small number of raised-lid readers without hardware eject buttons that might act like that. === oSoMoN_ is now known as oSoMoN [06:43] Good morning [06:43] StevenK, persia: terribly sorry for the cdbs blunder, and thanks for handling that! [06:43] pitti: wgrant deserves most of the credit, really. [06:43] pitti: You're welcome ;-) [06:44] superm1: checking for dkms sounds good; would that suit your use case, too? [06:44] * StevenK wasn't expecting to get dragged into uploading a bunch of stuff on Saturday night [06:44] wgrant: thanks a lot for handling the cdbs breakage! [06:51] persia orchestrated most of it. [06:51] Thanks StevenK -- sorry for dragging you away from whatever you were doing. [07:01] lamont: hm, it seems jackfruit's http server hangs forever (noticed from hanging ddeb-retriever, but also reproducible with w3m) [07:17] doko_: hm, does that directory have strange permissions? === nixternal_ is now known as Guest87737 [07:18] didrocks: so, Q-FUNK just pointed out that gthumb 2.11 is an unstable series, and not fit for release [07:19] directhex: was there a pressing reason to upgrade to it? or should we downgrade to 3:2.10.11-3build1? [07:19] sorry, didrocks ^ [07:19] moo? [07:19] directhex: sorry, tab completion error [07:19] pitti: actually, others that responded to my blog post pointed it out and, now that I'm taking pictures again, I cannot help but notice that it indeed is unstable, as in constant random crashes and features no longer working. [07:20] pitti: it also seems ot be used as a sandbox for testing new UI paradigms. [07:21] pitti: by the time something as simple as re-saving a JPEG as a PNG makes the application crash, I think that we can safely conclude that this is not fit for an LTS release. [07:21] I agree [07:24] pitti: just to be sure, I pulled a slightly more recent upstream from debian that supposedly fixes a lot of bugs, but it still doesn't. [07:49] amitk: did you happen to see bug 427925? it seems that pm-powersave-policy's sata link power management doesn't actually work in a lot of cases? [07:49] Launchpad bug 427925 in linux "unable to modify scsi host link_power_management_policy" [Medium,Triaged] https://launchpad.net/bugs/427925 [07:52] pitti: I didn't. Thanks for pointing it out. I've passed on my work to Chase Douglas who will be carrying on futher work on pm-powersave-policy. I'll point him to it. [07:53] amitk: thanks === mthaddon` is now known as mthaddon [08:05] Q-FUNK: pitti: the older one didn't work at all with the new udev/devicekit layer we have for camera detection. So, it was better than nothing. I saw that debian was going to package a new one (didn't check yet which version) a little bit better in term of stability. We should sync that one [08:06] didrocks: hm, the old one had a patch to gvfs-umount the camera before talking to it through libgphoto [08:08] pitti: it wasn't working IIRC (I tried it with 3 devices before asking for sync) [08:10] didrocks: hm, then perhaps we should restore that old patch; nothing changed wrt. gvfs/libgphoto since hardy [08:10] udisks etc. is just underlying maic [08:10] magic [08:11] pitti: can do that if you want. I have many crashy devices to test it :) === tkamppeter_ is now known as tkamppeter [08:35] didrocks: import works fine for me. [08:35] Q-FUNK: tried with 3 different devices, but I can revert the sync (or you can, if you want :)) [08:36] Q-FUNK: just that it was crashing on 2 laptop with 3 devices at home [08:36] didrocks: it's a bit more complicated than it appears. we'll need to either introduce an epoch or end up with an ugly version number like pulseaudio. [08:37] and the minute we introduce an epoch is the day we can no longer sync from debian. [08:37] Q-FUNK: avoid epoch, use newer-version.is.older-veresion [08:37] here, the latest 2.10 works fine on all my hardware. [08:38] Q-FUNK: maybe I had bad luck with mine but I tried with a camera, a video recorder and a mobile phone… [08:39] Q-FUNK: I could see them in nautilus, but gthumb didn't import anything [08:39] didrocks: that's a different bug altogether. nautilus has incorrect import apps defaults. [08:39] that was already reported... back in jaunty, IIRC [08:40] Q-FUNK: hum? I just told I can see the devices in nautilus, but not import using them in gthumb [08:40] didrocks: yes, because nautilus prevents you from importing, with its default media application settings. [08:41] its instance of libgphoto2 locks the camera [08:41] Q-FUNK: oh, that was the issue so, and how do you achieve that? you have to close nautilus (even when daemonize) to import with gthumb? [08:42] here, getting this to work required two things: 1) pitti's unmount script that shipped with 2.10 2) changing the media application defaults in nautilus 3) purging gnome-mount 4) purging hal. [08:42] right, make that 4 [08:43] actually, I cannot recall if purging hal was needed or not, but disabling anything else that could access libgphoto2, yes. [08:44] Q-FUNK: ok, understanding better now. Well, step 0 is to revert gthumb, I'm fine with this if we can workaround the importing from devices. Do you want to do it or that I do it? [08:45] didrocks: can we work on this later this afternoon? then we can compare notes about testing this and making possible changes to nautilus gconf keys as needed? [08:45] Q-FUNK: sure, ping me when you are ready to work on that with me :) [08:45] didrocks: cheers! :) [08:45] Q-FUNK: see you ;) [08:46] didrocks, was that discussion about downgrading gthumb? [08:46] seb128: right [08:46] didrocks, why [08:46] ? [08:48] seb128: because it's totally unstable [08:48] and because it's a development version that won't mature into a stable version on time for Lucid. [08:48] seb128: it's an unstable version, still a little bit crashy but no issue for me in one day. Apparently some people has crashes with it regularly. I looked with upstream who told me (when I decided to upload new version) that the new stable one will be really soon available (before beta1), unfortunately, there are late [08:48] did you try syncing from debian? [08:49] seb128: I filed a bug about the sync. needs to be acted upon. [08:49] the crashes will likely go down once synced [08:49] I would stay on the new serie [08:49] it will be easier to mainin forward that an outdated versiojn [08:51] the outdated version is rock-solid. much better suited to an LTS. [08:51] it also use old technologies and has issues [08:52] it did not have any issue. it simply never was ported to GIO. [08:53] softwares with no issues, we don't have any of those [09:14] Q-FUNK, didrocks: hal doesn't access libgphoto, that's fine [09:15] gthumb is supposed to try and gvfs-unmount the libgphoto mount [09:15] pitti: thanks for the info :) [09:22] pitti: Hi, do you have a minute for a question about the doc symlinking code in cdbs? (it's for the gdb FTBFS) [09:22] geser: sure [09:23] geser: that build log looked like the directory wouldn't be accessible or wouldn't be a directory in the first place [09:23] like a broken symlink [09:23] pitti: yes, gdb symlinks the whole /usr/share/doc directory [09:23] ah, that'd be it [09:24] the doc symlinking code has some guards but they only check debian/$(cdbs_curpkg)/usr/share/doc [09:24] isn't there a "/$(cdbs_curpkg)" missing at the end? or did I miss something this tests check? [09:25] geser: "symlinks the whole /usr/share/doc" -> apparently that was done only recently? [09:25] this will lead to trouble either way, though [09:25] dpkg does not replace directories with symlinks during upgrade [09:25] doko_: ^ [09:25] pitti: yes, this changes got introduced with the recent gdb upload (merge) [09:25] that's why cdbs does not symlink directories, just files [09:29] pitti: is there a reason to only check if debian/$(cdbs_curpkg)/usr/share/doc is not a symlink and a real directory and not the directory below it (the one with the doc files for the package)? in what case could usr/share/doc not be a directory? [09:30] Never underestimate what is possible as a result of an upstream build. [09:30] geser: you mean the if [ -d debian/$$dep/usr/share/doc ], righht? [09:31] pitti: yes [09:31] geser: I don't think it was deliberately written that way [09:31] i. e. it could be /$(cdbs_curpkg) too [09:31] pitti: no, the one 4 lines above: [ -h debian/$(cdbs_curpkg)/usr/share/doc ] [09:31] and the next one: [ ! -d debian/$(cdbs_curpkg)/usr/share/doc ] [09:32] geser: ah, that was introduced for some reason [09:32] geser: when we introduced this, this already stumbled over packages which do such crazy things [09:32] geser: but we could add an additional check for /$(curpkg) [09:33] pitti: do you know why the xorg-driver-fglrx package is still available in the archive? Shall I make it a transitional package? [09:33] (the package is named "fglrx" now) [09:34] tseliot: hm, wasn't that the official name until now? yes, it'd need a transitional package then, for lucid [09:34] pitti: ok, I'll take care of it then. Thanks [09:35] geser: you don't happen to have a built gdb tree around, do you? [09:35] pitti: no, but could have it in around 10 min [09:35] geser: how does http://paste.ubuntu.com/399192/ look to you? [09:35] geser: oh, I can test-build it myself, too [09:36] geser: I'll reproduce the ftbfs and test this patch then [09:36] thanks for pointing out! [09:37] pitti: looks good, I did a similar change to test my idea (but I changed the original one instead of adding a new one) [09:38] pitti: and you could add an "i" to my surname in your changelog entry: Bienia [09:38] geser: whoops, sorry; fixed [09:54] pitti: do you know why dpkg-trigger complains when I call it from the postinst? [09:54] dpkg-trigger: dpkg-trigger must be called from a maintainer script (or with a --by-package option) [09:54] I call it with dpkg-trigger gmenucache [09:55] hm, it sohuld be able to figure that out [09:55] apparmor.postinst: /usr/bin/dpkg-trigger update-initramfs [09:55] that looks very similar, and apparenlty works === radoe_ is now known as radoe [10:07] tseliot: does adding an explicit --by-package fglrx help? [10:07] (or nvidia*, whereever you call it from) [10:17] pitti: I'll try it, thanks [10:23] geser: confirmed to work, I'll upload that [10:24] pitti: thanks, not a change which I did introduce myself, therefore the question to fix it in cdbs ... [10:24] doko_: fixed cdbs uploaded [10:24] doko_: right, it should, I was just pointing out that symlinking dirs is brittle [10:28] replacing a dir with a symlink isn't a problem if you know that the package is the only one placing files in this dir [10:29] doko_: you do still need a preinst hack [10:30] i.e. rm -rf old-directory in the preinst, probably with a version guard, assuming that there are no configuration files in there [10:33] there should be no configuration files in /usr/share/doc/$pkg [10:35] cjwatson: really? we'll see with gdb-dev, gdbserver or gdb64, but isn't a package first removed before the new one is unpackacked? [10:35] coffee first ... [10:37] I definitively know that dpkg will never replace a symlink from the old version with a directory from the new one; I'm not sure about the other direction (replace dir with symlink) [10:38] nafaik [10:39] I believe dpkg unpacks *over* the existing package, rather than removing the package first, preserving any symlinks, etc. [10:43] doko_: no, as persia says. removing the package first would cause other problems [10:43] pitti: definitely in neither direction [10:43] it's quite deliberate [10:44] cjwatson: yes, it'd make sense, but I haven't tested it myself in that directio [10:44] too easy to make mistakes, so you have to explicitly force it by removing the old object in the preinst [10:44] thanks for the heads-up [10:44] geser: indeed - I was just trying to make my statement general === elmo_ is now known as elmo [10:52] apw: 2.6.32-17.26 binNEWed, FYI [10:56] pitti: any ideas as to why I've just received 5 messages about my uploads of fglrx-installer being rejected? [10:56] tseliot: yes, I do [10:56] tseliot: those were the binaries for older uploads [10:57] tseliot: I just kept the ones for the current version, makes review a bit easier [10:57] tseliot: please ignore [10:57] pitti: ah, ok, I was starting to think that I did something wrong ;) [11:15] pitti: jackfruit is, um, interesting [11:22] lamont: hi! If I understood you correctly last week, the ltsp squashfs should appear on the disc around any day now right? or was there something we sill needed to do? [11:23] the CD image building side of things needs to actually deliver the file that it now has available [11:23] and that bit is in the "not me" category [11:25] asac: did you have a chance to take a look at bug #542506? - or can you name someone else who can comment on this issue? [11:25] Launchpad bug 542506 in gxine "gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/542506 [11:28] highvoltage: sadly, it would appear that they're not building 'edubuntu', but rather 'edubuntu-dvd' :( [11:29] lamont: would you be able to fix it? [11:30] yeah - I'll add that to the dvd target as well, and upload a new livecd-rootfs today [11:31] thanks! === dendro-afk is now known as dendrobates === ogra_ is now known as ogra === ghostcube_ is now known as ghostcube [12:14] asac: I don't exactly parse your rationale for bug #544085, can you explain why we really want to have it in for lucid? [12:14] Launchpad bug 544085 in ubuntu "[FFe] sync ntrack 006-1 from debian/testing" [Undecided,New] https://launchpad.net/bugs/544085 === MacSlow is now known as MacSlow|lunch [13:24] sistpoty|work: simply to get upstreams easier adopt this === robbiew_ is now known as robbiew [13:48] asac: ah, k. you've got a "not" that mislead me in the description [13:48] asac: would a backport be ok as well? [13:48] (we're past beta1 so I'm very hesitant wrt. new packages) [13:50] sistpoty|work: backport wouldnt work as its not considere in-lucid [13:52] is anyone deeply familiar with dh_make here ? according to the manpage -p should override the directory check but apparently it doesnt [13:53] asac: hm... I guess I'm ok with it but you'll need to find and bribe an archive admin willing to denew it ;) [13:53] sistpoty|work: yeah. thats understood [13:53] :) [14:08] bug 542955 [14:08] Launchpad bug 542955 in bind9 "/sbin/ldconfig.real: File /usr/lib/libdns.so.64 is empty, not checked. " [Undecided,New] https://launchpad.net/bugs/542955 [14:13] argh [14:14] my git-fu is not strong today [14:14] lamont: every time I try and do any merge in util-linux, I get conflicts all over the place [14:14] Keybuk: ew. I'm afk for a few hours, can we chat after that? [14:15] or toss me what you're trying to merge from->to and I'll see about bludgeoning my way through [14:15] I have to rebuild my laptop, because lucid ate it. [14:15] well, to be fair, I fed it [14:15] I'm trying to merge ubuntu/master into your stable/v2.17 [14:15] in your git tree, and you've pushed the current state? [14:16] no, can't push cause just lots of conflicts [14:17] let me rephrase that - if I pull your published tree, will I have what you started with? [14:17] yes [14:17] ok [14:17] and afk [14:17] I guess it's just a "commit on both sides" issue? [14:17] GIT seems to be quite bad at those [14:17] (worse than bzr, and that's saying its shorter than Ronnie Corbet) [14:18] aha! [14:19] it is just that [14:19] Keybuk: commit on both sides? [14:22] amitk: right [14:22] the same commit has been applied to both sides [14:22] ie. to master and to stable/v2.17 [14:22] so is in the history of master [14:22] and in the history of where I'm merging from [14:23] so git is helpfully conflicting it [14:23] don't you have to rebase in this case ? (just guessing) [14:24] Keybuk: because they applied as different shaids, I guess? === didrocks` is now known as didrocks [14:24] c_korn: rebase would still conflict [14:25] right [14:26] pitti: apport seems to not like forms like "GST_DEBUG=*cheese*:3 cheese -v" for the command_output function. any thoughts on this? [14:26] nigelb: That's not a program invocation, but shell syntax :) [14:26] pitti: which means I can do that? [14:26] can't [14:27] nigelb: simplest is probably to use ['env', 'GST_DEBUG=*cheese*:3', 'cheese', '-v'] === MacSlow|lunch is now known as MacSlow [14:27] i. e. call env explicitly [14:27] pitti: ah, and one more question :) how do I do 'killall cheese' this way? [14:27] nigelb: the more general method is to call[ '/bin/sh', '-c', command] [14:28] nigelb: you don't want killall :) [14:28] nigelb: but that doesn't work with the simple command_output any more [14:28] pitti: the idea is to start cheese in debug mode [14:28] so if its already running, I want to kill it [14:28] nigelb: use subprocess.Popen(), wait ten seconds (or similar), and then call .kill() [14:28] nigelb: hm, that sounds a bit ... unexpected; it might be "data loss" in some cases? [14:29] pitti, nigelb: even Upstart calls /bin/sh -c "command" [14:29] nigelb: you could ask for it interactively [14:29] pitti: oh, wait I'm not clear [14:29] nigelb: i. e. ui.yesno("Blabla rationale need to restart cheese in debug mode") [14:29] The idea is, if uses calls Help> report bug and I want to start in debug mode, cheese needs to restart [14:29] nigelb: sure [14:30] nigelb: but you shouldn't "just do" this without warning, I think [14:30] the warning is thre [14:30] but the code to do it isn't working yet ;) [14:30] nigelb: well, unless there's no way to have unsaved changes in cheese (I'm not that familiar with it TBH) [14:30] so l[ '/bin/sh', '-c', 'killall cheese'] would work? [14:30] no [14:30] nigelb: just ['killall', 'cheese'] [14:30] that's a proper command [14:30] that didn't work [14:31] nigelb: but again, that's not what command_output is meant to be used for. Use subprocess.call() for that [14:31] pitti: ah, I will try that :) === steveire_ is now known as steveire [14:32] superm1: http://bazaar.launchpad.net/%7Eubuntu-core-dev/jockey/ubuntu/revision/400 -> ok for you? [14:32] superm1: oh, nice round commit :) [14:32] Keybuk: thank you too :) === fabbione_vac is now known as fabbione [14:45] fabbione: Padre! how are you? [14:45] pitti: wrong question today... just come back with 28 hours delay on my flight [14:46] need to settled down the kids [14:46] urgh, that sucks [14:46] pitti: sorry, I'd love to talk but I am sort of busy :) [14:46] fabbione: np, good luck with settling in! [14:47] how do you tell dpkg to unapply patches in an extracted fmt 3.0 source? [14:48] quilt pop -a ? [14:48] RAOF, ping. can you look at kamujin's super ghetto gnome-keyring-sharp replacement & see if it provides what f-spot needs? [14:48] pitti: ah thanks [14:48] ccheney`: although it's not immediately visible, it should still be quilt underneath [14:48] pitti: hmm quilt isn't installed does dpkg have an internal version too? [14:48] ccheney`: yes, it does [14:49] pitti: ah ok so just install quilt to work with it then, thanks [14:49] ccheney`: if you haven't worked with it, you might want to set QUILT_PATCHES=debian/patches [14:49] ccheney`: (it defaults to ./patches) [14:53] * persia` notes that not all Format: 3.0 packages are Format: 3.0 (quilt) [14:53] persia`: well thats confusing [14:53] maco: Why? [14:54] persia`: there's also (native), but also somethign else? [14:54] i thought all v3 packages used quilt by default [14:54] No. [14:54] Lots of packages use patch systems just like Format: 1.0 [14:54] i thought quilt was a patch system [14:54] AFAIR there was some discussion about "3.0 (bzr)" and "3.0 (git)", but I don't think either works today [14:54] Tbe base means of Format: 3.0 is essentially just a tarball diff. [14:54] or do you mean *other* patch systems [14:55] pitti: so you cant use quilt and bzr together? i guess that makes sense... [14:55] maco: you can, but it's really ugly [14:55] so far I avoided converting bzr or git maintained packages [14:56] it's confusing [14:56] quilt is 1) a tool for working with sets of packages, 2) a system that can be used as a substrate for a primitive VCS, 3) a patch system for debian format package, 4) a format specification for patch application in one flavour for debian format 3.0 packages, ... [14:56] git-buildpackage actually DTRT and applies the patches in the build-area === tlyu_ is now known as tlyu === tlyu is now known as tlyu_ === tlyu_ is now known as tlyu === tlyu is now known as tlyu_ === tlyu_ is now known as tlyu [15:02] which packages does ubuntu automatically pull? suggests? Recommends? [15:02] pitti: I actually find it works really well for me [15:03] cjwatson: I find it confusing to both apply patches and have them in debian/patches; that will still take a while to get used to for me, I think [15:03] pitti: in 3.0 (quilt), the tree generally stays in patched state except when you're actively working on the patches, so I find that tools like 'bzr blame' work much better than they do with old-style patch systems [15:03] pitti: definitely a feature as far as I'm concerned :) [15:04] pitti: http://paste.ubuntu.com/399335/ for example [15:05] it just means that when you commit a change you effectively see it twice in 'bzr diff', but *shrug* doesn't really bother me [15:05] maco: openssh is an example of using quilt and bzr together === aburch_ is now known as aburch [15:06] cjwatson: ok, ill have a look [15:06] muelli: depends and recommends. if using apt on command line (dunno about guis) itll mention the existence of suggests [15:07] the only real glitch I found was the one I filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 [15:07] Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] [15:09] persia`: IME you have to be fairly perverse to use format 3.0 with some other patch system, and the last (and only) time I encountered this I filed a bug and the maintainer said "er, yeah, sorry" === jamie is now known as Guest31598 [15:10] part of the point of format 3.0 was to unify all the patch system mess, so I think using it with an old-style patch system is very definitely Missing The Point [15:10] I'll agree with that, excepting when it's useful to add extra tarballs. [15:11] right, didn't say it was the whole point :) [15:11] yay for unifying patch systems indeed [15:11] I tried to package with bzr loom some months ago [15:12] bzr loom is still definitely in the "nice idea but experimental" bucket for me, I think [15:12] while that worked pretty well, everyone else will just ruin your tree, though, so doing it for some packages isn't worth the trouble [15:12] but it still feels weird to have to deal with debian/patches/ stuff if we have all that VCS magic already [15:13] especially now that you have to do _both_ (in-tree and separate patch) [15:13] I like the principle that patches should be an export format, but I'm not willing to deal with lots of scary experimental VCS technology just for that; having to commit to the original files and debian/patches/ together is IMO a small price to pay for the benefits [15:13] someone wake me when bzr and multi-tar work nicely together. things like pristine-tar need to deal with multi-tar === sladen_ is now known as sladen [15:15] gah === ArneGoet1e is now known as ArneGoetje [15:23] pitti, yes i believe it should help me. i'll double check today and let you know if it doesnt [15:32] Should not be doing an Octopus. [15:32] ... [15:32] thanks git. [15:33] Keybuk, I read your post on ubuntu forums and I checked the GSoC regarding the boot performance. I talked to Riddle and he forwarded me to talk to you. I am asking for any advices regarding making a proposal for improving boot performance that can satisfy for GSoC proposal. [15:34] aboSamoor: what kind of thing did you have in mind? [15:38] Keybuk, on personal level, I am just annoyed by the frequent re-profiling mechanism. As a power user using all the time pre-release software I am all the time updating the software. So according to the re-profiling policy I loose much of the ureadahead advantage. Apart from that, I was following the efforts of the boot performance team, and I am interested in going faster than what I have now. My laptop boots in 22 seconds. [15:39] asac: around? [15:40] aboSamoor: in terms of reprofiling, what we've been missing is the kernel side of tracking which blocks in the page cache were actually used -- that's a kernel patch we've written but haven't tested yet [15:41] in terms of ureadahead performance in of itself, what we need here is the ability to load blocks from disk into the page cache without needing to open a file first -- since the open()s take up a number of seconds === debfx_ is now known as debfx [15:41] I suspect that's way beyond GSoC level [15:41] boot performance > what ways of booting faster can you think of? [15:42] oh, come on, lists.gnu.org, archive things faster so that I can have a URL for my patch file [15:44] ext4 defrag would be nice for booting faster :) === deryck is now known as deryck[lunch] [15:44] Keybuk, I read the post yesterday, and it make my mind busy. I am not a computer engineer, but my work does not deal with PCs usually, more of embedded systems. If you do not mind I would like to ask questions regarding the mechanisms used now, so it helps me to understand better. [15:44] hopefully that doesn't eat your data in the process [15:44] aboSamoor: of course [15:45] ccheney`: would you trust an ext4 defrag that wasn't written by ext4 upstream? [15:45] (then again, would you trust an ext4 defrag that *was* :p) [15:49] ARGH!@# fuckign gnu.... I've been starting to think I was going insane because of all of these bizare performance results I've been seeing with tar while trying to compare it with dump.. .turns out gnu tar cheats and doesn't bother actually reading the input files and writing them to the output if it detects that the output is /dev/null... it just stats the input files [15:50] that seems like a sensible optimisation to me [15:50] no, that's like the old compiler "optimization" that explicitly detected if it was compiling a drystone benchmark and "fixed" it to not bother with all of the computations [15:51] no, that's "tar is not a benchmark" [15:51] and simply not naming the input file drystone.c would defeat the "optimization" [15:51] and the reason why tar does that is in ChangeLog.1 [15:51] "Corrections to speed-up the sizeing pass in Amanda:" [15:51] Keybuk: perhaps, ext4 upstream has shown to be somewhat odd in the past :) [15:52] no, but if I want to see how long it takes to read the files, without having the output compete with the read IO... it should do that... not run me around in circles not doing what I expect it to do when I redirect the output to null, I mean I want the output to go there [15:52] ccheney`: "ext4 defrag corrupted my data!" ... "no, you can't have your pony back" [15:52] Keybuk: definitely would want it well tested before use, i remember using xfs defrag and it eating all my data in the past [15:52] psusi: could you take this to #beingwrongontheinternet plz [15:52] psusi: it's not really relevant [15:52] hehe [15:53] and we're not going to patch tar ;) [15:54] now maybe tonight I can get around to testing defrag packing ureadahead boot files at the start of the disk in order... [15:55] siretart: yes on a call, but whats up? [15:56] asac: I wanted to hear your opinion on the libmozjs.so issue. it breaks applications like gxine [15:56] asac: see bug #544085 for details [15:56] Launchpad bug 544085 in ubuntu "[FFe] sync ntrack 006-1 from debian/testing" [Undecided,Confirmed] https://launchpad.net/bugs/544085 [15:56] err [15:57] make that bug #542506 [15:57] Launchpad bug 542506 in gxine "gxine fails to start: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory" [High,Triaged] https://launchpad.net/bugs/542506 [16:01] # modified: disk-utils/fsck.minix.c [16:01] # modified: disk-utils/mkfs.c [16:01] ... no I didn't, *you* did [16:01] patch system? === MacSlow is now known as MacSlow|afk [16:02] cjwatson: just GIT being unhelpful [16:02] sorry, I am computer engineer I made typos. I was reading the lastest updates to the post, so avoid redundant questions. Now, you cache all the files you will read during the boot in pack files and store names and some attributes. But what about making binary image of the memory for the files have been read, so we are sure that we are reading contiguous data from the hard disk? That will consume 200-300 MB from the hard disk space but i [16:02] t is not problem on many of the HDD drives [16:02] siretart: what does gxine use js for? [16:03] cjwatson: it's having fun by duplicating blocks in all the files [16:03] aboSamoor: because there's no way to tell the kernel that the binary image you're loading into memory is really the contents of blocks of other files on the filesystem [16:03] aboSamoor: as soon as the real files were needed, the kernel would just re-read them all over again [16:04] asac: you can script it with js [16:04] asac: on the command line with parameter '-c' [16:05] Keybuk: hah [16:05] cjwatson: when lamont made the 2.17 release, he merged "ahead" of the release on master and made that the release [16:06] cjwatson: unfortunately the release was the branch point for 2.17.1 - so now I have the "commits with different sha1s on two different branches that are otherwise the same" problem [16:06] Keybuk: this reminds me of doing the parted 2.2-1 release; it took ages to glue all the git history together, and I had to do something like three separate merges to clue git in to what was going on [16:07] I did eventually get to the point where it wasn't giving me spurious conflicts, but it wasn't straightforward === deryck[lunch] is now known as deryck [16:10] Keybuk, if I am not wrong, there is something called ramdisk that will create file system in ram. If we build the filesystem out of the binary image and forward all the files known to be cached to be read from that ram disk, i think it will help. sorry if this looks unrealistic or naive. [16:11] aboSamoor: it's the "forward" bit that's missing [16:11] all copying the files into a ramdisk will give you is a ramdisk with a copy of the files in it [16:11] which is a second copy of the file [16:11]