Howto completely remove/uninstall appamor?


[14:59] <abentley> me
[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <bac> hi, whose here?
[15:00] <bigjools> me
[15:00] <sinzui> me
[15:00] <gmb> me
[15:00] <jtv> me
[15:00] <bigjools> who's here, too :)
[15:00] <bac> :)
[15:00] <deryck> me
[15:00] <jtv> nice cascade we had there
[15:00] <mars> me
[15:00] <EdwinGrubbs> me
[15:00] <bac> bigjools: no, i found a very nice "here" and was wondering who'd claim it
[15:01] <gary_poster> me
[15:01] <henninge> me
[15:01] <gary_poster> I'll take it
[15:01] <noodles775> me
[15:01] <gary_poster> well, it's probably not mine
[15:02] <bac> well, let's get started then
[15:02] <adeuring> me
[15:02] <bac> not much on the agenda so we should zip right through
[15:02] <bac>  * Roll call
[15:02] <bac>  * Agenda
[15:02] <bac>  * Outstanding actions
[15:02] <bac>  * New topics
[15:02] <bac>    * PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
[15:02] <bac>  * Peanut gallery
[15:02] <bac> * jml(?) to set a policy on what can live in lib/lp, lib/services, and lib/coop
[15:03] <bac> since bjornt left us, this item was assigned to jml...but i forgot to tell him about it, so clearly nothing was done.
[15:03] <bac> my bad
[15:03] <flacoste> me
[15:03] <bac> sinzui: how goes your lint replacement?  good, no?
[15:03] <sinzui> lint is queued for landing
[15:03] <bac> \o/
[15:04] <sinzui> I will send an email announcing this today
[15:04] <sinzui> + instructions about embedding it in your editor
[15:04] <bac> very nice, thank you.
[15:05] <bac> as to new items we only have one
[15:05] <bac> [topic] PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
[15:05] <MootBot> New Topic:  PQM commit messages: I don't f***ing care what you're currently listening to.  See also https://dev.launchpad.net/PQMCommitMessages [bigjools]
[15:05] <bac> bigjools: the floor is yours.
[15:05] <bigjools> well first, I was in a bad mood when I added that topic title, but I think you get the gist
[15:06] <bigjools> the commit messages should follow the style guide
[15:06] <bigjools> EOT
[15:06] <sinzui> okay
[15:06]  * sinzui stops work to change editor
[15:06] <bac> any other thoughts?
[15:07] <henninge> Is that spec up to date?
[15:07] <henninge> e.g. Include bugs fixed in this landing. For each bug, include the bug number and the bug summary next to it. e.g. "Fixes: bug 12345: Mozilla Firefox lacks SVG support; bug 54321: Lack of spacing in new account form."
[15:08] <henninge> I never do that, I thought that's what [bug=xxx] is for
[15:08] <jtv> same here
[15:08] <bac> henninge: you are correct
[15:08] <bac> the guide is out of date
[15:08] <abentley> henninge, agreed.  ec2 land and lp-land use your syntax.
[15:08] <sinzui> bigjools, fixed
[15:08] <bac> i'll fix it this week
[15:09] <bac> thanks sinzui
[15:09] <bigjools> sinzui: sorry, I didn't meant to pick on you specifically.  I've just seen some poor commit messages lately.
[15:09] <bac> [action] bac to update https://dev.launchpad.net/PQMCommitMessages
[15:09] <MootBot> ACTION received:  bac to update https://dev.launchpad.net/PQMCommitMessages
[15:10] <sinzui> bigjools, I agree about the poor commit messages...I brought the issue up with Urshina when I was RM. There were 30 bugs un QAed and I could not say what they changed.
[15:10] <gary_poster> we're working on that and will have a report at epic
[15:11] <bigjools> totally
[15:11] <bigjools> oh cool
[15:11] <abentley> merge proposals have a slot for the commit message.  Maybe we should encourage people to fill it out as part of the review.
[15:11] <bac> [topic] other stuff
[15:11] <MootBot> New Topic:  other stuff
[15:11] <bac> abentley: +1
[15:11] <bigjools> +1
[15:11] <bac> anything else to discuss today
[15:11] <bac> ?
[15:12] <gary_poster> benji is a new launchpadder
[15:12] <gary_poster> he's doing new launchpaddy things now
[15:12] <gary_poster> but he will be asking for reviews
[15:12] <bac> great gary_poster
[15:12] <gary_poster> and will eventually want to go through the mentat process
[15:12] <henninge> I had a few issues come up in a recent review, let me pick one.
[15:12] <bac> everyone should make an effort to say hi to benji this week
[15:13] <gary_poster> +1, was hoping I could get him at this meeting
[15:13] <henninge> Anybody ever heard a guideline "one assert per test" in functional test cases?
[15:14] <bac> i have not
[15:14] <abentley> henninge, no.
[15:14] <henninge> The problem with multiple asserts is that the test will abort and the remaing asserts will not be executed.
[15:14] <abentley> henninge, the problem with one assert per test is that set-up time increases.
[15:14] <abentley> henninge, not to mention much more finger-typing.
[15:15] <henninge> abentley: it's either that or smarter asserts.
[15:15] <bac> and probably a less readable test
[15:15] <gmb> henninge, I'm not clear on how the abort is really a problem. For a start, it means you get to fix one test failure at a time rather than having to dig through many.
[15:15] <abentley> henninge, what's the disadvantage of having the test abort and not executing the remaining asserts?
[15:16] <henninge> hang on
[15:16] <henninge> Code like this:
[15:16] <henninge> > +        self.assertEquals(1, len(result_set))
[15:16] <henninge> > >>> +        self.assertEquals(self.ppa, result_set[0].archive)
[15:16] <henninge> > >>> +        self.assertEquals(self.cell_proc, result_set[0].processorfamily)
[15:16] <henninge> >>
[15:17] <henninge> You can test all three conditions at the same time. You can see how many rows
[15:17] <henninge> were returned instead and what their values are. Much more useful.
[15:17] <henninge> The problem with multiple assert statements in one test method is that not all
[15:17] <henninge> will be executed if one fails and you are missing valuable information that
[15:17] <henninge> you can only gain by changing the test code and running the test again.
[15:17] <henninge> For example, if result_set contained 2 instead of the expected 1 elements,
[15:17] <abentley> And how often would the test have failed anyway, because the remaining asserts assume the first assert passed?
[15:17] <henninge> you'd want to know what the two contain but this test would not even tell you
[15:17] <henninge> what the first contains because the asserts don't get called.
[15:17] <bigjools> abentley: point
[15:18] <abentley> henninge, so in your example, what if len==0?
[15:18] <henninge> abentley: sure, we should just make sure that is really the case. The dependency i mean.
[15:18] <henninge> The example is missing my proposed solution which would be comparing lists.
[15:18] <abentley> henninge, and since you're getting results you're not expecting, how do you know that result_set[0] is testing the right thing?
[15:18] <henninge> if len == 0, the list would be empty.
[15:19] <adeuring> you can have a test for "method X changes A into B". The test may need something like "assert(A); do_something(); assert(B)".  "assert(A)" may not be strictly needed, but it can help to ensure that you have a proper test setup.
[15:19] <abentley> henninge, right, and the rest of the asserts will raise IndexError.  Which seems like meaningless exceptions to me.
[15:20] <henninge> My suggestion:
[15:20] <henninge> result = [(row.archive, row.processorfamily) for row in result_set]
[15:20] <henninge> self.assertEqual([(self.ppa, self.cell_proc)], result)
[15:20] <henninge> From the review^
[15:20] <henninge> abentley: there are no other asserts to fail.
[15:21] <abentley> I thought self.assertEquals(self.ppa, result_set[0].archive) is an assert that would fail
[15:22] <henninge> abentley: with len== 0? yes
[15:22] <bac> henninge: i like your suggestion in this instance.  i don't think we'd want to generalize to a restriction of one assert per test case as other situations may not lend themselves so nicely.
[15:22] <abentley> henninge, If we followed a "one assert per test" rule, we might have the same test three times, with the different asserts.
[15:22] <henninge> I was not proposing a rule
[15:23] <bac> ok, i see you said 'guideline'.
[15:23] <henninge> just to have people think about smart asserts.
[15:23] <abentley> henninge, sorry, *guideline*
[15:23] <abentley> henninge, I like your solution.
[15:23] <abentley> henninge, but if you hadn't thought of it, I don't think applying the guideline would make sense.
[15:23] <sinzui> I recall the reason for "one assert per test" was not 10 asserts in a test, but that the test was actually several tests.
[15:24] <abentley> henninge, because it would multiply the number of tests and failures in ways that are not useful.
[15:24] <henninge> just make sure that functional tests suffer not from similar dependency problems like doctest might do.
[15:24] <sinzui> When an object is transitioned to a new state, it may be legitimate to very 3 aspects of the state, but not to then do another state change
[15:24] <sinzui> We had several tests that did that a few years ago
[15:25] <henninge> sinzui: jtv and I just looked at one this morning ... ;)
[15:25] <henninge> anyway, I have made my point.
[15:25] <jtv> henninge: I think that one did go through multiple state changes
[15:25] <jtv> ...with separate assertions
[15:25] <abentley> sinzui, I'm very much in favour of "test only one thing" as a guideline.
[15:26] <sinzui> abentley, I have read your tests, and I know you are
[15:26] <henninge> I had it mentioned to me in a review when I first started and just wanted to check if that is the general opinion.
[15:26] <bigjools> the exception to that is where the setup is very expensive
[15:26] <henninge> jtv: right.
[15:27] <abentley> bigjools, though often those are integration tests, so what you're testing is the integration, not the units.
[15:28] <bigjools> possibly
[15:28] <abentley> bigjools, YMMV
[15:28] <bac> henninge: thanks for bringing this up.  i think reducing the asserts, as you did in your example, is a good idea where practical.
[15:28] <jtv> Another form of testing-too-many-things is where the test sets up a large set of data, and then either performs the operation once and checks all the outputs; or several times with separate checks but without a clear reason why the output should be as expected.
[15:28] <bigjools> abentley: especially in Soyuz :)
[15:29] <bac> any other topics?
[15:29] <bac> 3
[15:29] <bac> 2
[15:29] <bac> 1
[15:29] <bac> thanks everyone
[15:29] <bigjools> thanks
[15:29] <bac> #endmeeting
[15:29] <MootBot> Meeting finished at 09:29.
[15:30] <bac> go read http://elliotmurphy.com/2010/07/06/teambuilding-and-culture-in-a-distributed-workplace/ for a canonical warm-n-fuzzy
[15:47] <bigjools> bac: that blog post is awesome, I read it yesterday and had a huge smile on my face
[22:33] <bac> thumper, rockstar: reviewer meeting?
[22:34] <thumper> bac: rockstar just went for a walk
[22:34] <bac> thumper: ok.  we didn't get up to much in the earlier meeting.
[22:34] <bac> thumper: main item was bigjools requesting that we follow the PQM submit message guidelines
[22:35] <bac> thumper: by that he meant cut out extraneous stuff like what music is playing, etc.
[22:35] <bac> everyone agreed
[22:35] <bac> henninge brought up the topic of a single assert per test case in functional tests which led to a pretty long discussion
[22:36] <bac> he was concerned that after the first assertion fails the test stops and you don't see the results of the later assertions
[22:36] <thumper> hmm
[22:36] <bac> we agreed that in the cases where you can do something clever to avoid multiple assertions then that was ok but we didn't want to codify such a thing
[22:36] <thumper> personally I don't care about the commit message thing
[22:37] <thumper> I'm happy to go either way
[22:37] <bac> henning agreed it should be a guildeline
[22:37] <bac> me too
[22:37] <thumper> I don't like the single assert in a test thing
[22:37] <thumper> if you want to see the others, I think there is a flag
[22:37] <bac> really?
[22:38]  * thumper thinks
[22:38] <thumper> maybe?
[22:38] <bac> dunno
[22:38] <thumper> lifeless would probably know
[22:38] <thumper> if there isn't one, we could add one
[22:38] <thumper> it isn't rocket science
[22:38] <bac> i'll look into it
[22:38] <thumper> ta
[22:39] <thumper> WRT unit tests
[22:39] <bac> often if an earlier assert dies then those following don't have much chance
[22:39] <bigjools> the commit message thing was more about writing something that actually explained the fix properly
[22:39] <thumper> I would say that the test should be short
[22:39] <thumper> and primarily test one thing
[22:39] <thumper> but that one thing may well need multiple asserts
[22:40] <bac> thumper: yes, you're channeling the gist of our discussion
[22:40] <thumper> ok
[22:40] <thumper> we're on the the same page then
[22:40] <bac> yeppers
[22:41] <bac> that was it.
[22:41] <bac> thumper: you have anything to pass on?
[22:41] <thumper> ok, I guess we are done then
[22:41] <bac> right.  have a good day.
[22:41] <thumper> not, not really
[22:41] <thumper> see you next week


[19:01] <cnd> bryceh, Sarvatt, what's the status of the latest xorg-server upload?
[19:03] <bryceh> cnd, heya
[19:03] <cnd> bryceh, hey, happy new year btw
[19:04] <bryceh> cnd, there were some various last minute additions to it, which is what we had been worried about
[19:04] <cnd> ahh
[19:05] <bryceh> I looked through the patches for several of those things and wasn't too put off, but I'd like to hear opinions from RAOF and Sarvatt first
[19:05] <cnd> bryceh, do you know what happened with the upload? pitti noted that there was a huge debdiff that seemed wrong
[19:06] <bryceh> oh, you must be referring to something else
[19:06] <bryceh> sorry thought you were asking about the new xserver release
[19:06] <bryceh> cnd, link me?
[19:07] <cnd> ahh, no, I mean the maverick xserver update
[19:07] <cnd> one sec on the link
[19:19] <cnd> bryceh, sorry for the delay: https://bugs.launchpad.net/bugs/670016
[19:19] <ubot4`> Launchpad bug 670016 in xserver-xorg-input-evdev (Ubuntu Maverick) (and 3 other projects) "Xorg crashes when performing gesture (affects: 1) (heat: 71)" [Undecided,New]
[19:20] <cnd> at the end of the comments you'll see pitti note the debdiff issues
[19:20] <cnd> it's entirely possible that I'm the one at fault since I updated the git repo :)
[19:20] <cnd> I was just wondering if you knew what might have happened
[19:25] <bryceh> ok looking
[19:28] <jcristau> looks like it was built from a dirty tree
[19:30] <bryceh> jcristau, yeah, I found the dirty tree it was built from
[19:32] <cnd> bryceh, I hope that tree isn't a clean clone from git.debian.org :)
[19:35] <bryceh> not sure what it was from.  blaming my git skilllessness for now
[19:38] <bryceh> cnd, reuploaded
[19:50] <Sarvatt> every time I start getting ready to put xserver 1.10 into the PPA -- <keithp> aaronp: I've got some RandR 1.4 proto changes to propose...
[19:51] <Sarvatt> got mesa fixed up to use the natty packaging though, will push that in there in tomorrow's update
[19:52] <bryceh> Sarvatt, heh
[20:02] <cnd> bryceh, thanks!
[20:02] <cnd> Sarvatt, did keithp acquiesce?
[20:06] <Sarvatt> aaronp asked if the abi was frozen to update the nvidia blob and they said nope
[20:11] <cnd> grr
[20:12] <cnd> oh, actually, I read that backwards
[20:12] <cnd> I see that keithp was saying there's changes to be made still
[20:12] <Sarvatt> bryceh: hmm so we need some way to get the dmesg from the actual crash not after the reboot..
[20:13] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/694244 looks the same as https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/686388
[20:13] <ubot4`> Launchpad bug 694244 in xserver-xorg-video-intel (Ubuntu) "[i965gm] GPU lockup (EIR: 0x00000010) - Invalid GTT entry during Display B Fetch (affects: 1) (heat: 6)" [Medium,Incomplete]
[20:13] <Sarvatt> that ickle commented on https://bugs.freedesktop.org//show_bug.cgi?id=32396
[20:13] <ubot4`> Freedesktop bug 32396 in Driver/intel "[i965gm] GPU lockup - Invalid GTT entry during Display B Fetch" [Normal,New]
[20:13] <Sarvatt> too bad /var/log/dmesg stops after boot is done
[20:14] <bryceh> Sarvatt, yeah
[20:15] <Sarvatt> /var/log/kern.log?
[20:16] <bryceh> Sarvatt, are you sure they're the same?  the gpu dumps look different to me
[20:16] <bryceh> one seems to involve a bunch of 3D calls, the other doesn't
[20:24] <Sarvatt> bryceh: they're from the same person and have the same EIR/PGTBL_ERR/INSTDONE, yeah I'm positive
[20:25] <bryceh> ah, didn't notice it was the same guy
[20:25] <Sarvatt> compiz was probably doing something at the time of one of the crashes and not the other
[20:25] <Sarvatt> me neither or I woulda duped it earlier :)
[20:26] <Sarvatt> 5 bugs, woohoo
[20:35] <bryceh> for bug #692677 I'm thinking of just dropping the patch... would prefer to actually solve it, but it's not clear looking at the patch what could be wrong with it
[20:35] <ubot4`> Launchpad bug 692677 in nvidia-settings (Ubuntu) (and 1 other project) "Desktop login to unity leads to hang and compiz crash when X Server Display Confirmation is clicked on (affects: 1) (heat: 394)" [High,Triaged] https://launchpad.net/bugs/692677
[20:35] <bryceh> lunch first tho... bbiab
[21:05] <bryceh> Sarvatt, I was thinking next week if we have time it might be useful to do a group walk-thru of all the X bugs marked high priority, and get some movement on them.
[21:14] <Sarvatt> bryceh: sounds good to me, platform services has a packed schedule and I'm not sure when will be good but will see then
[21:14] <bryceh> wonder if alberto will be there
[21:16] <Sarvatt> oh it's nowhere near as packed as I thought https://wiki.canonical.com/PlatformServices/DallasSprint2011
[21:16] <bryceh> oh good
[21:17] <bryceh> yeah typically sprints are not nearly so booked, like uds's, but some teams do more structured stuff than others
[21:18] <bryceh> maybe we could do 1 hr each morning following plenary
[21:26] <Sarvatt> ohh RAOF is already in texas!
[21:29] <bryceh> really?
[21:29] <bryceh> I can't keep track of that boy
[21:29] <bryceh> vacationing?
[21:31] <Sarvatt> yeah week vacation before the sprint the wiki says
[21:42] <bryceh> 694289 and 694381... more of our favorite bug
[21:45] <bryceh> Sarvatt, have you ever gotten an -nvidia install on a usb key to work?
[21:46] <Sarvatt> back in karmic/early lucid, didn't try again for a long time there
[21:47] <marjo> Sarvatt: FYI, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/693093
[21:47] <ubot4`> Launchpad bug 693093 in linux (Ubuntu) (and 1 other project) "[i945gme] 2.6.37-10.24: Black Screen on Boot (affects: 8) (heat: 337)" [High,Confirmed]
[21:47] <marjo> Sarvatt: thx for your help again
[21:50] <bryceh> hmm, wonder what changed
[21:50] <Sarvatt> that really should be an alpha 2 targetted bug but not comfortable adjusting the grub task since cjwatson is particular about those
[21:51] <bryceh> last commenter on #685017 said he got it working with -nvidia .29
[21:52] <Sarvatt> huh
[21:52] <Sarvatt> oh
[21:52] <Sarvatt> bryceh: i bet they installed from nvidia.com
[21:52] <Sarvatt> and now that i think about it, when I did have it working I also installed from nvidia.com
[21:53] <Sarvatt> back when that used to work in karmic/early lucid
[21:53] <Sarvatt> there's no .29 in x-updates natty
[21:53] <bryceh> interesting; how do you think that differs?
[21:53] <Sarvatt> no dkms, no jockey, no update-initramfs
[21:54] <Sarvatt> no gl
[21:54] <bryceh> aha
[21:54] <bryceh> yeah so that points back to not needing initrd updates
[21:56] <Sarvatt> asked for logs to see whats up
[21:58] <tormod> happy new year everyone! can anyone give bug 635362 some sponsor love?
[21:58] <ubot4`> Launchpad bug 635362 in xserver-xorg-video-savage (Ubuntu) (and 1 other project) "Xorg assert failure: X: /usr/include/xorg/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed. (affects: 14) (dups: 11) (heat: 138)" [Medium,Triaged] https://launchpad.net/bugs/635362
[22:03] <bryceh> hiya tormod
[22:05] <bryceh> tormod, on it
[22:05] <tormod> bryceh, thanks!
[22:08] <bryceh> tormod, looks good.  uploaded
[22:08] <tormod> thanks again
[23:11] <Sarvatt> http://semiaccurate.com/2011/01/02/sandy-bridge-biggest-disapointment-year/ -- someone should tell him to try any other distro livecd where he won't even get a 2D desktop :)
[23:59] <bryceh> Sarvatt, hmm, someone should send me one of those sandybridge machines


[04:30] <vpa1977> bdmurray: java-common migrated, thanks again !!!!!
[09:02] <Skuggen> mdeslaur: Hi! Sorry, I hadn't seen that before. I'll ask
[09:04] <Skuggen> coreycb: Great work on the router issue. The full revert should be reasonably safe as the router code is quite independent of server. Dev may have found the underlying issue, so we might also be able to get a targeted patch out
[10:07] <slyon> juliank: is there any way to use 'apt search ..' to only search for packages in the 'main' component?
[10:09] <juliank> No
[10:09] <juliank> slyon: You can use apt list with patterns perhaps
[10:09] <juliank> slyon: but you can't search descriptions in there
[10:10] <slyon> ok.. I'd like to search descriptions from 'main'
[10:10] <juliank> To find all packages in main, you could use ?not(?section(/))
[10:10] <slyon> searching just package names should already help, though.
[10:10] <slyon> let me try that
[10:11] <juliank> I need to implement ?description
[10:13] <juliank> Why is there no component pattern too
[10:13] <juliank> I want to search ?component(main), not ?not(?section(/))
[10:13] <juliank> or ?component(restricted) instead of ?section(restricted/.*)
[10:14] <juliank> I know I know we should just implement sql on top of the apt cache
[10:14] <slyon> right, a component pattern would be nice and searching the description, too.
[10:14] <slyon> but I think the ?not(?section(/)) does the trick for me now. thanks a lot!
[10:15] <slyon> my output is relatively small, to I can filter the rest manually
[10:16] <juliank> Can also use apt-cache show ?not(?section(/)) | grep-dctrl -rFDescription regex
[10:19] <juliank> ok there is a bug *somewhere*
[10:20] <juliank> oh yeah apt show splits on / first and hence parses ?not(?section( as the pattern, and )) as the release.
[11:49] <mdeslaur> Skuggen: thanks!
[11:58] <Skuggen> mdeslaur: coreycb: I have another patch for the router bug (basically, it couldn't handle 20+ long passwords over unencrypted channels). Just checking the build, and I can upload to the bug (Jan was able to reproduce the issue in the bug and tested against that)
[12:06] <mdeslaur> Skuggen: great!
[13:39] <coreycb> Skuggen: great, thank you
[13:41] <coreycb> Skuggen: that would probably be worth cutting a new patch release to include the bug fix
[19:07] <arraybolt3> Could I ask for some autopkgtest retries for lubuntu-update-notifier? I see it's stuck in PyQt5, but when I do an autopkgtest locally with all of -proposed in use, the test passes. List of URLs: https://paste.ubuntu.com/p/dzVYBFB5Br/
[19:08] <arraybolt3> (I added the "&all-proposed=1" to the end of each one, I think that's the way to do that but I don't know for sure, so please review and tell me if I messed that up.)
[19:10] <vorlon> arraybolt3: running
[19:10] <arraybolt3> Thanks!
[19:10] <vorlon> fwiw I'm just running the following pipeline rather than copying the above pastebin: retry-autopkgtest-regressions --blocks pyqt5 --all-proposed | xargs -rn1 -P10 curl --cookie ~/.cache/autopkgtest.cookie -o /dev/null --silent --head --write-out '%{url_effective}: %{http_code}\n'
[19:12] <arraybolt3> Wow, that looks complicated :P
[19:12] <arraybolt3> I think I can see the general idea of how that works, though. Thanks for sharing!
[19:13] <vorlon> the bit after the pipe is documented in the help output of retry-autopkgtest-regressions
[19:14] <arraybolt3> That's part of ubuntu-archive-tools (or something similarly named, can't remember it rn), right?
[19:15] <arraybolt3> Nevermind, found it.
[19:17] <vorlon> yah
[19:20] <MacSlow> Greetings everybody!
[19:21] <sarnold> wb MacSlow
[19:21] <MacSlow> hey sarnold
[20:33] <MacSlow> bbl


[00:13] <vwrules> I want to try unity
[00:13] <vwrules> how do i go about donwloding it
[00:13] <vwrules> do it donwload ubuntu 10.10 ?
[00:14] <Omega> vwrules: No
[00:14] <Omega> You download 11.04
[00:14] <coz_> vwrules,   no  download the daily build
[00:14] <Omega> Put it on a usb stick.
[00:15] <coz_> http://cdimage.ubuntu.com/releases/natty/alpha-1/    or   http://cdimage.ubuntu.com/daily-live/current/
[00:17] <vwrules> thanks
[00:17] <vwrules> i downloaded 10.10 and didn't work
[00:17] <vwrules> thanks
[00:18] <Omega> unity is not being ported to 10.10
[11:47] <fredreichbier> hi there
[12:00] <fredreichbier> i've got a question regarding application indicators: i've implemented this spec: http://www.notmart.org/misc/statusnotifieritem/ and thought this was the latest and final spec for indicators, but now i've stumbled upon launchpad.net/libindicate which seems to implement a totally different API. what's up with libindicate? =D
[21:19] <Devil505> http://lizards.opensuse.org/2010/12/29/kick-off-for-gnomeayatana-project/
[21:19] <Devil505> good for ayatana :)
[21:21] <dereks> hello. i am looking at trying out unity (upgrading to natty), but am curious how dual monitors will work. is there any documentation on that?