=== Seeker is now known as Seekers === Seekers is now known as Seeker` [00:26] cjwatson, still not had a chance to look at the logs and figure out the partman-auto problem? [00:31] psusi: I'm focusing on a wubi bug at the moment; it's taking a lot of attention [00:33] oh joy [00:34] I'll try to look at your bug next [00:36] I also made those cleanups you wanted for the two branches to merge... I used Conflicts instead of Breaks though, that ok? [00:36] no, please use Breaks [00:37] Conflicts << is generally bad [00:37] nowadays the policy manual has explicit language about when you should use Conflicts and when Breaks [00:37] hrm... why is that? I read that the difference is that breaks still allows the other package to be installed, just not configured... well who cares of dpkg thinks it is configured or not, if the lib is there, it's going to be used and thus, cause breakage, won't it? [00:37] see the policy manual [00:37] I won't merge a branch that uses Conflicts [00:38] (in this way) [00:38] it makes apt's job unnecessarily harder on upgrade [00:38] hrm... [00:38] * psusi runs and changes the Conflicts to Breaks [00:39] thanks for making the other cleanups; I haven't looked at them yet for much the same reason [00:48] changed Conflicted to Breaks and pushed... man I love emacs [00:58] honestly, how does gnome-system-monitor manage to burn through ~20% of the cpu when audacious playing mp3s doesn't even register as 1%... [00:59] playing mp3s is a common hw-accelerated operation, no? [01:01] azeem, no [01:02] * psusi remembers winamp using 90% of his 90 MHz pentium cpu, hehe.... come a long way since then... [01:09] psusi: pentiums didn't have hw-acceleration, no? [01:17] azeem, hw-acceleration is a function of... hardware... like a 3d video card... mp3s are decoded in software still... even idling alone at the low power 1.6 GHz state, this core i5-2500k is something like 100 times faster than that p-90... then you throw in the fact that it's got 4 cores... and somehow gnome-system-monitor manages to use a significant chunk of that... go figure. [01:22] psusi: I've found that gnome-system-monitor has been a CPU hog in the past too, no idea why though. [01:34] the cpu meter drawing algorithm is abysmal? [01:38] do I have to create a dedicated proxy object to use dbus_g_proxy_connect_signal(), then attach a signal handler to that proxy object, or can I use an existing gobject class that already has the desired signal handler and pass that AS the proxy to dbus_g_proxy_connect_signal? [01:43] that's the true answer btw. gnome-system-monitor is so slow because the resources graphs are written in about the most idiotic way they could be. see also http://audidude.com/?p=404 === dendro-afk is now known as dendrobates === asac_ is now known as asac [03:39] nothing like blaring loud rock ( Korn ) on a hacking session while the wife is out seeing a play with a friend [03:44] * RAOF prefers Cowboy Bebop for hacking. Or Radiohead when cooking up an undodly abomination unto nature of a regex, like now. [03:45] * StevenK is hacking LP while listing to Rammstein [03:45] Er. Listening [03:46] Not drunk-hacking? :) [03:47] No, just having my brain going faster than my fingers. Like usual. [03:48] Hm. dpkg-buildpackage is suggesting that missing build-deps is going to become a fatal error for -S in the future. [03:48] That would be annoying. [03:48] Indeed [03:49] I routinely build source packages with only debhelper installed. [03:50] ohh, Rammestein... there's something I've not listened to in quite some time... [03:59] Run along now evolution. Daddy wants his 2GiB back for the build tmpfs. [04:06] I compiled my own version of open-vm-dkms (using sbuild -d natty -A *.dsc), but installing the resulting open-vm-dkms*.deb gives me: [04:06] This package appears to be a binaries-only package you will not be able to build against kernel 2.6.38-5-generic since the package source was not provided [04:06] i don't know what htat means [04:07] RAOF: Thunderbird is only taking up 1GiB here [04:08] Yeah, I've tried Thunderbird in the past. I've always found it to be just a little bit more crap than Evolution. [04:09] Maybe we just should just ship mutt at the default MUA. [04:11] odd... my tibrd process only has 121m rss atm... and I have a LOT of very LARGE mailboxes ;) [04:12] My thunderbird's RSS is 300MiB, but virtual is a touch over 1GiB [04:12] I have been wondering lately why so many processes seem to have such massive virtual sizes when rss is reasonable [04:13] Leprachauns. [04:14] Interesting discussion at a time when I am poindering trying anothe email client for a bit... [04:14] pondering [04:14] And evolution is off the list already... [04:15] I keep meaning to make myself try mutt [04:15] ...and xul apps are off the list, as they perform poorly with Orca atm. [04:15] TheMuso: I suggest telnet [04:15] StevenK: lol [04:15] TheMuso: and kmail as well of course.... [04:16] maco: Of course... [04:16] oh right! there's a qt at spi tarball im supposed to turn into a package soonish [04:16] I was thinking about Claws actually, as its GTK based. [04:16] then again, I find myself getting sucked more and more into emacs lately... been using it for terminal windows now... probably going to end up using gnus to read mail [04:16] by which i mean 2 days ago [04:16] TheMuso: That isn't dead yet? [04:16] I tried claws for a while. [04:16] * psusi tries claws too for a while [04:16] StevenK: Not sure, haven't really started investigating yet. [04:16] I used to used emacs to read mail ... [04:18] Claws wasn't really better than evolution in any way I found, didn't have calendar stuff, and didn't have my 50-odd filtering rules. [04:18] That's what server-side filtering is for. [04:18] filtering rules go on the server.. sieve for the winz ;) [04:18] Well calendaring doesn't matter as I have to use Evolution to do that anyways *grumble grumble*, and filtering is done server side for me. === Amaranth_ is now known as Amaranth [04:19] RAOF: If you use dovecot for IMAP (and you should!), setting up sieve is easy and full of win [04:20] * psusi been using dovecot for imap with sieve on his server at work for a few years now [04:21] StevenK: Why would I run an imap server? [04:21] RAOF: For your personal e-mail? [04:21] Eh; google's got that. [04:21] though I need to rejigger it to put all of the old archives into a compressed mbox file instead of the Maildir [04:22] RAOF: I thought gmail did filtering anyway [04:22] It does, but it sucks at it. [04:22] Buy a Linode, set up dovecot and postfix, use sieve, profit? [04:23] Or, at least, almost all of my filters are filter-by-mailinglist (which it doesn't do correctly, or didn't last time I checked) or specific-header matching (likewise) [04:23] I guess I could… [04:24] It seems an awful lot like unnecessary work, though. [04:25] RAOF, what is "it"? [04:25] Buying a Linode, setting up dovecot and postfix, and sieve. [04:25] Then you need to move MX records and such :-) [04:25] Then maintaining the same. [04:26] is linode like a virtual server? I run dovecot and postfix on my server at work with sieve for filter rules and it works great [04:26] A Linode is a VPS [04:26] it pulls mail with fetchmail, then uses postfix and dovecot with sieve filters to sort, store, and serve mail [04:27] which I read with thunderbird at home and at work... though I have also tried using claws and evolution and ended up back in tbird [04:27] really need to give mutt a good try one of these days... [04:28] RAOF: I have dovecot, postfix, apache and duplicity to handle the-datacentre-is-now-a-smoking-crater case and spend maybe ten minutes a week looking after it. Then again, it is your time. [04:29] * psusi needs to spend some time again soon deciding if he should improve dump ( if it needs it ) or go back to using tar [04:29] StevenK: some of us still use procmail instead :) [04:29] Work mail is filtered using procmail, so I can use that too. [04:39] then again, maybe first I should finish my proposal from years ago about automagical read/write mounts of cd/dvd/bd-rw media so they behave like giant floppies [04:45] yea, so.. macs have a little check box in the gui to disable permissions on mounts... I did some work in that area for udf a few years aback... would it be useful to do some kernel work for ext4 to be able to disable permissions on external media and integrate that into the gui disc properties dialog box? === _LibertyZero is now known as LibertyZero [07:24] good morning [07:34] Good morning [07:35] good morning [07:52] lool: thanks for fixing cdbs! [07:52] lool: retrying gdb build [08:04] * pitti sends a metric ton of new langpacks launchpadwards === smb` is now known as smb [08:22] dpm: ^ FYI; note that they already have the firefox 4.0 final XPIs, so they won't work yet with our beta12; but Chris is going to upload 4.0rc1 this week [08:23] morning pitti. Thanks for the heads up. Can you paste the message you are pointing to above? I wasn't on the channel yet and I cannot see it [08:24] dpm: oh, nothing special: "* | pitti sends a metric ton of new langpacks launchpadwards" [08:24] ah, ok :) [08:26] pitti, do you think you'll be able to have a look at bug 731298, so that we can start the maverick langpack testing tomorrow? If not, I'll simply delay the call for testing [08:26] Launchpad bug 731298 in langpack-o-matic "Untranslated Firefox in the Maverick and Lucid language pack PPAs" [Undecided,New] https://launchpad.net/bugs/731298 [08:27] dpm: I'll try [08:27] I hope it's not too involved [08:29] pitti, thanks a lot. Yeah, if you could just let me know whatever the outcome is, that'd be great, so I know whether I should send the announcement or delay it [08:33] good morning [08:33] good morning [08:59] dpm: hm, they've always been meant to also be in the update package, but I guess since we don't use LP translations for them anyway they wouldn't need to be [09:00] dpm: that doesn't seem to be the actual problem, but it might aggravate it [09:00] dpm: anyway, I'm afraid we'll need fresh -base packages to clean this up [09:00] pitti, ah, I didn't know that. I thought they could only be on the -base packages because LP only exported FF translations on full exports [09:01] dpm: when I originally implemented that, I assumed that we do want them in updates as well, just as normal po files [09:01] dpm: I wasn't actually aware that we only use po2xpi [09:02] dpm: I'm totally unsure why https://lists.ubuntu.com/archives/ubuntu-translators/2011-March/004486.html claims that there's an empty firefox 4.0 dir, though; his dpkg -L output doesn't show that [09:02] but indeed it does show that the file structure changed quite a bit; I'll try to reproduce that [09:04] pitti, I'm not sure why LP can't export them in delta exports, because they are essentially PO files with a bit of a different format. Theoretically, it would be useful to have them in delta packages too, but I don't know if there are technical limitations there (either on the LP or the packaging side). "dpm: I wasn't actually aware that we only use po2xpi" - I'm not sure I follow this part, what do you mean with that? === hunger_ is now known as hunger [09:11] dpm: sorry, I mistyped; I meant to say "that we only use xpi2xpi, and not the LP translations" [09:11] ah, ok [09:11] anyway, I see the problem [09:13] dpm: I'll create a test case for it first [09:13] ok, cool [09:14] I still don't understand why installing the update package makes the original files go away, though [09:15] dpm: just to be sure, this only affects the PPA, not current lucid-updates, right? [09:15] or lucid-proposed as well? [09:16] pitti, that's what translators reported (it affects only PPA). They only started seeing it when they got the latest PPA update, as far as I understood it [09:16] in maverick, and then someone confirmed it for the Lucid PPA as well [09:16] dpm: right, because the lucid-proposed packs are empty [09:17] we had a -base refresh on 20110204 [09:17] ok, good [09:19] dpm: so, the PPA update packages do ship a single empty ./usr/lib/firefox-addons/extensions/langpack-de@firefox-4.0.ubuntu.com/ dir, but why does that remove the 3.6 translations.. [09:29] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: Daviey [09:34] pitti, do you think apport could grow a "report & restart" option? [09:34] in the case of compiz crashing I'd LOVE for it to be reported and compiz restarted, so I can get back to work afterwards [09:34] (and I'm never sure if compiz needs a bunch of command line arguments that I don't know of) [09:34] dholbach: sure; I guess at that point one of it should perhaps become a checkbox instead [09:35] to avoid having four buttons [09:35] whatever way it's implemented, I'm happy :) [09:36] dpm: would it matter much if we postpone today's call for testing? === Guest79780 is now known as Kmos [09:37] dpm: I could do a half-arsed hack and hope for the best, or fix it properly, with test cases, and in a robust fashion, but then it'll take a bit longer than "today 1400" [09:38] pitti, I'd prefer the full-arsed fix as well :) So let's delay it. Do you have any rough estimate when you'll have time to implement the proper fix, so I can add some info to the announcement? [09:39] dpm: I think I can get that done today, and let the new build/upload run overnight [09:39] dpm: should I do that straight to -proposed, or do you prefer having it in the PPA first? [09:39] (the former would avoid another build round in the ppa) [09:41] pitti, yeah, I think direct upload to -proposed would be a good idea. That's where people should test it from, no need to have it first on the PPA at this point [09:41] *nod* [09:42] thanks a lot pitti [09:50] fta, hello, the arm build still has not hardening enabled and needs debugging? [09:52] pitti: gdb rebuild worked fine; thanks! [10:05] janimo, Thanks for fixing i386 / axis2c... such a frustrating bug [10:06] Daviey, cheers [10:10] Daviey, you are aware that if janimo fixes an x86 bug for you you are on duty to fix an arm bug for us, right ? [10:10] *g* [10:11] ogra, you need to twist his ARM harder [10:11] haha [10:12] just when everybody thought all stupid ARM jokes had been made already :) [10:17] ogra, If you give me arm hardware, i'll gladly fix stuff :) [10:18] I know they don't cost an ARM and a leg... but even so. [10:18] (hope that isn't purely a britishism) [10:19] * ogra hands Daviey a bangle ... (i didnt know you were that much into jewelry) [10:20] thanks :) [10:45] dpm: btw, do you want me to upload both lucid and maverick at the same time? or just one? [10:46] pitti, just maverick to -proposed. I guess Lucid will be fixed automatically at the next PPA upload, and we're not planning any updates until the next point release there [10:48] cjwatson: if grub-gfxpayload-lists is in universe, I don't think I can fix cards that have problems with grub's bootsplash with nvidia and fglrx [10:48] pitti, FYI henninge just confirmed that for firefox translations exported from Launchpad there is no special treatment, i.e. they can either be exported in the delta tarballs or in the full ones, so my assumption that they were only exported on full tarballs was wrong [10:48] cjwatson: any plans to move it to main? [10:50] tseliot: oh, yes, it really ought to be moved to main [10:50] tseliot: could you send me an e-mail reminder? [10:50] cjwatson: sure [10:50] thanks [10:51] dpm: ok, thanks; I disabled the maverick cron job now, and kept lucid [10:56] pitti, ok, cool. Do you think you could you also enable the natty ones now that the full langpack is building? Btw, I see on http://macquarie.canonical.com/~langpack/crontab that natty langpacks are only being build on Tue, but according to the schedule they should also be built on Fri. Is the cron job set for Fridays as well, or is it just a glitch in the parser that creates the human friendly description on the exported crontab page? [10:57] dpm: sure; do you want to enable it youselves, to get the hang of it? [10:57] pitti, sure :-) [10:59] dpm: it's not just a glitch, natty cronjobs really just run once a week right now [10:59] dpm: but I'm sure that the current perl magic won't get along with two days [11:00] pitti, ok, that's not critical as long as the two days are enabled, and it shows it's enabled/disabled [11:11] I am working on security issues of package phpmyadmin. the patch available on http://www.phpmyadmin.net/home_page/security/PMASA-2011-2.php . it seems that they are fixing all the issues in 3.3.x version, lucid has 3.3.2 with no issues fixed while maverick has 3.3.7 with most of the issues fixed. What should I do, take the patch from the link and fix version 3.3.2 or backport the maverick one? === asac_ is now known as asac [11:19] c2tarun: patch any issue the lucid version is affect by and ask ubuntu-security-sponsors for sponsoring [11:47] geser: hey just applying is enough or we have to test also that patch is working or not? [11:52] c2tarun: don't know, better ask someone from the security team. [11:53] you should at least test if the application still works [11:53] geser: ok thanks :) i'll do that === MacSlow is now known as MacSlow|lunch [12:24] Hi there! couldn't find a development channel so I thought that I'd give it a try here. Is there anyone that tried to customize ubiquity? I've done quite a lot but there's one problem I can't seem to solve. And that is how to change the pre-highlighted install language. By default the highlighted installer-language is english. I would just like to change it to Swedish. However it seems like [12:24] tere 's ALOT of files ubiquity uses to process that kind of information...Oops, cut and paste from the ordinary ubuntu channel ;) [12:25] Norrlanning: just put sv in /isolinux/lang on the CD [12:26] or boot with debian-installer/language=sv as a boot parameter [12:27] cjwatson: And that will also make the english option remain? in that case that sounds awesome :-) [12:27] yes, that should just change the default [12:28] Norrlanning, I'm Skåning ;-) [12:28] Because the default on the system is correct, it's just ubiquitys installer that needs to change :-) [12:28] diwic: Hehe well hiya :-D [12:28] diwic: LX? [12:29] Norrlanning, I think we have to make skånska the default ;-) [12:29] Norrlanning: yes, I mean it should change the default selection on ubiquity's language selection page [12:30] dpm: at least it shows the first day correctly on http://macquarie.canonical.com/~langpack/crontab [12:30] cjwatson: Thank you very much. This problem has been bugging me for 2 whole days :-D [12:30] diwic: Haha oh yes ;) [12:30] pitti yeah :) [12:31] c2tarun, Hey, are you around? === diwic is now known as diwic_afk [12:32] Daviey: yup [12:32] hi [12:32] c2tarun, Super... you've been super busy fixing some of the FTBFS bugs! [12:33] Daviey: I was fixing some FTBFS but in free time :) not busy, why what happened? [12:33] barry, I just replied on the ubuntu-packaging-guide merge proposal [12:33] sorry for the long wait [12:33] although I had hoped somebody else would get to it earlier [12:33] c2tarun, it's really good work.... [12:33] Daviey: thanks :) [12:33] c2tarun, The only thing i'm thinking is https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032632.html [12:33] c2tarun, Under the latest natty toolchain they do build.. [12:34] c2tarun, As that mail says, when o-series opens - we'll have the same bug again. So i was thinking, keep the bug open, see if Debian adopt the patches when O-Series opens? [12:34] c2tarun, This will mean we should get the fix for free, without deviating too far from Debian. What are your thoughts? [12:35] c2tarun, Over the weekend, i did forward one of your patches to Debian... but am i right in saying that you have pushed the rest of the patches to Debian? [12:36] Daviey: yup, artur told me to file a bug in debian first and then close that bug in changelog. [12:37] c2tarun, So you are ok with your patches not going into Natty? [12:38] dholbach: no worries. i'll do the merge. i'll be taking off soon-ish to pack and travel for pycon [12:39] barry, gotcha - just get it in there and I'll put some work into restructuring [12:39] it'll be great to just have the content in there first [12:39] dholbach: awesome! [12:39] Daviey: what do you mean by not going into natty? I mean they are being fixed at both places I guess in debian as well as in natty, + I dont understand what on that link mean exactly? I mean the one who posted the bug is saying that do not drop ld --as-neede patch, why would someone drop that patch? [12:40] Daviey: is he saying for the release next to natty? [12:41] c2tarun, So, the patches you have submitted fix FTBFS.... but under the current toolchain in Natty they do build. What i am suggesting is that your work goes straight into Debian, and next cycle they'll get sync'd across. [12:42] So your fixes will be in O-Series when it opens. [12:42] Daviey: sorry to ask this but what is O-Series? [12:42] c2tarun, Part of the concern i have is that some of these packages, it introducing a delta - which means that someone will need to manually request a sync. [12:43] dholbach: merged and pushed [12:43] ROCK [12:43] * dholbach hugs barry [12:43] barry, blueprint updated [12:43] c2tarun, O-Series is the name of the next development cycle, that i can neither spell nor pronounce :) [12:44] * barry feels better already! [12:44] Daviey: ok :) so if my work goes straight to debian we can easily get them sync automatically without any manual sync request right? that sounds good :) [12:46] Daviey: ping [12:47] c2tarun, yeah! There is one more thing you can add to make tracking easier for the bugs you've opened... On Launchpad you can mark, "affects distribution" and paste the url to the debian bug. Makes it easier to track next for next cycle. === ogra is now known as Guest90542 [12:47] <\sh> micahg: zf 1.11.4 is ready for backport :) thx :) === Guest90542 is now known as ogra_ [12:47] Daviey: sure I'll do that :) not a problem at all. [12:50] c2tarun, you rock, thanks :) [12:50] Daviey: ty for the squid upload. :) [12:51] SpamapS, I wasn't sure if ":" was a bashism, that wouldn't work in dash... seems it does... perfect, didn't even need to comment on it :) [12:52] Daviey: I tend to think that all terse confusing things will work in dash. [12:52] portability of ':'> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#colon [12:56] the difference between : and true is that : is required to be a "special built-in utility", so need not be execve-able etc. [12:56] in some shells the special built-ins will be more efficient [12:57] cjwatson, bash doesn't have a built-in 'true' does it? [12:58] $ which true [12:58] /bin/true [12:58] Nope. [12:58] yes it does! [12:58] Really? [12:58] soren, I just did that aswell :), but wondered if exec overides the which :) [12:58] man bash [12:58] true has to be provided on the search path, per POSIX [12:58] I thought which would say it was a built-in. [12:58] type will say it's built-in [12:58] which explicitly searches $PATH [12:58] $ type true [12:58] true is a shell builtin [12:58] ah, so it does! [12:59] * soren thought which was a built-in, but apparantly not. [12:59] nope [12:59] I guess it would be kind of hard for a not-builtin to decide if something else was a built-in. [12:59] exactly [12:59] type is a built-in :) [12:59] This patch piloting lark, is educational :) [12:59] Indeed. [13:00] * soren crawls back under his rock [13:00] cjwatson, so in this instance : is as efficient as true, but if we had a shell which doesn't builtin true - : would be better? [13:00] right [13:01] nice. [13:01] 'true' is a "regular built-in utility" in POSIX parlance - may be built into shells, must still be provided on search path, has special treatment for command execution (http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01) [13:02] Who needs the internet / grep code, when you have a cjwatson. [13:02] that special treatment being in brief that you can't change its behaviour just by putting a different implementation in front of the system one on $PATH [13:03] (which is probably not widely known - it's not something I remembered until I looked it up just now) [13:04] Interesting. === MacSlow|lunch is now known as MacSlow [13:33] dpm: ah, forgot one thing to reply: the lucid .debs in the PPA will get fixed automatically in the next run, but people who already upgraded to the broken ones will need to purge them and the -base and reinstall [13:33] pitti, ah, thanks for the heads up. I'll let translators know [13:33] dpm: thanks [13:36] I see there's a blueprint to replace gdm with lightdm in natty, but it's not implemented yet. will this feature come in natty or natty+1? [13:40] artfwo: the blueprint was about providing lightdm; it wasn't planned to replace the default in natty [13:40] artfwo, not natty for sure but it will be discussed at uds for next cycle [13:41] it's about replacement judging from description, https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-display-manager [13:42] but thanks for the answers, hopefully this area will get some attention for the ocelot [13:42] artfwo, see the whiteboard [13:43] seems like the whiteboard didn't really get a summary of the UDS discussion notes though [13:44] seb128, gnome-user-share was in the default install in 10.04 but gone in 10.10; was it an intentional change? (looking at bug 536766) [13:44] Launchpad bug 536766 in gnome-user-share (Ubuntu) "Personal file sharing preferences dialog does not offer to install needed packages" [Low,Triaged] https://launchpad.net/bugs/536766 [13:45] chrisccoulson, ^ [13:45] mdz, was it? [13:45] yeah, i think it was recommended by gnome-bluetooth [13:45] seb128, it wasn't seeded, but it was on the CD (chrisccoulson pointed it out to me) [13:46] that's how I noticed: I wanted to receive files over bluetooth and it took a while to figure out what to install [13:46] seems like it should still be recommended [13:46] not sure when and why it got dropped though [13:46] it was dropped to suggests [13:46] ah [13:46] that seems wrong [13:46] yeah, the "Receive Files" button in gnome-bluetooth doesn't work without it [13:46] no mention in the changelog [13:47] oh, the changelog is abbreviated [13:47] [ Andrea Veri ] [13:47] * debian/control: [13:47] - added a suggests on gnome-user-share, its bluetooth [13:47] support should be working fine now. === diwic_afk is now known as diwic [13:48] mdz, that seems wrong [13:48] seb128, it's an odd thing to say if it already had a Recommends [13:49] mdz, ? [13:49] oh the changelog [13:49] y [13:52] mdz, ok, it's a merge error in http://launchpadlibrarian.net/49137567/gnome-bluetooth_2.30.0-0ubuntu3_2.30.0-1ubuntu1.diff.gz [13:52] seb128, ahh, well spotted [13:53] mdz, I will put it back, thanks for spotting it [13:53] seb128, should we use bug 536766 to track the lost recommends then? [13:53] Launchpad bug 536766 in gnome-user-share (Ubuntu) "Personal file sharing preferences dialog does not offer to install needed packages" [Low,Triaged] https://launchpad.net/bugs/536766 [13:54] I will fix it up if so [13:55] it should be a non-issue if gnome-user-share is installed by default [13:55] though it's not directly to do with bluetooth [13:56] maybe it would make sense to seed gnome-user-share [13:56] is there any option to pass to fsck so that it takes all answers as yes by default ? :-| I am unable to boot , filesystem seems to be corrupted [13:57] mdz, no, let's keep that bug about what the title describes, people might still uninstall the recommends and run into it [13:57] mdz, I will add the Recommends back now, no need to track it in a bug [13:57] ok [13:57] yeah, it's talking about the apache based sharing so a different issue [14:06] TheMuso, hello, planning a new pulse upload soon? [14:07] janimo, did you recieve the patches from ndec ? [14:07] * ogra_ cant remember seeing them yet [14:13] ogra_, ndec? Related to what? [14:14] who is ndec? :) [14:14] janimo, nicolas from TI ... he has pulse atches we need to integrate [14:14] *patches [14:15] ogra_, ah no. There's just one small issue in the porting queu [14:15] ah [14:16] ogra_, I did not know about anything TI &pulse related [14:16] we still need to add the UCM config to alsa-utils first though [14:16] and we can only do that after the kernel was switched to .38 [14:18] * ogra_ grumbles, still no trace of the new livecd-rootfs ... the publisher annoys me === ogra_ is now known as ogra [14:46] mvo: any objections for a patch to app-install-data for a package before it's in the archive? [14:46] (but is in my PPA ;) ) [14:47] YokoZar: hello! will it be in the archive soon? [14:48] mvo: I hope so, but there's a chance it might not make it in at all in the release. Would that be a bad thing? [14:48] mvo: I'm hoping software center does the smart thing and hides it completely if the referent package doesn't exist. Which would make adding it a good thing even if it only existed in PPA [14:49] I need to double check that, it may assume your repo data is outdated [14:49] (i.e. for some reason /var/lib/apt/lists/ is empty/incomplete) [14:49] so it will probably offer you to update [14:49] over and over [14:49] which would be bad [14:50] but wouldn't that happen if a user disabled universe? [14:52] YokoZar: if an app is listed in app-install-data, then s-c will display it in the listings whether it is available or not; in the details view an error will appear 'the pkg $pkgname is not available in your current software sources' [14:53] kiwinote: ahh ok, that makes sense. Best to get it in the archive then! [14:53] YokoZar: yep, that would be best ;) [14:53] * YokoZar laments that we still don't have the ability for PPAs to add additional proper entries [15:34] hm, why is my install-exec-hook not happening? [15:38] dpm: uploading maverick-proposed langpacks now; they'll compete on buildd power with the natty ones, so it'll take a while === dendrobates is now known as dendro-afk [15:54] LP bug #422298 has been fixed in Debian's dash 0.5.6.1-1~exp1, but Natty has 0.5.5.1-7.2ubuntu1. [15:54] I'm interested in helping get this backported for Lucid, what method should I follow? I think the standard SRU policy doesn't apply here as the bug isn't fixed in Natty... [15:54] Launchpad bug 422298 in dash (Ubuntu) "dash interpreter don't handle some unicode characters correctly" [Undecided,New] https://launchpad.net/bugs/422298 [15:59] alkisg: do you really think that is a good idea? I *SERIOUSLY* doubt it [16:00] alkisg: given that dash is the default /bin/sh, there is a LOT of potentital for regressions [16:00] janimo, hi, correct, pie disabled on arm (only), due to lack of h/w on my side and lack of help in general [16:11] diwic: Hey, just wanted to let you know --> Great work on the audio hook! [16:11] Chipzz: why not? It currently breaks even touching a file in the Greek translation of "desktop" [16:11] nigelb, thanks :-) [16:11] diwic: I'd taken a session on apport hooks and was WOW when I saw it :) [16:12] * nigelb hugs diwic [16:12] alkisg: I just told you why... [16:13] Chipzz: well, it's a 2 lines patch, which is confirmed to fix a serious problem [16:13] So I don't see why I should be afraid of regressions for that [16:13] alkisg: yeah? and? so? what? [16:13] Chipzz: and so, systems here break, and they can be fixed [16:13] alkisg: you do realize that not every bugfix gets a backport to stable, do you? [16:13] I don't see your point [16:13] and I do not see your point at all [16:13] Sure. I only care about serious bugs [16:14] and IMO that one is not serious [16:14] I say again, that touching a file in the greek desktop fails because of this bug [16:14] (but that's just my 2c) [16:14] I wouldn't have reported that bug if I wasn't affected [16:14] Anyway, any answers to my question? [16:14] (thank you for your thoughts + time btw) [16:14] alkisg: please elaborate on how the fact that this bug affects you personally makes it important? [16:15] Chipzz: no, it affects all of 200 greek schools I keep an eye on [16:15] I have dozens of bugs affecting me, but I'm not going to claim they're important because they affect me... [16:15] It doesn't affect me personally [16:15] alkisg: to me, that bug sounds reasonable to fix in an SRU [16:15] it's high-impact for many people [16:15] cjwatson: thank you. My problem is that I think that for an SRU, it needs to be fixed in Natty first [16:15] yes, it does === tkamppeter_ is now known as tkamppeter [16:16] figure that out first :) [16:16] Yup, that's where I have the problem, and why I was asking :) [16:16] How to get that fixed for natty past feature freeze :) [16:16] cjwatson: do you really think it is a good idea to mess around with the default /bin/sh ?? [16:16] are there any other feature changes between what we have now and what's in Debian [16:16] Chipzz: if it's having that kind of impact, it is perfectly reasonable to consider it [16:17] I haven't checked the changelog from natty to debian exp [16:17] cjwatson: like I mentioned above, the regression potential is HUGE [16:17] obviously such a change should be well-tested [16:17] but I think it's inappropriate of you to reject it out of hand [16:17] if a backport of dash breaks, it doesn't just break lightly, it breaks everything everywhere [16:18] alkisg: you should - but if it's too big, we can backport just that fix to natty [16:18] Is there some cherry picking procedure that we could use to only backport those 2 lines? [16:18] Chipzz: excellent, then we'll notice it and we can avoid promoting it to -updates [16:18] Thank you cjwatson, will check the changelog and comment on the bug report [16:19] alkisg: sure, fish out the patch and apply it :) [16:19] cjwatson: I doubt users of an LTS release would appreciate literrally having half of their system broken ^^ ;) [16:19] Chipzz: it won't affect them until it's been regression-tested in -proposed [16:19] it is sensible to take care with -updates, but frankly I think you're being unnecessarily alarmist [16:20] we can assess this sort of thing calmly, without resorting to hyperbole [16:21] if an update exhibits that kind of breakage, then it's an easy decision not to roll it out to everyone === dendro-afk is now known as dendrobates [16:22] Daviey: If you are still on duty, could you check on the branch at bug 715766? [16:22] Launchpad bug 715766 in pyserial (Ubuntu) "ImportError: no module named serial" [Medium,Confirmed] https://launchpad.net/bugs/715766 [16:24] well I'ld say if that bug is so important how come it was unfixed in an LTS for close to a year? [16:24]