[00:09] <lamont> cjwatson: you have tarballs in place
[00:10] <lamont> the only change from what they were an hour ago is that debconf-english is installed (removing debconf-i18n); armel has apt on hold
[00:11] <lamont> cjwatson: and once you've fixed the world (which needs to include apt/armel being current and published...), you know how to get the untweaked tarballs back
[00:11] <lamont> anything more before I run off?
[00:11] <cjwatson> I think that's the lot
[00:11] <cjwatson> enjoy the party
[00:12]  * cjwatson does the rescore-auto-manual dance
[00:12] <cjwatson> (i386 first, to see if it works)
[00:12] <lamont> I'll hang out for a few more
[00:13] <doko> do you just build the three, or all seven rebuilds?
[00:13] <cjwatson> doko: what are the others
[00:13] <cjwatson> ?
[00:14] <doko> libhtml-parser-perl libtemplate-perl
[00:14] <doko> libalgorithm-diff-xs-perl libxml-parser-perl
[00:15] <cjwatson>  Package: libtext-iconv-perl Depends: libc6 (>= 2.1.3), perl-base (>= 5.12.3-6ubuntu3), perlapi-5.12.3
[00:15] <cjwatson> looks good
[00:15] <cjwatson> doko: I'm happy to give them all a try
[00:16] <doko> thanks
[00:16] <lamont> cjwatson: last call.
[00:16] <cjwatson> lamont: this is looking good, go
[00:16] <cjwatson> thanks a lot
[00:16] <lamont> gone
[00:17] <doko> hmm, don't see perl building on armel
[00:19] <cjwatson> damn, I forgot that, sorry
[00:20] <cjwatson> argh, I guess that means it requires another rebuild upload
[00:20] <doko> ok, will prepare these
[00:21] <cjwatson> just  libtext-iconv-perl libtext-charwidth-perl libtemplate-perl liblocale-gettext-perl libhtml-parser-perl
[00:21] <cjwatson> the others haven't started building
[00:21] <cjwatson> sorry about that
[00:22] <doko> cjwatson: hmm, no, every upload has a b-d perl (>= 5.12)
[00:22] <cjwatson> oh, good
[00:22] <cjwatson> as soon as one fails I'll start perl building then
[00:23] <doko> genip is idle
[00:23] <cjwatson> so it is
[00:24] <doko> and libtext-iconv-perl in dep-wait
[00:24] <cjwatson> genip building perl now
[00:25] <doko> not starting on the perl component mismatches now ...
[00:38] <cjwatson> doko: looks like libxml-parser-perl needs libhtml-parser-perl to be published; I think it would be mostly OK to go ahead without it though?
[00:39] <cjwatson> hm, intltool would still be uninstallable, which would break cdbs
[00:39] <cjwatson> so I think I'll have to revise my estimate for OEM back a bit
[01:01] <cjwatson> perl/armel apparently takes on the order of four hours normally, so I'm not going to wait up for it
[01:49] <infinity> lamont: FWIW, my buildd chroots always used to use debconf-english and purge libirritating-unnecessary-perl* to avoid a lot of these problems.  I assume somewhere along the way, they got rebuilt instead of just continuously upgraded?
[01:50] <infinity> lamont: (There's no real argument for debconf-i18n on chroot systems that only speak LANG=C anyway)
[01:51] <infinity> cjwatson: ^^ see above to lamont, there's no real reason to put the debconf-i18n chroots back, IMO.  Mine never had it installed. :P
[01:53] <cjwatson> hm, well, while I'm not entirely sure I disagree, I think I'll put them back and let lamont make that decision in his scripting
[01:54] <cjwatson> (since I'd agreed a plan with lamont before he went off to party)
[01:54] <cjwatson> you're probably right though, debconf-english is there for a reason
[01:54] <cjwatson> lamont has a scorched-earth-rebuild-chroot script which he applies liberally - definitely no continuous upgrading going on
[01:56] <cjwatson> all seven of those packages published on !armel - testing installability up to cdbs, and then I'll restore normality on all-but-armel
[02:05] <cr3> packaging question: when building a python package, lintian is returning python-script-but-no-python-dep whereas my package debian/control depends on ${python:Depends} and debian/rules calls dh_pycentral on binary-indep. what might be missing?
[02:06] <cr3> err, make that a "debian package containing python stuff", a "python package" could mean something else :/
[02:09] <cjwatson> builders back on auto, except for armel
[02:26]  * psusi slays another parted bug
[02:29] <Pretto> who knows the icon name used by unity-launcher when the application icon is not found?
[02:30] <Pretto> that question mark icon
[02:31] <Pretto> found, twf :)
[02:36] <j1mc> hey all, i submitted some blueprints for discussion at UDS a few days ago. i don't see them in the list of sessions for uds, though.
[02:36] <j1mc> should i ping someone about this?
[02:38] <stgraber> j1mc: if they haven't been approved for uds you'll need to ping the track lead
[02:38] <j1mc> stgraber: thanks... is there a list of track leads somewhere?
[02:39] <stgraber> j1mc: what's the specs ? the two I could find from your LP account are both approved (on LP's side)
[02:40] <cr3> turns out that moving dh_pycentral nearer to dh_installdeb fixed the ${python:Depends} problem. ugh
[02:40] <j1mc> stgraber: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-ubuntu-docs-strategy
[02:41] <j1mc> https://blueprints.launchpad.net/ubuntu/+spec/community-o-ubuntu-docs-goals-oneiric
[02:41] <stgraber> first one is: 2011-05-11 17:05..18:00 => kazincy
[02:42] <stgraber> second one is: 2011-05-09 12:00..13:00 => jozsef
[02:42] <stgraber> at least that's what I see in the DB, not sure if it's visible on summit.u.c
[02:42] <j1mc> there are so many sessions... maybe i missed them.
[02:43] <j1mc> i'll have a look
[02:44] <stgraber> yep, both are there. Too many rooms/specs :)
[02:45] <j1mc> stgraber: i would like to flip-flop them, if possible. would be better to discuss the strategy first, and then discuss the 11.10 goals.
[02:45] <j1mc> do you know where i could direct that request?
[02:46] <stgraber> j1mc: I can do it. I'll just have too see if I don't create conflicts doing that though
[02:48] <stgraber> j1mc: done. That created a conflict on Monday though, hopefully the scheduler will fix it next time it runs
[02:48] <j1mc> stgraber: ok - thanks. *fingers crossed*
[02:50] <j1mc> stgraber: thanks v. much for your help.
[02:51] <stgraber> np
[03:18] <lucidfox> What's the difference between libappindicator and libappindicator3?
[03:18] <lucidfox> GTK2 vs GTK3?
[03:19] <lucidfox> hmm, seems so, looking at the uploads
[03:26] <smoser> is there an etherpad installation that we're planning on using for uds ?
[03:26] <smoser> i'd like to start populating documents if possible.
[03:28] <stgraber> summit.u.c seems to be using pad.ubuntu.com now. Not sure if it's final though
[03:36] <ScottK> It looks like the schedule on summ
[03:36] <ScottK> ...it has links to the relevant document stubs.
[03:43] <bryceh> stgraber, smoser, there's a mention about it on planet.ubuntu.com
[03:44] <smoser> yeah, it looks official. i just hand't seen aything
[03:45] <smoser> that really rocks. summit has good integration too, providing links for the pads.
[03:46] <bryceh> smoser, yeah I poked at it a little myself and it seems really nicely hooked into things; I think people are going to really like it
[03:47] <stgraber> yup, I like it too. I just hope it's going to scale well and we won't find weird bugs like with gobby last time.
[03:47] <bryceh> although really to make people happy all it has to do is not delete everyone's documents
[03:47] <smoser> openstack summit used etherpad fairly well.
[03:47] <smoser> they only had 2 tracks really , and much less use of it generally than i'd expect for ubuntu
[03:47] <StevenK> bryceh: Or crash every ten hours ...
[03:48] <smoser> but, it did well for that.
[03:50] <keffie_jayx> hello all, I currently maintain an app called turpial, before in the systray we had an Icon, now in unity this is not so. I have read discussions. what is the policy. Can a twitter client be allowed to be on the system notification area?
[03:50] <keffie_jayx> if so, where can I have info on how to add this functionality to an app?
[03:56] <stgraber> keffie_jayx: the recommended way of "fixing" that is by using the appindicators API instead of "systray". https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting%20Guide%20for%20Applications
[03:57] <stgraber> keffie_jayx: there's indeed a whitelist in Unity to allow for exceptions but it's usually for proprietary apps that can't be tweaked to use the indicators
[03:57] <stgraber> (sorry, can't really tell you more, I'm not a desktop developer)
[03:58] <keffie_jayx> stgraber: shall read that and see if I can come up with the fix to send upstream
[03:58] <keffie_jayx> heck I do not even use unity, I am fixing i for heloing the team :)
[03:59] <ScottK> keffie_jayx: That or just tell people to use Kubuntu where such things work fine.
[04:00] <keffie_jayx> ScottK: ;)
[04:01] <keffie_jayx> ScottK: thing is turpial packaging and I am sort of stuck with it... :S
[04:01] <ScottK> keffie_jayx: I understand.  It's a difficult situation.
[05:30] <lamont> awesome.  gcc-4.6 finished building, now I just need it to publish
[05:31]  * lamont restores the apt-held, debconf-english arm chroot
[05:33] <ScottK> Poor time of the day to be needing that.
[05:33] <alkisg> Vlc in Lucid is only semi-translated to Greek (looks bad to have only half of the menus translatd), while in e.g. Natty it's almost fully translated to Greek.
[05:33] <alkisg> Is there any process to backport vlc/el.mo to Lucid? I tried maintaining a PPA version for schools here but I got tired of re-uploading after each vlc security update... :-/
[05:35] <pitti> Good morning
[05:35] <ScottK> alkisg: There is the normal backports repository, but it would still need someone worrying about updating the backport after security updates.
[05:35] <ScottK> pitti: Would improved translations in a Universe package be SRU worthy?
[05:36] <ScottK> Good morning, BTW.
[05:36] <pitti> ScottK: depends on how bad they are ATM, but as they are low risk I wouldn't object
[05:36] <pitti> i. e. "sound a little weird" might not worth it, but "totally confusing or broken" -> sure
[05:37] <micahg> good morning pitti, could you please apply an override for me, thunderbird-mozsymbols in natty-security to universe?
[05:37] <ScottK> alkisg: ^^^ I think that's your answer.  If you can prepare an SRU with the fixed translations for Lucid, then problem solved.
[05:37] <alkisg> Scott/pitti, thank you, I'll file an SRU for it. Currently half of its menus are in Greek and half in English, confusing users.
[05:38] <pitti> alkisg: sounds fine
[05:38] <alkisg> Thank you guys
[05:43] <pitti> micahg: done; I wonder how I ended up in main in the frist place..
[05:45] <micahg> pitti: non-private PPAs are all in main by default
[05:45]  * micahg still uses the mozilla-security PPA so we can get extended testing from users (hopefully)
[05:46] <lamont> dear publisher.  do that thing you do
[05:48] <siretart> maxb: oh, I wasn't aware that we don't do installer respins for non-LTS releases. but can't we get at least the netboot installers fixed?
[05:49] <ScottK> siretart: We don't normally.
[05:49] <ScottK> There can be exceptions though.
[05:52] <slangasek> ScottK: postfix uploaded to the SRU queue
[05:52] <ScottK> slangasek: Thanks.
[05:53] <ScottK> pitti: I'd appreciate it if you could give an accelerated review to slangasek's postfix SRU.  Broken MTAs aren't a happy thing.
[05:53] <pitti> understood, will do
[05:54] <ScottK> Thanks.
[05:55] <pitti> slangasek: I wonder why it changes the html files in the source -- are they autogenerated during clean or so?
[05:55] <pitti> (http://launchpadlibrarian.net/71105169/postfix_2.8.2-1ubuntu1_2.8.2-1ubuntu2.diff.gz)
[05:55] <slangasek> pitti: correct
[05:56] <slangasek> or at least, they're touched somewhere in a build->clean->build cycle
[05:56] <slangasek> er, clean->build->clean
[05:56]  * pitti hugs bzr bd for building in a separate tree
[05:56] <slangasek> that just hides bugs :)
[05:57] <pitti> most is whitespace changes, but it actually adds another option there
[05:57] <pitti> -\fBpostmap\fR [\fB-Nbfhimnoprsvw\fR] [\fB-c \fIconfig_dir\fR]
[05:57] <pitti> +\fBpostmap\fR [\fB-Nbfhimnoprsuvw\fR] [\fB-c \fIconfig_dir\fR]
[05:57] <slangasek> that option is in the manpage... so the html was out of date :)
[05:57] <pitti> postmap --help doesn't have -u either
[05:58] <slangasek> oh, n/m, that *is* the manpage you're quoting (and I'm looking at)
[05:58] <slangasek> do you need me to reroll without this change?
[05:59] <pitti> slangasek: my current version on natty does have the manpage as well
[05:59] <pitti> slangasek: I think it's harmless, as the package build will fix them anyway
[05:59] <pitti> s/have the manpage/have the option/
[05:59]  * slangasek nods
[05:59] <pitti> seems they shouldn't be in the source at all
[05:59] <pitti> slangasek: ok, thanks for checking
[06:09] <pitti> slangasek, ScottK: accepted; I think it's prudent to waive the 7 day period here
[06:09] <ScottK> Agreed, once we have some test results from the affected people.
[06:10] <ScottK> I'll be able to check for regressions, but didn't have the actual bug.
[06:10] <pitti> same here; I run a local MTA for forwarding to my server, but mail is working fine
[06:10] <pitti> relayhost = 213.9.93.70:2525
[06:10] <pitti> hmm, no wonder :)
[06:10] <pitti> little DNS to do here
[06:12] <ScottK> Actually I had the symptoms in the dupe, so I can check that.
[06:14] <pitti> stgraber: question for you in bug 436936
[06:15] <lamont> asm/termios.ph: missing
[06:15] <lamont> syscall.ph: Can't locate asm/unistd.ph in @INC (@INC contains: ./etc/perl ./usr/local/lib/perl/5.12.3 ./usr/local/share/perl/5.12.3 ./usr/lib/perl5 ./usr/share/perl5 ./usr/lib/perl/5.12 ./usr/share/perl/5.12 ./usr/local/lib/site_perl) at usr/lib/perl/5.12/sys/syscall.ph line 7, <> line 1.
[06:15] <lamont> Compilation failed in require at usr/lib/perl/5.12/syscall.ph line 5, <> line 1.
[06:15] <lamont> Compilation failed in require at debian/check-require line 71, <> line 1.
[06:15] <lamont> make: *** [install-stamp] Error 1
[06:15] <lamont> so... WTF is missing from arm that perl hates us all?
[06:21] <StevenK> lamont: perl also failed on amd64 with much the same error due to multiarch
[06:22] <lamont> do we have a fix?
[06:26] <StevenK> lamont: Does /usr/include/asm exist?
[06:27] <lamont> dunno
[06:28] <StevenK> lamont: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625634
[06:28] <lamont> StevenK: not in the base chroot tarball... if it's going to exist, something'll need to create it
[06:28] <ScottK> I think the standard way to fix multiarch bugs is bug slangasek until he fixes it.
[06:28] <lamont> slangasek: ^^
[06:32] <slangasek> ehm, did doko not already fix that bug?
[06:32] <lamont> cjwatson: ^^ armel perl ftbfs, apt is building, arm is on manual, I am sleeping
[06:32] <slangasek> oh, maybe he fixed it by adding a build-dep on gcc-multilib, which I guess doesn't help armel
[06:32] <lamont> slangasek: might be
[06:33] <slangasek> lamont: ICMP redirect doko
[06:34] <lamont> slangasek: if you can get a new perl 5.12 uploaded that is expected to build, and then stuff or have it stuffed into building on arm (score it to at least 5555556 to win), that'd be cool
[06:34] <lamont> slangasek: heh
[06:34]  * lamont is crashing
[06:35] <lamont>  doxygen : Depends: doxygen-latex but it is not going to be installed <-- doko_: OH hai.  perl is blocking apt, too.
[06:39] <lamont> buildfarm is back on auto, with the apt-segvs chroot tarball for oneiric
[06:40] <lamont> and on that note, bed
[07:01] <cjwatson> StevenK: uh, the most recent perl/amd64 succeeded
[07:01] <StevenK> cjwatson: I was going by the Debian bug that doko_ filed.
[07:13] <cjwatson> looks like it would fail if not for gcc-multilib.  I guess that gives me a quicker test case than armel ...
[08:04] <Sweetshark> Morning all!
[08:05]  * Sweetshark wiggles around in his shiny new IRC cloak so everyone can see it.
[08:10] <UGod> ubuntu devel: looking to install libid3-tools package.
[08:10] <UGod> get an error - Package libid3-tools is not available, but is referred to by another package.
[08:10] <UGod> This may mean that the package is missing, has been obsoleted, or
[08:10] <UGod> is only available from another source
[08:11] <UGod> which package to install please?
[08:13] <micahg> UGod: it's in natty and oneiric
[08:20] <UGod> thanks micahg... downloaded the source.. not to build and install... Cheers
[08:22] <nigelb> morning dpm
[08:24] <UGod> micahg: downloaded the NATTY id3lib3.8.3_3.8.3.orig.tar.gz  tarball.
[08:24] <UGod> micahg: It refuses to configure!!! Error: configure: error: Missing a vital header file for id3lib
[08:24] <UGod> micahg: any ideas?
[08:25] <micahg> UGod: why not just install the package?
[08:25] <abhinav-> pitti: I think I have found a work around to avoid using cairo. But I am getting this error on running the script: "TypeError: GObject.__init__() takes exactly 0 arguments (5 given)"
[08:29] <dpm> morning nigelb
[08:29] <nigelb> dpm: :)
[08:40] <jtaylor> can a bugfix release of some software be done in a SRU or should these be backported?
[08:45] <pitti> jtaylor: if it's only a few bug fixes, then yes
[08:45] <pitti> jtaylor: sorry, s/yes/a new upstream release is acceptable/
[08:45] <pitti> abhinav-: ah, you need to call constructors with their explicit name
[08:45] <pitti> abhinav-: i. e. Gtk.Something.new(arg, arg)
[08:45] <abhinav-> oh
[08:46] <pitti> abhinav-: or give the property names explicitly, such as Gtk.Label(label='foo')
[08:46] <cdbs> Anybody seen mvo around lately?
[08:47] <pitti> abhinav-: see "Differences to the C API" on https://live.gnome.org/PyGObject/IntrospectionPorting
[08:48] <pitti> cdbs: he might be in Budapest now, at the Canonical summit
[09:02] <c2tarun> can anyone please help me with this error http://paste.kde.org/51883/
[09:04] <lucidfox> Hmm
[09:06] <doko> cjwatson: yes, just remove gcc-multilib on any other arch
[09:06] <jtaylor> c2tarun: is HAVE_POPPLER_0_15_0 defined?
[09:07] <c2tarun> jtaylor: nope.
[09:08] <jtaylor> c2tarun: against which poppler version do you want to compile?
[09:09] <c2tarun> jtaylor: I dont know, I just grabed the source from debian and I was trying to merge/sync. How can I check?
[09:12] <cjwatson> doko: indeed.  I've reproduced it
[09:13] <cjwatson> doko: I'm out for a couple of hours now; pretty sure it's utils/h2ph.PL:inc_dirs that needs to be changed, so unless you beat me to it I'm happy to finish off when I get back
[09:13] <doko> cjwatson: ok, looking at it now
[09:13] <jtaylor> c2tarun: sync to oneiric? then you need to have that defined
[09:13] <jtaylor> c2tarun: debian only has poppler 0.12
[09:13] <c2tarun> jtaylor: sorry, but what is poppler?
[09:14] <jtaylor> c2tarun: no idea but its the cause of the build failure ^^
[09:14] <jtaylor> c2tarun: the api change of it
[09:14] <c2tarun> jtaylor: hmm... any idea how to fix it?
[09:15] <jtaylor> c2tarun: it seems defining the variable should do, I'm currently checking how to do it
[09:15] <c2tarun> jtaylor: is there any wiki page for such build errors?
[09:16] <jtaylor> c2tarun: no its probably a failure in the configure.ac specific to epdfview
[09:16] <cjwatson> doko: possibly something like http://paste.ubuntu.com/603595/, though that's entirely untested and of course we need to set and export DEB_HOST_MULTIARCH in debian/rules for that to work consistently
[09:18] <jtaylor> c2tarun: seems easy to fix, I'll provide a patch soon
[09:18] <c2tarun> jtaylor: I'll wait :) in case I got disconnected I'll come back and take the patch from you.
[09:19] <Laney>     - ubuntu_poppler-0.15.patch: Patch taken upstream. This fixes a FTBFS with poppler 0.16 because of API changes.
[09:19] <Laney> does that no longer work?
[09:20] <c2tarun> Laney: I dont think so, that patch is in there and also it applied succesfully but this error is coming
[09:23] <c2tarun> Laney: can you tell me what is poppler? may be I can understand the bug then.
[09:23] <Laney> poppler is a pdf rendering library
[09:28] <doko> cjwatson: that would work, but imo better to replace the test by: gcc -v -E - < /dev/null 2>&1 | awk '/^#include/, /^End of search list/' | grep '^ '
[09:29] <jtaylor> c2tarun: did you merge debian/rules correctly
[09:29] <c2tarun> jtaylor: let me check
[09:30] <jtaylor> needs: --with dh_autoreconf and a build depend on it
[09:30] <c2tarun> jtaylor: there is no conflict in rules, so I didnt touched it
[09:31] <c2tarun> jtaylor: yup its there http://paste.ubuntu.com/603597/
[09:34] <Laney> show the full build log please
[09:36] <c2tarun> Laney: full build log http://paste.ubuntu.com/603598/
[09:37] <jtaylor> c2tarun: the ubuntu patch does not get applied in that log
[09:37] <jtaylor> c2tarun: it also needs refreshing
[09:37] <c2tarun> jtaylor: which line?
[09:38] <jtaylor> c2tarun: quilt push  -a -f; quilt refresh
[09:38] <c2tarun> jtaylor: I mean from where did you figured out that patch was not applied?
[09:39] <c2tarun> jtaylor: oh... shittt...
[09:39] <c2tarun> jtaylor: I got it
[09:41] <jtaylor> c2tarun: how did you build the package? fakeroot debian/rules build?
[10:00] <sudipta> can  anyone tell me where to find something about upcoming features of unity in ubuntu11.04
[10:01] <doko> cjwatson: now checking http://paste.ubuntu.com/603613/
[10:01] <pitti> sudipta: 11.04 is what it is, there won't be new features after the release
[10:02] <popey> cjwatson: were you aware that on a 10.10 live CD (no install of Ubuntu), Update Manager pops up offering to upgrade to 11.04? Want me to file a bug about it?
no even in unity shell?
[10:02] <pitti> sudipta: it's a stable release
ok...then anything about 11.10?
[10:04] <pitti> sudipta: not yet, UDS is next week
thanks about the info
[10:18] <micahg> pitti: could you apply the thunderbird-mozsymbols override in natty-updates as well please?
[10:19] <pitti> micahg: done; there's no powerpc binary, though
[10:20] <micahg> pitti: that's normal, thanks
[10:21] <micahg> pitti: could you copy over to oneiric as well please?
[10:21] <pitti> micahg: that's "thunderbird" source, right?
[10:21] <micahg> pitti: yes please
[10:22] <pitti> micahg: done; this doesn't autoclose oneiric bug tasks, so please do that manually
[10:22] <micahg> pitti: ok, thanks
[10:47] <Sweetshark> Hi all, Id like to lobby for some more endorsements on https://wiki.ubuntu.com/BjoernMichaelsen/DeveloperApplication doko? Maybe you could do me the favour?
[10:49] <doko> Sweetshark: should I write about the mismatch of https://bugs.launchpad.net/~openoffice-pkgs/+packagebugs and https://bugs.launchpad.net/~libreoffice/+packagebugs ? ;-P
[10:55] <Sweetshark> doko: touche. However I just frantically searched a way to add those and did not find one. Either LP is too confusing to me or I might have to permissions to do that.
[10:56] <Sweetshark> doko: If it is the second, supporting the application might help. ;D
[10:57] <doko> Sweetshark: https://launchpad.net/ubuntu/+source/dict-af, then Edit bug mail subscription
[10:57] <doko> for every package
[10:58] <doko> not the dict-* packages are not available in Debian
[10:59] <doko> Sweetshark: feel free to add other packages related to LO
[10:59] <Sweetshark> k, will do.
[10:59] <Sweetshark> doko: Should I remove them from OOo scribblers?
[11:03] <doko> is it needed? anyway, you can do it now
[11:03] <doko> lamont, cjwatson: looks like apt isn't on hold anymore, perl failed to build on armel
[11:04] <Sweetshark> doko: It makes it easier as I can see if ther are any packages left at OOo then. Ill do it.
[11:05] <doko> Sweetshark: would be good if the dict-* packages could see an update after some years
[11:38] <cjwatson> doko: agreed, that looks much cleaner
[11:39] <cjwatson> popey: yes, in fact I mentioned it here yesterday :-)  I'm working on a fix, but a bug would be good anyway since I think it would be worth SRUing
[11:39] <cjwatson> popey: on casper
[11:39] <popey> groovy
[11:40] <cjwatson> I think diverting /usr/lib/update-manager/check-new-release{,-gtk} is the right answer
[11:51] <tseliot> apw, cjwatson: any ideas as to why a failure to start X with a proprietary driver such as nvidia would result in having the VT stuck in KD_GRAPHICS? Shouldn't we fall back to KD_TEXT?
[12:14] <cjwatson> popey: have you filed that bug?  I have the patch ready to commit once I have a bug number ...
[12:14] <popey> not yet, on windows at work, happy for me to file one with no apport stuff?
[12:15] <cjwatson> yes, the apport stuff would be irrelevant anyway
[12:15]  * popey files now
[12:15] <cjwatson> ta
[12:16] <popey> bug 777759
[12:16] <popey> ooo, so close to 777777
[12:18] <jdstrand> cjwatson: hey, sorry to bother you, but can you think of any reason why lp-remove-package.py wouldn't work?
[12:18] <jdstrand> cjwatson: http://paste.ubuntu.com/603664/
[12:18] <ScottK> slangasek: My part of the postfix bug is verified fixed.  Thanks again.
[12:20] <cjwatson> jdstrand: looks like a held lock or something, have you tried stracing it?
[12:20] <jdstrand> no, I'll do that. I just hadn't seen it before and didn't know if something was going on that I didn't know about
[12:21] <cjwatson> doesn't ring a belel
[12:21] <cjwatson> *bell
[12:22] <jdstrand> aha
[12:22] <jdstrand> slangasek: pam-devperm is hung
[12:22] <jdstrand> err
[12:22] <jdstrand> slangasek's
[12:23] <jdstrand> slangasek: your lp-remove-package.py of pam-devperm is hung on cocoplum
[12:23] <jdstrand> slangasek: maybe it is looking for confirmation?
[12:24]  * jdstrand jots down the command and kills the process
[12:27] <jdstrand> slangasek: it seems you maybe forgot a '-y' in a script/looping command: now there is the same for tla-buildpackage
[12:35] <jdstrand> slangasek: and wmsmpmon. I'm guessing ./process-removals.py in a screen session. I'm done harassing you now, but anyone wanting to remove a package will have to kill the lp-remove-package.py on cocoplum that is holding the lock
[12:59] <ScottK> Need to hurry if you want to report bug 777777
[12:59] <ScottK> Oops.  Too late.
[13:14] <doko> cjwatson: for perl rebuilds, I wanted to follow the stages in http://release.debian.org/transitions/html/perl.html once armel is working again,
[13:16] <cjwatson> doko: oh, sorry.  I checked that they were at the bottom level in terms of build-deps
[13:16] <doko> np, just trying to track rebuilds which are already done
[13:16] <cjwatson> that order is confusing.  Why are libtext-charwidth-perl and libtext-iconv-perl not at the top level?
[13:17] <cjwatson> well, tracking is easy, grep for Depends: perlapi-5.10.1
[13:18] <doko> right
[13:40] <tseliot> cjwatson: no ideas? Also, can you point me to the commit that you made in grub to address the black screen on VT switch issue (the one that required switching back to page 0 before loading Linux), please?
[13:43] <YokoZar> What's the UDS channel gonna be?
[13:43] <YokoZar> I'm in Budapest already
[13:43] <cjwatson> tseliot: sorry, it doesn't ring a bell; note though that there's more than just KD_GRAPHICS and KD_TEXT, there's also KD_TRANSPARENT which turns into text mode on VT switch
[13:44] <cjwatson> tseliot: if it really is KD_GRAPHICS, it sounds like a plymouth bug of some kind maybe?
[13:46] <cjwatson> tseliot: http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/3116 upstream, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/natty/grub2/natty/revision/2138 in Ubuntu
[13:47] <Laney> I just put http://people.ubuntu.com/~laney/transitions/perl.html up (run against the Ubuntu archive)
[13:48] <cjwatson> oh, nice
[13:48] <cjwatson> where's the source for the tracker?
[13:48] <deffcon> i want to compile openelect.tv on ubuntu natty, when i do a make i get error on glibc-static
[13:48] <Laney> doesn't have multiple archive support though, so i couldn't add ports
[13:49] <Laney> cjwatson: git+ssh://git.debian.org/git/collab-maint/ben.git
[13:49] <Laney> i'll push my changes to a branch soon
[13:49] <cjwatson> nice, thanks
[13:50] <cjwatson> deffcon: it's generally much easier to debug the exact text of error messages, rather than descriptions of the errors.  if it's more than a line or two, put it on paste.ubuntu.com
[13:51] <tseliot> cjwatson: I assumed that it was KD_GRAPHICS as plymouth switches between it and KD_TEXT and this problem is about being stuck with a splash screen when X fails (I should have probably mentioned this). Switching to KD_TEXT with a custom app that I wrote seems to solve the problem
[13:52] <cjwatson> tseliot: any VT switch might do the job too
[13:53] <tseliot> cjwatson: according to the engineer who reported the problem, VT switch had no effect. Thanks for the links BTW
[13:55] <cjwatson> tseliot: cranking up plymouth debugging options might be a plan
[13:55] <tseliot> cjwatson: good point
[14:02] <tseliot> cjwatson: also, since gdm is supposed to tell plymouth to quit without any kind of transition effect when X fails,it might be a good idea to make gdm switch to KD_TEXT if plymouth is stuck. Here's what we currently do: http://pastebin.ubuntu.com/603705/
[14:10] <cjwatson> tseliot: maybe on those error paths
[14:11] <tseliot> cjwatson: yes, that's what I was suggesting
[14:11] <tseliot> so that at least we are back to text mode if something nasty happens
[14:11] <cjwatson> I've certainly heard worse ideas :)
[14:13] <tseliot> hehe
[14:53] <abhinav-> pitti: partial success :). problem is that instead of producing screenshot in  PNG a postscript file is being produced :D
[14:54] <stgraber> pitti: hi! I'll re-upload to clarify changelog. Thanks for noticing my bad copy/paste :)
[14:55] <stgraber> pitti: I'll use kdm.conf instead of kdm.upstart as it's the name it'll have on the installed system and so should be clearer to the user
[14:58] <pitti> stgraber: ah, right; thanks
[14:59] <pitti> abhinav-: weird, a PS should be a lot harder to get than a PNG :)
[15:00] <abhinav-> pitti: yeah. I don't know but something is going wrong. It should save it in png by the name "test.png" but it dumps a file by the name "gi" :-P
[15:00] <abhinav-> that is a ps file
[15:02] <abhinav-> pitti: I am getting these tracebacks at the end of script execution http://paste.ubuntu.com/603736/ .
[15:03] <pitti> abhinav-: hm, do you try to run a python file which doesn't have a proper hashbang line or something similar?
[15:04] <abhinav-> pitti: ah yes, I didn't declare the hashbang
[15:04] <pitti> or a python file through shell or so?
[15:05] <abhinav-> pitti: yes, declaring hashbang seems to have resolved. Thanks :)
[15:07] <effie_jayx> hello all, yesterday I asked about adding an icon to "systray" in unity. I am the current maintainer of a microblogging app and I would like to know what isthe best way to have integrated with unity?
[15:08] <BlackZ> pitti: re rsyslog: does create /dev/xconsole help?
[15:09] <effie_jayx> I have read about libappindicator https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting%20Guide%20for%20Applications, however I am not clear If I as a maintainer should develop a patch and send it upstream, it being a little change that is not very intrussive. Or if I should just work with them in making changes that will affect funtionality in other distros like debian and the rest.
[15:11] <pitti> BlackZ: haven't tried, but removing the xconsole rule doesn't
[15:12] <BlackZ> pitti: hmm.. let me know if creating /dev/xconsole manually helps
[15:12] <pitti> BlackZ: does it for you?
[15:14] <BlackZ> pitti: I don't remember having this problem.. do you have it on different machines?
[15:14] <pitti> just tested on my main workstation
[15:17] <BlackZ> pitti: ok, will check carefully later. I will let you know if I have this problem
[15:17] <pitti> thanks
[15:17] <pitti> I have no rsyslog customization at all on this matchine
[15:19] <cjwatson> stgraber: BTW, merges.u.c did sort itself out
[15:19] <BlackZ> pitti: me neither. And the configuration file in the Debian package didn't change
[15:22] <Chipzz> effie_jayx: the page you linked to mentions #ayatana as the place to be
[15:23] <stgraber> cjwatson: yep, I noticed it eventually updated at some point yesterday in my afternoon/evening.
[15:27] <effie_jayx> Chipzz: thanks for the heads up
[15:34] <mdeslaur> who's the dbusmenu specialist?
[15:34] <shadeslayer> stgraber: around?
[15:34] <stgraber> shadeslayer: yep
[15:35] <shadeslayer> stgraber: i have a tiny issue in pastebinit
[15:35] <shadeslayer> it doesn't list any supported pastebin sites
[15:35] <shadeslayer> i've removed all possible config files related to it and re-installed it using --purge .... still doesn't work
[15:36] <stgraber> shadeslayer: oh, that could be a problem :) what do you have in /usr/share/pastebin.d/ ?
[15:36] <shadeslayer> stgraber: all the conf files for pastebin sites
[15:36] <stgraber> ok, and "pastebinit -l" returns nothing ?
[15:37] <shadeslayer> yep
[15:38] <stgraber> shadeslayer: can you pastebin (manually :)) the output of: "strace -fF pastebinit -l 2>&1 | grep pastebin.d" ?
[15:39] <shadeslayer> sure
[15:40] <shadeslayer> stgraber: http://paste.ubuntu.com/603750/
[15:40] <stgraber> shadeslayer: ok, I found the issue, though it's an upstream bug ...
[15:40] <stgraber> shadeslayer: sudo rmdir /etc/pastebin.d
[15:40] <stgraber> and you'll be good
[15:41] <shadeslayer> whee :D
[15:41] <shadeslayer> stgraber: {{hugs}}
[15:41] <shadeslayer> now ... i'll write a backend for gist.github ;)
[15:41] <stgraber> I'll file a bug upstream so I fix it with the next release (next release will be a major rewrite)
[15:41] <shadeslayer> oh goody :D
[15:42] <soren> Erk. This can't be good: [19277.870958] apt-get[11134]: segfault at 7f8fa4bf7000 ip 00007f7cd6249dbd sp 00007fff7fe05f60 error 4 in libapt-pkg.so.4.10.1[7f7cd61fd000+10b000]
[15:44] <soren> Doh. Fetching apt and dpkg -i'ing it solved it. Something's amiss.
[15:52] <Daniel0108> hi
[16:02] <ScottK> soren: Are you on oneiric armel perchance?
[16:15] <SqRt7744> hi, does anyone know how to get a package uploaded to a ppa to be built for multiple releases? ...well at least 10.10 and 11.04?
[16:16] <tumbleweed> SqRt7744: #launchpad for non-ubuntu-development questions. And no you can't. Upload once for each release (with differennt versions, i.e. ~maverick1 & ~natty1 )
[16:17] <SqRt7744> tumbleweed, ah ok thanks.
[16:19] <hallyn> so, libvirt in natty and oneiric currently have the same versions.  I uploaded a fix to oneiric.  Then I wanted to upload the fix to natty-proposed.  But that got rejected bc of same contents as oneiric.  What to do?  (Beside syncing a newer version for oneiric, which I want to do anyway 'soonish')
[16:21] <Laney> what did the error message say?
[16:21] <Laney> the natty version needs a lower version number than in oneiric
[16:23] <hallyn> so i can call it 6.1 or something?
[16:23] <hallyn> or is that too funky?
[16:23] <barry> Laney: btw, thanks about winpdb
[16:23] <Laney> hallyn: 6.1 sounds right yeah
[16:23] <Laney> barry: no probs
[16:24] <hallyn> Laney: great, thanks
[16:32] <lamont> cjwatson: lets chat at UDS about -i18n vs -english sometime in the hall, eh?
[16:38] <cjwatson> lamont: yep
[16:38] <lamont> clearly doesn't warrant a full session or anything close to it.
[16:39] <lamont> though if it fits into one somewhere, that's fine too
[16:40] <cjwatson> lamont: I don't think it does
[16:41] <lamont> 'zactly
[17:38] <slangasek> jdstrand: yes, I have process-removals running here, trying to clear up the backlog of Debian removals from past cycles - sorry if it was in your way
[17:40] <jdstrand> slangasek: it wasn't in my way once I figured out what the problem was. that said, I killed a few of your removals so it would need to be run again
[17:40] <jdstrand> slangasek: I think just the three I mentioned
[17:43] <slangasek> jdstrand: yeah... it's a long enough run that having to run it again is a minor roadbump ;)
[17:47] <jdstrand> well, they could be removed by hand...
[18:01] <slangasek> jdstrand: nah, less mental effort to just rerun process-removals
[18:19] <infinity> cjwatson, lamont : If you have wireless in that hall, feel free to poke me about it.  I was using -english over -i18n on both Debian abd Ubuntu buildds for years for a variety of reasons.
[18:41]  * pmatulis surprised that both MIT and Heimdal Kerberos are in universe
[18:52] <Tyr999999> Hello, when i watch flashvideos the vid starts becoming more and mor "choppy" after approx. 10 mins.Anyone an idea?
[18:52] <Pici> Tyr999999: This isn't a support channel, use #ubuntu instead.
[18:53] <Tyr999999> Whopops, sorry.
[18:57] <slangasek> pmatulis: only the KDC is in universe for MIT Kerberos; the libraries and clients are all in main; if krb5-kdc and krb5-admin-server are wanted in main, I guess you should talk to the server team and convince them to seed them
[18:58] <pmatulis> slangasek: ah, thx for that
[18:58] <slangasek> n/p
[18:59] <slangasek> effectively we already have to provide security support for the kdc since it's from the same source package as the libs, so seeding it is probably pro forma :)
[19:01] <broder> slangasek, pmatulis: in fact i'm pretty sure i've seen krb5 USNs that were for KDC-only issues, so i think the support may be effectively there already :)
[19:03] <pmatulis> broder: yeah, we send out USN for non-main stuff sometimes
[19:15] <doko> lamont, cjwatson: perl built \o/  I assume I can rescore, give back the failed perl builds in 20 minutes
[19:41] <geser> doko: is the perl transition already in a state where one can start with rebuilding packages depending on libperl5.10? or should I wait some more days?
[19:42] <doko> 5.12? no, please let armel catch up
[19:43] <geser> ok
[20:48] <Otacon22> Hi all
[20:51] <lamont> doko: are you doing the perl retries then?
[20:51] <lamont> because it looks to be ready for that
[20:52] <doko> lamont: I did, but apt needs libxml-parser-perl
[20:52] <lamont> yeah, I figured apt would prolly wind up behind them all
[20:52] <doko> lamont: is it safe, to set the buillds to auto after the apt build?
[20:54] <lamont> doko: I need to restore the chroot tarball
[20:54] <lamont> once apt is started, poke me or a gsa to do that, and once that's done, we can go auto
[20:54] <lamont> well, once apt is built
[20:55] <doko> lamont: even if the apt build is started
[20:56] <lamont> oh right.
[20:57] <lamont> since after apt is built, we'll retry all of arm/oneiric
[20:57] <doko> will have to do a give-back anyway
[20:57] <lamont> so yes, once the apt build is started (and all of perl rebuilds are at least started), let me know
[20:57] <lamont> and by "started" I mean "have fetched the tarball and started unpacking it
[20:57] <doko> will be in 40min
[20:59] <kelemengabor> Hi, can somebody tell me, what should I do to get a blueprint approved for UDS?
[20:59] <kelemengabor> this one: https://blueprints.launchpad.net/ubuntu/+spec/community-o-hungarian-loco-brainstorm
[21:00] <kelemengabor> Is it automagic? Or I should ask someone?
[21:22] <natschil> Good Day. I would like to setup another configuration for the filesystems for ubiquity, apart from the "use free space" and "use all space" etc options, and support for another filesystem type in partman following that. What would be the easiest way to implement this?
[21:23] <natschil> I downloaded the source code for ubiquity, but before trying to figure out how it all works and what file does what, I was wondering if there was some documentation here or elsewhere to help me.
[21:26] <ScottK> kelemengabor: It's not purely automagic.  I'd imagine jono will have a look at it sometime today.
[21:27] <kelemengabor> ScottK: thanks!
[21:29] <natschil> any suggestions?
[21:44] <jcastro> ScottK: I'd like to switch the Qt Panel with your kubuntu defaults (9am on Tuesday) if possible, there's a flight conflict with one of the Nokia folks and he has to be in the morning.
[21:45] <natschil>  any suggestions as to where to ask about how to do things like described earlier with ubiquity?
[21:45] <ScottK> jcastro: Should be fine.  That should increase the chances apachelogger gets up on time.
[21:45] <jcastro> hah
[21:45] <jcastro> ok moving it now
[21:59] <bdrung_> lool: will you merge devscripts?
[22:00] <bdrung_> lool: are you interested in reducing the diff to debian in devscripts?
[22:09] <popey> cjwatson: wthanks for answering my question
[22:09] <geser> jelmer, poolie: can somebody of you fix the bzr-* FTBFS in oneiric? you probably need to reorder the build-depends on "bzr (<< 2.4.0~beta1-2) | python-bzrlib.tests" to "python-bzrlib.tests | bzr (<< 2.4.0~beta1-2)" so the buildd install the right package (see e.g. https://launchpadlibrarian.net/70985338/buildlog_ubuntu-oneiric-i386.bzr-dbus_0.1~bzr49-1_FAILEDTOBUILD.txt.gz for a FTBFS)
[22:10] <jelmer> geser: sure, I'll have a look when I get a chance
[22:10] <geser> thanks
[22:11] <poolie> geser, why does that make a difference?
[22:14] <geser> poolie: because of bug #594916 when checking which build-depends need to be installed: the version constraint isn't checked when computed which packages need to be installed and later dpkg-buildpackage complains about it
[22:17] <geser> the buildd installs bzr (the first preference) instead of python-bzrlib.tests but the version in the archive is newer than requested
[22:18] <poolie> ok thanks
[22:18] <infinity> To be fair, it's best practice for your first option to be the one you actually want anyway.
[22:18] <geser> if you reorder this build-dependency, the buildd will pick python-bzrlib.tests first and only fallback to bzr if the first one doesn't exist
[22:18] <infinity> And obviously you don't want people downgrading bzr.
[22:21] <Laney> are or-ed buildds actually supported by policy?
[22:21] <Laney> build-depends, even
[22:22] <geser> wasn't there recently (a few weeks ago) a discussion about it on the debian-devel ML?
[22:22] <Laney> right, around the topic of sbuild's resolver
[22:22] <Laney> I don't think there was consensus that they are a good idea
[22:37] <apachelogger> ScottK: :)
[22:38] <stgraber> Laney: ping
[22:38] <Laney> hi stgraber
[22:39] <stgraber> Laney: seems like the DMB meeting is supposed to be at 3pm and not 4pm (budapest time)
[22:39] <Laney> oh really?
[22:39] <stgraber> Laney: http://www.timeanddate.com/worldclock/converted.html?month=5&day=9&year=2011&hour=13&min=0&sec=0&p1=0&p2=50
[22:39] <Laney> I thought it was 1400 utc
[22:41] <stgraber> Laney: I'll see if I can move it without too many conflicts. If not, then I guess we should just advertise that it'll be an hour later than usual :)
[22:42] <doko> lamont: the perl stuff did build, apt did ftbfs again due to doxygen not built (now started). I think you can revert back the chroots, but keep apt on hold, and then set the buildds to auto again
[22:42] <doko> please give back apt if doxygen is in the archive
[22:42] <doko> afk now
[22:42] <stgraber> Laney: multiple conflicts :(
[22:43] <stgraber> Laney: in multiple sessions, so I can't just swap them to fix it :(
[22:43] <Laney> whoops
[22:43] <Laney> I thought we'd moved 1300 → 1400
[22:43] <Laney> but we actually moved 1200 → 1300. sorry :(
[22:45] <stgraber> np :) I guess we should just e-mail ubuntu-devel and maybe get the fridge updated to say that next week's meeting is going to be from 14:15 to 15:00 UTC
[22:46] <Laney> I guess it doesn't matter so much as most people will be there in person
[22:47] <stgraber> yeah. I prefer to have it stay at 14:15 and have everyone there than move it an hour earlier and miss persia and rsalveti
[22:58] <doko> lamont, cjwatson: doxygen FTBFS, so I assume the best thing would be to set apt on hold, restore the tarballs, and set the buildds on auto
[23:07] <lamont> doko: do we know why it's ftbfs?
[23:09] <doko> lamont: https://launchpadlibrarian.net/71162021/buildlog_ubuntu-oneiric-armel.doxygen_1.7.4-1_FAILEDTOBUILD.txt.gz
[23:09] <doko> see email
[23:13] <ScottK> doko: That looks somewhat like https://buildd.debian.org/status/fetch.php?pkg=kde4libs&arch=armel&ver=4%3A4.4.5-5&stamp=1304545515
[23:22] <stgraber> Laney: sent an e-mail to ubuntu-devel about the next DMB meeting
[23:22] <Laney> thanks
[23:53] <SpamapS> pitti: ping re erlang that I am uploading at the moment. I am removing the patch that turns on "+slim" and "+compresed" because they produce weird results .. figure we will pose the question to upstream later.