[00:03] <barry> cjwatson: nothing special.  i run ubuntu in a fusion vm, so the underlying os is totally stock
[00:03] <barry> cjwatson: but yeah that *is* interesting :)
[00:04] <slangasek> does Ubuntu even see the hardware from within fusion?
[00:04] <slangasek> (hardware/EFI)
[00:04] <kees> hmpf, I can't compile gdb with sbuild.
[00:04]  * kees scratches his head
[00:04] <kees> dpkg-source: error: cannot fstat file ./gdb_7.1.orig.tar.bz2: No such file or directory
[00:04] <kees> why is that "./" instead of ../ ?
[00:05] <slangasek> kees: is that a dpkg-source -x or dpkg-source -b?
[00:05] <barry> slangasek: how can i find out? :)  i doubt it though; vms probably see a bios from fusion.  however, this shouldn't enter into it because it was a host machine boot to cjwatson's test cd
[00:05] <kees> slangasek: not sure how sbuild is calling dpkg-source
[00:05] <slangasek> barry: cat /proc/cpuinfo inside the VM, maybe
[00:05] <slangasek> barry: oh, you did a host machine boot - n/m
[00:06] <slangasek> barry: in that case my questions are irrelevant :)
[00:06] <barry> slangasek: :)
[00:06] <slangasek> kees: well, if it were using dpkg-source to unpack (-x), it could be a bad path in the .dsc
[00:06] <barry> slangasek: but it does see it as an intel core 2 duo T9900 @ 3.06GHz
[00:06] <slangasek> kees: if it's when building the source package (-b), I don't know
[00:06] <kees> slangasek: oh! that alone was enough to remind me about what I think the problem is.
[00:06] <slangasek> kees: ok :)
[00:07] <kees> I think my sbuild wrapper is doing the wrong thing about where it puts the source.
[00:07] <kees> where I use "my" loosely given several other people wrote it too
[00:07] <kees> hm, no
[00:08] <cjwatson> barry: well, if I get a report from an EFI machine that's i386-efi or x86_64-efi (and that isn't my kvm testbed), then that's basic functionality confirmed and I just need to wait to see if I get reports of BIOS machines falling over
[00:08] <cjwatson> I plan to ask for it to be run through the certification lab as well
[00:08] <barry> cjwatson: +1
[00:18] <TheMuso> cjwatson: If I boot that CD and let refit search for it, I get a lot of different options. Haven't looked at what each one is yet. When I boot the CD using teh C key, I get no farther than the "welcome to GRUB" message. I'll email you with more details when I test more.
[00:21]  * barry -> away
[00:31]  * kees kicks sbuild
[00:32] <CynthiaG> What should I do if a package has unit tests that "succeeded" before, but now "fails" because of a fix that made things more true to a spec?
[00:32] <CynthiaG> If that question is no good here, and depends on the package in question, please say so instead :)
[00:32] <kees> CynthiaG: i'd say is depends on the spec, the package, and the test.  :)
[00:33] <CynthiaG> kees: SVG, librsvg, all unit tests :\
[00:34] <kees> CynthiaG: ah, in that case, I'd bring it to the attention of the upstream librsvg folks, since it sounds like the tests need fixing if you made it more strict to SVG, etc
[00:34] <CynthiaG> sounds like a plan
=== Seeker`_ is now known as Seeker`
[00:44] <SpamapS> micahg: ping!
[00:44] <micahg> SpamapS: pong
[00:44] <SpamapS> micahg: do you have a moment to discuss couchdb?
[00:45] <micahg> SpamapS: sure
[00:45] <SpamapS> micahg: I'm working on merging 0.11.0-1 .. but this seems to be breaking the build: sed -i s,$(LIB)$$,$(LIB)/$(DEB_UPSTREAM_VERSION), configure
[00:45] <SpamapS> micahg: I'm not sure why, but it causes an issue with AC_CHECK_CURL
[00:46] <micahg> SpamapS: can you pastebin the error?
[00:46] <SpamapS> micahg: standby
[00:47] <SpamapS> http://paste.ubuntu.com/446894/
[00:49] <SpamapS> micahg: if I remove the sed line, and re-run, it fails later (on the js library configuration, which makes sense).
[00:53] <micahg> SpamapS: I'm not sure
[00:53] <blue_anna> how can I get around dependency issues from having too recent of a version of a package (off of launchpad)
[00:53] <blue_anna>   libxmu-dev: Depends: libxmu-headers (= 2:1.0.5-1) but 2:1.0.5+git20100604.af962b3b-0ubuntu0sarvatt~lucid is to be installed
[00:54] <SpamapS> micahg: what is that sed line meant to do? Is there no way to fix that problem w/ LD_LIBRARY_PATH or a configure option?
[00:55] <micahg> SpamapS: I'm not sure, it was there in the last version
[00:56] <micahg> SpamapS: it seems to set up a specialized versioned path for the compiler
[00:57] <SpamapS> micahg: ok well I must have done something weird because I backed up a bit and now I can't reproduce that problem
[00:58] <SpamapS> dpkg-shlibdeps: warning: couldn't find library libmozjs.so needed by debian/couchdb-bin/usr/lib/couchdb/bin/couchjs (ELF format: 'elf64-x86-64'; RPATH: '').
[00:58] <SpamapS> now I'm getting that one
[00:58] <micahg> SpamapS: k, just a note, BTW, better to do a versioned xulrunner-1.9.2 GRE check in rules
[00:58] <micahg> SpamapS: that's normal
[00:59] <SpamapS> micahg: rules has been carried forward so should still be doing everything from before
[00:59]  * micahg might have forgotten it :)
[01:00] <micahg> SpamapS: ^^
[01:01] <SpamapS> xulrunner_gre_version := $(shell xulrunner --gre-version)
[01:01] <SpamapS> xulrunner_dep = xulrunner-$(shell echo $(xulrunner_gre_version) | cut -f1-3 -d.)
[01:02] <micahg> SpamapS: right, so the first line should be xulrunner_gre_version := $(shell xulrunner-1.9.2 --gre-version)
=== MattJ100 is now known as MattJ
[01:05] <SpamapS> aha.. the AC_CHECK_CURL thing is back.. argh
[01:05] <SpamapS> something to do with aclocal.m4
[01:05]  * SpamapS 's heads start to spin when autoconf lets its magic smoke out
[01:05]  * SpamapS has two heads, yes. ;)
[01:11] <SpamapS> micahg: thanks for your help, I'll keep digging
[01:12] <micahg> SpamapS: no problem, feel free to ping me if I can help
=== bjf[] is now known as bjf[afk]
[02:56] <artfwo> Hi! Would anyone care to sponsor bug 591528 (main)?
[02:56] <ubottu> Launchpad bug 591528 in libraw1394 (Ubuntu) "FTBFS on all architectures (Maverick)" [Undecided,Confirmed] https://launchpad.net/bugs/591528
=== sconklin-gone is now known as sconklin
=== nhandler_ is now known as nhandler
=== bjf__ is now known as bjf
[03:57] <RAOF> How do I get to attach gdb to compiz now that our security overlords have restricted ptrace?  Things I've tried which don't work: running “sudo gdb compiz”, and “echo 0 | sudo tee /proc/sys/kernel/ptrace_scope.
[04:00] <lifeless> RAOF: see pitti's announcement
[04:00] <lifeless> RAOF: there is a sysctl you can set
[04:00] <lifeless> which he documented
[04:02] <RAOF> Ok.  Re-reading that, i'm setting the sysctl to 0, and it's still not working.
[04:06] <RAOF> Debugging compositors sucks.
=== sconklin is now known as sconklin-gone
[04:11] <lifeless> RAOF: perhaps you need to set it to zero before anything starts up ?
[04:11] <lifeless> it might be a process flag?
[04:11] <lifeless> total speculation
[04:12] <RAOF> Possibly it's inherited by children, so you need to set it before logging in.
[04:14] <lifeless> yes
[04:14] <lifeless> thts what I'm saying
[04:14] <lifeless> so you want it in sysctl.d
[04:14] <RAOF> I've set it there, so I'll see next time I log in.
[04:15] <RAOF> I've got a usable backtrace by more devious methods anyway.
[04:23] <lifeless> oh?
[04:25] <RAOF> Well, the not terribly devious method of starting compiz under gdb and queuing up commands to run, of which the final one is “let it actually die and start metacity”
=== bjf is now known as bjf[afk]
[05:44] <kees> RAOF: "echo 0 | sudo tee /proc/sys/kernel/ptrace_scope" will disable the ptrace protection, so if you're hitting something else that's a different problem.  what is the error you're seeing?
[05:44] <kees> lifeless: and which announcement by pitti?
[05:44] <RAOF> kees: ptrace: operation not supported.
[05:44] <RAOF> Bah, sorry.  Not permitted.
[05:44] <lifeless> kees: by you. brain fail.
[05:44] <kees> lifeless: oh! okay, thought I missed something.
[05:45] <lifeless> kees: by your other other evil twin
[05:45] <kees> lifeless: heh
[05:45] <kees> RAOF: what's the action you're taking with gdb, exactly?
[05:45] <RAOF> Ok.  Now I'm surprised.  That works now!
[05:45] <kees> setting the sysctl in /proc should immediately revert the behavior.
[05:46] <kees> RAOF: either "sudo gdb ..." or setting the sysctl should do it.
[05:48] <RAOF> Hm, no it still doesn't work.  It works in the same VT as where I started compiz, but switching to VT1 gives operation not permitted, even with sudo gdb
[05:49] <kees> what's the command exactly you're using?
[05:50] <kees> (vt really should not matter)
[05:50] <kees> are you restarting procps possibly?  is /proc/sys/kernel/ptrace_scope remaining 0 ?
[05:53] <kees> RAOF: this works for me...
[05:54] <kees> "pidof compiz" then "sudo gdb" then "attach PID" where PID is whatever pidof returned.
[05:56] <kees> even tried different vts etc
[05:56]  * kees has to hit the sack.  email me if you learn anything more.
[06:00] <RAOF> Sleep well.
=== lifeless_ is now known as lifeless
=== almaisan-away is now known as al-maisan
[07:44] <pitti> Good morning
[07:44] <jussi> Morning Martin!
[07:45] <pitti> RAOF, lifeless: ptrace> rather kees' announcement, I figure? :-)
[07:46] <pitti> RAOF: sudo gdb doesn't work ?!?
[07:48] <RAOF> pitti: It didn't when I was trying it, but now it seems to work.
[07:48] <RAOF> I'm not sure what was happening.
[07:50] <RAOF> And I think I'll need a debug build of mesa to track the segfault down, anyway.  The optimisations appear to be doing strange things (like optimising out statements that would cause a null pointer dereference).
[07:56] <dholbach> good morning
[07:57] <mvo> hey dholbach
[07:59] <dholbach> hey mvo
[08:30] <cjwatson> could an ubuntu-mir member have a look over bug 582189, please?  I'm approaching being blocked on a new grub2 package
[08:30] <ubottu> Launchpad bug 582189 in libisofs (Ubuntu) "MIR: libisoburn, libisofs, libburn" [Undecided,New] https://launchpad.net/bugs/582189
[08:38] <pitti> superm1: wrt. bug 550288 and bug 444420, would it make sense to combine the rule to match KERNEL=="hiddev*|hidraw*", to cover both cases?
[08:38] <ubottu> Launchpad bug 550288 in udev (Ubuntu Lucid) "bluez fails to discover mx5000 keyboard and mouse" [Undecided,Triaged] https://launchpad.net/bugs/550288
[08:38] <ubottu> Launchpad bug 444420 in udev (Ubuntu) "USB logitech bluetooth doesn't work" [Undecided,Fix released] https://launchpad.net/bugs/444420
[08:38] <pitti> superm1: or does it wreak havoc to apply it to the respective other device?
[08:42] <superm1> pitti, unfortunately I don't have any of that logitech hardware to be able to verify myself
[08:42] <superm1> so i'm not sure what happens if you use the other device in that scenario
[08:43] <pitti> superm1: I asked in the bug for testing; I just wondered whether you'd know in general
[08:44] <superm1> pitti, ah, no, not so sure, sorry
=== hrw|gone is now known as hrw
[08:59] <jo-erlend> I'm exploring Quickly and I have some questions about it. Something tells me this might not be the proper channel for it, but what is?
[09:01] <dholbach> jo-erlend: you could try #ubuntu-app-devel or #ubuntu-desktop
[09:03] <jo-erlend> thanks. :)
[09:15] <cjwatson> hm, another new kernel ABI, and I'd only almost got rid of 2.6.34-5 from the archive ...
[09:34] <danigm> hello, I need to update ubuntu poppler package to upstream, what's the correct way to make that with launchpad?
[09:34] <seb128> danigm, what do you mean there?
[09:35] <seb128> danigm, you want to package a new version for maverick or for yourself?
[09:35] <seb128> danigm, which version?
[09:35] <danigm> both
[09:35] <danigm> 0.14
[09:35] <danigm> I want to package 0.14 for maverick and then I have a "unofficial" patch to add to my own package
[09:36] <danigm> and then make a backport for guadalinexV6 (ubuntu jaunty)
[09:36] <danigm> I see that there is a lp:ubuntu/poppler and a lp:poppler
[09:37] <seb128> danigm, you can get the new poppler without new cairo
[09:37] <seb128> danigm, lp:poppler is an upstream import
[09:37] <seb128> danigm, lp:ubuntu/poppler is the ubuntu package, you want to use that to base your changes
[09:37] <danigm> seb128: yep, and there's my question, what's the correct way to merge the package and the upstream?
[09:38] <seb128> danigm, we don't want cairo 1.9 though
[09:38] <seb128> danigm, so no new poppler for now
[09:39] <seb128> danigm, I'm not sure about autoimports, I usually apt-get source poppler to work on it and copy the debian dir over to the new tarball
[09:39] <seb128> danigm, then dch -v version and work there
[09:39] <danigm> seb128: ah, ok
[09:40] <danigm> seb128: then that's what I'll do
[09:40] <seb128> you can probably bzr merge-upstream tarball in the import
[09:40] <seb128> danigm, but as said don't bother for maverick the poppler update require an unstable cairo
[09:40] <seb128> danigm, and cairo is stalling for a while, they should have got 1.9 stable in january and it didn't move since
=== Amto`Off is now known as Amto_res
[11:48]  * ogra wonders if Keybuk is on vacation
[11:50] <seb128> ogra: you have access to a calendar with those infos
[11:50] <seb128> ogra: the said calendar says he is
[11:50] <ogra> i do ?
[11:52] <cjwatson> pitti: random thought - would it be worth looking at generating /usr/lib/locale/locale-archive?  it takes the syscall count of executing a trivial program (/bin/true) from 100 to 34
[11:52] <pitti> cjwatson: I think we can; it'll increase the time to build/remove locales, but that's rather insignificant
[11:53] <pitti> cjwatson: I actually did some boot charts with locale-archive, but I didn't get any measurable difference
[11:53] <cjwatson> locale build time is a bit of a concern on low-memory systems because localedef is so memory-hungry
[11:53] <pitti> shoudl just be a matter of setting ARCHIVE=yes in /usr/sbin/locale-gen
[11:54] <cjwatson> what sort of increase are we talking about?  just running 'localedef --add-to-archive /usr/lib/locale/*' doesn't seem to take too long here
[11:54] <pitti> and cleaning up the unarchived ones in postinst
[11:54] <cjwatson> I was wondering if there were compatibility implications; I seem to recall the odd bug when the broken-out dirs were missing
[11:54] <pitti> cjwatson: ah, good; removing a locale used to require rebuilding all other ones, but as I said that should not be a common use case
[11:55] <pitti> cjwatson: I have that running in a VM for some days, but I didn't test it extensively; just standard desktop bits
[11:55] <pitti> cjwatson: so perhaps we should switch it early in maverick for testing?
[11:55] <cjwatson> --delete-from-archive seems to take negligible time
[11:56] <pitti> cool
[11:56] <pitti> seems that didn't exist back then (in belocs age)
[11:56] <cjwatson> I suspect it doesn't make a huge boot difference because everything is LANG=C
[11:56] <cjwatson> it's only once you reach a session that it starts making any difference at all
[11:56] <pitti> the desktop bits do use the locale, though
[11:56] <pitti> right
[11:57] <pitti> and I didn't notice any difference there
[11:57] <cjwatson> should we have *only* locale-archive, or the broken-out dirs as well?
[11:57] <pitti> but still, it's fewer syscalls
[11:57] <pitti> cjwatson: they do take a nontrivial amount of space, so I'd vote for either-or, not both
[11:57] <pitti> Debian has used locale-archive only forever, I think
[11:58] <pitti> (and Fedora, too)
[12:00] <cjwatson> ok, if you're comfortable with either-or then I am too
[12:01] <cjwatson> shall I file a bug somewhere?
[12:06] <pitti> cjwatson: against langpack-locales, I guess
[12:07] <cjwatson> shall I just paste this conversation?
[12:07] <pitti> sure
[12:07] <pitti> I don't know whether I'll have time to implement logic to use --delete-from-archive (since I only have limited time this cycle), but using archive in general sounds easy
[12:08] <cjwatson> done, bug 591676
[12:08] <ubottu> Launchpad bug 591676 in langpack-locales (Ubuntu) "switch locale-gen to ARCHIVE=yes" [Undecided,New] https://launchpad.net/bugs/591676
[12:08] <cjwatson> if you need me to do part of it then feel free to lob it over
[12:09] <pitti> ok, thanks
=== MacSlow is now known as MacSlow|lunch
[12:41] <didrocks> cjwatson: hey, did you apply the same changes from the desktop seed to the netbook seed (seeing one of your commit on 2010-06-01) or should I check?
[12:44] <cjwatson> didrocks: I don't remember - probably best to check
[12:44] <didrocks> cjwatson: ok, thanks, I will :)
[12:51] <ItalicBold> hi all, I heard sysv init is being replaced by another method in the future with ubuntu, can anyone advise what this is so i can look it up further?
[12:53] <stanley_robertso> hi all
[12:53] <stanley_robertso> iam new to this ubuntu stuff and going through the ubuntu wiki page
[12:53] <stanley_robertso> Want to contribute as a developer.... Any suggestions/pointers in that direction would be of great help
[12:54] <micahg> stanley_robertso: have you seen this wiki page: https://wiki.ubuntu.com/UbuntuDevelopment/
[13:02] <apw> ItalicBold, that sounds like upstart
[13:13] <ItalicBold> apw: ta
=== MacSlow|lunch is now known as MacSlow
[13:26] <stanley_robertso> yes micahg .. iwent through it.. but could not get a sgtarting point
[13:27] <stanley_robertso> *starting
[13:29] <didrocks> pitti: can I refresh a lucid metapackage from a maverick machine? Don't know how germinate works on that kind of setup
[13:36] <micahg> stanley_robertso: you can fix bugs and/or work on build failures
[13:37] <pitti> didrocks: sure, it downloads everything it needs by itself
[13:38] <pitti> didrocks: there's a .cfg file which defines the release
[13:38] <didrocks> pitti: ok, I was wondering about checking packages that are in main and so on depending on the apt cache, but it's done in a smart way, sweet :)
[13:38] <didrocks> pitti: thanks
[13:39] <pitti> didrocks: yes, it downloads all seed branches and Packages.gz indexes by itself
[13:40] <didrocks> pitti: that seems… way safer than relying on something local, thanks for the anwser, better to ask before regretting :-)
[13:47]  * popey wonders if cjwatson could please let my mail to ubuntu-devel mailing list through
=== txwikinger2 is now known as txwikinger
[14:39] <pitti> didrocks: why do we need bug 588723 in netbook-meta as well? the bug just talks about ubuntu
[14:39] <ubottu> Launchpad bug 588723 in ubuntu-meta (Ubuntu Lucid) "kubuntu-desktop / kubuntu-netbook / ubuntu-netbook should Depends ttf-liberation due to poor font fallback otherwise" [Undecided,Triaged] https://launchpad.net/bugs/588723
[14:40] <didrocks> pitti: it's already fixed in ubuntu-meta, I guess the report was for netbook-meta
[14:40] <didrocks> changing affected package
[14:40] <pitti> ah, indeed; but still, pointing out why it's necessary for netbook would be nice
[14:41] <pitti> or giving a test case why/where the current one looks bad
[14:41] <pitti> didrocks: mind that the first point release will need to fit into a CD image again
[14:41] <didrocks> pitti: it's ccheney who pinged about this issue, I think he's more aware about a real testcase than I
[14:41] <didrocks> pitti: yeah, I'll have a look at CD size then, that's why I'm doing that now
[14:42] <didrocks> ccheney: if you can provide a testcase, that will be good
[14:43] <cjwatson> popey: done
[14:47] <popey> cjwatson: thanks
=== alessio is now known as `Alessio`
=== `Alessio` is now known as quadrispro
=== sconklin-gone is now known as sconklin
=== jtechidna is now known as JontheEchidna
[15:15] <didrocks> pitti: I'll soon have a document using a New Times Roman font for testing if the ttf-liberation font is rendering it better than the default. If you do an apt-cache show ttf-liberation, you will see that this package is included in almost all seed already
=== bjf[afk] is now known as bjf
[15:31] <pitti> didrocks: right, noted
[15:39] <didrocks> pitti: ok, added a testcase
[15:52] <mpt> kees, hi
[15:53] <kees> hello mpt
[15:54] <mpt> kees, that grep of the archive you did for gtk_status_icon, could you please do the same for use of either KSystemTrayIcon or QSystemTrayIcon?
[15:54] <mpt> kees, I guess you could make it much quicker by looking only in packages that depend on Qt
[15:55] <kees> mpt: sure; which packae specifically would indicate a qt dep?
=== jtechidna is now known as JontheEchidna
[15:57] <JontheEchidna> kees: libqtgui4, since qsystemtrayicon is in the QtGui module
[15:58] <mpt> kees, either libqtgui4 or kdelibs5 [sic]
[15:59] <JontheEchidna> ^in maverick kdelibs5 was split up, and the appropriate kde library is now libkdeui5
[16:00] <seb128> kees, so it's SystemTrayIcon in rdepends for libkdeui5 and libqtgui4 I guess
[16:00] <kees> JontheEchidna, mpt: cool. i'll get it kicked off
[16:00] <seb128> kees, thanks
[16:00] <mpt> thanks kees
[16:00] <kees> seb128: no problem
[16:04] <mpt> and thanks JontheEchidna :-)
[16:07] <JontheEchidna> yup, no prob
[16:19] <agutierr> hello, someone usings 10.04 preseeds?
[16:20] <agutierr> Is there any way to see packages sources during ubuntu install (on busybox)?
=== DrPepperKid is now known as MacSlow
[16:34] <ccheney> didrocks: hi
[16:34] <didrocks> ccheney: hey
[16:35] <didrocks> ccheney: I've added info on the bug report concerning the ttf-liberation font, do not hesitate to correct it :)
[16:35] <ccheney> didrocks: ok will take a look
[16:35] <didrocks> ccheney: thanks
[16:36] <ccheney> didrocks: yea your comment looks correct
[16:36] <didrocks> ccheney: sweet, thanks
[16:37] <ccheney> didrocks: i think this would occur with pdf viewing as well, so not just in the OOo case
[16:37] <ccheney> didrocks: at least for pdf's where the fonts aren't embedded
[16:37] <didrocks> ccheney: can you add a comment about that?
[16:39] <ccheney> didrocks: ok just followed up
[16:40] <didrocks> ccheney: seems fine, thanks
[16:40] <nigelb> Is there a way to know if a package has an apport hook without installing or looking into the source?
[16:40] <pitti> nigelb: check file list on packages.u.c.?
[16:41] <nigelb> pitti: err file list? or dependency list?
[16:41] <pitti> nigelb: file list (/usr/share/apport/package-hooks/*)
[16:41] <pitti> it's got nothing to do with dependencies
[16:43] <nigelb> pitti: I'll tell you my problem.  I hvae a list of 1000 packages in descending order of number of bugs filed, I have to filter them for pckages wihtout apport hook so I can lead an activity on writing the hooks.  Any easy way to do the entire thing in one go?
[16:43] <nigelb> (number of bugs filed for each month - I have data for 2 months)
[16:44] <pitti> nigelb: http://archive.ubuntu.com/ubuntu/dists/maverick/Contents-i386.gz is your friend, I think
[16:44] <pitti> you can grep it for ^usr/share/apport-package-hooks/.*/$PKGNAME$
[16:45] <nigelb> oh, yay!
[16:45] <pitti> nigelb: caveat: those are binary package names, not source
[16:45] <pitti> but with some grep-dctrl magic this is easy to map
[16:46] <nigelb> pitti: ok, I'm going to have to do a lot of work, but still worth if you ask me.  Better than apt-get x1000
[16:46] <nigelb> Thank You!
[16:47] <pitti> yep, Contents.gz gets the heavy lifting
[16:47] <pitti> nigelb: I'd suggest to write a script which wgets contents.gz and all Packages.gz, and iterate over all Package: to check if it's got an apport hook
[16:48] <pitti> nigelb: then this can spit out a list of packages without hooks, and you could even cron that somewhere
[16:48] <pitti> nigelb: but you certainly don't want to look at 1000 packages?
[16:48] <jpds> I suggest downloading said files off the user's mirror in sources.list to balance out the load.
[16:49] <pitti> seems like adding sensible and well thought-out package hooks to the top ten is better than adding minimal ones to 50 just to make the stats look better?
[16:49] <nigelb> pitti: I'm not sure how to go about all that you've said, but one step at a time.  when I get stuck I'll ask here.  I'm sure someone will know
[16:49] <nigelb> Yes, I'll probably only look at ones with 30+ bugs
[16:49]  * pitti dinner &
[16:50] <SpamapS> anybody know what the policy would be on a package that contains a sources.list.d file pointing to a set of "blessed" PPA's? Would such a thing ever be acceptable in main?
[16:50] <nigelb> oh, wait.  I have to hug brian.  He got it sorted on the list he gave me :)
[16:54] <ScottK> SpamapS: No.
[16:54] <ScottK> SpamapS: Such a thing did get through once and it got reverted before release.
[16:56] <SpamapS> ScottK: how are the updates to things like mozilla being done?
[16:57] <ScottK> SpamapS: In the normal -updates or -security pockets.
[16:57] <SpamapS> ScottK: ah. We're trying to figure out how to keep up with projects like Cassandra and Hadoop on the server side, where the upstreams are releasing and deprecating old releases faster than 6 months.
[16:58] <ScottK> SpamapS: You need an exception from the tech board for this.
[16:58] <cjwatson> mvo: would it be useful for --print-uris to print URIs useful for other applications, rather than mirror:// URIs which can only be understood by apt?
[16:59] <SpamapS> ScottK: yeah I think we're trying to make sure we gather enough information to ask for something reasonable once we know what we want. :)
[16:59] <mvo> cjwatson: yes, absolutely
[17:00] <cjwatson> want a bug?
[17:00] <mvo> a bug is fine, otherwise I will just make a note
[17:05] <ScottK> SpamapS: https://wiki.ubuntu.com/ClamavUpdates is an example of one that got approved.
[17:08] <SpamapS> ScottK: That makes sense. :) I'm hesitant to relate this issue to clamav though. For instance, Cassandra (a distributed database engine) releases binaries at almost the same clip (4-6 times per year), the software itself is far less useful for most users.. so I am not sure its worth as much attention as clamav warrants.
[17:09] <SpamapS> s/binaries/major releases/
[17:09] <ScottK> SpamapS: You'd have to have your own rationale.
[17:09] <ScottK> I provide the example to give you an idea of the type of documentation needed.
[17:09] <ScottK> Particularly the issues around package qualification and testing.
[17:10] <SpamapS> ScottK: at this point, I think its just going to have to be a team-hosted PPA that people can trust.
[17:10] <SpamapS> ScottK: I really do appreciate the example. :)
=== beuno is now known as beuno-lunch
=== yofel_ is now known as yofel
=== deryck is now known as deryck[lunch]
[18:09] <kees> seb128: http://people.canonical.com/~kees/search-qt-systemtray.txt
[18:09] <seb128> jcastro, ^
[18:09] <seb128> kees, thanks!
[18:09] <kees> seb128: welcome!
[18:09] <kees> 108 hits fwiw
[18:12] <jcastro> ta!
=== beuno-lunch is now known as beuno
[18:26] <kees> where do the stdout and stderr of upstart jobs go?
[18:32] <cjwatson> kees: man 5 init /console
[18:33] <cjwatson> (so by default, /dev/null)
[18:33] <kees> cjwatson: well that's kinda suboptimal.  it should go somewhere in /var/log
=== odyi_ is now known as odyi
[18:33] <cjwatson> plymouth, perhaps
[18:34] <kees> plymouth stops running after a certain point.
[18:35] <cjwatson> mm
=== odyi is now known as ody
=== ody is now known as odyi
[18:35] <cjwatson> still, it should tie into that while plymouth is running
[18:37] <kees> sure, that's fine by me, but I'd like to be able to find my stdout/stderr somewhere.  perhaps if I run "start" from a command line it could go there...
=== deryck[lunch] is now known as deryck
[18:58] <saycheeze> any of you guys not AFK? haha
[19:01] <saycheeze> damn, guess not
[19:02] <CynthiaG> saycheeze: hi
[19:02] <saycheeze> ahh Hi, Cynthia! How are you?
[19:02] <CynthiaG> If you have a question to ask, don't ask if you can ask it; just do :)
[19:02] <saycheeze> haha Well I do!
[19:02] <saycheeze> This thread I posted yesterday pretty much sums it up.. http://ubuntuforums.org/showpost.php?p=9432432&postcount=1
[19:03] <CynthiaG> not so bad, not so good; I'm trying to understand what "make a unit test, but don't make a test file" means, for a program that has image rendering as its test
[19:03] <saycheeze> I just wanted to get some answers straight for the source
[19:03] <saycheeze> haha I hear ya. Well, at least you're alive I guess! :)
[19:04] <Chipzz> saycheeze: /join #ubuntu-server I would say
[19:04] <CynthiaG> well, I'm not a real Ubuntu developer, like a core developer, so I can't answer your calling out about your experience
[19:05] <saycheeze> Thanks guys. I've read through the Wiki stuff but I'm wanting to actually talk it out with someone
[19:05] <Chipzz> kees: I wonder if having it go to a file even makes sense (in a way)
[19:05] <saycheeze> I'll stick around here but I'm about to join the server channel as well
[19:06] <Chipzz> kees: since upstart jobs run in parallel, you would need some kind of mechanism to order the output
[19:06] <CynthiaG> however, what you can do is hang out around here and answer requests for packaging, handle bugs with patches available to review on Launchpad (those bugs have patch files in them, or the tag 'patch'), have several USB drives and CD-Rewritables ready for testing ISOs and USB images of Ubuntu builds, have a few computers ready or one beefy computer + VMs to test bugs
[19:07] <Chipzz> or you might end up with half lines of process' A output intermangled with lines of process' B output
[19:07] <saycheeze> Ahh gotcha. Yep, I've got a few PCs I can use and VMWare running on 3 boxes so that shouldn't be an issue
[19:07] <CynthiaG> Some bugs are hardware-specific, like the Broadcom wireless bugs and modemmanager + Huawei modems cropping up recently, so you might not be able to test everything, but that's what the rest of the community is for
[19:08] <saycheeze> Yeah, I gotcha. Alright, well that's a good start! haha
[19:13] <ogasawara> superm1: wanted to get your comments on a kernel patch of yours we've been carrying.  do you prefer I use your @dell.com or @ubuntu.com email address?
[19:14] <superm1> ogasawara, i have a feeling i know what patch you're referring to, @dell.com is better
[19:14] <CynthiaG> [me @ saycheeze]+  You also said you would need to get up to speed on open source development; here are some tools you need: 'patch' (man patch, look at tutorials of the patch tool), 'bzr' (#bzr, #launchpad on this network), 'git', 'svn', a text editor (you should be familiar with that), and getting familiar with how bug trackers work, Ubuntu being based on Debian you'll need to know how to forward bugs to Debian etc. And finally there's #ubuntu-packag
[19:14] <CynthiaG> ing
[19:14] <CynthiaG> + sorry, truncated. #ubuntu-packaging
[19:15] <smoser> james_w, or anyone, have an idea how i could convert something (cloud-init) that was not a native package into a native package ?
[19:16] <saycheeze> Ahh gotcha. Yep, I went ahead and grabbed everything yesterday. Thanks! I'm just trying to figure out where to start after that, ya know?
[19:18] <ScottK> smoser: What are you trying to do that?
[19:18] <CynthiaG> Start by triaging bugs on Launchpad, testing them out, seeing if they occur on your systems, trying to find out why. The natural next step will be to delve into the code to see what's doing it. While you may not be able to change the code like you want at first, you'll get valuable experience in reading others' code. Then you can package patches, and finally be a coder yourself. The steps in-between are kinda cloudy to me. :)
[19:18] <smoser> ScottK, because i'm the upstream developer and I don't see a lot of value in maintaining a release tarballs and separate debian packaging branch.
[19:19] <saycheeze> Haha It's all a bit cloudy to me ATM, but I think it's starting to get a little bit clearer
[19:19] <ScottK> smoser: So every time you change something in the packaging you're good with doing a new upstream release?
[19:19] <kees> Chipzz: right, that's what plymouth should be doing.  but without plymouth, it should still go *somewhere*
[19:19] <kees> I will bug Keybuk about it :)
[19:21] <saycheeze> I'm going to check out the documentation and everything one more time, I'll stop back by in a bit. Thanks for the help Cynthia.
[19:21] <smoser> ScottK, i'm not sure i understand.  I basically dont see a reason to make upstream releases. at this point the package is sufficiently ubuntu specific (dependent on certain boot characteristics).
[19:21] <CynthiaG> You're welcome, and thanks in advance for the help you're going to be providing to Ubuntu :)
[19:23] <ScottK> smoser: With a native package there's no distinction between upstream and Ubuntu releases, whereas with non-native you can have revisions of upstream releases separately.  Unless the package will only ever be useful on Ubuntu, it's probably better to leave it non-native.
[19:23] <saycheeze> My pleasure!
[19:23] <ScottK> If you want to make it native, make a new version with no "-" in the version number.
=== asac_ is now known as asac
[19:30] <smoser> i'm generally aware of what a native package is. i was only wondering if there was any bzr magic that i would have to revert due to previous use of merge-upstream
[19:32] <ScottK> No idea about the bzr implications.
[19:32] <ScottK> For the packaging bit, you just need to not have a dash in the version.
=== sconklin is now known as sconklin-lunch
=== al-maisan is now known as almaisan-away
[21:10] <kees> oh, neat.  "dpkg-dev provides a new script called dpkg-mergechangelogs"
[21:11] <kees> double-neat.  "dpkg-dev provides a new script called dpkg-buildflags"
=== dendro-afk is now known as dendrobates
=== sconklin-lunch is now known as sconklin
[22:35] <slangasek> kees: yep, now we just need dpkg-mergechangelogs integrated into bzr-builddeb :)
[22:37] <ajmitch> it certainly helps in doing those merges without using bzr
=== dendrobates is now known as dendro-afk
[22:43] <jcolei64> lamont: hello sir... im looking for a packages.ubuntu.com for ia64.. does that exist?
[22:43] <offy> I'm working on modifying gnome-terminal 2.3 but I can't find where the username@host file is
[22:45] <CynthiaG> offy: you mean the file in which the prompt is set to username@host? the file defining the username? or the file defining the host?
[22:45] <offy> prompt
[22:45] <cjwatson> jcolei64: there's a contact address at the bottom of http://packages.ubuntu.com/
[22:45] <CynthiaG> offy: that's in .bashrc, the line setting PS1=
[22:46] <cjwatson> or /etc/profile
[22:46] <CynthiaG> or you may want to look in the process' environment from within gnome-terminal and grab the value of PS1
[22:46] <CynthiaG> but I don't know about how reliable that is
[22:47] <offy> well, i'm trying to add a string to display infront of the prompt
[22:48] <offy> oh, .bashrc can do that
[22:48] <offy> Thank you
[22:49] <jcolei64> cjwatson: well, im looking to see if ubuntu ports has a searchable package database via web (similar to packages.ubuntu.com)
[22:51] <cjwatson> jcolei64: https://launchpad.net/ubuntu/
[22:51] <cjwatson> not the same interface, but it should have pretty much all the information, aside from maybe Contents files searching
[22:51] <cjwatson> jcolei64: anyway, what I'm saying is that if you want packages.ubuntu.com to work for ports, it's probably just a matter of mailing the contact address at the bottom of its front page
[22:55] <jcolei64> cjwatson: thanks.. for example, im looking to see which ubuntu releases have qemu for ia64 (and the qemu versions)
=== bjf is now known as bjf[afk]
[23:23] <olmari> hello... I know mine opinion won't propably weigh much but I'd still like to say...
[23:24] <olmari> that please, no CSD... that's in essential
[23:25] <olmari> instead focus on improving window decorator and/or manager to make it happend what is meant to be done with CSD
[23:25] <olmari> this is just an (advanced??) user opinion, but still...
[23:27] <olmari> afaik CSD isn't something that REALLY would be the answer.. it's rather circumventing the issues of GTK and/or rest of the subsystem flaws...
[23:30] <olmari> now otherwise I am not by any means undermining general ubuntu development, but with Client Side Decoration I really think it's not right direction
[23:40] <olmari> so... please take a note from mine humble opinion too :)
[23:43] <CynthiaG> I'm not really an Ubuntu dev, but I can see the bad things that having each application draw its own decorations would give. Mainly, each application developer would be reinventing the wheel, possibly hindering localisation (by e.g. not supporting multi-byte characters or UTF-8 in the decorations) along the way
[23:47] <olmari> CynthiaG: indeed... and more generally, I think CSD would be circumventing flaws of backend by bad way..
[23:48] <gord> CynthiaG, thats not how CSD works. all the decoration drawing is still handled globally, but instead of metacity or compiz or mutter drawing the window decoration, its drawn in the gtk window
[23:48] <CynthiaG> I thought CSD was akin to how programs in Windows can draw their own title bar if they're not happy with what Windows gives them
[23:48] <olmari> gord: but is it still a GOOD way to do things?
[23:49] <gord> CynthiaG, they can if they want, chromium will prolly end up doing that. but 99.9999% of apps won't
[23:49] <CynthiaG> gord, true
[23:50] <gord> olmari, yup, it is :) lots of benefits and it lets window managers concentrate on what they should be doing, ala: managing the windows. rather than having to do trivial things like draw pretty things on the screen
[23:50] <james_w> smoser: you can set the config to be explicit that it is native.
[23:50] <james_w> echo -e '[BUILDDEB]\nnative = True' > .bzr-builddeb/default.conf
[23:51] <olmari> gord: but does it work on every "place"?
[23:54] <gord> no new tech works flawlessly from the get-go olmari, that is why bug reports and patches are so vital. there is a lot of time left to get it right
[23:55] <olmari> gord: I'm still not sure that CSD is the real way to go... but I'm all in for 'turnaround' :p