[11:53] <creepancake> Hello everybody, I'm looking for help with Lubuntu..anyone willing to?
[12:00] <diogenes_> !ask | creepancake
[12:09] <creepancake> I recently installed lubuntu on a Asus E200HA netbook, everything works fine except for video and audio streaming, tried on firefox, chrome and chromium. Videos on youtube are laggy and without audio. On win 10 I did not have those problems so I excluded an hardware related issue. The netbook has an Intel Atom x5-Z8300 with integrated graphics and 2GB RAM. Thanks in advance
[12:10] <guiverc> creepancake, what release of Lubuntu?
[12:10] <creepancake> 18.04
[12:10] <guiverc> 18.04, 18.04.1, 18.04.2, 18.04.3?
[12:11] <guiverc> (I'm asking if you are using HWE or the later kernel & software stack which will contain later drivers esp. video..)
[12:12] <creepancake> 18.04.3
[12:12] <guiverc> creepancake, if you're near or on box; uname -r will say 4.15 is older ISOs were used; 5.0 if ...  :)
[12:13] <creepancake> 5.0.0-37-generic
[12:14] <guiverc> yep & thanks... thinking... If you `sudo lshw -C video`  (list hardware of class video) what is your video "driver=" listed as?
[12:16] <creepancake> driver=i915
[12:17] <guiverc> okay; written by intel so hopefully they know your intel card..  unless wrongly detected it shouldn't be reason for video I suspect...
[12:18] <creepancake> I'm not sure of that, it comes with product: Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration
[12:18] <creepancake> looks pretty generic
 Have you tried streaming in vlc?
[12:19] <guiverc> one link says "sudo apt-get install chromium-codecs-ffmpeg-extra" for chromium (https://askubuntu.com/questions/1095347/some-videos-have-sound-and-some-have-no-sound-on-ubuntu-18-04); but follow @HMollerCl's direction
[12:20] <guiverc> (my last won't impact other browser you mention so unlikely it)
[12:23] <creepancake> i'll try, thank you. @HMollerCl I didn't try vlc, honestly I'd like to access directly from browser, the other users in the family may have difficulties with vlc
 Currently there is no hw acceleration in chromium, chrome nor Firefox in linux, but there is in vlc.
 There is an experimental version of chromium with hw acceleration, but it's not stable
 If your CPU relies heavy on gpu for decoding, might be an issue
[12:26]  * guiverc : Sorry I've found nothing else useful online
[12:29] <creepancake> @guiverc thanks, installed the codecs in chromium but nothing happened. @HMollerCl i'll try both vlc and the unstable version of chromium, do you have a link for it?
[12:33] <creepancake> vlc is also laggy and no audio
 Do you have audio on other things?
 Will look experimental chromium
[12:36] <creepancake> not anymore, yesterday played music on audacious with no problems
 I've read that chromium snap (instead of apt) has hw acceleration by default
 If you have apt chromium unistall it and install the snap onr
[12:39]  * guiverc was thinking same thing (try snap),  if it's no better, I'd remove snap & return to deb version (snap will have some overhead, but will ensure latest software is being used)
[12:40] <creepancake> ok i'm trying
[12:54] <guiverc> creepancake, there is a snap of firefox, I haven't used it - but it maybe worth trying too (snapped by Mozilla) -- (I've no better ideas)
[17:46] <sebastian_> hey
[17:46] <sebastian_> what's up


[04:29] <mup> PR snapcraft#2714 closed: tests: completely mock mercurial tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2714>
[10:38] <mup> PR snapcraft#2715 closed: Unit 7z <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2715>
[15:46] <mup> PR snapd#7411 closed: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7411>


[12:04] <Tm_T> libqt4-debug - Qt 4 debugging runtime libraries :)
[12:05] <seth_k> yeah, Riddell... the Debian diff makes changes outside debian/, so I have to apply those by hand?
[12:06] <Tm_T> Riddell: thanks :)
[12:11] <Riddell> Tm_T: make some .debs for us :)
[12:11] <Tm_T> aww, ok, configure went trough, but still cant compile kdelibs4...
[12:11] <Riddell> sebas: that pyqt tutorial would make a good dot story
[12:11] <Tm_T> Riddell: from kde trunk stuff?
[12:12] <Tm_T> actually I thought to make deb from kopete as soon as we get msn protocol working =)
[12:12] <Tm_T> but without kdelibs4 I cant help getting it working
[12:13] <Riddell> Tm_T: what's wrong with msn?
[12:13] <Tm_T> http://kubuntu.pastebin.com/454795
[12:14] <Tm_T> Riddell: afaik in trunk kopete it doesn't compile
[12:14] <Tm_T> Riddell: so said duncan, and asked if I can help
[12:15] <Riddell> ok
[12:15] <Tm_T> that was weeks ago, dunno if it fixed already :p
[12:18] <Riddell> seth_k: what changes?
[12:18] <Riddell> seth_k: if it's just Makefile.in stuff they can be ignored
[12:19] <seth_k> Riddell, there're also some po change stuff
[12:19] <seth_k> in the German translation
[12:20] <Riddell> seth_k: in the diff?  evil
[12:20] <Riddell> seth_k: either ignore it or turn it into a patch
[12:20] <seth_k> Riddell, that and some configure.in.in stuff... and without the configure goodies, it doesn't compile. I'll turn it into a patch :)
[12:21] <seth_k> that's why I didn't just copy debian/ dir before, b/c it changed other stuff
[12:21] <seth_k> and I hadn't done one of those before, where it wasn't either a simple uupdate -u or debian/ copy
[12:22] <allee> seth_k: what pkgs are you talking about?
[12:23] <seth_k> allee, this is Krusader 1.60.0-3 from Debian
[12:23] <allee> are the makefile changes in a file called 98_buildprep.diff?
[12:29] <allee> seth_k: maintainer added maintainer mode to configure.in.in.  So he had to rerun make -f Makefile.cvs
[12:30] <seth_k> allee, yeah, I saw that after my build failed complaining about maintainer mode. Should I make that change in a patch?
[12:32] <allee> seth_k: well I prefer all changes as debian/patches/XX_describe_wnat_I_do.diff
[12:32] <seth_k> yep
[12:32] <seth_k> that was my plan, so I guess I'll go ahead and do it that way
[12:33] <allee> seth_k: do you know the create-buildprep script?
[12:34] <seth_k> allee, no
[12:34] <allee> its in alioth pkg-kde repo in scripts.
[12:34] <Flosoft> what is the command for a dist upgrade with apt?
[12:34] <allee> apt-get dist-upgrade
[12:35] <allee> seth_k: you apply it to a clean source + debian dir.  run make -f Makefile.am and places everything in debian/patches/98_buildprep.diff
[12:36] <allee> seth_k: this way you always have those hundreds of autogenerated hunk in one diff file.
[12:36] <Riddell> can't say I see much advantage in 98_buildprep.diff myself
[12:36] <Riddell> make -f Makefile.cvs, not .am
[12:37] <Riddell> or admin/Makefile.common
[12:37] <allee> Riddell: ops right.
[12:38] <Flosoft> well ... nite @ all
[12:38] <allee> Riddell: when one lsdiff of diffstat on krusader diff the advantage of build_prep.diff is obvious.
[12:41] <allee> ah, and after build_pref.diff is filtered out, interdiff is usable again too.
[12:41] <allee> nevertheless everyone has his own like/dislikes.
[12:42] <allee> nite all, seth_k wish you much success ;)
[12:45] <seth_k> okay Riddell, almost done now. I patched de.po and configure.in.in with patches in debian/patches :)
[12:45] <Riddell> awooga
[12:46] <seth_k> now I just need to make sure it makes a .pot file
[12:46] <Riddell> have you edited debian/rules for it?  (or is it cdbs?)
[12:46] <seth_k> I just added in cdbs, to do my patches
[12:46] <seth_k> so that's what I'll use
[12:47] <seth_k> but what was the part about "If you use cdbs in dapper your package should now do this automatically"
[12:47] <seth_k> I don't have to make any more changes other than just adding in cdbs?
[12:48] <Riddell> if you use the kde.mk file that'll include the rules to make the .pot
[12:48] <Riddell> otherwise you need to add them, you can just copy them
[12:48] <seth_k> preference?
[12:48] <Riddell> and you need the patch for cvs.sh
[12:48] <Riddell> if it's a KDE package I'd expect it to use kde.mk anyway
[12:49] <seth_k> ok
[12:49] <seth_k> and CVE-2005-3856 for the win
[12:53] <seth_k> Riddell, do I keep the name kubuntu_01_kdepot.diff and just put that file in debian/patches ?
[12:53] <Riddell> seth_k: yes
[12:53] <Riddell> seth_k: assuming it applies, there's lots of different versions of cvs.sh you may have to adapt it
[12:53] <seth_k> sure
[12:54] <seth_k> and I don't see any kde.mk
[12:54] <Riddell> in /usr/share/cdbs/..
[12:54] <seth_k> right, but it's not included in debian.rules, that means I should include it?
[12:54] <seth_k> *debian/rules
[12:56] <Riddell> could do, we don't want to deviate too much from debian but then we already have with this package so may as well
[12:56] <seth_k> ok
[12:56] <Riddell> and e-mail the debian maintainer, politely tell him how to package properly :)
[01:01] <seth_k> haha, will do
[01:02] <seth_k> okay, I ended up applying the cvs.sh changes by hand into a new patch, because the admin/ directory was a bit older than your patch's version
[01:02] <Riddell> not too surprising
[01:21] <seth_k> All right, now only one more thing. I need to make -f Makefile.cvs, how do I do that without dirtying my pristine source
[01:21] <Riddell> my way would be to dirty the pristine source, allee's way would be to take a copy, make -f Makefile.cvs and diff -urN the two and put that in 98_buildprep.diff
[01:22] <seth_k> how about using cdbs-edit-patch, won't that watch the difference for me and make a diff?
[01:22] <Riddell> should do yes
[01:22] <seth_k> ok :)
[01:25] <seth_k> I'm totally a fan of pristine source, but is that just overkill in your opinion? It *is* going to increase the ubuntu1 diff size considerably
[01:26] <Riddell> not really any way around that
[01:29] <raphink> Riddell: did you have the time to look at some of my packages?
[01:44] <Knowerrors> Hey all, Im stuck on a modem connection and just spent alot of time upgrading to kde 3.5 to have it not work proper on some things... can I use the K 5.10 cd to downgrade?
[01:45] <Riddell> yes
[01:46] <Knowerrors> how would I do that?
[01:47] <Riddell> remove libqt3-mt
[01:47] <Riddell> remove kubuntu.org from sources.list
[01:47] <Riddell> put in CD, apt-cdrom it, install kubuntu-desktop
[01:50] <Knowerrors> Im not sure it will solve my issues though, so I got on here as a last ditch to try to fix things manually
[01:51] <Knowerrors> Riddel: prob#1- going to system settings, I am unable to change settings for gtk-looknfeel, and storage media notifications...
[01:52] <Knowerrors> Riddel: prob#2- kde mounts things in system:/media, but I can't browse files there, I must go to /media/ to browse them
[02:01] <Riddell> I can't recreate either problem
[02:03] <raphink> Knowerrors: fresh install?
[02:03] <raphink> gone :(
[02:03] <raphink> Riddell: did you have the time to look at some of my packages?
[02:03] <Riddell> raphink: doing now
[02:03] <raphink> Riddell: thanks :)
[02:04] <raphink> wb Knowerrors
[02:04] <raphink> Knowerrors: what is your install history?
[02:04] <raphink> is it fresh?
[02:04] <Knowerrors> Ive had this install running for about 4 months or so
[02:04] <Knowerrors> I started with kubuntu 5.10
[02:05] <raphink> hmm
[02:05] <raphink> kubuntu 5.10 was released less than 4 months ago
[02:05] <raphink> as stable I mean
[02:05] <raphink> ;)
[02:05] <raphink> it's the last stable version, released in october
[02:05] <raphink> (as the 10 indicates)
[02:06] <Knowerrors> hmm, it feels like longer ;)
[02:06] <raphink> haha
[02:06] <raphink> so you basically didn't dist-upgrade it
[02:06] <Knowerrors> correctamundo
[02:06] <raphink> or had it through big upgrades
[02:07] <Riddell> raphink: kyamo fails to compile
[02:07] <Riddell> make[3] : *** No rule to make target `kyamo.pot', needed by `all-am'.  Stop.
[02:07] <raphink> really?
[02:07] <raphink> :(
[02:07] <raphink> insteresting
[02:07] <raphink> I'll have a look at it
[02:07] <raphink> it's rc3 right Riddell ?
[02:08] <Riddell> yes
[02:08] <Riddell> from revu
[02:08] <Knowerrors> when I first did my install, I enabled root for a couple days cause I was used to regular Debian and missed root, then someone told me that was bad and I turned it off
[02:08] <raphink> weird
[02:08] <raphink> I'll check it
[02:09] <raphink> I'll try it in my pbuilder
[02:09] <Knowerrors> ever since then, I had problems with the kcontrol not keeping certain settings, unless I ran it as sudo kcontrol from cli
[02:09] <raphink> I'm pretty sure I had tried it in a pbuilder before uploading it though
[02:09] <raphink> Knowerrors: put root again and don't use it
[02:10] <raphink> never know if that helps ;)
[02:10] <Knowerrors> hehe, yeah tried that already :(
[02:10] <raphink> doesn't work?
[02:12] <raphink> let's see... pbuilder updated
[02:12] <Riddell> raphink: where is the postinstall file from in kubuntu-grub-splash?
[02:12] <Riddell> raphink: and are all the files definatly GPL?
[02:13] <raphink> the files are GPL (checked on kde-apps.org)
[02:13] <raphink> and the postinst is in debian/
[02:13] <raphink> was last time I checked ;)
[02:13] <raphink> at least
[02:13] <raphink> argh my internet is sloooooooooow
[02:14] <raphink> getting crazy with it
[02:14] <seth_k> blast it Riddell, this package is on crack :)
[02:14] <seth_k> /tmp/buildd/krusader-1.60.1/./krusader/DiskUsage/radialMap/widget.cpp:12:20: error: Config.h: No such file or directory
[02:14] <seth_k> /tmp/buildd/krusader-1.60.1/./krusader/DiskUsage/radialMap/widget.cpp:13:19: error: debug.h: No such file or directory
[02:14] <seth_k> /tmp/buildd/krusader-1.60.1/./krusader/DiskUsage/radialMap/widget.cpp:14:22: error: fileTree.h: No such file or directory
[02:14] <seth_k> I've applied patches to let it build on gcc4 already
[02:15] <raphink> Riddell: kubuntu-grub-splashimages.postinst is the postinstall
[02:15] <raphink> I knwo using the package name is not mandatory ;)
[02:15] <Riddell> raphink: but did you write it?
[02:15] <raphink> Knowerrors: maybe you could ask in `norma' help channels
[02:15] <raphink> Riddell: yes I did, why?
[02:15] <Knowerrors> raphink: whats 'norma' ?
[02:15] <raphink> Knowerrors: s/norma/normal/
[02:16] <raphink> Riddell: don't like it?
[02:16] <raphink> Knowerrors: here is a development channel, normal help channels such as #kubuntu might be nicer for your issue
[02:16] <Knowerrors> you mean #kubuntu?
[02:16] <raphink> imo
[02:16] <Riddell> raphink: it's just that if I'm to review this properly I should probably try and understand the script, which I don't feel like doing just now
[02:16] <Riddell> raphink: can you describe to me what it does briefly?
[02:16] <Knowerrors> right, yeah, Ive been asking there too but nobody knows
[02:17] <raphink> Riddell: sure
[02:17] <Riddell> seth_k: do you get that error with the pristine sources?
[02:17] <raphink> 1) it tests if grub was installed properly, by testing /boot/grub/device.map
[02:17] <raphink> if device.map doesn't exit, it exits the script
[02:17] <seth_k> Riddell, I tried it with pristine + patch and with dirty source
[02:17] <seth_k> Riddell, maybe it's a KDE 3.5 incompatibility? That's the only similar explanation I can find on their forums
[02:18] <Riddell> seth_k: and do you always get that error?
[02:18] <raphink> 2) if device.map exists, it guesses the grub partition using it with a dh -f to get the partition for /boot, so as to know where the splashimages are installed
[02:18] <seth_k> as in every time I try the build? yes
[02:18] <raphink> 3) it installs the the splashimage line in grub.conf from these infos
[02:18] <Riddell> seth_k: do those header files exist?
[02:18] <Knowerrors> Riddle, is there a way to just reload the default settings for all of kde 3.5 and or kubuntu?
[02:19] <raphink> Riddell: the old grub.conf is saved with a date stamp
[02:19] <raphink> and I use a safe temp file for the modifications on grub.conf
[02:19] <seth_k> Riddell, yes, all three exist
[02:20] <seth_k> Riddell, they exist in /krusader/DiskUsage/filelightParts/ though...
[02:20] <seth_k> so weird
[02:21] <seth_k> Riddell, should I put commands in rules to copy them, or to move them?
[02:23] <Riddell> raphink: seth_k patch it to #include <../foo.h>
[02:23] <Riddell> seth_k rather
[02:23] <raphink> hehe
[02:23] <Riddell> raphink: tried running make -f Makefile.cvs over it?
[02:23] <seth_k> Riddell, isn't the problem that it's looking in the wrong place, though?
[02:23] <Riddell> raphink: or removing the .pot, doing that then compiling?
[02:23] <raphink> hmm nope
[02:23] <raphink> I'm having a look
[02:23] <raphink> I'm trying to get the source just in case
[02:23] <seth_k> Riddell, because it's apparently trying to find the header files
[02:24] <raphink> but y internet is too slow
[02:24] <raphink> right now
[02:24] <Riddell> seth_k: well it's trying to find them and doesn't know where they are so you need to fix the #include
[02:25] <Riddell> raphink: http://revu.tauware.de/details.py?upid=1027 konq-encrypt-menu approved with comments
[02:25] <raphink> thanks
[02:25] <Riddell> I'm off to bed
[02:25] <seth_k> night Riddell, thanks a lot... I hope to have a fixed krusader on REVU to greet you in the morn :)
[02:25] <raphink> Riddell: well if I change compat you'll have to advocate again ;)
[02:25] <raphink> no?
[02:26] <raphink> I have to fix kyamo tonight aswell :)
[02:26] <Riddell> raphink: it's not requited in my rule book, but it's not hard for me to tick a box again
[02:26] <raphink> just checked rc2 would build fine
[02:26] <raphink> so I have to to find what's wrong with rc3
[02:26] <raphink> Riddell: ok :)
[02:27] <raphink> rc3 builds fine from source
[02:27] <raphink> so theres something there ;)
[02:27] <raphink> that I have to find
[05:13] <seth_k> ahhhhhhhh
[05:13] <seth_k> i swear this compile is on crack, it's asking for files that don't even exist
[08:01] <viviersf> Riddell : PING
[09:24] <sebas> Riddell: (re: pyqt tutorial dot story) Please go ahead :) I wasn't sure myself wether to submit it or not.
[09:24] <sebas> Ok, checked the dot now :>
[10:11] <Flosoft> hey @ all
[11:23] <jpatrick> raphink: ping
[11:27] <raphink> yop jpatrick
[11:28] <jpatrick> raphink: thanks for the review
[11:28] <jpatrick> I've uploaded a updated package now : http://revu.tauware.de/details.py?upid=1092
[11:28] <raphink> pfiew just woke up :s
[11:29] <jpatrick> :) like me
[11:30] <raphink> lol
[11:34] <raphink> jpatrick: you can add a newline between the long description and the homepage in debian/control. this line should only contain a space and a dot.
[11:36] <jpatrick> done
[11:36] <raphink> jpatrick: this is a small detail, but you don't have to cut lines @ 60 characters or so in the descriptions. It's 80 chars max
[11:36] <raphink> so the long description can fit on 3 lines
[11:37] <raphink> when you're in a 80 chars wide console, you like to have as few lines as possible in your output ;)
[11:37] <jpatrick> long des. = 2 lines ?
[11:38] <raphink> well if you put them on 80 cols yes
[11:38] <jpatrick> that's done too
[11:38] <jpatrick> :)
[11:38] <raphink> good :)
[11:39] <jpatrick> that should do it?
[11:40] <raphink> you'll have to explain me about the .pot file, since I'm getting crazy on packaging kyamo 0.13rc3
[11:40] <raphink> it says there's no rule to build a pot file
[11:40] <jpatrick> I'm just doing what it says on KubuntuPackagingGuide :/
[11:40] <raphink> oh good I'll hav a look thanks :)
[11:42] <raphink> jpatrick: just the last point : how about the desktop file?
[11:42] <raphink> oh ic it in misc
[11:42] <raphink> doh
[11:42] <raphink> forget about it :(
[11:43] <raphink> hehe
[11:43] <jpatrick> raphink: yeah I forgot to tell you that..
[11:43] <raphink> that's ok
[11:43] <jpatrick> reuploading src package
[11:43] <jpatrick> finished :)
[11:44] <raphink> good
[11:44] <raphink> I'll build it and put a comment ;)
[11:45] <jpatrick> raphink: thanks :)
[11:48] <jpatrick> shouldn't it build-dep on debhelper ?
[11:49] <raphink> jpatrick:
[11:49] <raphink> dh_testdir
[11:49] <raphink> make: dh_testdir: Command not found
[11:49] <raphink> make: *** [clean]  Error 127
[11:49] <raphink> pbuilder: Failed autobuilding of package
[11:49] <raphink> doesn't build
[11:49] <jpatrick> :?
[11:49] <raphink> so yes you need debhelper in the build-dep
[11:49] <raphink> I'll bb
[11:50] <raphink> add debhelper to the build dep and try to build it in a pbuilder
[11:50] <raphink> I'll at it after that
[11:53] <jpatrick> raphink: reuploaded
[11:53] <jpatrick> brb
[12:01] <raphink> jpat|away: debhelper (<<4.1) please
[12:06] <raphink> jpat|away: sorry debhelper (>>4.1) hehe
[12:06] <raphink> gna
[12:12] <jpatrick> raphink: done
[12:29] <raphink> jpatrick: looks fine :)
[12:30] <raphink> ask a MOTU to advocate it
[12:30] <jpatrick> Riddell: ping
[12:30] <raphink> hehe
[12:31] <raphink> Riddell: I changed compat in kubuntu-grub-splashimages. Should I change the debhelper version in build-dep too?
[01:19] <Riddell> jpatrick: hi
[01:22] <jpatrick> Riddell: could you look at http://revu.tauware.de/details.py?upid=1095 , please ?
[01:26] <Flosoft> Riddell: did you add the beta download?
[01:45] <allee> jpat|away: ping
[01:53] <freeflying> Riddell:  hi
[01:53] <freeflying> Riddell:  I've reloaded skim to revu today, plz have a look
[02:29] <jpatrick> allee: i'm here
[02:29] <allee> ah, hi
[02:30] <allee> jpatrick: Great to see people workong on KubuntuPackaging!
[02:31] <allee> but I think the copyright section is more than simplified
[02:32] <allee> e.g., every copyright notice if source, translation and docs need to be listed and even in simple pkgs there are more than 1
[02:33] <allee> copyright contain copyrights and distribution licenses and beside standard (L)GPL, artistic etc one has to include the complete text, eg. GDFL that is usually used in handbooks
[02:33] <jpatrick> yes...
[02:34] <allee> do you plan to add these 'important' details?  Or should I add them.
[02:35] <allee> I don't want step on your feet ;)
[02:35] <jpatrick> Maybe you should
[02:35] <allee> 'k I see if I find some time this weekend.
[02:36] <allee> btw. you used compat 5 in filelight so debhelper has to be >> 5 ;)
[02:38] <jpatrick> ah yes
[02:40] <jpatrick> reuploaded to REVU
[02:43] <allee> and version 1.0beta6 is bigger than 1.0 :(  So maybe 1.0final but what if there's an rc1? So maybe 1.0+beta6 and later 1.0.0
[02:45] <allee> why did you remove debian/menu?  It should be included for the people using purists desktop env ;)
[02:47] <jpatrick> so it should be filelight-1.0+beta6 ?
[02:48] <allee> no manpage and, can't check right now, I think the docs are installed into the wrong dir
[02:49] <allee> yes. but then, if you want to avoid epochs, you have to use 1.0.0 even when upstream calls it 1.0 ;)
[02:50] <allee> other use 0.9.9+1.0beta6 then 1.0.
[02:50] <jpatrick> okay
[02:51] <allee> jpatrick: your friend is: dpkg --compare-versions oldvers lt nextvers && echo okay
[02:54] <jpatrick> ?
[02:55] <allee> dpkg --compare-versions 1.0beta6 lt 1.0  && echo okay    --> outputs nothing :(
[02:56] <jpatrick> :(
[02:56] <allee> dpkg --compare-versions 1.0beta6 lt 1.0.0 && echo okay  --> print okay
[03:00] <allee> need a pbuilder test but I bet autoconf and automake 1.9 are no build-deps.
[03:09] <allee> jpatrick: grep -Ri copyright src doc po misc | grep -v Makefile    # You missed at least Micheal
[03:10] <allee> licensecheck tool does not help much too. Max does not use the standard blurbs :(
[03:28] <jpatrick> allee: uploaded changes
[03:33] <allee> jpatrick: sorry busy right now
[03:35] <raphink> ok I'm pretty sure this is a pb with cdbs or so
[03:37] <allee> raphink: ?
[03:41] <raphink> allee: look in #ubuntu-motu
[03:41] <allee> 'k
[03:41] <raphink> oh no you're not there
[03:41] <raphink> well then
[03:41] <raphink> http://ubuntu.pastebin.com/455459
[03:41] <raphink> there allee ^^
[03:42] <raphink> a package of mine fails to build
[03:42] <raphink> it built ok before
[03:42] <allee> now i'm in ;)
[03:42] <raphink> now it doesn't anymore
[03:42] <raphink> ./configure && make works fine
[03:42] <raphink> but if I run dpkg-buildpackage I get this error, and after that `./configure && make' doesn't work anymore
[03:46] <allee> strange.  interdiff off first and the second run.  po/de not writeable?
[04:24] <seth_k|away> morning Riddell
[04:25] <Riddell> bah humbug
[04:25] <seth_k> I fixed a ton of the krusader errors, but now it is saying "file not found" on a file that doesn't even exist in the source tree
[04:25] <Riddell> that's not nice of it
[04:25] <seth_k> nope
[04:26] <seth_k> it asks for actionpropertybase.h
[04:26] <seth_k> but the only file similar is actionpropertybase.cpp
[04:26] <Riddell> upload to revu and I'll try and take a look at it sometime this decade
[04:26] <seth_k> hehe, alright
[04:27] <Riddell> waa!  that's never enough time to sort out all these problems in xpdf!
[04:29] <freeflying_> Riddell: hi
[04:30] <Riddell> hi freeflying_
[04:30] <freeflying_> Riddell:  have you got my message here
[04:30] <Riddell> I'll look at skim too in a bit, thanks for keeping working on it, we'll get there soon :)
[04:32] <freeflying_> Riddell:  how can we get all articles of wiki.kubuntu.org
[04:32] <seth_k> uploaded Riddell, I hope xpdf doesn't eat you first
[04:33] <sebas> Riddell: Wasn't that fixed with the new freetype? (Or are you referrring to all those overflows in there? :D)
[04:33] <jpatrick> wow!
[04:33] <jpatrick> nice design
[04:35] <Riddell> freeflying_: not too sure I'm afraid, you probably need to ask henrik<EMAIL_ADDRESS>[04:36] <freeflying_> Riddell: thx
[07:29] <Flosoft> how is the support of webcams in Kubuntu?
[07:30] <Riddell> no idea
[07:31] <Flosoft> hmm
[07:35] <Flosoft> what about adding the new kvirc package?
[07:35] <Flosoft> the version in Synaptic: <IP_ADDRESS> ... current: 3.2.0
[07:36] <jpatrick> Flosoft: Dapper verison == 3.2.0
[07:36] <Flosoft> nice :)
[07:37] <Flosoft> does dapper work with KDE 3.5?
[07:37] <jpatrick> Flosoft: Dapper has 3.5
[07:37] <Flosoft> ok
[07:37] <jpatrick> http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=kvirc&searchon=names&subword=1&version=dapper&release=all
[07:37] <Flosoft> what is the difference if I change my sources from breezy to dapper?
[07:37] <jpatrick> Flosoft: new kernel, new Xorg, new KDE
[07:38] <Flosoft> ok
[07:38] <Flosoft> so I could delete the kde extra source i have for 3.5 @ the moment?
[07:38] <jpatrick> you can keep it...
[07:40] <jpatrick> I'm not on Dapper, becuase modprobe kept segmentfaulting here
[07:40] <Flosoft> ow ... well ... i'll wait a bit too :p
[07:40] <Flosoft> i'm quite happy with breezy
[07:40] <jpatrick> I'll go back when Flight-2's out
[07:40] <Flosoft> my only software that is missing is kvirc
[07:40] <Flosoft> can't it be added to breezy?
[07:41] <jpatrick> Flosoft: Backports
[07:42] <Flosoft> yes
[07:42] <jpatrick> it will probably end up there
[07:42] <Flosoft> will it be backported?
[07:43] <jpatrick> might
[07:43] <Flosoft> :)
[07:43] <jpatrick> my ksplash-engine-moodin package did
[07:43] <jpatrick> :)
[07:54] <Flosoft> what is the programm that loads the boot logo?
[07:54] <Flosoft> it isn't splash
[07:55] <jpatrick> Flosoft: usplash
[07:55] <Flosoft> ok
[07:58] <Flosoft> will there be a new bootsplash with dapper?
[08:00] <jjesse> one that is a little brighter hopefully
[08:00] <Flosoft> yes
[08:00] <Flosoft> well like the login screen background
[08:03] <Flosoft> and how do you see the console while booting?
[08:03] <Flosoft> F2 doesn't work
[08:04] <Flosoft> ESC neither
[08:05] <jjesse> Flosoft: no clue
[08:22] <Tm_T> humm
[08:22] <Tm_T> I don't use usplash
[08:23] <Tm_T> but yes, dapper will have usplash themes too
[08:25] <Flosoft> :)
[08:26] <Tm_T> we planned to do similar look from boot to Gnome desktop
[08:26] <Tm_T> prolly same to Kubuntu side


[04:16] <pitti> Good morning
[04:16] <pitti> tkamppeter: it's worth a try now, anyway
[04:16] <Nafai> good morning pitti! :)
[05:40] <didrocks> good morning
[06:22] <tkamppeter> pitti, what do you mean with "It is worth a try now"?
[06:22] <pitti> tkamppeter: reuploading your crash report
[06:23] <tkamppeter> pitti, will try.
[06:25] <tkamppeter> pitti, bug 856139, let's see ...
[06:47] <pitti> tkamppeter: meh -- seems it just doesn't like that crash; I don't think it's the oboslete dbgsyms, seems the memory is just too disrupted
[06:47] <pitti> tkamppeter: do you get anything sensible in gdb?
[06:54] <tkamppeter> pitti, I did not try gdb, how do I proceed for that, especially as I cannot reliably reproduce the problem.
[06:54] <pitti> tkamppeter: you can install apport-retrace, and try
[06:54] <poolie> hi pitti
[06:54] <pitti> apport-retrace -S system -g -v /var/crash/yourcrashfile.crash
[06:54] <pitti> hey poolie
[06:55] <pitti> tkamppeter: that'll build a temp dir with all debug symbols it can get, and put you into a gdb session with that crash
[06:55] <pitti> tkamppeter: so you can do "bt full", poke around in the frames, etc.
[07:06] <dholbach> good morning
[07:13] <robert_ancell> mr_pouit, hey, did you get that lightdm alternatives patch to work?
[07:43] <OdyX> tkamppeter: oh, right.
[08:06] <doko_> cyphermox, ping
[08:11] <ricotz> doko_, the new clutter/cogl upload includes the armhf bits which will hopefully work in 12.04
[09:00] <tkamppeter> pitti, it seems that apport-retrace has a bug, see http://paste.ubuntu.com/695005/
[09:14] <Sweetshark> pitti: fyi: I have a 3.4.3-1ubuntu3 locked and loaded -- it compiled locally and is currently testcompiling on armel -- it fixes bug 835153, bug 835663, bug 779798, bug 841562 and bug 850372. When would you be allowed to upload that for final?
[09:18] <Sweetshark> eh, thats bug 835662 (not 835663)
[09:27] <tkamppeter> pitti, see bug 856216 for my experience with apport-retracer.
[09:35] <pitti> Sweetshark: we can upload it right now, i'll be caught in unapproved
[09:36] <pitti> tkamppeter: will look in a bit, still doing release-y stuff
[09:37] <pitti> tkamppeter: "No keyring installed", uh
[09:38] <pitti> tkamppeter: you don't need root there, btw; all user stuff
[09:38] <pitti> tkamppeter: can you please add the output of "apt-key list" to the bug?
[09:39] <tkamppeter> pitti, which keyring does it need and how do I get such a keyring?
[09:39] <pitti> you knock on elmo's door with some chocolate and ask nicely
[09:39] <pitti> no, it should be there already
[09:40] <pitti> tkamppeter: it complained about the standard ubuntu archive one
[09:40] <pitti> tkamppeter: I'll try to reproduce this, but I need the apt-key output
[09:40] <tkamppeter> pitti, done.
[09:43] <pitti> tkamppeter: do you have anything in /etc/apt/trusted.gpg.d/ ?
[09:44] <tkamppeter> pitti, crash file attached.
[09:46] <tkamppeter> pitti, yes, see bug
[09:58] <pitti> tkamppeter: can you attach /etc/apt/trusted.gpg.d/jockey-drivers.gpg to the bug? just to ensure that I have the same files?
[09:58] <pitti> tkamppeter: (it's nothing secret, just the public GPG keys from epson, etc.)
[10:05] <tkamppeter> pitti, attached.
[10:48] <tkamppeter> pitti, can you have a look at bug 856274? It seems that it has a problem with its i386 version.
[10:50] <pitti> tkamppeter: seems like mirror lag
[10:51] <pitti> tkamppeter: followed up
[10:57] <pitti> tkamppeter: hm, still can't reproduce that apport-retrace bug
[10:58] <pitti> tkamppeter: if you do a normal "sudo apt-get update", do you see similar GPG errors?
[11:02] <pitti> tkamppeter: anyway, as for the actual crash, I think there's a bug in python-apt or in apport-retrace, it doesn't seem to install all debug symbols that it downloaded
[11:02]  * pitti investigates tthis
[11:04] <pitti> ah, no, it's there, I just mislooked
[11:05] <pitti> tkamppeter: oooh, I know
[11:05] <pitti> tkamppeter: cups-dbg only has debug symbols for libcups2, nothing else; in particular, not for /usr/sbin/cupsd
[11:14] <pitti> it seems the upstream build system already strips the daemon
[11:17] <tkamppeter> pitti, perhaps we should patch the build system for Oneiric so that it does not strip any executable or library from CUPS, so that we can investigate crashes. Can you look into this?
[11:18] <pitti> yeah, usually the build system shoudln't do this, especially not if you build with -g -O2
[11:18] <tkamppeter> pitti, if I run "apt-get update" manually I do not get any GPG errors, only a not available http://ftp.freestandards.org/.
[11:19] <pitti> tkamppeter: can you reproduce that crash?
[11:19] <pitti> tkamppeter: I have rebuilt cups with debugging symbols now, but as the core dump is from a different binary, it doesn't match any more
[11:19] <tkamppeter> pitti, no. I get it here and there when I create CUPS queues.
[11:20] <pitti> tkamppeter: so, I'm afraid this .crash file is useless :(
[11:20] <pitti> tkamppeter: I'll look into fixing cups-dbg
[11:21] <tkamppeter> pitti, AFAIR it happens preferably if creating queues with the dnssd backend pointing to CUPS queues on other servers.
[11:21] <pitti> without my "sudo ln -s /bin/true  /usr/bin/strip" hack, that is :)
[11:23] <tkamppeter> pitti, when you have the fixed package up, with debug symbols for all executables and libs of CUPS, please tell me, then I will update and try to get the crash again by quickly creating many print queues.
[11:23] <pitti> tkamppeter: test build running
[11:24] <pitti> tkamppeter: do you have cups-dbg installed? If so, even the locally created StackTrace in the .crash file should be useful
[11:25] <apw> slangasek, when you say brief clear to black is that literally just before plymouth, and does the backlight turn off in teh gap, ie. could it be a mode switch?
[11:26] <pitti> tkamppeter: that also explains why we don't have any -dbgsym packages
[11:27] <tkamppeter> pitti, I have it installed, but apport-retracer still crashes for me.
[11:28] <pitti> tkamppeter: for that one, perhaps you can tar up /etc/apt/ and attach it? I'll try to replace mine with your's
[11:29] <pitti> mvo: do you have an idea what could be wrong in bug 856216?
[11:29] <pitti> mvo: apt-get update doesn't complain, and I installed the very same /etc/apt/trusted.gpg.d/jockey-thing as Till has, but I don't get the error
[11:30] <pitti> tkamppeter: cups-dbg fix pushed to bzr
[11:31] <pitti> tkamppeter: if you install cups-dbg, you won't actually need apport-retrace; just say "report" to the crash report, and then cancel when it asks you to upload to launchpad, then the .crash file will have the stack trace
[11:31] <tkamppeter> pitti, /etc/apt attached.
[11:32] <mvo> pitti: you modify dir::etc::trusted where it should be trustedparts maybe? check apt-config dump|grep trusted
[11:32] <tkamppeter> pitti, then it has it already, as it is from the report.
[11:32] <mvo> pitti: just a wild guess without having looked at this in more detail though
[11:33] <pitti> mvo: actually not, I just set RootDir
[11:33] <pitti>         apt.apt_pkg.config.set('RootDir', apt_root)
[11:33] <pitti>         apt.apt_pkg.config.set('Debug::NoLocking', 'true')
[11:33] <pitti>         apt.apt_pkg.config.clear('APT::Update::Post-Invoke-Success')
[11:33] <pitti> mvo: ^ that's all it does
[11:33] <pitti> mvo: but if it was a general bug, I should get it, too
[11:33] <pitti> mvo: something on Till's system is different than mine
[11:33] <mvo> pitti: ok, then I need to look a bit close, I'm in a call now, I can check after that. a permissions problem is ruled out as well? gpg is pretty picky here sometimes
[11:33] <pitti> anyway, post-lunch problem, bbl
[11:34] <pitti> mvo: thanks; I'll poke this some more
[11:35] <tkamppeter> pitti, http://paste.ubuntu.com/695060/
[12:13] <pitti> tkamppeter: "(no debugging symbols found)"
[12:13] <pitti> tkamppeter: is that with the current bzr packages?
[12:14] <pitti> tkamppeter: when I do "gdb /usr/sbin/cupsd", I get (no debugging symbols found)"; but after installing the locally built cups-dbg, I get "Reading symbols from /usr/sbin/cupsd...Reading symbols from /usr/lib/debug/usr/sbin/cupsd...done."
[12:18] <doko_> pitti, seb128 please have a look at bug 831143, the package doesn't seem to work at all, but is a dependency of ephiphany-browser
[12:31] <tkamppeter> pitti, the paste was of before today's BZR, so still without your cups-dbg fix.
[12:31] <pitti> ah
[12:48] <tkamppeter> pitti, building CUPS from BZR ...
[12:54] <cyphermox> doko_: pong
[12:56] <tkamppeter> pitti, installed the new CUPS, now I must get the bug triggered again ...
[12:57] <doko_> cyphermox, looking at the wireless-regdb ftbfs, wondering which package in Ubuntu does have this information?
[12:59] <cyphermox> doko_: crda
[12:59] <cyphermox> afaik it should be the only one
[13:00] <cyphermox> doko_: actually, I mean crda is, I think, the only package to use this
[13:01] <doko_> cyphermox, well, wireless-regdb was never built
[13:02] <doko_> so we maybe should remove these two packages
[13:02] <cyphermox> oh, yeah probably
[13:02] <cyphermox> weird, because I could have sworn we always did have a package to do this
[13:05] <cyphermox> doko_: ok, found what I was looking for, I was thinking of iw
[13:06] <cyphermox> so yeah, I do agree these packages could be removed
[13:06] <cyphermox> shoudln't it be easy to just not sign the reg data?
[13:07] <doko_> cyphermox, please go ahead and upload a fix
[13:07] <cyphermox> doko_: ok I'll have a look
[13:17] <dobey> do packages seeded for default install/CD *have* to be in something else's Depends/Recommends that's already there?
[13:18] <cjwatson> I don't think you mean the same thing by the term "seeded" as I do
[13:18] <cjwatson> can you rephrase your question?
[13:19] <cjwatson> (I use "seeded" to mean "explicitly added to a seed as opposed to pulled in purely by dependencies")
[13:20] <cyphermox> doko_: I'll need sponsoring shortly
[13:21] <dobey> cjwatson: oh; typically whwenever we wanted something on CD, we always got the "something needs to Depends/Recommends it"
[13:22] <dobey> cjwatson: perhaps that created some confusion :)
[13:23] <cjwatson> dobey: in order for something to be on the CD, it must either be explicitly listed in a seed, or listed in Depends/Recommends of something that's already there
[13:23] <cjwatson> (listing it in (e.g.) the desktop seed will cause it eventually to be depended upon by ubuntu-desktop)
[13:23] <dobey> ok
[13:24] <cjwatson> the rule of thumb is that you explicitly seed things that are top-level requirements
[13:24] <Chipzz> cjwatson: would it be incorrect to say that to have stuff included on the CD, you have dependency-trees, and the seeds are the roots of those that pull in all other dependencies?
[13:24] <cjwatson> Chipzz: that's roughly correct
[13:24] <dobey> and eww; but i always end up uninstalling ubuntu-desktop anyway, so i can uninstall things it depends on
[13:24] <cjwatson> dobey: that's orthogonal
[13:24] <cjwatson> dobey: and in any case there is a syntax for causing ubuntu-desktop to only Recommends something
[13:25] <cjwatson> if it's not core desktop infrastructure, it should typically be Recommends
[13:25] <Chipzz> cjwatson: are seeds always meta-packages?
[13:25] <dobey> ok
[13:26] <cjwatson> Chipzz: no
[13:26] <cjwatson> for example the ship seed (which defines the set of packages added to the pool on the alternate CD but not installed by default) is not a metapackage
[13:27] <cjwatson> or rather is not used to generate a metapackage
[13:27] <Laney> recommends> I wish :-)
[13:33] <cyphermox> doko_: well, forget this, crda is not installable, it tries to install /sbin/crda which is already provided by wireless-crda (which is required by the kernel)
[13:35] <doko_> apw, ogasawara: any idea why crda cannot be used?
[13:36] <apw> doko_, sounds like something rtg would be most familiar with
[13:36] <cyphermox> oh fun, it's just a duplicate package
[13:36] <apw> cyphermox, could well be
[13:36] <cyphermox> I'm trying to figure out which is the latest version
[13:37] <apw> i suspect we added wireless-crda, as we had kernels requiring it before debian, so we might be able to merge them.  rtg was point man on crda so i'd recommend bring it to his attention
[13:38] <ScottK> mvo: I'm just upgrading my test server via ssh and I noticed that the dialogue around the alternate sshd is much improved (particularly around firewalls).  Thanks.
[13:39] <mvo> ScottK: great, thanks!
[13:40] <apw> cyphermox, doko_, ok tgardner is looking into it
[13:41] <cyphermox> ok
[13:43] <apw> cyphermox, when was crda last sync'd and how would if find out the real debian version now
[13:44] <cjwatson> https://launchpad.net/ubuntu/+source/crda/+publishinghistory  http://packages.qa.debian.org/crda
[13:44] <doko_> apw, http://packages.qa.debian.org/c/crda.html
[13:44] <cyphermox> apw: crda was probably auto-imported
[13:44] <cyphermox> I doubt anyone touched it :)
[13:44] <cjwatson> we're in sync with Debian
[13:44] <apw> then i suspect its pretty out of date.  the DB it contains is updated fairly often
[13:45] <cyphermox> apw: then you mean wireless-regdb and the database from the wireless-crda package, those are in sync
[13:45] <doko_> apw, the db is packaged in wireless-regdb
[13:45] <cyphermox> it's both 2011-04-28, the debian package adds an EU domain
[13:46] <apw> ahh ok
[13:46] <cyphermox> your package appears to only have just a bit of extra code to crda to have it work with libnl3
[13:47] <apw> cyphermox, then it osunds like potential for a merge ...
[13:50] <tgardner> cjwatson, given that wireless-crda is in the desktop seed, do you really want to change that right now ?
[13:51] <tgardner> I suggest we change to crda+wireless-regdb during the P cycle.
[13:52] <doko_> nobody said right now. seen while cleaning up the archive. it's fine if this is done for P
[13:52] <tgardner> doko_, works for me
[13:52] <tgardner> I'll git it on my todo list for when P opens
[13:52] <cyphermox> yeah, I think we should probably do this in P
[13:53] <tgardner> I'll start a bug so tha it doesn't get forgotten
[13:57] <tgardner> skaet, sure would be handy to be able to specify milestones for the P series already. do we have to wait until the P archive is opened ?
[13:59] <ScottK> tgardner: You can.
[13:59] <ScottK> (IIRC)
[14:00] <skaet> tgardner,  we need a name for p-series first before the milestones can get populated.
[14:00] <ScottK> Ah, right - milestones, not series.
[14:00] <ScottK> skaet: It would also be nice to have a name so we can update development tools in oneiric to know what to call P.
[14:01] <skaet> ScottK,  agreed.  absence of a name is starting to get in the way. :P
[14:05] <tkamppeter> pitti, I succeeded the stacktrace now, with CUPS locally built from BZR and doing ~60 queue addition/removal operations, and on one removal it actually crashed. Will paste the stacktrace into the bug.
[14:06] <pitti> tkamppeter: ah, great
[14:07] <cjwatson> tgardner: yeah, P is fine
[14:07] <tgardner> cjwatson, ack
[14:13] <tkamppeter> pitti, bug 855445
[14:19] <pitti> tkamppeter: ah, that looks a lot more useful
[14:21] <ScottK> mvo: As I mentioned, I just upgraded my test server to oneiric.  It appears that I've no packages left that require python-central, but it wasn't removed on upgrade.  Is that something you could check for?  Would you like a bug about this?
[14:25] <mvo> ScottK: that is interessting, yes, a bug would be nice
[14:25] <ScottK> OK.
[14:28] <ScottK> mvo: Bug 856458
[14:29] <mvo> thanks scottk!
[14:54] <rbasak> hey cyphermox, sorry I didn't understand https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/3 at all. Which same default route, and what do I point to the same device with link-local?
[14:55] <cyphermox> rbasak: ah, I mean, could you try with the link-local address to your router
[14:55] <cyphermox> here I get a standard global ipv6 address from dhcp, and my defualt route is automatically set properly by NM, to the link-local address of the router
[14:57] <rbasak> Ah, so you want me to see what happens if I specify the link-local router address as the gateway in the settings?
[15:03] <doko_> plars, pitti: please could you have a look at bug 756043 ?
[15:03] <pitti> doko_: yeah, can do
[15:04] <plars> doko_: I haven't looked at it in a while, but I know there's a new upstream version
[15:05] <cyphermox> rbasak: yup
[15:08] <doko_> yeah for configure modularization ...
[15:09] <doko_> dnl insert here your program name and version number
[15:09] <doko_> AC_PROG_CC
[15:09] <doko_> KDE_DO_IT_ALL(phaseshift,0.4)
[15:14] <slangasek> apw: I'm not sure if the backlight turns off; I get different behavior based on whether I have an external monitor plugged in or not, in one of these cases I briefly get a cursor and in the other I don't.  (I think the cursor is with the external monitor plugged in.)
[15:19] <rbasak> cyphermox: didn't work; I've commented in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/4
[15:21] <Laibsch> I have added http://paste.debian.net/131459/ to my pbuilderrc s suggested in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler to build with gcc 4.4 (4.6 has a bug on my CPU), but logging in to the pbuilder and doing "gcc --version" still show 4.6.1.  What's wrong?
[15:22] <seb128> mvo, is /usr/share/update-notifier/notify-reboot-required still used nowadays?
[15:22] <mvo> seb128: yes
[15:22] <seb128> it seems to do nothing there
[15:22] <seb128> like I did sudo /usr/share/update-notifier/notify-reboot-required
[15:22] <seb128> it created the files in /var/run
[15:23] <seb128> but neither update-manager nor the indicator nor anything says I need to restart
[15:24] <cyphermox> rbasak: ok, so there's really something very broken there, I'll see what I can make with this
[15:25] <rbasak> OK thanks
[15:26] <mvo> seb128: right, you need to touch /var/lib/update-notifier/dpkg-was-run as well, this is done automatically by apt after it ran dpkg
[15:26] <seb128> mvo, thanks
[15:30] <mvo> yw
[15:36] <apw> slangasek, i guess i'd like to see it boot in total.  might you be able to video it on your phone or something
[15:37] <slangasek> apw: ok, will try to do that later today.  First I'm trying to see if I can reproduce it on my old T60, since that would give me more flexibility to play
[15:38] <apw> slangasek, if you arn't using crypto, installing and removing those tools moves the mode switch about in the boot and is a good way to know if it is the modeset
[15:38] <slangasek> apw: I am using crypto ;)
[15:38] <apw> damn
[15:38] <slangasek> part of why I want to reproduce it on another box first
[15:38] <slangasek> though I do have an unencrypted VG on here partly for just this sort of thing, so I can install to that if needed for testing
[16:05] <slangasek> mdeslaur: bug #856534 looks like something we should get fixed for release; do you have interest/time to work on this?
[16:09] <mdeslaur> slangasek: I'll take a look, thanks
[16:34] <pitti> doko_: moserial uploaded
[16:34] <pitti> plars: ^ FYI
[16:34] <plars> pitti: awesome, you rock!
[16:35] <plars> pitti: according to comments from the author, that one should work better with current vala versions
[16:35] <pitti> yep, it works fine with 0.14
[16:35] <pitti> 2.32 didn't work either
[16:35] <pitti> and 3.0 makes more sense in oneiric anyway
[16:40] <doko_> lucas, is libdb-ruby worth fixing, or better just remove it?
[16:59] <pitti> kees, mdz, cjwatson: oh, we have TB meeting today; apparently no selected chair, but not much of an agenda anyway
[17:00] <mdz> pitti, indeed
[17:02] <cjwatson> oh, hmm, it's inconvenient for me this week - my brainstorm update is that a couple of people have responded but so far the response rate is not great; I'll start harassing people soon
[17:02] <cjwatson> I'll try to attend but possibly only by IRC-from-phone
[17:06] <chmrr> I'm one of the upstream maintainers of https://launchpad.net/rt/ -- https://launchpad.net/rt/+packages shows that request-tracker3.8 packages list rt/4.0 as upstream, instead of rt/3.8  What's the right way to fix this on launchpad, as I don't seem to have rights to change them myself?
[17:07] <cjwatson> it'd be best to ask #launchpad
[17:07] <chmrr> Will do; thanks!
[17:08] <cjwatson> oh, that interacts with an Ubuntu package, hmm
[17:08] <cjwatson> let me see
[17:08] <Laney> I see remove/link buttons, don't know what gave me permissions there though
[17:08] <cjwatson> chmrr: I've fixed it for you
[17:08] <chmrr> Thanks!
[17:08] <cjwatson> I guess I need to fix natty/maverick too ...
[17:09] <cjwatson> ignore the "Bilimbi Test" one, that's an LP test of derived distributions
[17:09] <chmrr> Yeah, I was wondering what was up with that
[17:10] <cjwatson> the Ubuntu ones should all be fixed now
[17:10] <cjwatson> Laney: upload privileges to the package
[17:11] <Laney> thought as much
[17:11] <cjwatson> (at least, I expect so)
[17:11] <chmrr> lucid's request-tracker3.8 reports it's against master, which is also wrong
[17:12] <cjwatson> OK, I've made that 3.8 too
[17:12] <chmrr> Thanks!
[17:12] <kees> pitti: cool, I'm around
[17:59] <stgraber> @pilot in
[17:59] <stgraber> infinity: still piloting?
[18:01] <infinity> stgraber: Oh, no, just retarded.
[18:01] <infinity> @pilot out
[18:43] <slangasek> mterry: bug #854202> who did you hear from that we're not dropping these packages from the CD?  I expect that's correct, but ubuntuone-couch is currently out of main and has other dependencies, so I want to be sure to follow up with the primary source before simply promoting the packages
[18:44] <mterry> slangasek, from pitti and dobey.  It was only dropped from main because deja-dup dropped the recommends recently
[18:44] <Laney> slangasek: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/856405
[18:45] <slangasek> mterry: ok; is that true of python-mocker as well?
[18:45] <mterry> slangasek, I don't know about mocker
[18:45] <slangasek> mterry: is there a channel log for this that I can peruse to my satisfaction, or should I just leave it to pitti?
[18:45] <slangasek> the latter may be simpler :)
[18:46] <Laney> it was discussed a bit in #-release earlier, but only retrospectively
[18:46] <mterry> slangasek, I think it was brought up in last #ubuntu-desktop meeting, but again, retrospectively
[18:49] <mterry> slangasek, https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-09-20 (the meeting I mentioned)
[19:01] <cnd> it looks like there's some support for pkg-create-dbgsym in ppas
[19:01] <cnd> looking at the source for pkg-create-dbgsym, it seems that if "Build-Debug-Symbols: yes" is set somewhere, it will build them
[19:01] <cnd> is there any docs on this?
[19:02] <cnd> pitti, ^^ ?
[19:08] <slangasek> mterry: thanks - and I found the previous MIR for mocker, so I've repromoted both packages
[19:38] <doko_> slangasek, do you mind updating qemu-linaro to the recent release, fixing the build failure?
[19:49] <slangasek> doko_: I don't /mind/, no, but it requires a FFe... was just discussing that on #ubuntu-release this morning, I'll go ahead with it soon
[20:12] <bladernr> Does anyone off hand know who maintains mesa-utils (glxinfo, glxgears, glxheads) or who/where to poke with bugs and questions?  I keep running into dead ends on Launchpad and google gives me blog posts about mesa-utils, but nothing useful
[20:18] <doko> seb128: could you pitti please have a look at the seed build failure? looks like you did request the sync and did ignore the build failures
[20:18] <seb128> doko, will do if I've time next week
[20:18] <seb128> doko, if pitti doesn't beat me to it but it called it a week already
[20:18] <doko> seb128, sorry, but next time please spend your time before doing syncs like these
[20:19] <Sarvatt> bladernr: ubuntu-x-swat, #ubuntu-x. its a new package which was split off from the mesa source is probably why there's a dearth of info
[20:19] <bladernr> Sarvatt:  awesome! thanks a lot :)
[20:19] <seb128> doko, 3.0.0-1 built
[20:19] <doko> yeah, but not -2
[20:19] <seb128> it has no code change
[20:20] <doko> and no reaction from your side
[20:20] <seb128> we would have got the same issue without syncing it
[20:20] <seb128> right, it's a toolchain segfault
[20:20] <seb128> not a seed issue
[20:20] <doko> seb128, bullshit
[20:21] <seb128> well -1 built fine and there is no code change
[20:21] <seb128> well "toolchain" can be "build-depends"
[20:21] <seb128> but seed didn't change between the version which built and the one which didn't, it was only packaging cleaning
[20:21] <seb128> the same version built in debian and is in testing
[20:21] <doko> seb128, when will you learn that the toolchain uncovers issues in broken code?
[20:22] <seb128> well nothing tell you that it doesn't expose a bug in the toolchain either
[20:22] <seb128> doko, you are just doing claims, it could be either way
[20:23] <seb128> only debugging will tell us, but -1 built and -2 which is what we have built in Debian and is in testing
[20:23] <doko> usually I'm right with my "claims". it's the non-action on your side which concerns me
[20:23] <seb128> well, it's not in the default install so I don't really care
[20:24] <seb128> which I admit is not a position everybody share, but we have the resources to either make our default install good or everything medium, I prefer to focus on what is most used
[20:24] <seb128> but feel free to drop seed from oneiric and epiphany-browser with it if nobody fixes it
[20:26] <seb128> seems similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582774
[20:27] <doko> seb128, please could you reply to the launchpad issue that it is ok to remove epiphany-browser? I'm fine with this
[20:28] <seb128> well, I'm not deciding with that but if the issue is not fixed that's what we should do
[20:28] <seb128> but if somebody cares and want to fix the issue they should be able to do it
[20:28] <seb128> it's true for any ftbfs not fixed by oneiric...
[20:32] <micahg> doko: seb128, can we just remove the binaries and not the source in case someone wants to fix it?
[20:34] <doko> we can, but still shows up as a ftbfs. I don't see any harm to remove the sources too. cjwatson does want to improve the sync script to not accept the same version again, if it was already in ubuntu
[20:34] <seb128> well no reason to not sync that one next cycle
[20:35] <micahg> doko: I don't think showing up as an FTBFS is a bad thing, it might encourage someone to fix it
[20:35] <seb128> it could well be a toolchain bug since it built before in the cycle and builds in debian
[20:35] <doko> removal doesn't mean not syncing new versions
[20:36] <doko> seb128, just be honest and clear, that you even that you didn't event check to build the package with -g
[20:36] <doko> s/even/even check/
[20:37] <doko> damn mousepad
[20:37] <seb128> what -g would change?
[20:38] <stgraber> kenvandine: ping
[20:38] <doko> get a backtrack which you could look at?
[20:38] <kenvandine> stgraber, pong
[20:39] <stgraber> kenvandine: Currently reviewing https://code.launchpad.net/~vanvugt/ubuntu/natty/light-themes/fix-772972-natty/+merge/70667 but don't know much about the design stuff, is that something we want in natty as an SRU?
[20:40] <seb128> doko, right, I could fix an issue in the default installation that most users will run into or debug something nobody use...
[20:40] <doko> seb128, then we should remove it. agreed?
[20:41] <seb128> not that I don't like epiphany-browser but be realistic most users run firefox and chromium
[20:41] <kenvandine> stgraber, i haven't seen the bug... but it might be worthy of a SRU
[20:41] <kenvandine> jitters sound annoying
[20:41] <seb128> doko, well I personally don't care enough to spend my time on it but others might do
[20:41] <seb128> so I will not speak for them there
[20:41] <doko> ok, removing
[20:41] <seb128> we should let them a chance to fix it if somebody cares enough to step for it
[20:41] <seb128> ok
[20:42] <seb128> doko, you will probably not make friends over it ;-) I would rather let people who care another week chance to fix it
[20:43] <doko> seb128, I disagree. the bug report was filed a month ago. there is no reason why we cannot reintroduce the sources again
[20:43] <seb128> doko, well your call, I've nothing to do with it ;-)
[20:44] <micahg> doko: post-release, it's easier if the sources are there already
[20:44] <doko> besides syncing in the first place :-/
[20:44] <micahg> it's not like it's abandoned upstream
[20:44] <seb128> doko, I synced a debian revision with no code change, we would have got the same issue without that sync
[20:45] <seb128> -1 built, -2 doesn't without code change
[20:45] <seb128> it's something else which changed
[20:45] <seb128> it would have showed up in your rebuilt test
[20:45] <doko> seb128, and you din't care about the build results
[20:45] <doko> repat loop on
[20:45] <doko> repeat even
[20:45] <seb128> how that has to do with the issue?
[20:46] <seb128> you would have got the same issue if -2 wouldn't have been synced
[20:46] <stgraber> kenvandine: ok, diff looks reasonable and the change seems to be in Oneiric (though a lot more changed so not too easy to check). I'm going to sponsor that and get more testing once it's in -proposed
[20:46] <doko> seb128, expose the issue months earlier, and not hiding with "let's wait one more week"?
[20:47] <seb128> well if anything the sync exposed the issue earlier
[20:47] <seb128> because it failed to build at the sync, not in an archive rebuilt later on
[20:48] <smoser> slangasek, around ?
[20:48] <slangasek> smoser: hey there
[20:48] <smoser> i'm playing around with a cloud-image booting locally in kvm
[20:48] <smoser> and after a bunch of poking / digging, i'm seeing stuff like
[20:48] <smoser> /sbin/dhclient-script: line 73: /etc/resolv.conf.dhclient-new: Read-only file sy
[20:48] <smoser> chmod: cannot access `/etc/resolv.conf.dhclient-new': No such file or directory
[20:48] <smoser> can't create /var/lib/dhcp3/dhclient.eth0.leases: No such file or directory
[20:49] <smoser> oh...
[20:49] <micahg> doko: FTBFS are SRU worthy, so please just remove the binaries
[20:49] <smoser> slangasek, i think that network-interface.conf is coming up before / is RW
[20:50] <smoser> and nothing is enforcing it to wait, although it clearly needs it.
[20:50] <chrisccoulson> politcally, removing epiphany will be very bad for us btw ;)
[20:50] <slangasek> smoser: what do you mean, "clearly needs it"?
[20:50] <smoser> well, if it can't write resolv.conf, then i can't resolve hostnames
[20:50] <slangasek> network-interface.conf should certainly not be writing to the root fs
[20:50] <smoser> and i don't want to pass /etc/hosts files around
[20:50] <smoser> :)
[20:50] <micahg> chrisccoulson: right :)
[20:50] <seb128> yeah, removing epiphany would be an error
[20:51] <slangasek> smoser: what's writing to /etc/resolv.conf?  That's not the standard behavior of ifupdown
[20:51] <smoser> dhclient is
[20:51] <slangasek> smoser: God forbid
[20:51] <smoser> dhclient is getting called on the add of eth0
[20:51] <smoser> which is happening before / is rw
[20:52] <slangasek> smoser: no, dhclient does not write to /etc/resolv.conf either; it'll be some hook script called by dhclient in /etc/dhcp3/dhclient-{enter,exit}-hooks.d - and not a standard one
[20:52] <smoser> well... i dont knwo about not a standard one
[20:52] <ScottK> jbicha: One of the changes in http://launchpadlibrarian.net/80663925/yelp-tools_3.1.6-0ubuntu1_3.1.7-0ubuntu1.diff.gz is that it now refers to files in /opt/gnome.  That seems "bad".  Would you please double check this.
[20:53] <slangasek> smoser: point is, writing this to /etc/resolv.conf is *wrong*, and whatever is doing that is *buggy*.  If something wants to provide interfaces for managing resolv.conf dynamically, it should be symlinking this file to somewhere in /run and managing it there
[20:53] <smoser> i'll see what i can find, but there is nothing in the image that is not in main.
[20:53] <seb128> ScottK, is that an autogenerated file? i.e one that will be overwritten on build? it's often the case with GNOME components
[20:54] <slangasek> it is not correct to wait for writable root before bringing up the network interfaces - in some configurations, / may never be made writable
[20:55] <smoser> slangasek, well, its /sbin/dhclient-script that is writing it
[20:55] <smoser> isc-dhcp-client
[20:56] <seb128> doko, chrisccoulson, micahg: seed 3.2 builds fine it seems, I will upload it
[20:56] <smoser> depended on by isc-dhcp-client and ubuntu-minimal
[20:56] <smoser> errr... well not depnedend on by itself, but by ubuntu-minimal
[20:57] <smoser> why exactly i have ubuntu-minimal installed i'm not sure.
[20:58] <slangasek> because it's not an Ubuntu system without ubuntu-minimal? :)
[20:59] <slangasek> so I'm surprised that isc-dhcp-client is doing this... let me dig into the history and get back to you
[21:00] <smoser> slangasek, so how would you think i should get entries in resolv.conf on a dhcp system ?
[21:00] <ScottK> seb128: I don't know.  It's possible.
[21:01] <ScottK> seb128: I don't know much about Gnome stuff, but the diff seemed worth a second look.
[21:01] <seb128> ScottK, well I didn't look at this one but it's 99% chance
[21:01] <ScottK> OK.
[21:02] <ScottK> I'll accept it then.
[21:02] <seb128> thanks
[21:06] <slangasek> smoser: /etc/resolv.conf should be a symlink to somewhere managed in /run
[21:06] <slangasek> smoser: which *used* to be how we did this; I don't understand why we've regressed here
[21:08] <smoser> hmph.
[21:08] <smoser> on my sys, i have resolvconf managing it so it is a symlink, but i know on installation i it complains it is not a symlink and I end up fixing it.
[21:09] <smoser> slangasek, but in the non-dhcp case, then, what would be managing resolv.conf ?
[21:10] <seb128> doko, ok, seed 3.2 uploaded and in approved, it builds fine there
[21:11] <seb128> the new version is part of GNOME and has a small diff so it shouldn't need a feature freeze exception
[21:11] <slangasek> smoser: well, that's a question - I don't have an immediate answer for you.  I can just say that architecturally, assuming /etc/resolv.conf should be managed in-place is wrong :)
[21:12] <slangasek> smoser: btw, /sbin/dhclient-script has a loop that waits for / to become writable... is that not working?
[21:12] <smoser> must not be working
[21:12] <slangasek> smoser: does your /etc/fstab not have a line for the rootfs?
[21:13] <smoser> LABEL=cloudimg-rootfs              /               ext4    defaults        0
[21:13] <smoser>  0
[21:13] <slangasek> should work
[21:13] <smoser> nope
[21:13] <smoser> oh.
[21:13] <slangasek> *should* work :)
[21:13] <smoser> yeah, it should
[21:15] <smoser> slangasek, yeah, that loop seems sane
[21:16] <smoser> i'll poke more at this later.
[21:16] <slangasek> smoser: ok... I'll continue poking at the history to see where things have gone astray, and see what we can do about getting this all properly architected for p
[21:16] <smoser> interestingly, if /etc/resolv.conf *were* a symlink to /run, it would sit and wait until root is rw
[21:16] <smoser> it waits for '-w /etc/'
[21:16] <slangasek> yep
[21:17] <smoser> later.
[21:17] <slangasek> enjoy :)
[21:17] <smoser> thanks for your help, slangasek
[21:17] <micahg> seb128: will epiphany 3.0 work with it though?
[21:19] <seb128> micahg, there is like 25 commits between 3.0 and 3.2 and mostly translation updates and bug fixes, so I guess so
[21:19] <seb128> micahg, if not we will fix epiphany
[21:41] <jtaylor> doko: glib2.0 fails to build with APPEND {CFLAGS,LDFLAGS} -flto (binutils <IP_ADDRESS>10810-0ubuntu3 with PR ld/13201 "fixed")
[21:43] <jtaylor> http://paste.ubuntu.com/695329/ bug should get filed soon by the guy who found it
[21:44] <jtaylor> is flto still not ready for general use or could this be an as-needed related bug?
[21:45] <doko> jtaylor, is this with the glib2.0 in the archive?
[21:45] <jtaylor> yes
[21:45] <jtaylor> 2.29.92-0ubuntu1
[21:46] <jtaylor> its weird ldd -r libglib.so does not list any undefined references
[21:46] <doko> in general, anything else than -g -O2 (distribution defaults) should be handled by the package maintainer
[21:46] <jtaylor> those functions are connected to FORTIFY_SOURCE or?
[21:47] <doko> jtaylor, please check with -U_FORTIFY_SOURCE if you can
[21:48] <jtaylor> running
[21:52] <jtaylor> ok now I get this: /tmp/glib2.0-2.29.92/./glib/tests/mem-overflow.c:137:1: sorry, unimplemented: gimple bytecode streams do not support the optimization attribute
[21:53] <jtaylor> but it got past the linking issue from before
[21:53] <doko> I'll look at it tomorrow, but not now
[21:53] <jtaylor> no problem thanks
[21:59] <stgraber> @pilot out
[22:15] <jtaylor> bug 856839
[22:43] <Sweetshark> Hi all. I have a question about bug status handling: Could somebody have a look at https://bugs.launchpad.net/df-libreoffice/+bug/745836/comments/51 and give me an opinion/judgement before that escalates into a bug-state-war? (asking here because ubuntu-bugs is silent)
[22:53] <Viper550> Hello
[22:55] <bdrung> tumbleweed: $ syncpackage ubuntu-dev-tools
[22:55] <bdrung> syncpackage: Error: Debian version 0.132 does not exist!
[23:01] <Laney> https://launchpad.net/debian/+source/ubuntu-dev-tools


[14:27] <slickymaster> elfy, if you want me I can review https://code.launchpad.net/~elfy/ubuntu-manual-tests/1350122_1359371/+merge/236220
[14:28] <elfy> it's ok - no rush for those
[14:28] <elfy> trying to clear some bugs
[14:28] <slickymaster> ok, I''l do it through the weekend
[14:29] <elfy> ok :)
[14:29] <knome> slickymaster, you can communicate that via the merge request itself by claiming the review
[14:30] <slickymaster> I know knome, but I thought og ping elfy first, in case he might had other intentions on who would be reviewing it
[14:30] <slickymaster> s/og/on
[14:31] <knome> then he could have set the reviewer:)
[14:31] <elfy> he meant too
[14:31] <slickymaster> well, I was being polite then :P
[14:31] <knome> nah ;)
[14:32] <elfy> thanks for the politeness slickymaster :)
[14:33]  * slickymaster bows towards  elfy's and knome
[14:33] <slickymaster> without the 's
[14:33] <knome> lol
[15:21] <Nothing_Much> I can't launch testdrive on 14.10 :(
[15:23] <Nothing_Much> https://bugs.launchpad.net/ubuntu/+source/psensor/+bug/1346299 I get this exact error here
[15:24] <Nothing_Much> Should I report a new bug?
[15:24] <Nothing_Much> Or since it's the same error, should I bump that report?
[15:26] <Nothing_Much> o.o
[15:36] <Nothing_Much> I guess I'll just report a new bug
[15:45] <Nothing_Much> https://bugs.launchpad.net/ubuntu/+source/testdrive/+bug/1374784


[00:26] <thumper[m]> added
[00:27] <tlm> matrix thumper
[00:27] <thumper[m]> I've added a #juju channel in matrix.org with an IRC bridge
[00:28] <timclicks[m]> removed it from the juju-devops room I created
[00:28] <thumper[m]> Just messing around testing just now
[00:31] <tlm[m]> howdy
[00:40] <thumper> it looks like the matrix bridge only creates users on demand...
[00:41] <timClicks> I think we confused the bot because there were two matrix rooms bridged
[00:43] <thumper> have you removed the second one?
[00:47] <thumper[m]> https://github.com/juju/juju/pull/11313 up for review
[00:47] <TimM[m]> <thumper "have you removed the second one?"> yes, that room is now empty
[00:48] <tlm[m]> thats working
[00:48] <TimM[m]> lol yup
[00:48] <thumper[m]> uh ha, I see many new folks
[00:48] <thumper[m]> also, I was curious as to how the reply would look in irc
[00:49] <TimM[m]> pretty keen to charm up a matrix home server now
[00:49] <tlm[m]> was having the same thought
[00:49] <thumper[m]> I think ec0 has done that
[00:49] <thumper[m]> or at least some aspects of that
[00:50] <TimM[m]> https://github.com/alchemy-charmers/charm-matrix
[00:52] <ec0[m]> yep, that one :)
[00:52] <ec0[m]> Tim M:
[00:52] <ec0[m]>  * Tim M: let me know if you get stuck on it
[00:53] <ec0[m]> there's still some rough edges but the snap stuff has been merged upstream, and the charm does deploy a working homeserver
[00:53] <TimM[m]> I was thinking about Juju for web workloads, and discovered that the latest series that fail2ban supports is trusty
[00:54] <TimM[m]> I made several edits yesterday after work and I have it working for more recent series also
[00:54] <TimM[m]> it's still based on charmhelpers, but that can change too over time
[01:00] <wallyworld> timClicks: just saw this "Controller independent of the k8s cluster: A Juju controller must sit outside of Kubernetes."
[01:00] <wallyworld> in the mapping juju concepts
[01:00] <timClicks> Oh right, yes I meant to clarify that
[01:00] <wallyworld> that's no longer true
[01:00] <wallyworld> used to be early on
[01:00] <timClicks> Cool, I thought so, will update
[01:00] <wallyworld> ty
[01:19] <tlm[m]> wallyworld kelvinliu pushed up the tmp work around
[01:21] <kelvinliu> yup, will have a look, ty
[02:13] <thumper> wallyworld: this is the PR we talked about https://github.com/juju/juju/pull/11313
[02:13] <wallyworld> sorry, getting to it, will look now
[02:13] <thumper> ack
[02:15] <wallyworld> thumper: lgtm. love deleting tests from state
[02:15] <thumper> thanks
[02:15] <wallyworld> if we delete enough, maybe no more timeouts
[02:15] <thumper> if we move the check tests to github actions, we may have the same
[02:15] <wallyworld> indeed
[06:38] <TimM[m]> ec0:  here is the fail2ban charm I was talking about https://github.com/timClicks/fail2ban-charm
[10:08] <stickupkid> manadart, did you land the model cache changes in 2.7 or 2.8 ?
[10:08] <stickupkid> manadart, https://mail.google.com/mail/u/0/#inbox/FMfcgxwGDNVHpPHvPqQWhcTLDkdQLjNz
[10:09] <stickupkid> manadart, https://bugs.launchpad.net/juju/+bug/1860970
[10:09] <mup> Bug #1860970: SetCharmProfiles is called too frequently <juju:Triaged> <https://launchpad.net/bugs/1860970>
[11:11] <stickupkid> manadart, wtf is this https://github.com/juju/juju/pull/11279#issuecomment-598669584 ?
[11:13] <manadart> ¯\(°_o)/¯
[11:13] <stickupkid> silly bot
[11:42] <manadart> stickupkid: Got a sec for https://github.com/juju/juju/pull/11316 ?
[11:44] <stickupkid> manadart, done
[11:44] <manadart> stickupkid: Ta.
[12:41] <hml> stickupkid:  why does https://github.com/go-goose/goose/pull/82 include the deprecated commit as well?  got really confused in review.  :-D
[12:42] <rick_h> sorry achilleasa looking
[12:42] <stickupkid> hml, I wanted to rebase once deprecated one has landed
[12:42] <stickupkid> :)
[12:42] <achilleasa> rick_h_: so I am nearly there with the relation-created hook https://pastebin.canonical.com/p/CJkg76rpKS/ I am still trying to get rid of that spurious relation-departed hook
[12:43] <achilleasa> is this the right order of hooks? install, xxx-relation-created, leader-elected, ... ?
[12:43] <rick_h> achilleasa:  yea, so after the install (deps/etc are available on the system) and before leader-elected. So that it can check if there are/will be other units coming in.
[12:43] <stickupkid> rick_h, achilleasa manadart https://github.com/juju/juju/pull/11317
[12:44] <achilleasa> rick_h: and this is how it looks for the non-leader unit: https://paste.ubuntu.com/p/3vGczmCQ7v/
[12:45] <stickupkid> rick_h, exactly, doing that step now
[12:46] <rick_h> achilleasa:  cool!
[12:46] <stickupkid> rick_h, offically /usr/bin/env python should work, but it doesn't - shame
[12:46] <rick_h> stickupkid:  well it's not "python" it's python3
[12:46] <rick_h> that works
[12:46] <rick_h> the thing is that if you want it to work you'd have to symlink python3 to just python
[12:46] <rick_h> it's the "official way"
[12:47] <stickupkid> :(
[12:47] <rick_h> stickupkid:  for our purposes, given we know the system, we should just prefix the .py script command in the dh with the right python for the system
[12:48] <rick_h> stickupkid:  e.g. HOME=obj-x86_64-linux-gnu/home /usr/bin/$PYTHON /<<PKGBUILDDIR>>/src/github.com/juju/juju/scripts/generate-docs.py man -o obj-x86_64-linux-gnu/juju.1
[12:48] <rick_h> where $PYTHON is figured out with shell foo for "should it be path to py2 or py3"
[13:11] <stickupkid> rick_h, yeah, works for 2.7 and 3 https://github.com/juju/juju/pull/11317/files
[14:04] <hml> stickupkid: approved 81
[14:04] <hml> looking at 82
[14:12] <achilleasa> hml: can you take a look at https://github.com/juju/charm/pull/305 ?
[14:13] <hml> achilleasa:  will do after current review in progress.  :-)
[14:13] <achilleasa> hml: not in a hurry
[14:17] <hml> stickupkid: 82 is approved with some suggestions.
[14:28] <manadart> Bionic packages for 2.7.4 are in stable. Confirmed and tested. Working on the others.
[14:40] <hml> achilleasa:  approved
[14:55] <manadart> Eoan is there.
[15:52] <admcleod> having a problem fetching interfaces, e.g. https://juju.github.io/layer-index/interfaces/haclster.json
[15:52] <admcleod> feels like a faulty node in a pool somewhere
[15:52] <admcleod> or a firewall rule here somewhere
[19:24] <hml> admcleod: looks like the whole site is down.  not sure who is around right now to help.  maybe an RT?  grasping here.  :-)