[00:34] <abhinav-> soren,  sorry for wrongly disturbing you. this stupid xchat does autocompletion whenever it wishes :-/
[00:47] <bryceh_> kees, hmm did you put your mountall changes into bzr?
[00:48] <kees> bryceh_: there is no bzr tree in debian/control for it. did I miss something?
[00:50] <bryceh_> yeah, there is a bzr tree with a change from cjwatson
[00:50] <bryceh_> (and an outstanding merge from me; I'd made the mistake of assuming bzr had current mountall changes)
[00:51] <bryceh_> kees, no worries, I'll fix up
[00:51] <bryceh_> (and fix up control)
[00:52] <kees> bryceh_: argh, uncommitted in UDD? crap, sorry.
[00:52] <kees> bryceh_: I'm still getting used to the idea of people developing in UDD without doing uploads.
[00:53] <bryceh_> it's a bit weird for me too, although we've been doing this (in git) with X a while
[00:53] <kees> yeah, for me, I just don't like having both the automatic upload stomping on the same tree as devel work
[00:54] <kees> bryceh_: if you're not already in the middle of it, I can clean up my mistake; just let me know.
[00:54] <bryceh_> already done
[00:54] <kees> heh, cool.
[00:56] <superm1> doko, mterry what was the package in question that's making mythbuntu uninstallable? i didn't see it mentioned in bt
[00:57] <doko> superm1: dbus-c++ and libconfig, b-d's of libffado
[00:58] <superm1> ah libffado isn't a direct rdepend of anything seeded - but it is of libjack-dev
[00:58] <superm1> that will probably mess both mythbuntu and ubuntu studio then
[01:00] <doko> see the two MIR's, I think both could need a version update and symbols files
[01:00] <superm1> jack support isn't that important in mythbuntu though, so if yall decide jack support has to go for any reason, it's not that big of a deal to just disable it
[01:00] <superm1> the studio guys might feel a bit differently
[01:02] <doko> superm1: could you subscribe these groups to the reports?
[01:03] <superm1> doko, sure what were the bug numbers?
[01:03] <doko> looking ...
[01:04] <kees> bryceh_: I double-checked it too and added the missing conf file.
[01:04] <doko> superm1: bug #730759 and bug #730760
[01:05] <LLStarks> jcastro, is there any way to completely wipe unity settings?
[01:06] <superm1> doko, okay subscribed.  in the meanwhile, i'll disable jack so that the builds stay installable for your archive rebuild
[01:07] <doko> superm1: thanks, will look tomorrow if libffado can be demoted
[01:22] <abhinav-> TheMuso, thanks for looking at my tomboy patch for bug 386893.
[01:24] <abhinav-> I have replaced the messagebox with a label and buttons in the tomboy UI itself. I also posted in the tomboy mailing list, about the changes that I am making. There hasn't been much response :-|
[03:23] <wip> almost done with packaging (.deb) my own application. i have all those dependencies for my application: http://pastebin.com/aTqQEciF (objdump -p ./myapp | grep NEEDED) do i need to list all (and how) in control depends. for example: libgmodule-2.0.so.0 how to write it in my control file: Depends: libgmodule-2.0 OR Depends: libgmodule-2.0.so.0 or...?
[03:26] <highvoltage> wip: you probably want to ask that in #ubuntu-packaging or #ubuntu-motu
[03:26] <wip> highvoltage: thx!
[03:26] <highvoltage> wip: you're welcome
[04:30] <abhinav-> barry, I pushed the changes for the tomcat6 bug , I requested another review :)
[07:07] <abhinav-> could someone please give me the link for getting the latest build of natty ?
[07:09] <abhinav-> I think I found it :)
[07:09] <abhinav-> http://cdimage.ubuntu.com/
[07:17] <c2tarun> need help with last comment of bug 730121 can anyone please tell do I have to make change in Makefile.in as well because changing only Makefile.am is not working.
[07:34] <geser> c2tarun: Makefile.in is generated from Makefile.am ; so you either regenerated it or what I do for simple changes is to patch both files (Makefile.am and Makefile.in) so the change doesn't get lost if someone later regenerates it
[07:37] <didrocks> good morning
[07:38] <geser> good morning
[07:44] <pitti> Good morning
[08:05] <dholbach> good morning
[08:05] <ion> that
[08:18] <c2tarun> geser: ping
[08:35] <pitti> kees: publishing https://launchpad.net/ubuntu/lucid/+source/linux-ec2/2.6.32-314.27 to lucid-{updates,security}
[08:45] <didrocks> ev: hey, when you have some time, can we discuss about bug #730588 (see the discussion on it)?
[08:59] <cjwatson> apachelogger: libpipeline tracks it internally, but there's no method to get pids externally right now.  could you file a bug with an explanation of what you're doing and what you need?
[09:00] <cjwatson> kees: while the automatic upload may stomp on the same tree as development work, it moves any pending changes aside so that they can be restored easily
[09:04] <cjwatson> bryceh_: urgh, I had some review comments on Surbhi's mountall branch :-/
[09:04] <cjwatson> (problem with patch piloting: you have to be quick to grab something you actually want to substantively review ...)
[09:05] <speakman> hi dev folks! This is the second computer having problem with gnome-session-daemon hanging (or dysfunction) on login. If you could tell me who to speak to, I can help tracing this bug as it hits every single time I log in.
[09:06] <lag> Doh! I just competed a dist-upgrade, how my desktop is FBARed
[09:06] <speakman> I've even got a 'bt full' available, but according to that it isn't supposed to be locked up. But it still doesn't die on SIGTERM for example.
[09:06] <lag> s/how/now
[09:06] <bryceh_> cjwatson, urp sorry
[09:06] <lag> cjwatson: Hi Colin
[09:07] <bryceh_> cjwatson, fwiw I did leave the two dmraid ones for you ;-)
[09:07] <cjwatson> bryceh_: thanks, that's good
[09:07] <cjwatson> lag: hi
[09:07] <lag> cjwatson: Have you seen any bugs which allude to problems booting post-dist-upgrade?
[09:08] <lag> cjwatson: The last think I see on my screen is: "*Starting TiMidity++ ALSA midi emulation..."
[09:08] <lag> thing*
[09:08] <cjwatson> lag: I fixed such a bug the other day
[09:08] <cjwatson> bug 723482
[09:08] <cjwatson> but that fix was last Wednesday
[09:08]  * speakman having serious problems booting his RAID0 too. Two out of three times, it asks me to run the RAID0 degraded (how that's possible..). Even though dmesg tells me Linux has found both disks and both partitions.
[09:09]  * cjwatson is not prepared to debug everyone's boot problems all at once :-)
[09:09] <lag> cjwatson: :)
[09:10]  * speakman is a developer himself, but won't invent the wheel if there's already some known issues.
[09:10] <cjwatson> speakman: whatever your problem is is (a) entirely unrelated to what I was talking about (b) nothing I know about myself
[09:11] <speakman> cjwatson: I see. Just joined so wasn't really aware of that's discussed.
[09:12] <speakman> But is there a ubuntu gnome developer channel on freenode? My primary goal is to fix the gnome-session-daemon issue.
[09:12] <cjwatson> #ubuntu-desktop
[09:12] <speakman> Great, thanks!
[09:46] <tdn> I am trying to report a bug in the amd64 version of the linux kernel. What package do I report it on?
[09:48] <pitti> tdn: ubuntu-bug linux
[09:49] <tdn> pitti, ok.
[10:51] <tkamppeter> doko, hi
[11:16] <cjwatson> apachelogger: I have a plausible-looking implementation of pipeline_get_pid now - if you file that bug, I can check whether it will meet your requirements
[11:42] <SpamapS> cjwatson: btw, I have not forgotten your rpcbind diffs. Should be able to look at them soon.
[11:42] <ara> cjwatson, did you find useful the list of system and splash screen videos?
[12:00] <speakman> cjwatson: Do you know a certain channel for solving my raid0 issue described earlier?
[12:01] <GunnarHj> dpm: Hi David, Thought I'd review and update the docs with respect to languages and locales including language-selector, but the only page I found was https://help.ubuntu.com/community/Locale. Are you aware of anything else?
[12:05] <dpm> hi GunnarHj, what are you trying exactly to document?
[12:12] <GunnarHj> dpm: Well, at first hand I'm thinking of a short manual for l-s (to the extent it's not obvious by the UI). Another thing is to explain how to make a more fine grained locales configuration, e.g. separate locales for date formats and numbers. Third I'm thinking of explaining where and how things are stored now, bearing those in mind who help with answering questions.
[12:14] <dpm> GunnarHj, ok. Two things come to mind: either document it first on the wiki, or create a help document for language-selector. For the first one you can start straight away; for the second you might want to contact the docs team about how they work, the tools they use, etc.
[12:16] <GunnarHj> dpm: That sounds reasonable. I take that neither you know of any other existing docs.
[12:16] <GunnarHj> dpm: On another topic, since a few translatable text strings in language-selector were changed recently, shouldn't https://translations.edge.launchpad.net/ubuntu/natty/+source/language-selector/+imports show those strings? Is the time lag that long, or does it indicate that I missed something when updating language-selector?
[12:18] <dpm> GunnarHj, on the first question: no, I don't know of any other documentation. There are some links here you could use as a reference -> https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Coding#Additional%20documentation, but they serve a bit of a different purpose
[12:18] <cjwatson> SpamapS: don't worry too urgently about it - libtirpc/nfs-utils needs work in order to let us configure nfs-utils with TI-RPC support without breaking interoperability with portmap
[12:18] <cjwatson> ara: I will find them useful, but have not started working through them yet
[12:18] <cjwatson> speakman: no, sorry
[12:18] <cjwatson> speakman: maybe #ubuntu-server I suppose
[12:22] <GunnarHj> dpm: Yeah, that page rather shows what you need to do to turn a package to a package which is parsed for strings to be translated. Since l-s already is that kind of package, I thought it would work 'magically' already without doing anything special. Maybe I was wrong...
[12:23] <dpm> GunnarHj, as for the 2nd question, that url ^ shows the status of the templates (or translations) imported. If it's empty, it means that either the templates or the translations have just been imported or that they haven't reached the queue yet. When was the package uploaded with the changes, and are they not in https://translations.launchpad.net/ubuntu/natty/+source/language-selector/+pots/language-selector/sv/+translate ? (you can use the search box i
[12:23] <dpm> n there)
[12:28] <GunnarHj> dpm: No, they are not there (checked it already). And according to https://translations.edge.launchpad.net/ubuntu/natty/+source/language-selector the last edit was made 2010-09-24.
[12:30] <dpm> GunnarHj, could you point me to the package version which introduced them, and give me one of the strings that were modified in the source? (btw https://translations.launchpad.net/ubuntu/natty/+source/language-selector lists the last edit done by translators, it has nothing to do with the date the template was uploaded)
 GunnarHj, could you point me to the package version which introduced them, and give me one of the strings that were modified in the source? (btw https://translations.launchpad.net/ubuntu/natty/+source/language-selector lists the last edit done by translators, it has nothing to do with the date the template was uploaded)
[12:48] <YokoZar> What's the proper way for a package to demand the uninstall of a package before it starts installing?  I have a weird situation where if I uninstall foo and then install bar, it works fine, but if I install bar (which is a later version of foo!) it breaks
[12:48] <YokoZar> Should I make the package conflict with earlier versions of itself?  Somehow that sounds absurd
[12:51] <GunnarHj> dpm: These were two altered strings in language-selector (0.12), released on January 28:
[12:51] <GunnarHj> Language &amp; Format
[12:51] <GunnarHj> &lt;small&gt;Use the same language choices for startup and the login screen.\nChanges take effect only after a restart of the system.&lt;/small&gt;
[12:53] <dpm> GunnarHj, btw, why did you use &amp; and &lt;?
[12:54] <GunnarHj> dpm: I didn't introduce them. Think they are needed for GTK to do the right thing.
[12:55] <GunnarHj> dpm: or maybe because it's XML...
[12:56] <dpm> not sure why & and <> cannot be used, though
[12:56] <dpm> anyway, let me have a look at the strings
[12:59] <GunnarHj> dpm: Not sure about & and <> - didn't test.
[13:00] <apachelogger> cjwatson: https://savannah.nongnu.org/bugs/index.php?32710 within the same context, would it be possible to get a function to write something on the pipeline (i.e. vpnc gets informatin from stdin unless one defines a config file)
[13:01] <dpm> GunnarHj, the latest template seems to have &:
[13:01] <dpm> #: ../data/LanguageSelector.ui.h:26
[13:01] <dpm> msgid "Language & Format"
[13:01] <dpm> msgstr ""
[13:03] <dpm> pitti, I've just built language-selector locally and it didn't create a translations tarball (I've got pkgbinarymangler installed and striptranslations enabled). This might be why GunnarHj didn't see the template in LP being updated. Any hints on what could be happening?
[13:04] <dpm> GunnarHj, btw, if you want to test this yourself, you can try this: https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/RecipeVerifyingTranslationUploads
[13:04] <GunnarHj> dpm: In that case the changes resulted in new templates, at least...
[13:07] <GunnarHj> dpm: Thanks for the tip on how to verify translation uploads.
[13:11] <dpm> no worries :)
[13:12] <pitti> GunnarHj, dpm: language-selector sets NO_PKG_MANGLE=1 in debian/rules
[13:13] <pitti> GunnarHj, dpm: presumably we want language-selector .deb to include all translations, so that at least this program is translated into your language when you need to install missing langpacks
[13:14] <dpm> pitti, ah, ok. So template changes are better uploaded manually, I guess.
[13:14] <pitti> dpm: no, hang on
[13:15] <pitti> dpm: see https://launchpad.net/ubuntu/+source/language-selector/0.6.6 changelog
[13:15] <pitti> dpm: that's bug 654548
[13:16] <pitti> dpm: I think we can just drop the NO_PKG_MANGLE
[13:16] <dpm> pitti, ok
[13:16] <pitti> verified that it's in the blacklist
[13:16] <pitti> dpm: I'll upload a new package now
[13:17] <dpm> cool, thanks pitti
[13:17] <pitti> dpm: sorry for forgetting about it
[13:17] <dpm> no worries!
[13:23] <GunnarHj> pitti, dpm: Thanks for helping with this. Suppose it means that fresh templates with the latest changed strings will soon appear at Launchpad.
[13:23] <pitti> they should; just uploaded 0.24
[13:23] <GunnarHj> Great!
[13:25] <brendand> hi,
[13:25] <brendand> i have a HP Elitebook 6930p
[13:26] <brendand> with a Radeon HD 3400 Series graphics card
[13:26] <brendand> it is a complete disaster with natty
[13:26] <brendand> there are so many problems i can't even isolate one to raise a bug
[13:26] <dpm> pitti, ah, and another thing. While you are looking at the FF xpis to appear in the language packs, do you think you could look at that issue I was mentioning re: the FF translations having disappeared from the maverick+lucid langpack PPAs?. I just want to make sure it's in your radar, as I didn't report it as a bug or anything.
[13:27] <brendand> i'm currently using classic desktop (no effects)
[13:27] <brendand> which is just about stable
[13:27] <pitti> dpm: would you mind reporting it as a bug against langpack-o-matic? I'm working on something else ATM, and still need to wait for the new firefox XPIs to get relaseed anyway
[13:28] <brendand> does anyone else have any experience with this card?
[13:32] <cjwatson> apachelogger: if you use pipeline_want_in (p, -1), then you can call pipeline_get_infile (p) after the pipeline is started and write to that.  Is that what you need?
[13:33] <brendand> it's not really support. i'm wondering have ATI cards ever been tested
[13:38] <dpm> pitti, sure, bug 731298
[13:46] <jhunt> cjwatson: thx for merging https://code.launchpad.net/~jamesodhunt/ubuntu/natty/vim/add-upstart-syntax, however we've got a FTBFS: "internal compiler error" (i386).
[13:52] <Daviey> jhunt, Is this part of a master plan to wean people off i686?
[13:53] <jhunt> :)
[13:56] <apachelogger> cjwatson: sounds like it, I will give it a try later, thank you :)
[13:56] <cjwatson> jhunt: hmm, that would be a doko question
[13:57] <smoser> cjwatson, i'd like your opinion on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/731307
[14:00] <cjwatson> smoser: sorry, later, am still patch piloting
[14:01] <cjwatson> drat, forgot to add myself to the topic, oh well too late
[14:07] <SpamapS> slangasek: ping, when you are around, could you confirm bug #726348 and review the fix .. I filed it based on your comments and I'd prefer not to confirm my own bug report. :)
[14:07] <jhunt> doko_: FYI, I've raised bug 731327 on the gcc internal compiler error issue just mentioned.
[14:09] <cjwatson> SpamapS: FYI, holding off on your upstart branch because jhunt has a big merge in progress
[14:09] <doko_> jhunt: known, preparing a fix
[14:10] <jhunt> doko_: thanks!
[14:15] <SpamapS> cjwatson: ah the 1.0 commeth? ;)
[14:15] <cjwatson> SpamapS: 0.9.1
[14:19] <tjaalton> is there a way to keep packages in main other than keeping deps on them?
[14:20] <cjwatson> tjaalton: seed them
[14:21] <tjaalton> cjwatson: ok. just wondering about dropping some xorg drivers to recommends like they are in debian, and whether it's worth it or not
[14:21] <tjaalton> probably not at this point of release
[14:25] <cjwatson> tjaalton: Recommends keeps things in main too
[14:28] <cjwatson> smoser: commented
[14:28] <tjaalton> cjwatson: ah ok, well I'll postpone it anyway and we'll revisit it for OO
[14:29] <smoser> cjwatson, the issue is that a major use-case is for apt-get upgrade to be run un-attended on boot of the image (or at least at some point)
[14:29] <smoser> so a prompt will completely block that
[14:31] <cjwatson> smoser: I know, but I don't know how to fix your problem ...
[14:32] <cjwatson> (without making the already horrible configuration file handling even worse)
[14:33] <cjwatson> smoser: I suppose you could try to figure out why GRUB_TERMINAL=console is needed
[14:37] <smoser> but what about GRUB_HIDDEN_TIMEOUT_QUIET ? and isn't this problem larger than me? doesnt it affect anyone who changes that file ?
[14:39] <cjwatson> smoser: I commented in the bug about that part
[14:40] <cjwatson> smoser: by design, if you change a configuration file and it is also changed in the package, you get prompted
[14:40] <cjwatson> smoser: I'm not concerned about a larger problem heree
[14:40] <cjwatson> *here
[14:49] <psusi> cjwatson: what's a DEP-3 patch header?
[14:50] <Ampelbein> psusi: http://dep.debian.net/deps/dep3/
[14:51] <psusi> nevermind, just found the answer ;)
[14:52] <cjwatson> psusi: I even gave you that link in the review :-/
[14:52] <cjwatson> (maybe only in one of them ...)
[14:52] <cjwatson> I wrote the dmraid review first, maybe read that first
[14:53] <psusi> cjwatson: also, about the mutual Breaks: I was thinking... the change is actually only incompatible with the previous natty release where we added the 'p' all the time.  Since the 'p' is now only added if the previous character was a digit, then it is compatable with oder versions
[14:54] <psusi> cjwatson: so should I only breaks that one version, or not bother since it was only during development cycle?
[14:57] <cjwatson> psusi: personally I'd just add the Breaks anyway if it was me
[14:57] <cjwatson> in this case it's not going to hurt to be overly strict, and it saves having to think about more interoperability cases
[14:59] <psusi> true
[15:00] <psusi> hrm.. I wonder then, if I should also add a Breaks: for old versions of gparted to parted?
[15:01] <doko_> bdrung: lintian: Missing build dependencies: perl (>= 5.12)
[15:03] <bdrung> doko_: i am asking myself why i didn't stumbled over it
[15:03] <bdrung> doko_: what can i do to solve it?
[15:04] <doko_> please don't sync perl
[15:05] <cjwatson> psusi: I don't know
[15:08] <YokoZar> Would merging in experimental gnome-games from Debian be appropriate?
[15:08] <YokoZar> It was released in October
[15:08] <pitti> YokoZar: you should coordinate with robert_ancell aobut that
[15:09] <YokoZar> pitti: gnome-games maintainer?  Debian dev?
[15:09] <pitti> YokoZar: gnome-games upstream and Ubuntu maintainer
[15:10] <YokoZar> pitti: Ahh ok.  Long story short I was updating the branding package and I noticed that the background for solitaire disappeared entirely in Maverick (and is still gone in Natty)
[15:12] <cjwatson> bdrung,doko_: the build-dependency is perl (>= 5.12) | libtest-simple-perl (>= 0.93), and libtest-simple-perl 0.96-1 is in natty
[15:12] <cjwatson> doko_: get a better build-dependency resolver? :)
[15:16] <doko_> cjwatson: tell it launchpad ;p
[15:17] <cjwatson> doko_: I'm surprised that's a problem in Launchpad; I distinctly remember working with lamont way back in 2004 or so to teach sbuild to fall back to second and subsequent alternatives in build-dependencies
[15:18] <doko_> cjwatson: https://edge.launchpad.net/ubuntu/+source/lintian/2.5.0~rc1ubuntu1/+buildjob/2283540
[15:18] <cjwatson> yes, I see it
[15:18] <doko_> ahh, ok
[15:18] <cjwatson> perhaps it can't cope with that when the first alternative is merely insufficient-version rather than missing
[15:19] <cjwatson> well, simple fix, just drop the first half of that alternative for the time being
[15:29] <micahg> cjwatson: I have a bug open for that dependency issue
[15:31] <micahg> bug 594916
[15:47] <ari-tczew> doko_: did you fresh rebuild already?
[15:47] <ari-tczew> with reverted binutils-gold
[15:48] <doko_> ari-tczew: I don't know what you are talking about
[15:49] <ari-tczew> doko_: https://lists.ubuntu.com/archives/ubuntu-devel/2011-March/032634.html
[15:50] <doko_> ari-tczew: this is nothing to do with binutils-gold. and no, no rebuild started
[15:52] <ari-tczew> doko_: what's the difference between linking in binutils-gold and --no-add-needed?
[15:54] <ari-tczew> janimo: could you forward your patch for axis2c to Debian in order to keep in sync with Debian?
[15:58] <doko_> gold is a different linker, which happens to default to --no-add-needed
[15:58] <psusi> cjwatson: if other quilt patches apply but with some offset, should I refresh them, or leave them be?
[15:59] <ari-tczew> doko_: if I'm fixing ftbfs with 'undefined reference to...' how should do I describe it? ftbfs with binutils-gold or rather --no-add-needed?
[16:00] <doko_> it depends on the error message. it can be caused by --as-needed too
[16:00] <cjwatson> psusi: I would refresh them
[16:01] <barry> doko_: bug 719206 can be fixed by uploading my scons 2.0.1-1 merge and doing a no-change rebuild upload for csound.  merge proposal: https://code.launchpad.net/~barry/ubuntu/natty/scons/scons-2.0.1/+merge/52571
[16:01] <doko_> see http://wiki.debian.org/ToolChain/DSOLinking
[16:01] <ari-tczew> doko_: should do we still fix these ftbfs if you've reverted it?
[16:02] <barry> doko_: i can put some source packages on chinstrap if you prefer
[16:02] <barry> doko_: would you do the uploads for me?
[16:02] <doko_> yes, and I didn't revert the ld --no-add-needed default
[16:02] <doko_> barry: on chinstrap?
[16:02] <barry> doko_: i haven't yet, but i can
[16:03] <barry> doko_: % scp scons_2.0.1-1* chinstrap:
[16:03] <barry> scons_2.0.1-1.debian.tar.gz                   100% 6897     6.7KB/s   00:00
[16:03] <barry> scons_2.0.1-1.dsc                             100% 1832     1.8KB/s   00:00
[16:03] <barry> scons_2.0.1-1_source.changes                  100% 2216     2.2KB/s   00:00
[16:03] <barry> scons_2.0.1-1_source.ppa.upload               100%  307     0.3KB/s   00:00
[16:04] <janimo> ari-tczew, upstream axis2c seems to have fixed the bug in their trunk
[16:04] <micahg> barry: why isn't scons a ync?
[16:04] <micahg> *sync
[16:04] <barry> micahg: yeah
[16:04] <janimo> ari-tczew, feel free to ping debian though - are they not following merge-o-matic or some similar output?
[16:05] <micahg> barry: so, you should just use requestsync for it and it'll be brought into natty later this week
[16:05] <ari-tczew> janimo: it's rare case when maintainer takes a look on Ubuntu delta. btw. merge-o-matic is broken.
[16:05] <micahg> barry: you probably need an FFe as well
[16:05] <barry> micahg: i won't be around to verify it later this week though since i'm at pycon for 10 days starting tomorrow
[16:06] <barry> an FFe for a micro release update?
[16:06] <janimo> ari-tczew, that is sad. As it would help a lot in avoiding manual work to subscrobe to the LP packages they maintain in Debian.
[16:06] <micahg> barry: yes, unless it has an exception since it's in main
[16:07] <ari-tczew> janimo: I don't understand what do you mean, sorry.
[16:07] <barry> micahg: i'll get the ball rolling but someone else is going to have to follow through with both scons and csound bugs.  i'll assign them to doko_ after i do what i can
[16:07] <doko_> barry: so I can sync it?
[16:08] <janimo> ari-tczew, if a debian maintainer subscribed to the LP notifications concerning their packages they could fish out interesting thigs themseleves
[16:08] <janimo> and not requiring ubuntu devs to explicitly forward everything
[16:08] <janimo> makes sense especially for a lot of universe stuff which we do not usually patch
[16:08] <ari-tczew> janimo: feel free to suggest him it :)
[16:08] <barry> doko_: sync'ing scons to debian testing version, then no-change rebuild of csound after that lands will fix the csound bug
[16:09] <cjwatson> ari-tczew: merge-o-matic will be fixed soon, I have it nearly fixed now
[16:09] <ari-tczew> cjwatson: ok nice :) would be nice if you could inform it via lists - I've opened a thread for this case.
[16:09] <cjwatson> yeah, I'll mention it on -devel
[16:14] <cjwatson> (the MoM downtime was a combination of a dpkg bug-fix that needed to be backported, and then casey running out of disk space again - both fixed now)
[16:16] <YokoZar> mvo: what does X-AppInstall-Popcon=#### do in a .desktop file in app-install-data?
[16:16] <YokoZar> (these days)
[16:16] <YokoZar> If it is what I think it is, is that data being autoregenerated still?
[16:18] <ivoks> i have serious issue to report; latest dist-upgrade is telling me that it will remove 'vim'; that's a critical bug :)
[16:19] <cjwatson> known build failure
[16:19] <cjwatson> probably resulted in bits of vim being out of sync across architectures
[16:19] <cjwatson> 14:09 <doko_> jhunt: known, preparing a fix
[16:19] <ivoks> but it was very funny :)
[16:20] <cjwatson> bug 731327
[16:21] <cjwatson> (bug status alone isn't very clear - from the bug history, I believe that's now worked around for natty)
[16:33] <lamont> cjwatson: I'm pretty sure that the sbuild hackery didn't take versioned build-deps into account... since perl exists, it gets picked, even though it's verison is insufficient
[16:34] <lamont> at least iirc
[16:39] <terlmann> Let's say you had a package that didn't have a newer version available because of  developer circumstances. It is needed by the user because of their usage circumstances. It relies on core libraries that the user wanted to upgrade to newer versions, like gtklib from 2 to 2.9/3.
[16:40] <terlmann> Could you add logic to your apt chain of tools to automatically detect such "dead-end" packages and sandbox them with the specific dependencies that would differ from the new packageset in a /opt chroot, until such time as they can be upgraded?
[16:43] <NCommander> doko_: directhex: ping, do we have a VCS for mono's packaging on ARM? I found the Debian git repo, but I can't find something for Ubuntu
[16:43] <doko_> NCommander: I don't have one
[16:44] <directhex> NCommander, nothing ubuntu specific
[16:44] <NCommander> doko_: so you just uploaded the package directly? (I have patches to mono to help fix it with SMP+Thumb2)
[16:44] <directhex> NCommander, generally, ubuntu things can go into git branches, although you won't have write access to that repo
[16:44] <pitti> dpm: ah, the new natty langpack build just finished
[16:45] <NCommander> directhex: I don't even see an ubuntu branch for that git repo
[16:45] <Laney> could the patch not go into Debian?
[16:45] <pitti> chrisccoulson: ^ FYI; so I'm ready to build new packs whenever we have a decision what to do with the xpis
[16:45] <Laney> . o O ( or upstream )
[16:45] <NCommander> Laney: mono on Debian moving to 2.10 which has this properly fixed in git
[16:46] <directhex> NCommander, we don't have any ubuntu specific things that we're tracking in debian right now.
[16:46] <Laney> oh, they're upstream already — great
[16:46] <dpm> pitti, ah, what does it look like? Does it come with FF translation goodness? :-)
[16:46] <NCommander> the backport to 2.6 is complicated since it only should be applied to ARMv7
[16:46] <NCommander> 2.10 has a nice mechanism to handle that
[16:46] <NCommander> 2.6, not so much
[16:46] <pitti> dpm: no, I didn't enable po2xpi
[16:46] <pitti> it's still broken (and it wasn't used before either)
[16:46] <NCommander> Laney: the SMP partch should be acceptable for Debian but I don't ahve any hardware to properly test it
[16:46] <Laney> I'd use the UDD branches, or you can push mono.git to github
[16:46] <Laney> and create a branch there
[16:47] <NCommander> directhex: we have a ubuntu1 version on Ubuntu
[16:47] <chrisccoulson> pitti - we should use the new rc1 xpi's from ftp://ftp.mozilla.org/pub/firefox/nightly/4.0rc1-candidates/build1/linux-i686/xpi/
[16:47] <chrisccoulson> (i shall be uploading RC1 later this week)
[16:47] <pitti> chrisccoulson: I thought they'd have a too tight version?
[16:47] <pitti> chrisccoulson: ah, you mean they'll actually work until the final, and we only need to update them then
[16:47] <chrisccoulson> pitti - yeah they do. for now, we'll either need to mangle the maxVersion in them, or we could ship them as they are and update them later
[16:48] <Laney> NCommander: from the mono group POV it was syncable. A Ubuntu developer then uploaded it and made this not so any more. Thus there is no Ubuntu branch from our side.
[16:48] <directhex> NCommander, perhaps, but we didn't put it there
[16:48] <chrisccoulson> either way will work fine for now
[16:48] <pitti> chrisccoulson: ack; so, I'll update my po2xpi branch with them now, can you merge afterwards?
[16:48] <chrisccoulson> pitti - sure, no problem
[16:48] <directhex> NCommander, to an extent, it doesn't matter - we're working on 2.10 in debian, so 2.6-specifics are a bit meh
[16:49] <NCommander> directhex: so the basic answer is, just upload with the backports from upstream
[16:49] <psusi> what's the difference between Conflicts: and Breaks:?
[16:49] <Laney> and if you want, make a branch and get us to pull it
[16:50] <directhex> NCommander, if the changes are upstream in 2.10, then yeah
[16:50] <NCommander> Laney: if your on 2.10.1, you should get it for free
[16:50] <Laney> yep
[16:50] <NCommander> cool
[16:50] <NCommander> That makes my life MUCH simplier
[16:50] <directhex> Laney, won't there be automatic bze branches we can cherry pick from?
[16:51] <Laney> dunno
[16:51] <pitti> seb128: calendar> sometimes I do (evo sometimes seems to just forget about them), but right now they all work
[16:51] <seb128> pitti, the indicator is still empty?
[16:51] <Laney> NCommander: Yeah, just to track the Ubuntu stuff on alioth. We do it for other packages, but whatever it's not so important here
[16:51] <pitti> seb128: yes, clicking on it opens an 1-pixel empty menu
[16:51] <seb128> pitti, usually it means it's crashing, https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/724856 most likely
[16:51] <Laney> psusi: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
[16:51] <pitti> seb128: checking
[16:51] <seb128> pitti, try turning off you gcalendar in evo
[16:51] <seb128> just to see
[16:51] <Laney> Breaks means the broken package must be deconfigured, Conflicts means it must not be on the system at all
[16:52] <pitti> seb128: yes, no indicator-time-something
[16:52] <seb128> pitti, is indicator-datetime installed?
[16:52] <pitti> seb128: confirmed; running /usr/lib/indicator-datetime/indicator-datetime-service crashes immediately
[16:52] <pitti> seb128: thansk!
[16:52] <seb128> pitti, is that the same crash?
[16:53] <dpm> pitti, so what is this new langpack build going to be? A -base refresh without the xpis?
[16:53] <pitti> dpm: no, -base with xpis
[16:53] <pitti> dpm: but the upstream ones (as we used to do in all releases so far)
[16:53] <pitti> seb128: need some debug symbols, hang on
[16:53]  * psusi goes with Conflicts
[16:54] <Laney> breaks is usually sufficient
[16:54] <dpm> pitti, yeah, that was my question earlier, I should have rephrased it a bit clearer. So regardless of whether they are upstream ones or LP ones, we will have a localized Firefox after this langpack update I understand?
[16:55] <pitti> dpm: correct
[16:55] <chrisccoulson> dpm - we will do once we get ff4.0rc1 in the archive
[16:55] <psusi> I don't see what difference it really makes whether the package is just unconfigured or not... if the library is installed, then it's installed
[16:55] <pitti> seb128: ah no, your's is an FPE, mine is a SEGV
[16:55] <chrisccoulson> (the new xpi's won't work with b12, but there's no point in uploading b12 xpi's now)
[16:55] <dpm> chrisccoulson, ah, ok, understood
[16:55] <pitti> seb128: in update_appointment_menu_items(); looking for an existing bug, or filing one
[16:56] <doko_> janimo: do you want to join robbiew's server team, now starting to fix server bugs? ;P
[16:56] <chrisccoulson> pitti - i think i might get the same crash as you then ;)
[16:56] <chrisccoulson> (although, i didn't debug it yet)
[16:56] <chrisccoulson> but i get a SEGV on start
[16:56] <seb128> pitti, likely bug #729444
[16:56] <seb128> bug #729175
[16:56] <seb128> ^ that's a valgrind log I did some days ago which is likely the same issue
[16:56] <pitti> seb128: correct
[16:56] <janimo> doko_, nah, it just happens I get bugged by some packages :)
[16:57] <dpm> pitti, ah, cool, thanks. We did use po2xpi for some languages, though. For example until ast was accepted upstream it was built with po2xpi.
[16:57] <seb128> chrisccoulson, if you want to have a go to it please do
[16:57] <NCommander> directhex: For the sake of mantience, I'll put these on the UDD branch for mono.
[16:57] <seb128> chrisccoulson, klattimer is off tonight until the end of the week
[16:57] <janimo> since it was on server list it appeared more than once in the ftbfs report, so I think that is why I went for axis2
[16:57] <NCommander> as I don't feel like adding a patch system to the mono package
[16:57] <chrisccoulson> seb128 - ok, will take a look once i've figured out the other menu issues
[16:57] <seb128> chrisccoulson, thanks
[16:57] <pitti> dpm: right; we only have fi and oc on the whitelist, though
[16:58] <janimo> NCommander, narrowed down the mono issue? Something besides memory barriers?
[16:58] <dpm> pitti, ack. yeah, just pointing out that po2xpi was not entirely useless :)
[16:59] <pitti> dpm: no, to the contrary; but it is broken right now, so I'm afraid we can't use it just now
[16:59] <NCommander> janimo: more I just got around to finally getting everything to the point I'm ready to cook a test package
[16:59] <janimo> NCommander, based on 2.6 ?
[16:59] <dpm> pitti, yeah, sure, I understand. I just wanted to point that out
[17:00] <dpm> pitti, another question: I've been asked this on gnome #i18n. Could you tell me if it's correct? -> http://paste.ubuntu.com/577519/
[17:00] <NCommander> janimo: yeah
[17:02] <pitti> dpm: that's correct, it's rather easy to include them
[17:03] <dpm> pitti, I guess the easiest thing is to file a bug requesting a package update? Or what would be your recommendation?
[17:03] <rollo>  hi pitti
[17:04] <pitti> dpm: yes, with a pointer to the upstream bugs
[17:04] <dpm> pitti, ok, thanks a lot, I'll go ahead and do that, then
[17:04] <pitti> dpm: I'd appreciate if you (or the submitter) could subscribe me, for faster processing
[17:04] <OraLinda> Hi all
[17:04] <pitti> hey rollo
[17:04] <dpm> pitti, ok, will do
[17:04] <OraLinda> How are you guys doing ?
[17:05] <OraLinda> Tell me, where can I get the source for the gorgeous libvisual plugin infinite I can see running in Totem visualization?
[17:05] <NCommander> OraLinda: apt-get source totem-plugins
[17:06] <NCommander> OraLinda: run that on command line. That should put you on the right track, although I'm not sure if that plugin is in totem-plugins or another package
[17:07] <OraLinda> Thanks. Let me have check.
[17:11] <cnd> stgraber, cody-somerville, bdrung: I just tried to upload utouch-geis, but was rejected
[17:12] <cnd> does some bit need to be twiddled somewhere?
[17:12] <pitti> cnd: upload ACLs need to be set in Launchpad, yes; was that recently approved by DMB?
[17:13] <cnd> pitti, yes at the last dmb meeting
[17:13] <cnd> a utouch package set was created
[17:13]  * pitti checks
[17:13] <pitti> nope, no ACL set for utouch-geis
[17:14] <cnd> pitti, this was the package set approved: https://wiki.ubuntu.com/Multitouch/uTouchPackageSetApplication
[17:15] <pitti> cnd: there is no "utouch" package set right now; could it be spelled differently?
[17:15] <pitti> or perhaps it wasn't created yet
[17:15] <pitti> cnd: is your LP ID "cnd"?
[17:15] <pitti> it's not
[17:15] <cnd> pitti, chasedouglas
[17:16] <pitti> cnd: you currently can uplaod linux-firmware, linux-firmware-nonfree, and trace-cmd
[17:16] <cnd> pitti, that's correct
[17:17] <pitti> cjwatson: can/should I run "./edit_acl.py -P utouch -S natty add"? or does it require special magic on your side?
[17:18] <cjwatson> create rather than add, I think
[17:18] <cjwatson> and then add packages to it
[17:18] <pitti> cjwatson: so it's (1) create package set, (2) add packages and people with "add"?
[17:18] <cjwatson> yeah
[17:19] <cjwatson> the owner should, I assume, be developer-membership-board
[17:19] <tkamppeter> pitti, I have a question. There is bug 731420
[17:19] <tkamppeter> pitti, have you any idea what this "low mode" is?
[17:20] <pitti> tkamppeter: I assume it's the 640x480 VESA mode that X.org falls back to if the real driver (such as nvidia) doesn't work
[17:23] <tkamppeter> pitti, for me it looks more like a problem of X and not of the printer.
[17:24] <pitti> cnd: ok, I created the package set with the minimal contents (you as member, and utouch-geis); try uploading again?
[17:24] <cnd> pitti, will do, thanks!
[17:25] <cnd> pitti, it was accepted this time :)
[17:25] <pitti> cjwatson: does http://paste.ubuntu.com/577541/ look reasonable to you?
[17:29] <cjwatson> pitti: yep
[17:41] <doko> bdrung: now a real lintian build result ... ftbfs ;-P
[17:42] <kees> pitti: lucid linux-ec2 2.6.32-314.27> noted, thanks
[17:42] <bdrung> ups
[17:46] <mvo> YokoZar: its still auto-generated at package build time
[17:47] <abhinav-> barry, I have pushed the changes on the tomcat6 branch. and hope you have a great time at Pycon :-)
[17:47] <mvo> YokoZar: but its (much) less interessting nowdays
[17:47] <YokoZar> mvo: even for the static entries?
[17:47] <YokoZar> eg in menu-data-additional
[17:47] <mvo> YokoZar: it should be auto-generated for that too
[17:47] <mvo> unless there is a bug of course?
[17:48] <YokoZar> nah, I was just wondering since I'm changing package names in those files and using the wrong data, but if it gets replaced as soon as it builds who cares
[17:54] <cjwatson> barry: sigh, now this wubi bug has got to the point where I'm emulating x86 code by hand :-/
[17:54] <cjwatson> (assembly)
[17:55] <RoAkSoAx> \/win 2
[17:56] <bdrung> tumbleweed: let's wait until u-d-t migrated to testing and then upload 0.120
[17:59] <lool> pitti: Oy; gdb builds started failing with unrelated changes, it seems to be in the documentation de-duper logic; e.g. http://launchpadlibrarian.net/65878156/buildlog_ubuntu-natty-amd64.gdb_7.2-1ubuntu9_FAILEDTOBUILD.txt.gz
[18:00] <lool> pitti: I copied the previous version of the source which built fine in natty some time ago into my PPA, and it failed to build too
[18:00] <lool> This is with cdbs 0.4.90ubuntu6
[18:00] <lool> pitti: is this something you saw on other packages?
[18:06] <lool> Ok, I think it's gdb's symlink in parallel builds which confuses cdbs
[18:10] <pitti> lool: (sorry, busy; will have a look tomorrow, have a tab open for it now)
[18:10] <pitti> lool: I haven't seen it on other packages so far
[18:10] <lool> pitti: gdb is creating some gdb-foo -> gdb symlinks below usr/share/doc before gdb dir exists (built in parallel too)
[18:11] <lool> pitti: I'm going to test a change in cdbs to skip creation of symlinks below usr/share/doc/$(cdbs_curpkg) if that's a symlink
[18:11] <pitti> lool: ah; dir symlinks are really evil, packages shouldn't do that (due to dpkg's special handling of symlinks)
[18:11] <pitti> lool: but that's something that should be testable
[18:11] <pitti> lool: indeed, if any dir along the path is a symlink, it should skip its own thing
[18:11] <pitti> lool: merci
[18:18] <terlmann> Hey people.
[18:18] <highvoltage> hey terlmann
[18:18] <terlmann> You know google's new l33t compression tool that they're using to diff assembly for binaries?
[18:19] <terlmann> What if we precompiled all our mono binaries from bytecode to each of the possible ~40 architectures and just kept one basic binary+diffs, to save memory space ?
[18:19] <terlmann> Then they wouldn't need to be built jit.
[18:20] <YokoZar> uhhh
[19:39] <till_> i'm building a package and it relies on one of my other packages. how do i tell launchpad that this is a valid build dependency?
[19:40] <SpamapS> slangasek: thanks for the triage ;)
[19:41] <SpamapS> till_: you upload the other package into the PPA
[19:41] <till_> SpamapS: i did that, of course. but when i upload the other package, it still complains that it doesn't know about the other package
[19:42] <SpamapS> ETOOMUCHINDIRECTION
[19:42] <SpamapS> till_: package A build-depends on package B, yes?
[19:42] <till_> yeah
[19:42] <till_> i'm doublechecking the ppa :x
[19:42] <SpamapS> till_: Then B must precede A into the PPA.
[19:42] <till_> ok, good to know
[19:43] <SpamapS> till_: if B also build-depends on A, then you have to play a trick and upload one before the other w/o the build-depend in the control file, and which embeds whatever it needs.
[19:43] <till_> yeah, makes sense
[19:44] <till_> if it works if both are in the same ppa, let me doublecheck that the one the other depends on was build first.
[19:52] <slangasek> SpamapS: n/p :)
[20:28] <broder> jhunt: you wanted that merge proposal to be against lp:ubuntu/gdm, not lp:gdm
[20:29] <davidm> OK coffee time
[20:31] <tumbleweed> bdrung: sounds good to me
[20:35] <jhunt> broder: thx - can you be manifest? I cannot push it to lp:~jamesodhunt/ubuntu/gdm/blah ("No such distribution series")
[20:36] <broder> lp:~jamesodhunt/ubuntu/gdm/natty/blah :)
[20:37] <jhunt> broder: so there is no way to push to the "upstream ubuntu" branch"? (presumably because that points to the latest release (natty)?)
[20:38] <jhunt> broder: this is confusing because the branch I branched from was: lp:~ubuntu-desktop/gdm/ubuntu.
[20:38] <broder> jhunt: lp:ubuntu/foo is an alias for lp:~ubuntu-branches/ubuntu/natty/gdm/natty (where the last natty is an "arbitrary" identifier a la blah)
[20:38] <jhunt> not very symmetrical, or am I missing something?
[20:39] <broder> in user branches (i.e. with a ~), the second component is the project. if the project is ubuntu, the third component must be a distribution series. the last component is an arbitrary tag you give the branch
[20:39] <broder> so lp:~ubuntu-desktop/gdm/ubuntu is a branch off of the gdm project, and ubuntu is their arbitrary tag
[20:41] <broder> jhunt: on the actual patch itself, is this going to cause any of the pain around mixing and and or in a start on block? and do we ever have to worry about switching from runlevel S but not having dbus/filesystem/etc?
[20:42] <jhunt> broder: take 15: This works (not it is not the same as your example above): bzr push lp:~jamesodhunt/ubuntu/natty/gdm/ubuntu-desktop-single-user-mode-fix
[20:43] <broder> jhunt: where the branch goes is less important than proposing a merge into the same branch you started from
[20:45] <jhunt> broder: thanks very much for your help - your explanation is clearer than any other I've seen!
[20:55] <jhunt> broder: please tell me I've pushed the right branch to the right place now or I may have to open a bottle of something strong... :)
[20:58] <broder> so the diff is still massive. i think i may have given you bad advice when i said to merge into lp:ubuntu/gdm. if you branched from lp:~ubuntu-desktop/gdm/ubuntu, you should merge back into that
[20:59] <broder> if you look at the diff on https://code.launchpad.net/~jamesodhunt/ubuntu/natty/gdm/single-user-mode-fix/+merge/52610, it's, like, the entirety of the repository, which is something of a red flag
[20:59] <bdrung> tumbleweed: "pull-debian-source lintian experimental" fails
[21:01] <tumbleweed> bdrung: aah, that's easy :)
[21:12] <bryceh_> @pilot out
[21:12] <bryceh_> bdmurray, still piloting?  ;-)
[21:13] <ari-tczew> I guess bdmurray has forgot to do out from piloting. May topic needs fixing manually?
[21:15] <bdmurray> @pilot out
[21:33] <tumbleweed> bdrung: that commit should have fixed it
[21:35] <bdrung> tumbleweed: maybe put is_suite into DistroInfo?
[21:36] <bdrung> tumbleweed: confirming that your commit fixes my issue
[21:37] <tumbleweed> bdrung: yeah, that probably is a good idea. However it's by no means perfect (there isn't an experimental-p-u :)
[21:38] <bdrung> tumbleweed: yes, but experimental-p-u isn't a good name for a version ;)
[21:38] <tumbleweed> well, there isn't an unstable on either
[21:39] <tumbleweed> but yeah, experimental on its own makes moving it there complex
[22:20] <till_> SpamapS: thanks again, the correct order worked!
[22:32] <SpamapS> till_: w00t