[02:30] <ccheney> anyone know of a cli tool that can inspect pdfs for what fonts are inside, etc. i remember there being one but can't remember what it is called
[03:23] <psusi> seriously, what the hell is gcc smoking?   warning: function declaration isn’t a prototype... a prototype is EXACTLY what a function declaration is...
[04:00] <temugen> 1
[04:01] <temugen> psusi: What was the actual problem?
[04:01] <temugen> that's not all that uncommon for gcc error messages :P
[04:02] <psusi> the problem is that it's complaining about yes being true ;)
[04:03] <psusi> well, DUHHHHHH ;)
[04:04] <temugen> ah, just a warning message. nice.
[04:05] <psusi> yes, but it's warning me about water being wet
[04:05] <psusi> and saying that it ISN'T wet, when of course it is
[04:05] <xnox> I've had a similar thing and it went away when i did define POSIX
[04:06] <xnox> (long time ago can't remember exact semantics but it was with gcc4.5 snapshot)
[05:25] <SmSpillaz> didrocks: ping
[05:27] <nigelb> SmSpillaz: It may take a bit for him to respond.  He's somewhere in EU
[05:28] <RAOF> He usually turns up ~3 hours from now.
[05:29] <Kaleo> nigelb: he is in France actually
[05:30] <nigelb> yea, fits the 'somewhere in eu' ;)
[05:30] <Kaleo> :)
[05:31] <SmSpillaz> nigelb: ah right
[05:31] <SmSpillaz> well, I'll be around during EU working hours then
[05:31] <SmSpillaz> half of our developers are in the EU :p
[06:34] <ekoontz> anyone worked with graphviz?
[07:42] <hunger> Which gcc version will maverick use? I read this was going to get decided at UDS but did not find any updates yet.
[07:46] <pitti> Good morning
[07:48] <hunger> morning!
[07:49] <RAOF> hunger: I believe the answer is 4.5, but don't quote me on that.
[07:49] <RAOF> Morning, pitti!
[07:50] <hunger> RAOF: Thanks. cpp is still depending on 4.4 though, so maybe not. I'll wait and see.
[07:51] <pitti> hey RAOF, how are you?
[07:51] <RAOF> Thankful that it's the weekend ):
[07:51] <RAOF> :)
[07:53] <RAOF> I've not *quite* managed to recover from UDS yet.  The weekend will allow this.
[07:53] <pitti> RAOF: still jetlagged
[07:53] <pitti> ?
[07:54] <RAOF> No, just a bit sick.
[07:55] <RAOF> The cold weather here hasn't helped much :/
[08:05] <didrocks> SmSpillaz: yes? (can you please provide the question in the hilight instead of just "ping"?) thanks :)
[08:40] <SmSpillaz> didrocks: oh ok, sorry (ping pong, then talk is the way I'm used to :p)
[08:40] <didrocks> SmSpillaz: no pb, what's up? :)
[08:42] <SmSpillaz> didrocks: anyways, question was: in src/window.vala:toggle_window_picker () (for unity) do you think we can put instead of a debug message, something like the vala Xlib bindings equavilent of XInternAtom ("_UNITY_TOGGLE_EXPOSE", true); and XChangeWindowProperty (display, rootwindow, atom, l[1] = false/true) or something of the like?
[08:43] <SmSpillaz> that way other window managers like compiz and kwin can just read that property through a plugin (like we do for kde already) and toggle the expose mode for people who use compiz with unity
[08:43] <SmSpillaz> I can write a patch if you want
[08:45] <didrocks> SmSpillaz: not sure if toggle_window_picker doesn't do other checks that the Xlib call doesn't have. In any case, you should ping njpatel next week (he isn't there this week) about it
[08:46] <didrocks> SmSpillaz: think also that mutter is used to render the whole unity environment (upanel and launcher), not sure how you want to do that with other WM
[08:47] <SmSpillaz> didrocks: it doesn't
[08:47] <SmSpillaz> didrocks: I'm not particularly sure how it works, but I can use compiz with the unity shell
[08:48] <didrocks> SmSpillaz: hum, so, you have mutter launch, rendering unity by the libunity mutter plugin, and then run compiz in it? tricky :)
[08:50] <SmSpillaz> afaict (from a quick code once-over) is that the mutter plugin and the unity shell both import libunity and the mutter Unity.global_shell.toggle_window_picker method overload the one in libunity which was originally in window.vala
[08:50] <SmSpillaz> oh and also afaict by testing, I think unity-launcher automatically launches mutter, but you can kill mutter and launch compiz
[08:51] <didrocks> SmSpillaz: ok, I didn't have the time to check that part, only the big picture, if it works this way, that's great ;)
[08:51] <didrocks> SmSpillaz: but again, njpatel is the man to ping about that
[08:51] <SmSpillaz> didrocks: ok - hopefully njpatel will be good with patches to add that atom set/unset so it can work with other wm's :)
[08:52] <didrocks> SmSpillaz: if he does that, I'll update the packaging too :)
[08:54] <nigelb> pitti: how to get the output of 'lspci -k | grep -A2 VGA' with command_output.  most of what I try is failing :(
[08:57] <ddecator> didrocks: so far i'm getting glxinfo, dkms status (displays details on graphics driver, thought it might help), and nigel and i are trying to find a way to reduce the lspci -k output to just the video card. anything else you can think of off-hand that might be helpful for clutter?
[08:58] <didrocks> ddecator: I think that's already a lot in addition to attach_hardwaredinfo() (not sure about the spelling). We will see later if we need other info
[08:59] <ddecator> didrocks: i actually took off attach_hardware because i thought it might be overkill, but i can add it back in if you want
[09:00] <didrocks> ddecator: I think it's still good if you can add the specific commands first.
[09:00] <RAOF> ddecator: report['PciDisplay'] = pci_devices(PCI_DISPLAY)
[09:01] <ddecator> RAOF: yah, wasn't sure if that would be useful or not, but i'll add that as well
[09:01] <nigelb> RAOF: ah, forgot about that one ;)
[09:01] <RAOF> ddecator: That's how to get just the lspci info for the display :)
[09:02] <ddecator> oh, does it? o.o
[09:03] <RAOF>  /usr/share/apport/package-hooks/xserver-xorg-core.py - it contains all of that stuff, just waiting for you :)
[09:03] <ddecator> RAOF: ah, perfect, thanks :)
[09:03] <ddecator> RAOF: yah, that's what i've been looking at, but didn't know what pci_devices gave as output :p
[09:04] <AnAnt> Hello, is notify-osd going to be dropped in meerkat ?
[09:04] <RAOF> ddecator: That's why you use “ubuntu-bug xorg” to file a test bug on staging :)
[09:04] <ddecator> RAOF: yah, probably should, i've just been using that to file bugs to test my hooks on staging :p
[09:40] <pitti> nigelb: command_output does not take a shell command, just a normal argv
[09:40] <pitti> nigelb: you can run ['sh', '-c', 'lspci -k | grep -A2 VGA'] if you want, or do the searching in python
[09:42] <nigelb> pitti: hm, ok. ah, searching in python should be better :)
[09:42] <nigelb> Thank You!
[09:42] <pitti> np :)
[10:15] <Daviey> ping slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner: Letting you know of an upload to hardy-proposed fails verification: bug #455873.
[10:15] <AnAnt> Hello ?
[10:16] <mdz> Daviey: acknowledged, looking
[10:16] <cjwatson> hm, the documentation in StableReleaseUpdates seems overkill to me
[10:16] <cjwatson> I don't think we need to be alerted about regressions that are only in -proposed, not -updates
[10:17] <cjwatson> I wonder if this is wiki drift due to refactoring - I don't remember that it used to say that
[10:18] <mdz> cjwatson: I remember it saying that, and thinking it was a bit conservative. I think the rationale had to do with encouraging lots more people to run -proposed, and therefore taking regressions more seriously
[10:18] <cjwatson> that said, this is not a regression specific to hardy-proposed - the diff doesn't mention dpkg-statoverride anywhere
[10:18] <cjwatson> nor does it touch maintainer scripts at all
[10:19]  * Daviey is still wetting himself :)
[10:20] <cjwatson> in fact the hardy -> hardy-proposed diff doesn't mention statoverride either
[10:21] <cjwatson> looks like that code should be cut -d' ' -f3
[10:22] <cjwatson> from the looks of it, it only affects people who've manually set statoverrides
[10:23] <cjwatson> maverick is unaffected
[10:23]  * cjwatson bisect
[10:23] <cjwatson> s
[10:28] <cjwatson> fixed by removal of the broken code in karmic (specifically, Debian package version 2.2.12-1, Debian svn r995).  However, the code in question is for upgrades from apache 2.0 -> 2.2, and dapper had 2.0, so we need to fix it rather than remove it.
[10:28] <cjwatson> therefore I suggest a new -proposed upload adding -d' ' after cut.
[10:28]  * cjwatson goes to summarise in the bug
[10:29] <Daviey> cjwatson: thanks
[10:32] <soren> t/away
[10:32] <soren> Whoops :)
[10:34] <cjwatson> I've also reset the SRU bug in question to verification-needed, based on my analysis
[10:34] <cjwatson> Daviey: thanks for raising this quickly
[10:37] <Daviey> cjwatson: np.. I'm glad i can relax a bit :).  Are you suggesting it could just be a case of adding a ->-d' '<- ?
[10:37] <cjwatson> yes
[10:38] <cjwatson> cut splits fields on tabs by default, but dpkg-statoverride outputs fields separated by spaces
[10:38] <cjwatson> the code was apparently never tested (so I feel relatively safe in saying it's rare, but we should still fix it)
[10:39] <Daviey> cjwatson: wilco, thanks.
[11:13] <pitti> cjwatson: so, xorg-server depends on video-all | video-6, the latter is provided by all video drivers; if I seed e. g. -fbdev explicitly, -fbdev should get the corresponding Task: header and due to how task selection works (as discussed yesterday), video-all should not get installed
[11:13] <pitti> cjwatson: did I understand this correctly?
[11:15] <cjwatson> pitti: I would expect so
[11:15] <pitti> ok, thanks; then I know why it's not working (Task: header is missing)
[12:11] <geser> could a core-dev please give-back "gir-repository". It FTBFS because it couldn't detect libsoup (the logs doesn't mention why) but it build fine in my pbuilder now (and libsoup got detected). Thanks.
[12:11] <pitti> geser: doing, thanks
[12:20] <pitti> geser: ah, failed to upload, it needs gir1.0-gtk-2.0_0.6.5-6_i386.deb removed
[12:20] <lifeless> ev: hey, curious why you need to shut slaves down
[12:21] <ev> lifeless: thanks for the quick response.  My master plan is roughly: https://wiki.ubuntu.com/FoundationsTeam/Specs/SharingTestingInfrastructure#Implementation
[12:21] <pitti> geser: seems we're still ahead of debian there; http://launchpadlibrarian.net/44773564/gir-repository_0.6.5-5ubuntu1_0.6.5-5ubuntu2.diff.gz needs to be reapplied apparently
[12:22] <lifeless> \o/ code I wrote :P
[12:22] <geser> pitti: saw it, will prepare it for upload.
[12:22] <pitti> geser: cheers!
[12:22] <ev> lifeless: I'm debating if that's really necessary, and if I can get away with just leaving the live environment running and carefully cleaning up after each run of the installer.
[12:23] <lifeless> by live environment, you mean the pxe boot ?
[12:23] <ev> indeed
[12:24] <lifeless> so a couple of thoughts
[12:24] <lifeless> have a look at my platform node labeller plugin
[12:24] <Redache> .1
[12:24] <lifeless> 'platformlabeler' in plugins/
[12:25] <ev> will do
[12:25] <lifeless> you could tie the jobs to the builds inside the PXE environment with alabel
[12:25] <lifeless> using a plugin like platformlabeler to set an appropriate label when the slave comes up
[12:25] <lifeless> and if you listen to jobs *finishing*, removing the label after the test on it.
[12:26] <lifeless> or perhaps more simply, just reboot the darn slave to the ready-to-start mode after the job running on the pxe-booted mode completes.
[12:26] <lifeless> though you'd want to test/time that finely to make sure another job didn't start - I kind of like the idea of removing the label before another job can be scheduled.
[12:27] <lifeless> there are a lot of parallels with this and a cloud environment too, except that you don't want to run arbitrary tests on a node, just the latest sikuli stuff
[12:28] <lifeless> possibly worth sketching it out on the list - kohusake is very smart and knows the scope of hudson really well (apologies if you did this on the -user list -> I'm not on that one)
[12:28] <ev> the problem I've had with labels is that they're a "select one from this set" operation rather than a "give me everything", the latter of which I'd prefer for the ability to run across multiple machines in the datacenter to find hardware specific issues
[12:29] <ev> that is, I haven't found a way to target a job to a label and have it run on every slave in that label
[12:30] <ev> noted on elaborating more on what I'm trying to do on the list, and no, I didn't post to -user first.
[12:30] <lifeless> matrix build
[12:31] <lifeless> theres also a dude posted to the list in the last week about running a job on every element of a label
[12:31] <ev> oh cool, I'll dig that up
[12:31] <lifeless> but definitely check out the matrix build plugin if you haven't
[12:32] <lifeless> it may not be -quite- what you want, but its close - and his change is probably right on the money
[12:32] <ev> I have -- when I selected the label it only went to the first node.  Looking on the list showed a mail confirming that behavior as by design, but I've long since lost the URL.
[12:32] <lifeless> I wish I'd gotten to your session @ UDS :)
[12:33] <ev> lifeless: indeed, you're experience with this would've been quite helpful.  Still, this a massive hand and is putting me on a much better track than the head smashing I was doing last night.  Thanks!
[12:34] <lifeless> if you can't find that guy I'm mentioning, ping me via email and I
[12:34] <lifeless> 'll hunt it up monday
[12:34] <ev> will do
[12:34] <lifeless> worst case we write a little tweak to the matrix build plugin to do 'for each'
[12:34] <lifeless> rather than 'first of'
[12:34] <lifeless> that would be oh, 1 hour or so, including getting it upstream.
[12:35] <ev> cool!  I'm definitely liking how willing upstream is to accept such changes.
[12:35] <lifeless> have I mentioned how much I like SSD's ?
[12:35] <ev> heh
[12:35] <lifeless> svn on an SSD is almost not painful.
[12:37] <TerminX> hm, software-center package is missing dep on python-debian
[13:02] <geser> could a core-dev please give back: neon27 libgdata libgnomeprintui. Thanks.
[13:09] <micahg> persia: ping
[13:09]  * persia prefers contentful pints
[13:09] <persia> pings too :)
[13:10] <geser> nice typo
[13:10] <micahg> persia: heh, could you approve my mail to devel-permissions?  just saw that it never hit the list
[13:10] <persia> I don't believe I'm a listadmin for that list.  I'll double check.
[13:11] <cjwatson> I can
[13:11] <cjwatson> (done)0
[13:12] <persia> Thanks cjwatson
[13:12] <micahg> cjwatson: thanks
[13:12] <micahg> I hope it's not too late :(
[13:15] <pitti> cjwatson: will you ping me when I shall flush the work items for foundations? we'll flush it for desktop now, and did for security yesterday
[13:16] <jdstrand> pitti: hey, what is your plan with psql? is it on us to publish or do you want it to sit in -proposed?
[13:17] <pitti> jdstrand: I'm fine with getting it published; no upstream regression reports so far, and we both tested with p-common
[13:17] <jdstrand> pitti: I verified it in qrt (and therefore the postgreql-common testsuite)
[13:17] <jdstrand> pitti: cool, thanks
[13:17] <pitti> thanks to you
[13:19] <jdstrand> :)
[13:20] <cjwatson> pitti: yes - we're getting there but still more to do (I'm on my 5th spec of 5, if I'm counting properly)
[13:20] <pitti> cjwatson: ok, just give the word
[13:23] <geser> does somebody know if new package in Debian got already synced to maverick?
[13:24] <cjwatson> not across the board, sorry
[13:25] <Daviey> geser: you can use rmadison to check.. rmadison $PACKAGE, will check ubuntu version; rmadison -uqa $PACKAGE will check debian's
[13:26] <didrocks> pitti: I'm still unsure, do we do manual sync with your script or should we open a bug?
[13:26] <Laney> there was a thread on -devel
[13:26] <pitti> didrocks: so am I; I have used my script for years without problems, but you should still be cautious
[13:27] <Laney> but no AAs have replied as of yet
[13:27] <pitti> Benjamin Drung has a greatly improved version now
[13:27] <didrocks> pitti: I've used it some times too, but not sure about the "policy", ok, let's use it so :)
[13:27] <didrocks> thanks
[13:27] <pitti> in essence, it produces the same output as the LP one
[13:27] <pitti> but it doesn't check e. g. the blacklist
[13:28] <geser> Daviey: "new" as in not yet in maverick at all. so either the script to import NEW source packages from Debian didn't get run either yet or some other reason why the package did got synced to maverick yet.
[13:28] <pitti> geser: probably the former
[13:28] <didrocks> pitti: oh ok, I guess we know ourself if it's blacklisted or not if we keep our packages :)
[13:30] <Daviey> Is the blacklist somewhere we can query?
[13:30] <geser> didrocks: or we ask bdrung politely to add support for the sync-blacklist
[13:30] <geser> Daviey: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[13:30] <Daviey> ooo
[13:31] <pitti> the blacklist is mostly interesting for autosyncs, but it might help to avoid accidents
[13:31] <didrocks> geser: sure, is bdrung's version packaged somewhere? I don't see it
[13:31] <pitti> it's in bzr so far
[13:32] <geser> didrocks: lp:ubuntu-dev-tools only at the moment
[13:33] <cjwatson> while I haven't got round to doing it en masse yet (which is always a pain to start off with because we have to make sure we aren't reintroducing things that were removed but accidentally not blacklisted), I'm happy to sync new packages on request
[13:34] <didrocks> geser: ok, thanks :)
[13:34] <cjwatson> Laney: are you looking for this pile of haskell stuff to be synced, perchance?
[13:34] <geser> cjwatson: through bugs as usual?
[13:34] <cjwatson> geser: just tell me on irc
[13:34] <Laney> cjwatson: What pile of stuff? autosync candidates?
[13:34] <cjwatson> autosyncs are already happening
[13:34] <Laney> Dunno what you're referring to
[13:34] <cjwatson> I mean new source that isn't yet in Ubuntu
[13:35] <cjwatson> but that's in Debian unstable
[13:35] <Laney> not especially, as long as it happens at some point
[13:35] <Laney> if I get blocked I'll let you know though
[13:35] <cjwatson> $ new-source | grep haskell | xargs
[13:35] <cjwatson> haskell-bzlib haskell-cautious-file haskell-data-accessor haskell-datetime haskell-deepseq haskell-event-list haskell-explicit-exception haskell-fastcgi haskell-feed haskell-filemanip haskell-filestore haskell-ghc-mtl haskell-harp haskell-haxr haskell-hint haskell-hjavascript haskell-hscurses haskell-hstringtemplate haskell-hxt haskell-llvm haskell-markov-chain haskell-maybet haskell-midi haskell-mmap0.4 ...
[13:35] <cjwatson> ... haskell-monoid-transformer haskell-network-bytestring haskell-non-negative haskell-platform haskell-qio haskell-recaptcha haskell-sdl haskell-sdl-gfx haskell-sdl-image haskell-sdl-mixer haskell-sdl-ttf haskell-sha haskell-split haskell-tar haskell-text haskell-transformers haskell-type-level haskell-url haskell-utility-ht
[13:35] <cjwatson> guess I can lob that in now, doesn't look like any of it's been in Ubuntu before
[13:36] <Laney> shouldn't have
[13:36] <Laney> been
[13:36]  * Laney kicks brain
[13:37] <geser> could a core-dev please give back: neon27 libgdata libgnomeprintui. Thanks.
[13:39] <seb128> geser, doing
[13:39] <cjwatson> geser: done
[13:39] <seb128> too late :p
[13:39] <seb128> cjwatson, thanks ;-)
[13:41]  * cjwatson looks at the output of "m `new-source`" and once again defers most of this to another day :-/
[13:42] <cjwatson> ("which of these new packages from unstable has been in Ubuntu before?)
[13:42] <cjwatson> "
[13:42] <Laney> can't you tally with the removals log? (is there such a thing?)
[13:42] <cjwatson> could an archive admin other than me process dpkg in NEW?
[13:42] <cjwatson> Laney: yes, but the above is a lot quicker to run :-)
[13:42] <cjwatson> there's no single removals log but removals go in the publication history for each package in LP
[13:43] <seb128> cjwatson, looking
[13:43] <Laney> right, that would be some LP API fun then
[13:52] <seb128> cjwatson, being curious there but how come you have a libdpkg.a but no libdpkg.so?
[13:53] <seb128> seems unusual
[13:53] <seb128> is the .a useful for something?
[13:55] <cjwatson> seb128: at the moment it's a volatile API, but it's exposed as a static library for now to start getting a feel for how people want to use it
[13:55] <cjwatson> seb128: once it's stable it'll become a .so
[13:55] <seb128> cjwatson, ok, thanks, binaries newed now
[13:56] <cjwatson> and hopefully eventually it'll be usable by frontends like apt
[13:56] <cjwatson> thanks
[14:12] <qense> Kubuntu people: <http://www.canonical.com/logos> still shows the old Kubuntu logo.
[14:14] <Riddell> qense: I've notified the web master
[14:14] <qense> Riddell: OK, thanks!
[15:56] <bgupta> Is there any plans to patch mysql for the following advisory: http://www.vupen.com/english/advisories/2010/1137 looks fairly serious to the point that remote unauthenticated folks can exploit..
[15:58] <bgupta> also is this the right channel to ask about such things?
[16:01] <arand> bgupta: Report a bug if it doesn't already exist, mark as security issue, refer to the CVE, look for a fix to SRU...
[16:02] <arand> bgupta: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures?action=show&redirect=SecurityUpdateProcedures is a good reference.
[16:10] <SpamapS> bgupta: http://www.vupen.com/english/advisories/2010/1192
[16:10] <SpamapS> oops
[16:10] <bgupta> nice.
[16:11] <SpamapS> wrong url. ;)
[16:11] <bgupta> no worries
[17:08] <kees> doko: hm, glibc jaunty armel ftbfs due to extra _passed_ tests, I think.  should I adjust the expected test results, or what do you think?  https://launchpad.net/ubuntu/+source/glibc/2.9-4ubuntu6.1/+build/1198390
[17:13] <doko> kees: no
[17:13] <doko> Encountered regressions that don't match expected failures:
[17:13] <doko> test-fenv.out, Error 1
[17:21] <kees> doko: hmpf, I wonder what changed in armel between ubuntu6 and ubuntu6.1.  the actual patch in -updates is minimal.
[17:22] <ogra_cmpc> the buildds
[17:23] <doko> if you don't succeed, blame the buildds ;)
[17:34] <smoser> james_w, thank you for suggesting editmoin.  it improves working with wiki
[17:34] <james_w> cool
[17:48] <subway24> My name is Jim Colensworth and my 13 year old son Brandon is obsessed with Linux, i mean REALLY obsessed. he just got the new version of ubuntu and he is shouting out loud about how good it runs, even though we are not well off, our family prays to bill gates, he is our family's idol. my wife loves him almost as much as she loves me! so how do i get my son to stop using linux?
[17:48] <subway24> i like microsoft, but im using my sons computer for this
[17:50] <SpamapS> subway24: You should just yell at him and take linux away.
[17:50] <subway24> but we do not like to discipline him
[17:50]  * SpamapS secretly hopes the kid decides to move in with a reasonable uncle or something
[17:51] <subway24> his uncle is in prison
[17:51] <SpamapS> hmm... prison or parents who like windows.. which one is worse... tough call
[17:52] <subway24> lol
[17:52] <subway24> seriously, what should we do
[17:53] <subway24> i need help
[17:53] <charlie-tca> switch the whole family to ubuntu, quickly as possible
[17:54] <subway24> but my wife is in love with bill gates! we all want to know how to make money like he does, so we buy windows products
[17:54] <charlie-tca> doesn't matter
[17:54] <charlie-tca> You can still throw the money away on windows products
[17:56] <subway24> but its a good use for the money
[18:04] <subway24> hes screaming at me now!!!! i took his linux away\
[18:04] <mneptok> subway24: your conversation is offtopic for this channel. please use #ubuntu-offtopic, and trolling there is not welcome.
[18:14] <kees> pitti: wait, why aren't we just fixing the kernel for lucid with bug 539467?
[18:16] <SpamapS> so I found this awful upstream that only publishes .src.rpms for their releases.. but its fairly easy to extract the tarball inside... is there a way to write a watch file that can look for a .src.rpm and run alien --to-tgz on it?
[18:18] <SpamapS> even better... they haven't even bothered to modify their COPYING file properly..
[18:18] <SpamapS>     <program>  Copyright (C) <year>  <name of author>
[18:32] <tsimpson> SpamapS: not really, you'd need to create a rule in debian/rules, your best option is to bug the upstream not to do evil
[18:35] <SpamapS> tsimpson: ah that makes sense. I think I'll take door #2. :)
[19:02] <olvs> is there a ubuntu hardware/performance cannel?
[19:02] <olvs> channel
[19:04] <janeNarak> hello, i'm customize install cd, i'm add extra package  phpmyadmin and cacti, but dbconfig cannot connect mysql-server, because mysql-server not running. how to add phpmyadmin, cacti in customize install cdrom?
[19:11] <rahulattuluri> Hi Im a computer science student and a ubuntu user as of know I wish to develop ubuntu.I would like to have one mentor to guide me can any one guide me??
[19:13] <arand> rahulattuluri: https://wiki.ubuntu.com/MOTU/Mentoring/Contributor I'm not sure how much of it still applies though... :/
[19:14] <rahulattuluri> arand,Thanks
[19:17] <asac> hmm. one question: what type of script is ok for the upstart .conf script part?
[19:18] <asac> is there a way to say which shell to use?
[19:18] <smoser> asac, there is not. /bin/sh with '-e' is used.
[19:18] <asac> hmm
[19:18] <smoser> it is somewhat easily worked around if you wanted to do something else though:
[19:18] <smoser> exec /usr/bin/perl <<EOF
[19:19] <smoser> # perl here
[19:19] <smoser> EOF
[19:19] <asac> heh
[19:19] <asac> does it escape/evaluate anything in the script block?
[19:19] <asac> or is it all put unmodified in there?
[19:19] <smoser> i believe the man page discusses that
[19:20] <asac> which manpage? the ones i am looking at are not really content ful ;)
[19:20] <smoser> man 5 init
[19:21] <smoser> exec gets escaped
[19:21] <smoser> script does not
[19:23] <asac> kk
[19:23] <ogra_cmpc> asac, or try man Keybuk :)
[19:23] <asac> any idea if i could spawn exec two processes and upstart still tracks them (not sure what tracking for upstart means though)
[19:24] <asac> two processes from one .conf ;)
[19:25] <ogra_cmpc> asac, if you use respawn the respawn applies to the whole script part afaik
[19:26] <asac> ogra_cmpc: thats what i am not sure about ... what happens if i spawn some process, then exec another ;)?
[19:26] <ogra_cmpc> hmm ...
[19:27] <ogra_cmpc> if you do it inside one script piece i wuld expect upstart to care for both
[19:27] <ogra_cmpc> i guess its something to test out
[19:27] <ogra_cmpc> or man Keybuk as i said before :)
[21:36] <nxvl> i remember there was a send2debian script, is that correct or am i missremembering?
[21:36] <nxvl> i remember soren did it
[21:40] <micahg> nxvl: submittodebian?
[21:40] <nxvl> micahg: that one, thanks you!
[21:50] <ccheney> someone sent me a crash file instead of using apport to report it, what do you use to process the crash reports directly?
[21:52] <Daviey> ccheney: Have you tried double clicking it?
[21:52] <ccheney> it appears to be base64 encoded but base64 doesn't seem to like it
[21:52] <ccheney> Daviey, oh not yet, heh
[21:52] <Daviey> :)
[21:54] <ccheney> cool it turns it into a proper apport crash report :)
[21:54] <Daviey> ccheney: \o/
[21:55] <ccheney> Daviey, thanks for the tip, i wonder why it didn't prompt the user to do that automatically
[21:55] <Daviey> ccheney: you can use apport to do it on the command line, but double clicking is easier to remember :)
[21:55] <ccheney> yea