[03:05] <cwells> can I report a bug here?  launchpad is far too tedious
[03:05] <cwells> ubuntu 9.10 /etc/syslog.conf has incorrect line:  auth,authpriv.*          -/var/logauth.log
[03:05] <cwells> should be /var/log/auth.log
[03:06] <chrisccoulson> cwells, no, this is not the correct place to report a bug
[03:06] <cwells> is there a good place to report them?
[03:06] <chrisccoulson> yes, launchpad
[03:06] <cwells> yeah, no thanks
[03:06] <cwells> i had previously believe bugzilla to be bad, but launchpad has made me revise that opinion
[03:06] <chrisccoulson> well, don't expect your bug to be fixed then
[03:06] <cwells> shrug
[03:07] <cwells> perfect
[03:07] <cwells> i can fix my own installs
[03:07] <cwells> everyone else can wonder
[03:07] <chrisccoulson> dropping comments in to random IRC channels won't help anyone
[03:07] <cwells> this is a random IRC channel?
[03:07] <chrisccoulson> we have a bug tracker for tracking bugs, and that is the only place to report them
[03:07] <cwells> well, where is it?
[03:07] <chrisccoulson> launchpad
[03:07] <cwells> i find instructions for using a gnome tool
[03:07] <cwells> not an actual bug tracker
[03:08] <cwells> not actually interested in browsing launchpad pointlessly
[03:08] <chrisccoulson> well, i'm not interested in helping you any further then
[03:08] <cwells> great
[03:09] <cwells> cause you didn't
[08:21] <ubuntu> I am using Ubuntu 10 04 beta live cd, every now and then the entire SCREEN turns GRAY and everything slows down
[08:22] <ubuntu> happens on flash sites a lot
[08:23] <ddecator> ubuntu: please ask in #ubuntu+1 to see if anyone else has had that
[09:58] <BUGabundo> diæs !
[11:34] <Laibsch> Hi, anybody have an idea what is happening in bug 558345?  Which package is the most likely candidate for creating this issue?
[11:34] <ubot4> Launchpad bug 558345 in pygtk (Ubuntu) "found text and marked text don't match in gjots2 pygtk app (affects: 1)" [Undecided,New] https://launchpad.net/bugs/558345
[12:13] <qense> Laibsch: it seems that this really is an issue with gjots2, unless it's using a widget for the textarea from GTK+.
[12:13] <qense> in the latter case it can either be a bug in the PyGTK bindings, or in GTK+ itself.
[12:49] <xteejx> Afternoon all :)
[12:56] <xteejx> I haven't personally experienced this, but I understand what is happening here. Can someone take a look at this please? (Am waiting on apport data) bug 289322
[12:56] <ubot4> Launchpad bug 289322 in gnome-power-manager (Ubuntu) "gnome-power-manager put display to sleep timer incorrect when CPU is being used (affects: 2) (heat: 16)" [Medium,Confirmed] https://launchpad.net/bugs/289322
[13:08] <xteejx> No-one alive today?
[13:14] <persia> Well, it's a really confusing bug.  I suspect a few folks (like I) looked at it, got confused, and didn't comment.
[13:20] <yofel> and some of us don't actually use gnome
[13:40] <xteejx> I think I clarified the problem, but no worries, waiting on apport info anyway might have a fresh mind when I come to look at it when that information comes back :)
[14:05] <gbuonfiglio> Hello. I'm using Lucid, updating it daily and testing it. Yesterday I had a problem that I need guidance to report a bug.
[14:06] <gbuonfiglio> The boot fsck stopped at 72%.
[14:06] <gbuonfiglio> then nothing happens. I could not cancel it anymore with "C".
[14:07] <gbuonfiglio> ctrl-alt-del rebooted the machine, and it was back to the same point. Fsck now stopped at 75%.
[14:07] <yofel> gbuonfiglio: bug 554079?
[14:07] <ubot4> Launchpad bug 554079 in sysvinit (Ubuntu) "Lucid boot failed to complete after fsck (affects: 36) (heat: 170)" [Undecided,Confirmed] https://launchpad.net/bugs/554079
[14:08] <gbuonfiglio> looking at 554079
[14:08] <gbuonfiglio> thanks yofel! That's exactly the same issue. :)
[14:09] <yofel> gbuonfiglio: I have that too, if it's an auto check it should boot fine after a reboot though
[14:10] <yofel> gbuonfiglio: if you still need help to resolve this join us in #ubuntu+1
[14:10] <gbuonfiglio> Yes I did that.
[14:10] <gbuonfiglio> tty1 and reboot... :)
[14:11] <gbuonfiglio> yofel: what is this #ubuntu+1 channel for?
[14:11] <yofel> gbuonfiglio: lucid support and discussion
[14:11] <gbuonfiglio> yofel: great. I will keep and eye on it. Thanks!
[14:11] <yofel> gbuonfiglio: today it's the 'is beta2 out yet?' channel -.-
[14:12]  * xteejx giggles
[14:12] <xteejx> Probably tomorrow ;)
[14:13] <persia> Ya know, y'all could help test the outstanding test cases to make it be sooner :)
[14:14] <BUGa_vacations> I would if I could
[14:14] <xteejx> persia: What cases is that? I haven't got a test machine, I just run ubuntu+1 from around alpha 4
[14:14] <BUGa_vacations> but even in vacations I have to work :(
[14:15] <persia> xteejx: Hop on over to #ubuntu-testing and see https://wiki.ubuntu.com/Testing/ISO
[14:17] <xteejx> iso testing? :( damn I can't do install checks I don't have a spare system
[14:17] <yofel> VM?
[14:17] <xteejx> yofel: Not much point if it doesn't have direct access to all my hardware
[14:18] <xteejx> My laptop is a complete bugger with linux at the mo anyway - saying that I'm in Ubuntu
[14:18] <persia> Actually, there is a point.  It makes sure the *images* are good, which is the big point of ISO testing.
[14:18] <xteejx> Ohhhh :)
[14:18] <xteejx> I'm *extremely* slow minded today sorry guys :P
[14:19] <persia> Making sure all the software works we can do with ongoing rolling testing and bug reporting, etc.  But that doesn't help validate that a given image is good enough to be called "beta2"
[14:19] <xteejx> I can rsync these images for usage in VM right?
[14:19] <persia> Yeah.  The folk in #ubuntu-testing will be glad to share scripts and hints.
[14:20] <yofel> didn't we have something like dl-ubuntu-test-iso for that?
[14:20] <xteejx> Hmmm I might have a look at doing that in a bit then persia, just clearing out the last 34 bug messages in the inbox and replying lol
[14:20] <BUGa_vacations> xteejx: ISO boot from grub
[14:20] <BUGa_vacations> that's what I do
[14:20] <persia> Hey, testing is cool and all, but don't let me interrupt your usual work :)
[14:21] <BUGa_vacations> I should update my isos too
[14:21] <BUGa_vacations> but on a slow network
[14:21] <xteejx> persia: Nahh i can multitask ;)
[14:21] <BUGa_vacations> xteejx: use zsync instead
[14:50] <xteejx> sorry got sidetracked, will try zsync instead thanks BUGabundo
[14:50] <BUGa_vacations> np
[14:50] <BUGa_vacations> but do try the boot from grup
[14:50] <BUGa_vacations> much easier for quick test
[14:50] <xteejx> grup?
[14:51] <BUGa_vacations> *grub2
[14:51] <BUGa_vacations> it was doing an up side down
[14:53] <xteejx> hehe :P
[14:55] <xteejx> where is the kern.log file?
[14:55] <xteejx> dw got it :)
[15:07] <nigelb> ah, today is rhythmbox hug day, no wonder I'm getting too many mails
[15:13] <xteejx> is it? I must have been asleep when that email came through!
[15:14] <pedro_> yes it is today, you don't read Planet Ubuntu heh? ;-)
[15:15] <nigelb> pedro_, you've been making my mailbox full :D
[15:15] <xteejx> pedro_: You know what, I've been so bloody busy with loads of stuff I haven't been doing much of anything, just small bits of lots of things lol
[15:15] <xteejx> :P
[15:16] <pedro_> nigelb, ah don't worry it's all SPAM , I'm selling medicine now :-P
[15:16] <nigelb> pedro_, hehe :)
[15:16] <pedro_> xteejx, haha
[15:17] <xteejx> pedro_: don't forget your winnings of 86,000 Ugandan dollars...I keep winning in my emails lol
[15:17] <pedro_> lol
[15:17]  * charlie-tca did not have to win, they just want to give me money
[15:17] <xteejx> haha charlie :)
[15:18] <xteejx> Random question....does anyone here have Ubuntu on a PS3?
[15:18] <charlie-tca> I thought sony bricked them
[15:19] <xteejx> it has, but geohot (the renowned iphone hacker) has found a way to bypass the firmware update via proxy
[15:19] <xteejx> should see custom firmware in a couple of weeks
[15:20] <xteejx> I haven't updated mine, don't wanna lose linux on such a powerful machine...wanna see what it'll be capable of once all the barriers are broken....7 core processor....can't go wrong
[15:20] <charlie-tca> yup
[15:21] <xteejx> I'll install windows if it becomes too fast.........HA!
[15:21] <nigelb> xteejx, good one :D
[15:22] <xteejx> ;) I do love Microsoft....almost as much as being stabbed in the back by Richard Branson........anyway
[15:22] <xteejx> which is the better VM for ISO testing?
[15:24] <charlie-tca> I use VirtualBox for simplicity
[15:25] <datag> could someone please tell me how to get attention to bug #542185 ? freeze is near and it would be kinda unlucky if this won't be fixed.
[15:25] <xteejx> charlie-tca: Does that have direct processor access, etc?
[15:25] <ubot4> Launchpad bug 542185 in holdingnuts (Ubuntu) "holdingnuts GUI badly affected by a bug in Qt 4.6.2 (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/542185
[15:25] <charlie-tca> I don't know
[15:26] <charlie-tca> It doesn't use most of the hardware, though
[15:26] <xteejx> datag: Speak to #ubuntu-motu they'll be able to point you the right direction to get sponsorship for a patch
[15:26] <xteejx> charlie-tca: No worries, I'll try it out :)
[15:26] <datag> xteejx: i will, thanks!
[15:26] <xteejx> np :)
[16:04] <atrus> mrand: hm. so i tagged bug 498182 for release-notes, and it was marked invalid there. (shrug)
[16:04] <ubot4> Launchpad bug 498182 in indicator-session (Ubuntu) (and 3 other projects) "Indicator-application does not support vertical panels (affects: 10) (heat: 58)" [Medium,Triaged] https://launchpad.net/bugs/498182
[16:07] <mrand> atrus: release notes are a fine line... do you mention every little thing in them?  That would probably be too long a list.  So they likely want to keep the list very focused so that people will actually read it - which means that it probably needs to impact a large number of people (for the whole Ubuntu community) in a non-obvious way.
[17:27] <RemiemB> Howdy!
[17:49] <alvin> If a server crashes for a totally unknown reason, where would you start looking for the bugs. (kern.log shows nothing hours before the crash)
[17:54] <kamusin> alvin, have you looked at /var/crash and syslog?
[17:55] <alvin> /var/crash is empty. I guess I had to enable apport for that?
[17:55] <alvin> Two days ago, the same happened
[17:55] <alvin> syslog has something. Last event before the crash is : /etc/cron.hourly. I'll take a look at what runs then.
[17:56] <alvin> (oh, nothing)
[17:56] <alvin> I enabled apport. Maybe in 2 days I'll know more
[18:11] <decoder> how do I apply a patch when I have the source package? trying to fix a bug
[18:12] <persia> decoder: Do you want to do it the "right way" or the "quick way"?
[18:12] <decoder> the quick way would be ok, as I want to test the patch locally
[18:12] <decoder> not for redistribution
[18:15] <Damascene> persia, do you use rtl language
[18:17] <persia> The quick way (which usually works), is dpkg-source -x foo.dsc, cd foo-${ver}, check if debian/README.source provides instructions, if not, check if deban/patches contains anything, if so, run debian/rules patch.  Apply your patch (patch -p? < bar), debian/rules build, debian/rules binary, cd ..
[18:17] <persia> Damascene: Not usually.  I have an RTL locale installed if there's something special that needs testing.
[18:17] <Damascene> persia, do  you know about the vte bug?
[18:18] <decoder> persia: sounds good, ill try that, thx
[18:18] <persia> I don't.  The only RTL bug that I saw was the one with numbers.
[18:18] <persia> decoder: If that doesn't work, we'll do it the "right" way :)
[18:18] <Damascene> this bug >>> https://bugs.launchpad.net/vte/+bug/263822
[18:19] <ubot4> Launchpad bug 263822 in vte (Ubuntu) (and 1 other project) "RTL (right to left) support in terminal (BiDi) (affects: 12) (dups: 3) (heat: 110)" [Low,Triaged]
[18:21] <Damascene> persia, ?
[18:21] <persia> Reading...
[18:21] <persia> I think that was the one I saw before though.
[18:22] <persia> I'll see if I can replicate locally.
[18:24] <persia> Damascene: Ugh.  That's all sorts of annoying, yeah.
[18:24] <Damascene> persia, can you help with this problem?
[18:24]  * BUGa_vacations is tired of "when its ready"
[18:25] <decoder> persia: building now =) we'll see in a few
[18:26] <persia> Damascene: I can replicate with ` LANG=ar_TN.utf8 gnome-terminal &`
[18:26] <digital_> houdy everyone
[18:27] <persia> But no, I have no idea how to fix it, and I don't have upload for gnome-terminal or vte.  Maybe ask in #ubuntu-desktop?
[18:27] <BUGa_vacations> hggdh: http://article.gmane.org/gmane.linux.kernel/969355 LOOOOOL
[18:27] <Damascene> persia, I've sent email to ubuntu-desktop but no respond. I think of using mlterm instead of vte for RTL
[18:28] <Damascene> can you promote this idea?
[18:28] <persia> Did you try asking in #ubuntu-desktop?
[18:28] <persia> I don't blog :)  I've pressed the "me too" button in LP.
[18:29] <Damascene> :)
[18:29] <Damascene> thanks any way
[18:30]  * alvin tries to chmod his /proc/cpuinfo
[18:47] <decoder> persia: build ran through, Ill test the package now, thanks for the quick help :)
[18:47] <persia> decoder: No problem.  Thanks for testing the patch.  If you're up for patch testing, consider joining #ubuntu-reviews: we always need more folk :)
[18:59] <hggdh> BUGa_vacations: wow, this is good. I have one $1 note. Can I write $100 on it, and use it as a real $100?
[19:00] <BUGa_vacations> yes
[19:00] <BUGa_vacations> didn't you know that already?
[19:07] <pedro_> graph for today bug day is looking *awesome* http://people.canonical.com/~brian/complete-graphs/rhythmbox/plots/rhythmbox-1day-triaging.png
[19:17] <vish> today was bug day, .. /me getting forgetfull
[19:18] <vish> tsk tsk , rhythmbox adopter , nigelb ;p  not taking care huh?
[19:18] <blueyed> pedro_: *awesome*? more bugs (triaged), more incomplete, less new, more confirmed. not much fixed ;)
[19:18] <blueyed> also: interesting would be how much have been forwarded upstream..
[19:19] <pedro_> blueyed, you're welcome to submit patches for the triaged ones though ;-)
[19:20] <pedro_> but for now, that's not the target of a bug day
[19:20] <blueyed> pedro_: I know :) - I would be happy to review your patches! ;)
[19:20] <blueyed> forwarding upstream? but yes.
[19:48] <charlie-tca> I'll pick up my 10 or so after I finish the upgrade testing in progress
[20:38] <robertzaccour> is somethin missin in my bug report? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/555503
[20:38] <ubot4> Launchpad bug 555503 in xorg-server (Ubuntu) "screen flickers at least once every few minutes (affects: 2) (heat: 12)" [Undecided,Incomplete]
[20:39] <robertzaccour> either only one other person has lucid beta on their dell inspiron 1545 or people aren't gettin on launchpad to report it
[20:40] <xteejx> robertzaccour: Hence the reason why we need as many testers as possible
[20:41] <robertzaccour> but is there some information i may have left out? its still incomplete status, still undecided imprtance, and still not unassigned in the assigned to part
[20:41] <robertzaccour> i'm gettin the feeling 2 people with this bug aren't enough for it to be considered of importance for development
[20:42] <xteejx> try "apport-collect -p xorg 555503" instead of the one they told you, xorg-server doesn't have an apport hook AFAIK
[20:42] <xteejx> there is a workflow for bugs...nothing can be done without you supplying the information they need
[20:43] <robertzaccour> the apport box that came up crashed
[20:43] <xteejx> robertzaccour: as for the boot option, when grub bootloader comes up there is a button you can press to pass additional options to boot with, it will say what it is, I can't remember, think it may be "E" - in which case at the end of the long linux= blah blah line add the i915 powersave option as they have written it in the bug report
[20:44] <xteejx> crashed?? how do you mean crashed?
[20:44] <robertzaccour> i pasted that command, it did its thing, then a box came up collecting information and crashed in the middle
[20:45] <xteejx> hmmm hang on
[20:45] <robertzaccour> ok it sent data to developers
[20:45] <robertzaccour> anyting i can do in the comments?
[20:46] <robertzaccour> forget the bug, i force quitted and it sent correctly the 2nd time thanks anyhow
[20:46] <robertzaccour> i meant
[20:46] <robertzaccour> not the bug, just the apport crashing
[20:46] <xteejx> it will update the bug report with the debugging information for the X server
[20:46] <robertzaccour> xteejx, is there anything else i can do for now?
[20:46] <xteejx> I don't think apport worked correctly, there are no xorg logs
[20:47] <xteejx> Nope it has done it fine, just took a while to appear :)
[20:48] <xteejx> robertzaccour: Also, as explained above, try booting with the i915.powersave=0 flag in the GRUB menu.  ^^ Instructions above
[20:50] <robertzaccour> i sent the apport again
[20:50] <xteejx> The apport data is fine, sometimes it takes a while for Launchpad to update
[20:51] <robertzaccour> xteejx, oh so it got there to them?
[20:51] <xteejx> huh?
[20:52] <robertzaccour> i just tried to close the terminal and it said there is still a process running in this terminal. closing it will kill it
[20:52] <robertzaccour> does that mean its still working in the background?
[20:52] <xteejx> Yes, it's probably the apport-collect that you ran the 2nd time, it wasn't necessary, as I said Launchpad already had the data it just takes a while sometimes to show up
[20:53] <robertzaccour> xteejx, so should i close the terminal now?
[20:53] <xteejx> If you are sure that is the only thing running, yes it should be safe to
[20:53] <robertzaccour> ok it closed fine
[20:54] <xteejx> All you need to do now is follow the instructions above that I gave to add i915.powersave=0 to the GRUB boot options and test it, then report back to the bug report with your findings
[20:56] <robertzaccour> ok there's a lot more info from me on launchpad now. progress i hope?
[20:56] <xteejx> No. As I explained 3 times, you need to do what the triager has asked and test the boot option
[20:57] <robertzaccour> xteejx, will the i915 be a temporary or permanent change?
[20:58] <xteejx> temporary, it's only for 1 boot - the only time this would become permanent is if you went and physically changed the GRUB boot options in the grub boot file
[20:58] <robertzaccour> xteejx, oh ok thanks
[20:58] <xteejx> it's just to test :)
[21:20] <robertzaccour> how do i do what you were saying? didn't see that option on startup
[21:21] <xteejx> What version of *buntu are you using?
[21:21] <guntbert> robertzaccour: in the grub menu, select the item you want but press E instead of <enter>, the you can edit the command line
[21:21] <xteejx> thought it was E :)
[21:21] <robertzaccour> guntbert, i don't see that menu at startup, nothing about grub at all
[21:21] <robertzaccour> i restarted 3 times to look for it
[21:22] <xteejx> What version of Ubuntu are you running????
[21:22] <robertzaccour> xteejx, lucid
[21:22] <guntbert> robertzaccour: while booting press <shift>
[21:22] <xteejx> You need to press ESC to see the menu then
[21:22] <robertzaccour> ok and whats that command again?
[21:22] <robertzaccour> just to make sure i wrote it down correctly
[21:22] <xteejx> whatever was in the bug report
[21:22] <xteejx> just add the i91....blah to the end
[21:23] <robertzaccour> so at the very end just type in i915?
[21:24] <xteejx> no that wasn't the whole thing, look at the bug report
[21:24] <guntbert> robertzaccour: please look at the info request in the bug report
[21:25] <robertzaccour> guntbert, i just did
[21:25] <robertzaccour> so restart, tap shift, then add the command?
[21:25] <robertzaccour> oh ESC
[21:25] <xteejx> ESC
[21:25] <xteejx> the i915...blah blah =0 or whatever it was to the end yes
[21:25] <robertzaccour> ok i'll try that brb thanks
[21:28] <robert__> i'm back. i tapped ESC from restart til startup and nothing happened, no menu
[21:29] <xteejx> You need to press ESC when the purple ubuntu bit comes up right after the POST
[21:29] <guntbert> robert__: did you try with <shift>?
[21:29] <robert__> guntbert, yes
[21:29] <xteejx> I'm 99% sure its ESC not shift, and either way one should have worked
[21:29] <robert__> i'll try both again though brb
[21:30] <robert__> when the purple paper comes up hit esc?
[21:30] <robert__> i'll try that, if that don't work i'll try shift, then if not then brb thanks
[21:30] <xteejx> yes purple screen with 2 icons at bottom = press ESC now
[21:30] <robert__> 2 icons?
[21:30] <xteejx> you'll see
[21:31] <robert__> since i installed the beta there's never been 2 icons at the bottom, just on the boot disc
[21:31] <xteejx> then there is something seriously wrong..... I have 4 machines and all of them show the same
[21:31] <micahg> xteejx: seeing purple usually means it's too far...past grub
[21:32] <robert__> at what point to i tap ESC? because there's the purple screen with the orange dots, but no icons at the bottom
[21:32] <xteejx> micahg: My monitor might be on the way out then :P
[21:32] <micahg> xteejx: should be a boot list I thoguht?
[21:32] <xteejx> micahg: Nope not in Lucid Beta 1/2
[21:32] <robert__> there were 2 icons at the bottom when i originally booted the lucid disc before the run options though
[21:32] <micahg> xteejx: I might be out of date
[21:33] <xteejx> micah!! you should be testing!! tut tut lol :P
[21:33] <micahg> xteejx: I'm running xubuntu lucid since beta 1
[21:33] <xteejx> is it any good?
[21:33] <micahg> xteejx: but I still get my grub menu :)
[21:33] <robert__> xteejx, any other ideas or should i look for those 2 icons?
[21:34] <xteejx> i would link a youtube video of the boot process but I don't think it's relevant....if you reboot and look and press ESC you will get the GRUB menu
[21:34] <xteejx> micahg: It's been hidden for ease of use in Ubuntu I think
[21:34] <robert__> xteejx, so press ESC right at the start of power up? i tried that but i'll try again
[21:34] <robert__> do i tap it or hold it?
[21:34]  * micahg will watch more closely in testdrive :)(
[21:34] <xteejx> No
[21:35] <xteejx> not at power up or you'll enter the BIOS
[21:35] <xteejx> When the purple first comes up
[21:35] <charlie-tca> micahg: Xubuntu is different
[21:35] <robert__> actually bios is f2
[21:35] <xteejx> well after the POST then
[21:35] <robert__> tap or hold ESC?
[21:35] <xteejx> just press it
[21:36] <robert__> repeatedly or hold it down?
[21:36] <micahg> charlie-tca: yeah, we're stuck without a new desktop for Lucid :P
[21:36] <charlie-tca> yup, I know... but we also get to see the grub menu easier than Ubuntu
[21:36] <robert__> micahg, you can choose whatever desktop you want :)
[21:36] <robert__> xteejx, should i press it repeatedly or hold it down?
[21:37] <xteejx> one will work, one won't not sure which, try it
[21:37] <robert__> ok thanks brb
[21:37] <micahg> robert__: I choose xubuntu :) I just like new stuff :)
[21:38] <xteejx> micahg: Xubuntu is hardly new lol
[21:38] <xteejx> and please don't confuse the situation any more my heads gonna hit the wall in a minute!
[21:38] <xteejx> lol
[21:39] <micahg> xteejx: referring to teh fact that xfce is stuck at 4.6.x because the schedule was pushed back for 4.8
[21:39] <guntbert> robert__: you could permanently unhide the grub menu by editing /etc/default/grub
[21:39] <xteejx> micahg: really? :( not good
[21:39] <xteejx> i'm waiting for gnome 3
[21:41] <robertzaccour> i tried all 4 of those things none of them worked
[21:41] <robertzaccour> tap ESC, hold ESC, tap tab, hold tab, nothing
[21:42] <robertzaccour> oh look, plymothhd unexpectedly closed again, whatever that means
[21:42] <robertzaccour> tap ESC, hold ESC, tap tab, hold tab, nothing
[21:42] <xteejx> yeah were getting that a lot
[21:43] <robertzaccour> if i'm supposed to be getting grub menu but not, should i reinstall the beta?
[21:44] <xteejx> I don't think that will make a difference
[21:44] <xteejx> I'm gonna reboot and check this out
[21:45] <robertzaccour> ok
[21:45] <robertzaccour> i'm gonna ask about grub menu in #ubuntu+1
[21:45] <seb128> grub menu is on shift now
[21:46] <robertzaccour> really? thanks
[21:46] <seb128> you should press it from boot on
[21:46] <seb128> and not unpress until getting the menu displayed
[21:46] <seb128> easier way to get it
[21:46] <robertzaccour> oh ok
[21:46] <seb128> trying to hit to right instant is not easy
[21:47] <robertzaccour> your right?
[21:47] <xteejx> Right just checked
[21:47] <robertzaccour> xteejx, seb128 said its shift now
[21:47] <robertzaccour> i'm gonna try that brb
[21:47] <xteejx> there is no purple screen, maybe because I dual boot, but the GRUB menu just comes straight up
[21:47] <xteejx> seb128 will be right
[21:48] <robertzaccour> what do you mean right?
[21:48] <robertzaccour> he said shift. and whats right?
[21:48] <seb128> right = correct
[21:48] <xteejx> right=correct
[21:48] <robertzaccour> oh ok thanks
[21:48] <robertzaccour> i was thinkin a button lol brb
[21:48] <seb128> being right = saying something correct
[21:48] <xteejx> thanks seb
[21:49] <xteejx> I was pretty sure it was ESC, sorry to the other guy he said he tried Shift too
[21:49] <maco> grub1 is esc, grub2 is shift
[21:49] <xteejx> Ahhhh, that's why I confused myself ;)
[21:49] <xteejx> it still won't work you realise
[21:50] <xteejx> all that needs done is insert a grub boot option i915 something can't remember it
[22:04] <robertzaccour> my first kernel panic
[22:05] <robertzaccour> it said somethin about kernel panic and not syncing vfs somethin
[22:05] <xteejx> Was that with the boot option?
[22:06] <robertzaccour> xteejx, that was with that i912.powersave=0 i put that in right after the last word in that blah blah blah right next to that last word generic
[22:06] <robertzaccour> yes
[22:06] <xteejx> If so, add that to the report telling them you tested it and what the results were, and that should do for now until they ask for more info if they need it.
[22:06] <robertzaccour> option e in the grub menu
[22:08] <robertzaccour> would this be sufficient? I tried that i915.powersave=0 in the grub menu and got a kernel panic. it said something about not syncing with vfs
[22:08] <xteejx> Yeah that should do it
[22:08] <robertzaccour> xteejx, ok thanks. not sure if there's anything else i can do at this point
[22:09] <robertzaccour> never knew i'd get a kernel panic lol guess they do exist
[22:10] <xteejx> They haven't asked for anything else so just sit tight and see what happens :)
[22:11] <robertzaccour> do you want that bug #?
[22:11] <xteejx> If you have provided the information the triager asked for, then there's no need for me to tread on their toes
[22:12] <xteejx> :)
[22:12] <robertzaccour> oh ok
[22:15] <robertzaccour> i think i did it wrong
[22:15] <robertzaccour> first time i did it just to the right of the word generc
[22:15] <robertzaccour> this time i did it just below that last line of words
[22:15] <robertzaccour> was i right the first time or the 2nd time? this time i didn't get a kernel panic
[22:16] <robertzaccour> so instead of a kernel panic its a user panic about misinformed stuff on launchpad lol
[22:16] <xteejx> it needs to be at the very very right end of the grub line
[22:16] <robertzaccour> xteejx, any spaces between grub and the start of the command?
[22:17] <robertzaccour> i mean the last word
[22:17] <xteejx> the line will already be there with linux= ...... etc at the end of that line leave a space and add the option
[22:17] <robertzaccour> i think it was a /
[22:17] <robertzaccour> lemme check
[22:21] <robertzaccour> ok i made sure it ended like this "generici915.powersave=0"
[22:21] <robertzaccour> is that the correct way?
[22:22] <xteejx> no....
[22:22] <xteejx> I did say leave a space
[22:22] <robertzaccour> oh i'll try that brb
[22:34] <robertzaccour> ok i did it right this time
[22:34] <robertzaccour> here's what i commented on launchpad
[22:34] <robertzaccour> Oops I think I entered it in wrong at the end of the text. At first I didn't leave a space between the end of the last word and the start of i915.powersave=0 and I tried it with a space between the last word and the code I put in and it booted up fine. Now I'm waiting a few minutes to see if it still blinks and will report the results ASAP thanks :)
[22:43] <robertzaccour>
[22:56] <hassanakevazir> Anyone know how can I get more attention for this bug before it makes into the Final Lucid release?:
[22:56] <hassanakevazir> https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/553401
[22:56] <ubot4`> hassanakevazir: Error: Bug #553401 is private.
[22:57] <hassanakevazir> wtf its public
[23:00] <robertzaccour> hassanakevazir, whats wrong with public? you want it fixed right?
[23:00] <robertzaccour> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/555503
[23:00] <ubot4`> Launchpad bug 555503 in xorg-server (Ubuntu) "screen flickers at least once every few minutes (affects: 2) (heat: 12)" [Undecided,Incomplete]
[23:01] <hassanakevazir> robertzaccour, no, it is set in public, at least thats what I see on the report page. can you view it?
[23:04] <robertzaccour> i opened that link it came up
[23:05] <yofel> hassanakevazir: the bot can't distinguish between timeouts and private bugs, that's why it said private, the bug is public
[23:08] <hassanakevazir> Alright, thanks. well, I guess I'll just wait and see what happens.
[23:31] <robertzaccour> here's the bug # i submitted https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/555503
[23:31] <robertzaccour> anything else i can do?
[23:31] <ubot4`> Launchpad bug 555503 in xorg-server (Ubuntu) "screen flickers at least once every few minutes (affects: 2) (heat: 12)" [Undecided,Incomplete]
[23:33] <robertzaccour> anything else i can do?
[23:35] <persia> robertzaccour: I'd suggest changing it from Incomplete to New again: you've added the requested data.  Then wait for a response from a developer.
[23:36] <robertzaccour> persia, how do i change it?
[23:36] <robertzaccour> i did it thanks
[23:40] <persia> Excellent.  I wouldn't know how to explain it if it didn't seem obvious :)


 How do I remove my previous profile(or just clear my desktop preferences)? I have installed Lubuntu to "/" partition with formatting and have retained "/home" partition and have created the same username as before.
[05:58] <duflu> chraso, you can remove most of your settings with: dconf reset -f /
[05:59] <duflu> Although some apps use files instead, mostly ~/.config/
[06:00] <chraso> i'm getting problem with the lubuntu interface mostly
[06:00] <duflu> I don't know what Lubuntu uses but the above two locations will cover most things
[06:00] <chraso>  i'm having a dropdown menu at login screen showing Lubuntu, LXQt Desktop & Openbox as choices. Should i continue with Lubuntu or choose LXQt? currently my login session is Lubuntu and i'm unable to add program shortcuts to Quick Launch panel and neither can add bookmarks to the pcmanfm
[06:01] <duflu> Not sure. I wonder if there's a separate channel for that?
[06:02] <duflu> chraso, try channels #lubuntu or #lxde
[06:03] <duflu> This one is more for Gnome
[06:03] <chraso> i try mostly on lubuntu channel, and it's mostly dead.
[06:03] <duflu> Well, most of the developers are sleeping at this time of day.
[06:04] <chraso> oh ok
[06:05] <chraso> just ran the dconf reset -f /
[06:05] <chraso> will reboot now and relogin and rejoin here
[06:07] <seb128> goood morning desktopers
[06:10] <duflu> Morning seb128
[06:10] <seb128> hey duflu, happy friday! how are you?
[06:11] <duflu> seb128, going OK, other than most of my weekend seems to have been cancelled or about to be. But we are about to receive a cyclone around Sunday. You?
[06:11] <seb128> oh :(
[06:11] <seb128> I'm good thanks
[06:12] <duflu> It shouldn't even be a category 1 by the time it gets down here
[06:55] <didrocks> good morning
[07:01] <duflu> Hi didrocks
[07:03] <didrocks> hey duflu
[07:37] <duflu> Handy. gnome-shell-extension-prefs actually tells you the errors why (Ubuntu) extensions don't work with gnome-shell 3.37
[07:42] <seb128> the cycle started and they already changed things in a way that breaks extensions? :(
[07:49] <duflu> seb128, yes indeed. I was about to say that
[07:50] <duflu> For both ubuntu-dock and desktop-icons
[08:44] <seb128> duflu, technically 'doesn't work under 3.37' is invalid as an Ubuntu report since we don't package 3.37 yet
[08:45] <seb128> (and usually the new stack is prepared as one locked updates so we don't really a bug for tracking the fact that extensions need to be updated)
[08:45] <duflu> seb128, it's not a proper project. I have no choice but to use an Ubuntu bug
[08:45] <duflu> There's nowhere else
[08:46] <duflu> Unless I confirm the same is true for upstream dashtodock
[08:47] <seb128> k, fair enough, still I think we/Marco/upstream dashtodock know and assume the code needs updating every cycle to catch up with GNOME upstream changes
[08:48] <duflu> seb128, yeah I just wanted to notify people early this time instead of waiting till later in the cycle
[08:48] <seb128> but I guess it doesn't hurt to have a bug around restating it
[08:48] <seb128> right
[08:48] <seb128> though it probably makes sense to do it later rather than soon
[08:49] <seb128> if upstream shell changes again, best to do one porting
[08:49] <seb128> that do intermediate work that might be deprecated
[08:51] <duflu> You're assuming the API breaks regularly. I don't know how regular it is
[08:53] <seb128> I'm not assuming everything
[08:53] <seb128> I'm just saying that by doing earlier we risk doing work that is temporary and needs to be redone
[08:53] <seb128> everything->anything
[08:54] <duflu> seb128, I wouldn't advocate leaving all redesigns to late in the cycle
[08:55] <duflu> As a bonus, being forced to use 3.36 instead of 3.37 has just shown me one of my blocking issues seems to be a recent regression in 3.37
[08:55] <duflu> interesting
[08:56] <seb128> I guess there is value to test 3.37 earlier
[08:56] <seb128> but priority atm should still be on 3.36 and to stabilize the LTS
[08:57] <seb128> we should get the nvidia, scaling, rotation, dash creating problems for folder, flickers, etc worked out first
[08:59] <duflu> I am working on a 3.36 bug. But it needs to be developed against 3.37 like everything else
[08:59] <duflu> Also the Nvidia scaling issues are blocked waiting for Marco to fix a couple of common (non-Nvidia) bugs
[08:59] <duflu> As detailed in Trello
[09:00] <seb128> that's still ongoing?
[09:00] <seb128> Trevinho, ^ what's the status
[09:00] <duflu> Yeah, we fixed some bugs, not all
[09:00] <duflu> https://trello.com/c/oY9NYoDp
[09:01] <duflu> Though at 5pm on a Friday I really don't want to go into it
[09:02] <seb128> right, sorry if my comment went the wrong way, I didn't mean that you are doing anything wrong
[09:02] <seb128> I just don't want Marco to get distracted/derailled from the things he works on atm
[09:03] <seb128> once he's done with the scaling problems and maybe the current dock issues then he's free to look at 3.37 compatibility
[09:06] <seb128> Trevinho, duflu, oh, also I don't know if you saw but the gnome-shell 3.36.2 SRU was stopped due to regression being detected in the error tracker, that needs to be sorted out
[09:06] <seb128> https://people.canonical.com/~ubuntu-archive/phased-updates.html
[09:06] <duflu> Boo
[09:07] <duflu> seb128, it's showing as in updates
[09:07] <seb128> one error is not new, it has reports from .1 on the table so just need to Brian's email to see to clear it
[09:07] <seb128> it is
[09:07] <seb128> but phasing is something implemented in update-manager
[09:08] <seb128> it will give the update to n% of the users
[09:08] <seb128> that's to get incremental testing and be able to limit damage if there is a regression detected
[09:09] <seb128> in that case if you look on the page, it started with giving it to 10% and was set back to 0% now due to the regressions detected
[09:09] <seb128> the algorythm is buggy/suboptimal
[09:09] <duflu> seb128, one of the errors is what I proposed a fix to Salsa yesterday for
[09:09] <seb128> that's the xcb one right?
[09:09] <seb128> that's not a regression and shouldn't block the SRU
[09:09] <duflu> Correct
[09:10] <seb128> it's just the code logic is 'if no report with the version just before and then a report from the SRU then it might be a regression"
[09:10] <duflu> seb128, but localization of the assertion string makes it look like a new bug
[09:10] <seb128> well, https://errors.ubuntu.com/problem/d0b522b2800fadad804175817218d4a81fa27ea4
[09:10] <seb128> it had reports from previous version
[09:10] <duflu> And I can't make a bug for it due to bugs in errors.ubuntu.com
[09:10] <duflu> Which also has a bug
[09:10] <seb128> just not from the previous SRU that wasn't look in updates
[09:10] <seb128> anyway, https://errors.ubuntu.com/problem/ed05979081de9b66eac4a9eaa25e51fac88e43a3 seems it had no report before
[09:11] <seb128> so that needs investigation
[09:11] <duflu> Yeah looking
[09:12] <seb128> wasn't look -> wasn't long
[09:12] <seb128> anyway, the upload get emails about those issues so I guess Trevinho should be aware
[09:13] <duflu> seb128, the remaining issue is bug 1877760
[09:13] <duflu> which sounds like it might already be fixed in 3.36.3
[09:14] <seb128> was it a regression in .2?
[09:14] <seb128> if so we probably need another SRU
[09:15] <duflu> seb128, don't know but the other one seems to be specific to dash-to-panel
[09:15] <duflu> though the fix is in gnome-shell
[09:15] <seb128> duflu, anyway, don't worry about it on a friday evening
[09:15] <seb128> that's probably for next week and for Trevinho
[09:17] <duflu> seb128, I have been triaging those regularly. I think the fix in 3.36.3 covers both
[09:17] <seb128> thanks
[09:18] <seb128> .3 is due next week, we can probably wait for that
[09:21] <duflu> Ha. I may yet have to fix that bug in the errors.ubuntu.com website to reduce some of the confusion
[09:21] <duflu> Maybe not
[09:23] <seb128> tjaalton, thanks for the SRU review, could you review also network-manager/focal as it's trivial (fixing the path to iptables which breaks hotspot on systems without usrmerge) and maybe gnome-shell-extension-desktop-icons if you have some extra cycles?
[09:24] <seb128> libproxy and gnome-logs also are some trivial patches updates if you really feel like doing SRU reviews :)
[09:24] <seb128> but they are not important so don't consider those as nagging material
[09:25] <tjaalton> seb128: sure
[09:26] <seb128> thx
[09:28] <tjaalton> seb128: network-manager is already in proposed, should that get moved to updates first?
[09:28] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1733321
[09:29] <tjaalton> though it's friday so that would need to wait for next week
[09:41]  * duflu runs away to the weekend, before anything else goes wrong
[09:57] <seb128> tjaalton, it was marked block-proposed since it's only autopkgtest fixes and isn't needed for users
[09:58] <seb128> so I think it's fine to accept the new one over the existing SRU
[10:17] <tjaalton> okay
[10:49] <Trevinho> seb128: hey, as per dufu comments, non-nvidia bugs aren't something I've been able to reproduce so far, I remember I saw them in the early ages of the patch (like 3 cycles ago), not sure if I dind't take in account some changes in the latest iterations, but nothing pointed me there.
[10:50] <Trevinho> so, mostly not be able to reproduce or find the culprit so far :(
[11:01] <Trevinho> as per the things blocking g-s in proposed, I've triaged the one we've an upstream fix for, not sure we can handle https://errors.ubuntu.com/problem/d0b522b2800fadad804175817218d4a81fa27ea4 instead, nor it seems particularly new
[11:02] <Trevinho> looking better though
[11:02] <Trevinho> ah, indeed we've it
[11:03] <Trevinho> uff it's actually https://bugs.launchpad.net/bugs/1877075 but I can't create an error for that -_-
[11:03] <Trevinho> i.e. a bug from e.u.c (it fails for some reason)
[13:31] <seb128> Trevinho, hey, right, that's what duflu said earlier, that one should be fixed with  and isn't a regression, the other one does sound like a new issue in  though, at least e.u.c shows only reports from that version (but maybe it existed and it fails to match them or the signature changed?)
[13:31] <Trevinho> seb128: no, it's a regression
[13:31] <seb128> Trevinho, in any case duflu suggested that the issues were fixed with  so another week and we do another SRU round I guess?
[13:31] <Trevinho> I've marked upstream fixes for that
[13:32] <Trevinho> yeah, I can prepare it now but not sure if waiting a bit longer for more reports?
[13:34] <seb128> Trevinho, we will not get a SRU approved on a friday/long w.e so I think that can wait next week now
[13:59] <ricotz> hello desktopers :)
[13:59] <ricotz> seb128, hi :), I hope this still on your list - https://bugs.launchpad.net/ubuntu/+source/vala/+bug/1874127
[14:04] <seb128> ricotz, hey, https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=vala
[14:04] <seb128> sorry, I should have updated the bug
[14:05] <ricotz> seb128, I see, yeah, I assume some comment in the bug and subscribing ubuntu-release
[14:05] <seb128> subscribing is not needed since they work from the upload queue
[14:05] <seb128> but I should have commented, sorry about that, done now :-)
[14:05] <ricotz> ah ok, then dropping ubuntu-sponsors ;)
[14:06] <seb128> right, done now
[14:06] <ricotz> seb128, thank you
[14:06] <seb128> yw!
[17:16] <hellsworth> ricotz: 6.4.4 looks fine to me but the arm builds fail. the first amd64 and armf builds failed because of builder failure (with no log, even though it took 9 & 18 hours to fail)
[17:16] <hellsworth> are your arm builds of libreoffice 6.4.4 failing?
[17:17] <ricotz> hellsworth, look are prereleases ppa
[17:17] <ricotz> at
[17:19] <hellsworth> right hmm ok thanks
[17:20] <ricotz> hellsworth, good, I will be back later or tomorrow
[17:20] <hellsworth> ok thanks!
[19:09] <tsimonq2> Laney, et. al: https://salsa.debian.org/lintian/lintian/-/commit/aeea7148d5f3ea18f449cbb05bde8d982e6698ff \o/
[19:37] <tsimonq2> Debian bug 961294 submitted too.


[19:31] <webchat12> Hi, after upgrading to 22.04 I have problems to connect with global protect. When signing in I have this error "SSL handshake failed"
[19:32] <webchat12> I'm kde
[19:32] <lotuspsychje> webchat12: upgrading from wich ubuntu release?
[19:32] <webchat12> from 21.10
[19:33] <webchat12> everything was ok, now I can't connect with global protect cause the login (via web view) fails after entering credentials
[19:33] <lotuspsychje> webchat12: at this stage, its not adviced yet to upgrade to 22.04, instead the current testers use daily iso's
[19:33] <webchat12> and I can't connect to servers when using another vpn client
[19:34] <webchat12> what has changed at SSL level ???
[19:34] <lotuspsychje> clean install a daily iso webchat12
[19:34] <webchat12> I will try but I'd like to fix this
[19:36] <webchat12> the other vpn connects correctly but fails when I try an rdp with  - transport_connect_tls:freerdp_set_last_error_ex ERRCONNECT_TLS_CONNECT_FAILED
[19:36] <webchat12> I guess something is broken at distro level, not my installation
[19:38] <Maik> 22.04 is a development version, it's normal at this stage things break
[19:39] <webchat12> whereelse I could ask '
[19:39] <webchat12> ?
[19:39] <sarnold> I suggest filing a bug report -- maybe it's just expected tightening of security levels, or maybe it's something unexpected in a library transition
[19:46] <webchat12> ok I'll do it


[03:47] <noodles785> I was wanting to experiment adding egress rules to all units in an environment. I can't do that via constraints or similar juju functionality right? (I'm assuming I'll need to update the default secgroup for the env, which will only work when deploying to openstack/aws, not local)
[04:11] <rick_h_> noodles775: you could add a subordinate, I've thought of doing that
[04:11] <rick_h_> noodles775: having a egress filter subordinate that get attched in dev/qa to create firewall rules manually
[06:46] <noodles775> rick_h_: yeah - I was hoping to do it outside the units themselves (ie. secgroups), but wanted to check whether it's something juju manages (I'm assuming not). Thanks!
[06:47] <rick_h_> noodles775: I don't think so atm
[15:30] <skay> I think the charm helper docs for charm create are out of sync with the package, but could use a sanity check. here's what results from following the docs, http://paste.ubuntu.com/9125147/
[15:30] <skay> expected behavior should be http://pythonhosted.org/charmhelpers/getting-started.html#creating-a-new-charm right?
[15:35] <tvansteenburgh> skay: too many "create" in your commands
[15:36] <lazyPower> skay: are you looking at using the services framework as well
[15:36] <lazyPower> the python-basic template is more likely what you're looking for.
[15:36] <skay> lazyPower: when I tried to use the -t to specify a template, I got a usage error
[15:37] <tvansteenburgh> skay you have "charm create create"
[15:46] <skay> tvansteenburgh: woohoo, I like it when it's a typo instead of a complete crazy misunderstanding
[15:46] <tvansteenburgh>  :)
[15:47] <skay> lazyPower: python-basic is indeed what I was looking for (it also looks like the docs should indicate python-basic for hte template rather than python?)
[15:47] <skay> thanks all
[15:48] <lazyPower> skay: It's a bit confusing I agree - python being an alias for the services framework.
[15:49] <skay> lazyPower: for feedback: when I use the python template the dir tree does not resemble the dir tree on the docs.
[15:50]  * tvansteenburgh makes a note to update docs
[15:50] <tvansteenburgh> thanks for pointing that out skay
[15:50] <skay> tvansteenburgh: I wasn't sure if I should open an issue in case I had misunderstood something. thanks for helping.
[15:51] <tvansteenburgh> sure thing
[15:54] <skay> avoine: adding support for pip_extra_args in order to use --no-index --find-links=/some/path, isn't as straight forward as I thought due to pip not being able to find /some/path.
[15:55] <skay> avoine: I am not sure exactly what to do, and maybe I need to write a subordinate charm to populate /some/path on the python-django unit?
[15:55] <skay> because I don't think that functionality belongs in python-django
[15:56] <skay> I think adding support for pip_extra_args belongs, and python-django would just pass that to pip
[15:56] <skay> and it would be the responsibility of something else to ensure the path is reachable
[16:21] <avoine> skay: Have you tried to upgrade pip?
[16:23] <skay> avoine: I did try, that did not resolve the problem. (and also would be a problem if one applies pip_extra_args to all calls, if it is the case that the existing pip doesn't support the extra args, but while I investigated I introduced a temp kluge to ignore it when installing pip)
[16:31] <avoine> skay: just to be sure I understand, your installing a tar archive with your django project + your dependencies and then your pointing pip ... --find-links to your dependencies dir, right?
[16:32] <avoine> also pip don't need to be upgrade on trusty since "Added support for bare paths (including relative paths) as argument to –find-links" was added in version 1.3 and trusty is 1.5.4
[16:32] <skay> avoine: not exactly. I tarred up my django project and had dependencies in the local file system. oh derp, I should just tar them up too?
[16:32] <skay> avoine: I'm using precise at the moment (I thought the gunicorn charm was precise, but if I'm mistaken I can use trusty)
[16:34] <avoine> gunicorn is in trusty too
[16:34] <avoine> skay: how do you add your dependencies, with scp?
[16:35] <avoine> –find-links needs a dir where dependencies are already downloaded
[16:35] <skay> avoine: no, I ignorantly thought that juju would be able to provide access to them in the local file system
[16:35] <avoine> oh like vagrant does
[16:35] <avoine> ?
[16:35] <skay> yeah
[16:35] <avoine> no indeed it's not
[16:35] <avoine> I would put them in the tar
[16:36] <skay> yes, it is clear to me now
[16:36] <skay> this is simpler.
[16:36] <skay> thanks for walking me through that
[16:36] <avoine> but I think that's a feature they want to add
[16:36] <avoine> that would be usefull
[16:38] <avoine> lazyPower: mounting local directory inside a local deployement (with nfs for example) is still a feature you wanted to add to juju?
[16:39] <lazyPower> avoine: we found a work around as documented in the NFS charm
[16:39] <avoine> cool
[16:39] <avoine> skay:  ^
[16:39] <skay> o/
[16:39] <lazyPower> it requires some manual intervention - so adding something without the manual intervention would be nice - but i can see it as being lower priority
[16:40] <lazyPower> skay: https://jujucharms.com/nfs/trusty/0 - take a look at "On the LXC host" in the readme
[16:41]  * skay takes a look
[16:42] <avoine> I guess that would be a good use case for a juju plugin
[16:52] <jw4> lazyPower, avoine this sounds like what Juju Actions is intended for
[16:53] <lazyPower> jw4: i dont think actions will be able to modify the HOST on behalf of the user.
[16:53] <lazyPower> those particular edits take place on the LXC host so the containers can receive the nfs kernel modules - otherwise apparmor blocks them
[16:54] <jw4> lazyPower: I see - and actions run in the context of the units
[16:54] <lazyPower> correct
[16:55] <lazyPower> actions are intended to be helpers that dont necessarily belong in the hooks - like database backups, adding users to an app, etc.
[16:55] <jw4> lazyPower: oh well.  I got excited for a minute there
[17:19] <avoine> I forgot, is there a way I can get the data of a relation outside a hook or with a juju command?
[17:31] <avoine> juju-run on the vm did the trick
[18:41] <mwenning> hi juju team, can anyone help with a juju hang problem?
[18:47] <lazyPower> mwenning: hey o/ whats going on with juju?
[18:49] <mwenning> lazyPower, hi, I'm running juju bootstrap --debug -e maas and it hangs for 10 min and then fails with a timeout
[18:50] <lazyPower> mwenning: are the units still spinning up? iirc you're working in a pure hardware environment
[18:50] <mwenning> I'm pretty sure I didn't set the proxy right, but it won't take the right value anymore.
[18:51] <mwenning> juju destroy-environment --debug --force maas also hangs
[18:51] <mwenning> stby I'll get a pastebin
[18:51] <jose> mwenning: is it still giving the 502?
[18:51] <mwenning> yes.
[18:52] <jose> huh
[18:52] <mwenning> after I set the proxy correctly it worked for awhile, now it's hung again
[18:52] <mwenning> s/hung/hanging
[18:54] <mwenning> https://pastebin.canonical.com/120815/
[18:55] <mwenning> lazyPower, jose, it hangs at line 9 for probably 10 min, then dumps the rest of that stuff.
[18:56] <jose> mwenning: lazyPower will give you a hand with this - cannot access canonical services and I wouldn't risk pasting any private details on a public site
[18:56] <mwenning> jose, ok thx
[18:58] <lazyPower> mwenning: can your workstation reach the node its attempting to bootstrap when you just activate it in the MAAS gui?
[18:58] <mwenning> lazyPower, yes, maas works fine, I can start/stop all my nodes
[18:59] <jcastro> is `instance-type` ignored in environments.yaml?
[18:59] <lazyPower> mwenning: and workstation connectivity to the nodes works as well?
[18:59] <jcastro> I put m3.mediums but it's asking for m1.smalls
[18:59] <lazyPower> jcastro: thats a depreciated constraint
[18:59] <lazyPower> you should add proper constraints
[18:59] <mwenning> lazyPower, yes, I can ssh into all the nodes from my maas server
[19:00] <jcastro> I thought we were putting it back in?
[19:00] <jcastro> or at least defaulting to m3's?
[19:00] <lazyPower> mwenning: hmm... this is troubling
[19:00] <lazyPower> mwenning: which juju revision are you on? 1.20.x i assume?
[19:01] <mwenning> juju-core 1.20.11
[19:01] <lazyPower> ok, latest stable
[19:01] <lazyPower> hmm this sounds like a reachability issue though
[19:02] <mwenning> what's wierd is that it doesn't seem to take anything from environments.yaml or environments/maas.jenv
[19:03] <jose> what do you mean?
[19:03] <mwenning> I tried changing bootstrap-timeout to 120  and it didn't take it.
[19:04] <mwenning> I've got http-proxy and https-proxy set in the environments.yaml, that should point to the correct proxy but it doesn't seem to pay attention
[19:05] <mwenning> Is there somewhere else that juju is reading that info?
[19:06] <lazyPower> mwenning: im' asking for a core dev to come take a look with us - 1 moment
[19:06] <lazyPower> i'm not using any proxies and have limited interaction with using a proxy in juju
[19:10] <mwenning> hmm, what the heck?  It's trying to access <IP_ADDRESS>/MAAS .
[19:10] <mwenning> That's not my MAAS server, it's at <IP_ADDRESS>
[19:10] <lazyPower> mwenning: stale maas jenv?
[19:10] <mwenning> where is that?
[19:11] <mwenning> where is maas.jenv?
[19:11] <lazyPower> ~/.juju/environments/maas.jenv
[19:11] <jose> tvansteenburgh: ping, mind a quick pm?
[19:11] <tvansteenburgh> jose: sure
[19:12] <mwenning> actually maas.jenv is gone.
[19:15] <lazyPower> mwenning: ok so if its not reading a stale jenv file - something else is awry
[19:15] <lazyPower> can you verify the server config in environments.yaml is the correct ip address?
[19:17] <mwenning> I lazyPower , yes.  stby I'll paste the whole thing
[19:18] <mwenning> https://pastebin.canonical.com/120819/
[19:22] <lazyPower> mwenning: do you have another PROXy export set?
[19:22] <lazyPower> echo $JUJU_PROXY i think
[19:23] <mwenning> lazyPower, $JUJU_PROXY shows nothing
[19:23]  * lazyPower snaps
[19:23] <lazyPower> that was the last thought i had on what it could be
[19:23] <lazyPower> i unfortunately dont know why you're seeing that behavior :(
[19:24] <mwenning> lazyPower, ok.  I've got to drive downtown to a meeting, I'll look at this later
[19:25] <jcastro> hey bcsallerm can you add your +1 to this bug?
[19:25] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1373516
[19:25] <mup> Bug #1373516: Switch default instance type from m1.small to t2.small/m3.medium for EC2 provider <ec2-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1373516>
[19:27] <jcastro> hey natefinch, can we get this on someone's radar? ^^^^
[19:27] <jcastro> This will only get worse and worse
[19:33] <mwenning> lazyPower, if you can think of anywhere that juju might be cacheing that information please let me know, that's all I can figure
[19:34] <lazyPower> mwenning: my only other suggestion is to do a full env dump and sift through whats in there
[19:34] <lazyPower> juju reads from env => .jenv => environments.yaml - in that order.
[19:35] <mwenning> lazyPower, do you know if it reads http_proxy in the env?
[19:35] <lazyPower> i believe so
[19:36] <mwenning> ok, I think that's new, but I've set it there too.
[19:36] <natefinch> jcastro: I think we addressed that... lemme double check, thought I saw that in the 1.21 release notes
[19:37] <natefinch> jcastro: hmm. maybe not
[19:39] <natefinch> jcastro: it's definitely on our radar.  I'll see if I can get someone to put a little time into fixing it.  I think the main problem we had was that there wasn't really a no-brainer replacement.  both t2.small and m3.medium had slight problems (I believe t2.small is a burstable instance, and m3.medium is slightly more expensive)
[19:39] <jcastro> yeah
[19:40] <jcastro> it was just reiterated to us that m1's are going away much faster than we thought
[19:40] <natefinch> jcastro: personally, I'd just go with m3.medium.... it's not our fault amazon doesn't have cheap prices :)
[19:40] <natefinch> (for reasonable machines)
[19:41] <natefinch> jcastro: I'll bring it up right now.  I agree it needs to get fixed ASAP.  Of course, the problem is that it won't be fixed in older jujus
[19:41] <jcastro> I'd rather have people pay more than having it not work because m1's are being culled
[19:41] <natefinch> yep
[19:41] <natefinch> jcastro: we also should handle that error better by requesting from a different AZ in the region and/or trying a different instance type
[19:43] <natefinch> jcastro: who said the m1's are going away faster?  Just want to give proper attribution.
[19:43] <jcastro> ben and robert
[19:43] <jcastro> aka the CPC team
[19:43] <jcastro> robert filed the initial bug
[19:50] <natefinch> jcastro: just sent a mail to juju-dev.  Assuming no one objects, I'll try to make sure someone gets on it ASAP.
[19:50] <jcastro> -<3 thanks