[00:18] <persia> cody-somerville: Tell the CC, not me :)
[00:58] <RoAkSoAx> hey guys how to make autotool update patches during build with debhelper?
[00:58] <RoAkSoAx> i meant, how to make autotool files get update during build with dh7?
[00:59] <persia> How much of an update do you want?
[01:01] <RoAkSoAx> persia, let me explain, lighttpd used to be package with cdbs and in UBuntu the lighttpd-dev package was itnroduced and they were using DEB_AUTO_UPDATE_* variables to ensure autotool files get updated with the ubuntu patches. however, now lgihttpd has been changed to dh7. How would I do the same to ensure that autotool update its file with the patches?
[01:04] <persia> Do you understand what DEB_AUTO_UPDATE_* did?
[01:05] <RoAkSoAx> persia, just ensure automake's version to use?
[01:05] <persia> heh.  No.
[01:06] <persia> So, which of DEB_AUTO_UPDATE_* were actually used?
[01:06] <RoAkSoAx> persia, http://paste.ubuntu.com/390707/
[01:06] <persia> Generally the definitions of those can be derived from /usr/share/cdbs/1/class/autotools-files.mk
[01:08] <persia> (although autotools.mk and autotools-vars.mk have some)
[01:09] <persia> Once you know what you actually wanted to do, you'd probably want to add an override_dh_auto_configure: rule.
[01:09] <RoAkSoAx> ok
[01:11] <persia> Looks to me like it's intending to go all the way from libtoolize onwards.
[01:11] <persia> Note that you can call dh_auto_configure in your override_dh_auto_configure: rule to take care of the rest once you're finished with the autotools stuff.
[01:13] <RoAkSoAx> awesome. Thanks a lot
[01:20] <RoAkSoAx> persia, where can I find good documentation to learn everything about this?
[01:21] <rdz> hi all. i am trying to create a package for my ppa. everything seems to compile fine. howerver, the resulting deb files does not contain any binaries, although i see that those are compiled
[01:25] <persia> RoAkSoAx: For CDBS, search for "CDBS Documentation", but mostly read the source.  For dh(1), man dh and look at the sequences in the dh source.
[01:25] <persia> For autotools, get the goat book
[01:26] <RAOF> persia, RoAkSoAx: Also, running dh --no-act $TARGET in a packaging directory will list the sequence, including any overrides you've specified.
[01:26] <persia> rdz: One of four things is true 1) your debian/rules install rule is wonky, 2) You didn't set some variable you need to feed the upstream build system to define the install target, 3) the upstream build system is wonky, or 4) you need to add more hints to dh_install
[01:27] <persia> RAOF: Nifty.  Thanks for the hint.
[01:27] <RoAkSoAx> persia, awesome thanks :)
[01:27] <RoAkSoAx> RAOF, and good tip :)
[01:28] <persia> s/One of/At least one of the following/
[01:33] <rdz> persia, thanks for the hints...... but how can i find out, which one applies?
[01:34] <rdz> do the version and major varibals in the #shared library versions-section do have influence on this?
[01:36] <persia> rdz: They can, but it's potentially more complicated than that.
[01:36] <rdz> persia, here it the respective section from pbuilder output: http://pastebin.ca/1827974
[01:36] <rdz> i don't understand what is happening here, but it looks to me as in certain cases, files are removed
[01:38] <rdz> persia, netsplit: could you read my last message (i don't understand... )
[01:39] <persia> rdz: Are you trying to make multiple binary packages from a single source package?
[01:39] <rdz> persia, no.. i am trying to make a lib package
[01:40] <rdz> persia, i admit it's my first trial of creaeting a ppa package.. so i might made some mistakes
[01:40] <rdz> persia, actrually the only important file doesn't get included..
[01:41] <rdz> which is: /usr/lib/libsomelibraries.so
[01:41] <persia> That's not supposed to be an important file.  That should be a symlink.
[01:41] <rdz> which is: /usr/lib/libsomelibraries.so.1.0.0
[01:41] <rdz> would be the file, ,you're right
[01:41] <persia> But I'll strongly recommend you go work with other sorts of packages first.  libraries are hard for several reasons, and learning packaging and library packaging, and library management all at the same time is likely an exercise in frustration.
[01:42] <rdz> what makes library managment specially hard?
[01:43] <rdz> persia, the only thing, that seems not working right now, is that the file is not included.. is that a impossible to solve problem? it seems so silly to me
[01:44] <persia> rdz: It's an easy to solve problem.  The issue is entirely in your dh_install hint file contents.  I'm just certain that it's a lot to get right, and you'll end up finding a bunch of little issues.
[01:44] <rdz> persia, which i am willing to solve
[01:44] <persia> rdz: Also, have you read the prior IRC sessions about packaging libraries?
[01:44] <rdz> persia, this library comes with only one binary..
[01:44] <rdz> persia, no, but i will
[01:45] <rdz> persia, thanks for mentioning those
[01:45] <persia> rdz: A library should *never* come with just one binary.  At a minimum you want libfoo1.0.0 and libfoo-dev
[01:46] <rdz> persia, both packages are built.. i mean that libfoo package only contains 1 single binary
[01:47] <persia> Oh, right.  That's normal.  paste your libfoo.install file?
[01:48] <rdz> persia, hm.. now you're asking me that, i realize what might be wrong
[01:48] <rdz> the package is called 'libgavl1', however the files in debian are called simply gavl
[01:48] <rdz> gavl.*
[01:49] <rdz> like gavl1.install.. should they be called libgavl1.install etc?
[01:49] <persia> Something like that.  Should be a binary package name.
[01:49] <persia> (double-check against debian/control)
[01:49] <rdz> persia, thanks..
[01:50] <rdz> the package is called libgavl1, libgavl1-dev and libgavl1-doc
[01:53] <rdz> however, the 'source' is gavl
[01:53] <rdz> i mean the source field in debian/control
[01:54] <persia> rdz: That sounds right.
[01:55] <rdz> persia, but that means, that all files in debian need to be called libgavl1.install and the like?
[01:56] <persia> rdz: Well, ${binary-package-name}.${function}, but yeah.
[01:56] <rdz> persia, thanks.. for being so precise
[01:57] <rdz> persia, something is still worng.. how can i find out the ${binary-package-name}?
[01:57] <persia> It's listed in debian/control
[01:59] <rdz> persia, hm.. then there is something wrong with my debian/control file
[01:59] <rdz> i cannot find a variable like that
[01:59] <persia> rdz: It's not a variable.  It's the Package: name
[02:00] <rdz> ah.. ok.. then the files are named correctly
[02:13] <RoAkSoAx> persia, do you think it would be a good idea to add a lighttpd.pc.in and modify configure and Makefile without using a patching system since debian has dropped the use of it.
[02:14] <persia> RoAkSoAx: I need more context to have an opinion.
[02:16] <RoAkSoAx> persia, here's the changes made to enable the build of -dev package: http://paste.ubuntu.com/390741/
[02:17] <persia> RoAkSoAx: You'll also need lighttpd-dev.install
[02:18] <persia> RoAkSoAx: But are you saying there's no longer a patch system used in Debian, but there once was?
[02:18] <rdz> how is the libfoo.symbols files generated?
[02:19] <RoAkSoAx> persia, yeah there was one, I was thinking on enabling quilt and place what I've pasted in the patch, but I did that, added the --with quilt, but this way it's not building
[02:19] <persia> rdz: https://wiki.ubuntu.com/stefanlsd/dpkg-gensymbols is a good guide to what you seek to do that also happens to answer the question you asked.
[02:20] <RoAkSoAx> i applied the patch directly to the source and it builds and I can't figure out what might be wrong with it
[02:20] <rdz> persia, many trhanks
[02:20] <persia> RoAkSoAx: Race condition:  Check the build log.  If you want separated patches, but need them early, consider source format 3.0(quilt).
[02:22] <RoAkSoAx> persia, will look into it then. thanks :)
[02:27] <jayvee> persia: you got me to update tahoe-lafs to 1.6.1 for zooko. I still haven't heard back from him, but I just put the .diff.gz on the bug at https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/529350
[02:28] <persia> jayvee: OK.  The next step is to request upload.  Just subscribe the sponsors if you feel that this is uploadable.  As both zooko and you have noted, it shouldn't need a freeze exception.
[02:30] <jayvee> persia: who are the sponsors? is that the package maintainer?
[02:30] <persia> !sponsor
[02:30] <persia> https://wiki.ubuntu.com/SponsorshipProcess
[02:31] <jayvee> oh right
[02:31] <jayvee> I'd seen that before, but it didn't twig.
[02:31] <persia> jayvee: No worries.  Takes a while to get familiar with the processes, etc.
[02:31] <jayvee> I was trying to think of the team to subscribe, but I couldn't for the life of me remember it.
[02:31] <persia> Thanks a lot for helping out.
[02:34] <jayvee> On my other libvirt bug, mathiaz removed the ubuntu-main-sponsors subscription. He didn't give any clues as to why he might have done that. Do you have any idea?
[02:34] <jayvee> Is that normal after it gets looked at?
[02:35] <persia> Yes, but it's typically followed by an upload shortly.  What was that bug number again?
[02:35] <rdz> persia, i checked the four points you mentioned and the .so file is still not included.
[02:35] <jayvee> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/528934
[02:36] <persia> rdz: Considering that you can force-include it with debian/${binary-package}.install, I'm certain there's an issue with that file.  You aren't using a leading / in the target, are you?
[02:37] <rdz> persia, that is the content of libgavl1.install: usr/lib/libgavl.so.1*
[02:37] <rdz> persia, can it be, that might something goes wrong even before that?
[02:38] <persia> jayvee: mathiaz would have removed the subscription when asking for the upstream link, etc.  Once you've addressed the concerns in his comment (which you did), just resubscribe the team.  This is done to try to reduce the queue to only those things needing active sponsoring.
[02:38] <jayvee> Oh, I get it.
[02:38] <jayvee> Just re-added it.
[02:39] <persia> rdz: Maybe that file doesn't exist?  Maybe something went wrong earlier.  Try setting DH_VERBOSE=1 and reading the build log carefully.
[02:39] <rdz> persia, is it possible to log to a file instead a of to stdout?
[02:40] <persia> rdz: How are you building your package?
[02:41] <persia> Any of debuild, pbuilder, sbuild, cowbuilder, etc. will put the log in a file.
[02:41] <rdz> persia, debuild -S, then 'pbuilder build libgavl-xxxxxxxx.dsc'
[02:41] <persia> rdz: So pbuilder creates a log file somewhere (I don't know where), and you can inspect that.
[02:42] <persia> jayvee: Also, nominations for the current release don't usually mean anything.  If someone rejects it, don't think that means it won't hit lucid.  Nominations are more interesting for old releases.
[02:43] <jayvee> Good to know, thanks.
[02:44] <persia> Also, I'll encourage you to hang out in #ubuntu-server : that's a better place to get advice on working with server packages, contact server developers, etc.
[02:44] <jayvee> yeah, I was there the other day — had a good chat
[02:44] <persia> (not that we won't help you here: most of us are too lazy to check if some package falls into our purview, and will just answer questions)
[02:45] <jayvee> and I really appreciate the answers. :)
[03:05] <rdz> persia, the log doesn't reveal any specific.. am i supposed to put 'export DH_VEBOSE=1' into debian/rules ?
[03:05] <persia> rdz: Yes.
[03:06] <rdz> persia, probably i need to omit the 'export' part
[03:06] <persia> No.  You want the export part.
[03:06] <rdz> vim syntax highlighting seems to indicate that at least
[03:06] <persia> The vim needs to read the make manual :)
[03:06] <rdz> persia, there is no error nor something else suspicious
[03:06] <rdz> persia, hehe
[03:07] <persia> You aren't looking for an error.  You're looking to understand precisely what is happening so that you can see why what you expect isn't happening.
[03:07] <rdz> it compiles find, but then i am not able to trace what happens to the binary
[03:08] <rdz> persia, it's hidden in some obscure libtool commands
[03:09] <rdz> i am running out of ideas...
[03:09] <rdz> :-/
[03:09] <persia> rdz: That's part of why I said this was complicated to do all at once :)
[03:10] <persia> rdz: Try a local build (not using pbuilder) and inspect the leftovers after it's done.
[03:10] <rdz> persia, you mean: make && make install ?
[03:10] <persia> If you use debuild -b after debuild -S, you can usually safely remove the entire working directory and reunpack the source package with dpkg-source to get back where you were (ideally, the clean rule does this, but just in case your package is buggy)
[03:11] <RoAkSoAx> persia, if i put in build-stamp dh_quilt_patch, should I have to put also a dh_quilt_unpatch ?
[03:11] <persia> rdz: No, you want to exercise the build scripts in packaging.
[03:11] <rdz> persia, aha
[03:11] <persia> RoAkSoAx: No idea.  I never do it that way.
[03:11] <persia> RoAkSoAx: What are you trying to accomplish?
[03:14] <rdz> persia, where do i get some variables from ? $(CFLAGS)?
[03:14] <RoAkSoAx> persia, well I actually discovered how to make quilt to patch the source by adding dh_quilt_patch in build-stamp: http://pastebin.ubuntu.com/390768/ However, I do not know if I should create a clean target to put dh_quilt_unpatch or override the clean rule, or where
[03:14] <persia> rdz: Just run debuild -b in the package directory.  Anything that doesn't work wouldn't work in pbuilder anyway.
[03:15] <persia> RoAkSoAx: Just use --with quilt (man dh) for that.
[03:15] <persia> RoAkSoAx: Also, you may as well drop your binary and binary-arch rules: they don't do anything interesting.
[03:16] <persia> RoAkSoAx: Also, your life will be a lot easier if you replace the entire build/build-stamp section with an override_dh_auto_configure rule.
[03:16] <rdz> dpkg-checkbuilddeps: Unmet build dependencies: doxygen
[03:16] <rdz> however, it is mentioned in debian/control:build-depends
[03:16] <persia> RoAkSoAx: You probably want to do your chmods in an override_dh_fixperms rule (see man dh)
[03:17] <persia> RoAkSoAx: And finally, you ought be doing the install with dh_install rather than sticking it in install-stamp.  Allof these will make your rules file easier to read.
[03:17] <persia> rdz: debuild doesn't automatically install your build-dependencies.  Just install them.
[03:18] <RoAkSoAx> persia, I tried using '--with quilt', however, it wasn't actually patching the source so that's why It wouldn't get the changes for the -dev package, that's why I needed to figure out another way to make it patch the source before the configure and I did it that way and now the package builds
[03:18] <rdz> persia, thanks
[03:18] <RoAkSoAx> persia, binary,binary-arch, build/build-stamp, install-stamp all come from debian, should I just fix that and submit a patch?
[03:19] <persia> RoAkSoAx: Only if you wish, and don't change it if they do it that way.  To me, it's not an elegant way to use dh(1), but well.
[03:20] <persia> The reason --with quilt wasn't working for you is because you didn't add it to all the relevant dh calls.
[03:20] <persia> Well, and also, perhaps, because of timing issues, but that's separate.
[03:21] <RoAkSoAx> persia, where/what are those relevant dh calls, binary-arch:install ?
[03:22] <persia> RoAkSoAx: There are dh calls in build-stamp and install-stamp and binary-arch that don't have --with quilt
[03:22] <persia> There's also an unexpected dh_quilt_patch
[03:22] <RoAkSoAx> persia, oh so *all* have to be --with quilt
[03:22] <rdz> persia, the file is there in <package-src>gavl/.libs/libgavl.so.1.0.0
[03:22] <RoAkSoAx> i thought they only had to be in
[03:22] <RoAkSoAx> %:
[03:22] <RoAkSoAx>         dh --with quilt $@
[03:23] <persia> RoAkSoAx: Well, either that, or you need to manage quilt separately (e.g. with dh_quilt_patch and dh_quilt_unpatch at appropriate times)
[03:23] <persia> It only has to be there if that's the only dh call :)
[03:23] <persia> It's still a makefile, and %: only gets hit if nothing else matches.
[03:24] <RoAkSoAx> oh it now make sense then, so that might actually be the problem why It wasn't patching
[03:25] <RoAkSoAx> thanks for the enlightenment :)
[03:25] <persia> RoAkSoAx: The key is to understand the tools you use.  Once you have that, everything becomes easy :)
[03:26] <RoAkSoAx> persia, indeed though I haven't played with the new source format much yet :) So It is just matter of practice and reading
[03:27] <persia> RoAkSoAx: There's heaps of patches in the bugtracker, if you just want a target for experimentation.  Just grab one, test it, get it integrated in the packaging, and submit.
[03:28] <rdz> persia, i think, that is the relevant part of the log: http://pastebin.ca/1828110, but i cannot see anythin suspicious.. all pathes seem correct
[03:29] <persia> rdz: The first line is incorrect.  It doesn't matter if "/usr/lib" exists, because that's not the target.
[03:29] <persia> So the directory is probably not being created.
[03:30] <persia> Also, you have a warning: perhaps libtool hasn't actually done stuff.
[03:31] <rdz> persia, ah
[03:31] <persia> Did the file get placed in the right location in a test build?
[03:31] <RoAkSoAx> persia, any link in specific where i can look for them?
[03:31] <rdz> persia, no
[03:31] <rdz> it's empty as well
[03:31] <rdz> persia, by testbuild you mean the resulting deb file?
[03:32] <persia> RoAkSoAx: https://bugs.launchpad.net/ubuntu/+bugs?orderby=-date_last_updated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.omit_dupes=on&field.has_patch=on
[03:32] <persia> rdz: No, I mean by running debuild -b locally.
[03:32] <rdz> persia, that is what i did
[03:32] <persia> rdz: That lets you check what happened and what didn't, and may help you understand what is going wrong.
[03:32] <rdz> and it created deb files
[03:33] <persia> Right, but did it create /home/roman/sources/gavl-1.2.0pre1/debian/tmp/usr/lib/libgavl.so.1.0.0
[03:33] <rdz> ah
[03:33]  * persia suspects it didn't
[03:33] <persia> The point of the local build is to be able to inspect the leftovers, not to look at the logs.
[03:33] <rdz> indeed, the file is there
[03:33] <rdz> persia, gotcha.. thanks for your patience
[03:34] <rdz> persia, everything seems to be there in debian/tmp
[03:34] <persia> rdz: Now, did it get copied to debian/libgavl1 (or whatever) A?
[03:34] <RoAkSoAx> persia, awesome! Well I'll call it for the night. Thanks a lot for the help. Have a good one :)
[03:34] <persia> rdz: Just follow along the expected path until you find the missing bit.  Then fix that.
[03:34] <persia> RoAkSoAx: Have a good night.
[03:35] <rdz> persia, no,it is not there
[03:36] <persia> rdz: Then you have an issue with your dh_install call.
[03:36] <rdz> hm.. i don't have a clue what
[03:38] <rdz> yo... persia thanks so far.. you're a great help
[03:38] <rdz> dh_install: libgavl-dev missing files (usr/lib/lib*.a), aborting
[03:38] <persia> There you go.  That's the issue.
[03:38] <persia> Don't install those anyway.
[03:42] <rdz> persia, great.. dh_instal doesn't produce any errors......
[03:42] <rdz> persia, many many thanks
[03:42] <rdz> persia, i wonder, why i don't see the very same error in the log?
[03:51] <persia> So, anyone wanting support for packaging in general, not related to MOTU work, please go to #ubuntu-packaging
[03:51] <persia> Anyone willing to offer such support may want o idle there.
[03:55] <ScottK> persia: So we don't have enough channels already?
[03:55] <rdz> persia, am i right in assuming that the rules are executed as fakeroot?
[03:55] <persia> ScottK: I got tired of the ping-pong match between here and #launchpad about where to get PPA support, so I just created a channel.
[03:55] <persia> Interested people can use it.
[03:55] <persia> But there's no *requirement* to use it.
[03:56] <ScottK> OK. so "not related to MOTU" is about PPAs (at least in part)?
[03:58] <persia> ScottK: Right.  PPAs, new packages, other random stuff.
[03:58] <ScottK> Until Universe actually gets disestablished in some manner, I think that new packages are related to MOTU.
[03:58] <persia> Whereas helping track down something that needs fixing in one of our packages, is more on-topic here.
[03:58] <ScottK> Certainly.
[03:59] <persia> Sure, for new packages trying to actually enter the distribution.  Lots of support seems to be about new packages for PPAs, and I doin't think MOTU should be the support channel for that.
[03:59] <jdong>  what's the latest on how long / in what capacity is the MOTU entity supposed to stay around?
[03:59] <ScottK> persia: Agreed.
[03:59] <ScottK> jdong: Indefinitely.  Mostly like now.
[04:00] <jdong> ok
[04:00] <persia> jdong: Go read the "Future of MOTU" thread on the mailing list.
[04:00] <ScottK> There are quite a number of fine points around that 'mostly', but I think it's generally correct.
[04:00] <jdong> I was loosely following it
[04:00] <persia> My initial post covered the history, status, and expected plans fairly well (but real implementation depends on support from all MOTU)
[04:01] <ScottK> Thanks for taking care of that persia.
[04:01] <jdong> indeed, thank you persia
[04:01] <jdong> reading your initial post again more carefully
[04:01] <persia> ScottK: The issue is that I know I can't staff it myself, so whether this actually works depends on their being enough folk willing to make it happen.  I just fiddled the IRC server.
[04:03] <psusi> o/ jdong
[04:03] <jdong> hey psusi
[04:03] <jdong> long time no see!
[04:03] <psusi> yea, been a while ;)
[04:04] <psusi> say, you know much about udev?  I'm trying to track down what appears to be an infinite udev loop in 10.04 related to udev
[04:05] <psusi> related to dmraid rather
[04:09] <rdz> where can i read about the debian/rules file?
[04:10] <crimsun> rdz: http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
[04:11] <rdz> crimsun, thanks
[04:21] <rdz> persia, just for your information.. my issue is finally solved. many many thanks for all your help and your patience
[04:22] <rdz> persia, i could really learn a lot today, with your help
[04:36] <persia> rdz: Glad to hear it :)
[04:38] <rdz> am i right in thinking, that dh_makeshlibs is used to create automatically the postinst and postrm scripts, so that ldconfig is executed after installation/removal?
[04:41] <RAOF> It's primary purpose is to make the shlibs files, but it also adds the ldconfig calls, yes.
[04:41] <rdz> RAOF, when i simply do 'fakeroot dh_makeshlibs' i don't get any postrm / postinst scripts
[04:46] <RAOF> Hm.  I'm not sure off the top of my head if you'd expect that.
[04:47] <RAOF> You're running dh_makeshlibs in the root of your packaging directory, and you actually have some shared libraries there?
[04:47] <rdz> RAOF, yup
[04:48] <rdz> i see the file debian/libgavl1.postinst.debhelper file growing, but actually cannot find the actual script
[04:49] <RAOF> What about after running dh_installdeb?
[04:51] <rdz> RAOF, many thanks
[06:28] <dholbach> good morning
[06:40] <micahg> YokoZar: did you ever file that bug for pidgin-mbpurple?
[08:02] <wrapster> i have a control file like this.. http://pastie.org/859191 and i wanted to add 'Conflicts' to the pkg 'sprosslnk' I added/built the entire pkg.. but when i try to install that pkg i see that I can find this entry missing..When i open up the control file (the one i've pasted) after buildpkg, I can see that the entry im made is missing.. why so.. and how do i add it ?
[08:11] <persia> wrapster: I'll suggest you ask in #ubuntu-packaging (as we don't have that package, and it's past feature-freeze, so we're not concentrating on new packages)
[08:13] <wrapster> persia: they dont seem to be responding.. and hardly anyone on that channel
[08:17] <persia> wrapster: Just wait a bit.  I'm certain someone will help ;)
[08:39] <lifeless> wrapster: generally you don't want a conflicts
[08:39] <lifeless> wrapster: breaks is usually better
[08:39] <wrapster> lifeless: ok.
[08:39] <lifeless> wrapster: see policy for their specific meanings.
[08:39] <wrapster> ok
[08:55] <persia> In python, if I have a sequence "A and B or C and D or E and F" will that behave the same as "A && B || C && D || E && F" in shell?
[08:55]  * persia suspects so based on playing with the python interactive environment, but would like confirmation
[08:57] <lifeless> persia: yes
[08:57] <persia> lifeless: Thanks.
[08:58] <lifeless> or rather, 'near enough'
[08:58] <lifeless> as python has evaluations for true/false that shell doesn't.
[08:59] <persia> The important part was just that if the current state is false and the next word is "and" drop it, if the current state is true and the next word is "or" drop it, and otherwise continue.
[09:01] <lifeless> it also returns the last thing looked up
[09:01] <lifeless> false or 0 -> 0
[09:01] <superm1> persia, why don't you just add some extra parentheses to clarify your intent though?  surely someone who is reading over that code will have difficulty making sense of it and trying to figure out the order of operations otherwise
[09:02] <persia> superm1: Um...  I was saving them for the lisp hackers fund?
[09:02]  * persia adds parentheses
[09:04] <hyperair> iulian: it seems that the last person who touched gdeskcal in ubuntu was you. why was XB-Python-Version switched away from ${python:Versions} to >= 2.4?
[09:58] <slytherin> does anyone know if FFe are still being approved for packages in universe/multiverse?
[10:01] <persia> slytherin: On a case by case basis, FFes may be approved until release day.  Note that we are also currently in UI Freeze.  More freezes come into effect over time, and there will be more limitations.
[10:02] <slytherin> persia: Fine. The package I am working does not seem to break UI freeze. So I suppose it will get approved.
[10:02] <persia> Depends on the features, etc.
[10:06] <slytherin> persia: The package is gst-plugins-ugly-multiverse0.10. It is more of 'make it work with latest x264' release. But reading the changelog I feel like there are few feature additions.
[10:09] <persia> slytherin: If you're not sure, ask for ubuntu-release review.
[10:09] <slytherin> yes I am filing a FFe bug.
[10:40] <mok0> NCommander: I wanted to send you an email today, but your address is not on your LP page
[10:40] <NCommander> mok0: there's a "Send this user email" link if need be
[10:40]  * NCommander probably should de-private his email addresses again
[10:41] <mok0> NCommander: it doesn't hurt :-)
[10:41] <NCommander> mok0: what can I do for you?
[10:41]  * NCommander notes he's recovering from a harddrive crash, so I'm a bit disorganized ATM
[10:41] <mok0> NCommander: it concerns getting backporters team up to speed
[10:42] <mok0> NCommander: ... and I see you are a member of that team :-)
[10:42] <NCommander> eek
[10:42] <mok0> hehe
[10:42]  * NCommander runs out the nearest airlock
[10:42] <NCommander> mok0: I don't have a lot of free time to look at backports so much recently, but if you have a specific backport you want looked at ...
[10:43] <mok0> NCommander: That's not my problem
[10:44] <mok0> NCommander: let me send you the mail
[10:44] <NCommander> mok0: sure, but I won't be reading it for awhile. Still have to re-seutp mail clients
[10:44] <mok0> NCommander: I'll just use the web interface
[10:44] <mok0> NCommander: OK, I'll pastebinit
[11:04] <iulian> hyperair: Yay, that was a looong time ago.  I have no idea, sorry.
[11:57] <rdz> i uploaded a package to my ppa to be built for hardy, but i made the source package on karmic. now i am getting this error: dh_clean: Sorry, but 6 is the highest compatibility level supported by this debhelper.. is there a way for me to make the necessary files compat level 6?
[11:58] <hyperair> iulian: lol then you'll be okay with me dropping almost all the changes you made? =p
[11:58] <persia> rdz: We've a new channel to answer questions like that: #ubuntu-packaging.  Come visit.
[11:58] <rdz> would it be sufficient to just change the content of debian/compat to 6?
[11:58] <rdz> persia, hi btw
[11:58] <rdz> persia, thanks. i will
[12:54] <DktrKranz> oh! multiprocessing strikes again!
[12:56] <AnAnt> Hello, could someone grant FFe to LP 530204 ? especially it also fixes LP 491784, I asked on #ubuntu-release, but no one replies there
[13:00] <persia> AnAnt: You want to subscribe the ubuntu-release team.  If you're in a huge hurry, you can ask on #ubuntu-release.  If anyone here is able to address your request, it is purely by coincidence.
[13:00] <AnAnt> ok
[13:00] <persia> And just because nobody gets back to you soon there doesn't make this a better place :)
[13:00] <persia> They bugs will be reviewed.  Someone will respond.  This may take a bit of time.
[13:00] <AnAnt> persia: I just found out that Steve Langasek subscribed ubuntu-release already 4 days ago
[13:00] <persia> Well then, it's under consideration :)
[13:00] <AnAnt> ok
[13:01] <AnAnt> sorry then
[13:01] <persia> No worries.  The procedures are complicated and changing.
[13:01] <AnAnt> yeah, the requestsync tool subscribed motu-release instead of ubuntu-release
[13:02] <AnAnt> seems that Steve realized that & fixed it
[13:02] <slytherin> AnAnt: It is quite possible that Steve did that because requestsync script subscribes motu-release by default in karmic (which is wrong as per updated policy).
[13:02] <AnAnt> yup
[13:02] <slytherin> geser: Any chance requestsync could be fixed in karmic?
[13:03] <DktrKranz> james_w: mind removing (again) python-multiprocessing from lucid (bug #418280) ? Thanks!
[13:03] <persia> slytherin: You could fix it too :)
[13:04] <slytherin> persia: I could upload it in karmic-proposed. But I usually avoid that when I am not a regular maintainer.
[13:04] <POX_> DktrKranz: seriously? LOL
[13:04] <persia> slytherin: we don't have maintainers in Ubuntu.  Just do it :)
[13:04] <persia> slytherin: If you're not sure, ask someone else to review your change before you upload.
[13:05] <DktrKranz> POX_: yeah, I asked for blacklist, so it wouldn't have reappeared, but I had no luck.
[13:05] <slytherin> persia: geser already fixed it in lucid so I thought he might be interested in doing SRU. :-)
[13:05] <AnAnt> slytherin: I see you're interested in gnusim8085 btw
[13:05] <slytherin> AnAnt: interested in what way?
[13:06] <AnAnt> slytherin: aren't you the one who've been making the last couple of packages for it in Debian ?
[13:06] <slytherin> AnAnt: yes I am. Considering that I am primary maintainer upstream it seemed more natural. :-)
[13:07] <slytherin> AnAnt: We (upstream) could use help in completing Arabic translation. :-D
[13:08] <AnAnt> oh, I never noticed that
[13:08] <AnAnt> that's nice
[13:09] <slytherin> AnAnt: It is pretty recent development. I am trying to get FFe for the latest release. Meanwhile you can check - https://translations.edge.launchpad.net/gnusim8085
[13:09] <AnAnt> slytherin: hmmm, I'm not into translation (especially that we study/work in the electronics field in English language), but, there is a guy doing arabic translation for gEDA
[13:11] <slytherin> AnAnt: Never mind. I thought you were working on translations.
[13:12] <AnAnt> Adnene knows arabic ?
[13:13] <AnAnt> hmm, never mind
[13:25] <iulian> hyperair: If that is the right thing to do, then yes, sure.
[13:31] <hyperair> iulian: i'm in favour of dropping most of the changes to reduce the debian-ubuntu delta, since i can't see why they were added, other than for maintenance purposes. stuff like the standards-version bump.
[13:31] <hyperair> i'd just like to reconfirm that this dropping these changes is correct before i go ahead and do it
[13:32] <mok0> hyperair: sounds sensible to me
[13:32] <hyperair> well then. i'll get to work =)
[13:32] <mok0> hyperair: requestsync?
[14:34] <micahg> YokoZar: did you ever file that bug for pidgin-mbpurple?
[14:44] <persia> If anyone is handy with pbuilder and has time to create a stanza to add to http://people.ubuntu.com/~persia/pull-soyuz-chroot whilst I'm idle, I'd appreciate the help.  Corrections would be nice too :)
[14:51] <cemc> anybody any comments on bug #534261 ?
[14:53] <Rhonda> cemc: That one is not yet packaged in Debian and the release date is pretty short of a notice. :/
[14:54] <cemc> Rhonda: too bad ;) does it need to be packaged in debian though?
[14:54] <Rhonda> cemc: I would try to get in contact with Christoph Haas, the DD who maintains the package in Debain, from what I remember he usually is pretty responsive.
[14:54] <Rhonda> So that no duplicate efforts happen in that respect.
[14:56] <cemc> got it
[14:56] <cemc> thx
[14:57] <Rhonda> cemc: I'm currently chatting with him. :)
[14:58] <cemc> sent a mail too
[15:01] <cemc> Rhonda: what's he saying? :)
[15:01] <cemc> how's the weather? :)
[15:07] <Rhonda> cemc: Christoph isn't on the team anymore he said. :P  But I got the jabberID of the other person and he promised to look into the update tonight.
[15:08] <Rhonda> european time, I guess
[15:09] <cemc> Rhonda: cool, thanks! can you ping me if (news()) ?
[15:11] <Rhonda> cemc: And I'm not too sure if your PPA version is proper, does this take into account any possible Debian update?
[15:11] <Rhonda> cemc: About news, PTS subscribe to source uploads, http://packages.qa.debian.org/pdns-recursor :)
[15:13] <cemc> Rhonda: thanks. about the ppa versioning, I'm not sure... those packages I really did for myself for testing mainly... is it incorrect?
[15:13] <Rhonda> I have no clue, I guess it would work properly though. :)
[15:16] <cemc> Rhonda: I think if debian will have 3.2-1 that should be > 3.2-0whatever, right?
[15:16] <Rhonda> Yes, that's my thoughts too. :)
[15:17] <Rhonda> cemc: I think some non-maintainer update to the new upstream version might though use 3.2-0.1
[15:18] <Rhonda> So I guess -0~whatever might be more suiting. I'm not sure if there are some suggestions hanging around on the wiki, though.
[15:25] <YokoZar> micahg: not just yet
[15:25] <micahg> YokoZar: there was a bug filed about the conflict
[15:26] <YokoZar> probably a result of my mailing list thread
[15:26] <micahg> no, an install bug
[15:26] <micahg> bug 530660
[15:26] <YokoZar> ahh, well there you are
[15:27] <micahg> YokoZar: do you want to take it and prepare teh debdiff?
[15:45] <duanedesign> reviewing some patches. looking for some help adding some man pages to a package
[15:47] <randomaction> duanedesign: what's the problem?
[15:48] <duanedesign> randomaction: do i just place them in a directory called for instance: debian/db4.2-doc.manpages
[15:49] <duanedesign> then make a patch?
[15:51] <randomaction> You can call dh_installman from debian/rules. It will install manpages listed in debian/PACKAGENAME.manpages, see "man dh_installman".
[15:51] <duanedesign> the pages were already written and attached to a bug report about the missing manpages.
[15:51] <duanedesign> randomaction: ahh. ok
[15:51] <duanedesign> randomaction: i messed around with dh_installman and wasnt getting it right :)
[15:52] <randomaction> *.manpages is a text file, not a directory
[16:07] <BlackZ> once finished to modify a debian package for ubuntu to add a dependence in debian/control file, what's the next step? and, can be that a good reason for an exceptionfreeze?
[17:13] <geser> BlackZ: does the new dependency enable a new feature?
[17:30] <imbrandon> morning all
[17:33] <geser> Hi imbrandon
[17:42] <imbrandon> not support chan, i know i know, but i got a quick question , ok i got a ubuntu 9.10 install ( headless server , only access via ssh ) that seems to be going to sleep or hybernate every half an hour or so, i thought i disabled all PM and even removed some of the packages, what log can i look in to track this down ?
[17:42] <imbrandon> the reason i know its asleep is i can go in the other room and pound on the keyboard and it "wakes"
[17:45] <hyperair> imbrandon: are you sure it's really asleep, not just the screen?
[17:46] <imbrandon> there is no screen, nfs mounts lock and ssh access is dropped
[17:46] <hyperair> hmm
[17:46] <hyperair> i se
[17:46] <imbrandon> so i assume is asleep or hybernated, but i have no monitor on it
[17:46] <hyperair> weird.
[17:46] <hyperair> ssh in, check dmesg?
[17:47] <imbrandon> yea lookin at dmsg now, and syslog, nothing looks crazy though
[17:47] <hyperair> does dmesg say anything about PM
[17:47] <imbrandon> nah, some rpc stuff and other misc stuff
[17:47] <hyperair> and do you have X/some DE running?
[17:48] <imbrandon> no
[17:48] <imbrandon> gnome is installed, but gdm is off on boot
[17:48] <hyperair> if dmesg doesn't say anything about PM, then it definitely isn't suspending/hibernating at work
[17:48] <imbrandon> this box has been running for years, just upgraded it to 9.10 though and thats when this stuff happened
[17:48] <hyperair> some hardware-level crappiness perhaps?
[17:48] <hyperair> heh weird
[17:48] <hyperair> lemme see your dmesg anyway?
[17:49] <imbrandon> kk, lemme pastebin it
[17:51] <hyperair> imbrandon: hurry up before i pass out. i'm dead tired and need sleep.
[17:51] <imbrandon> heh pastin now, its a 200 line paste
[17:52] <imbrandon> http://imbrandon.pastebin.com/xa9PeTJM
[17:52] <hyperair> you should go get pastebinit
[17:52] <hyperair> it's as simple as dmesg | pastebinit
[17:52] <imbrandon> yea i have it on my desktops, but i try to keep this box minimal
[17:52] <imbrandon> lol
[17:52] <hyperair> er
[17:52] <hyperair> that's a very short dmesg
[17:53] <hyperair> has this box gone through suspend already?
[17:53] <imbrandon> yea, look about the time it says "link down"
[17:53] <imbrandon> thats when it was off
[17:53] <hyperair> what do you mean when it was off?
[17:53] <imbrandon> unreachable
[17:54] <imbrandon> ssh nfs etc
[17:54] <imbrandon> pound keyboard and it "wakes"
[17:54] <hyperair> imbrandon: i want dmesg *after* it wakes up.
[17:55] <hyperair> and mind, i can't find anything about eth1 link down apart from when eth1 is first discovered
[17:55] <imbrandon> yes thats a dmesg from both before and after
[17:55] <hyperair> which is 20 seconds into the kernel starting.
[17:55] <imbrandon> its awake now at the end of that
[17:55] <hyperair> what before and after?!
[17:55] <hyperair> you didn't do any strange stitching right?
[17:55] <imbrandon> hyperair, exactly, it dosent show anything in dmsg, thus my confusion
[17:56] <hyperair> if it dioesn't show anything your hardware is weird and doing things it shouldn't be
[17:56] <hyperair> because the kernel isn't suspending
[17:56] <hyperair> go downgrade and see if it happens
[17:56] <imbrandon> k
[17:56] <hyperair> like stick a live medium in
[17:56] <hyperair> liveusb/livecd
[17:56] <hyperair> an older one
[17:57] <imbrandon> yea a liveusb wont sleep, did try that
[17:57] <hyperair> huh
[17:57] <hyperair> weird stuff, that is
[17:57] <hyperair> just to check, do you have a /var/log/pm-suspend.log?
[17:57] <imbrandon> definatly, in my 4 years of ubuntu never had this issue
[17:57] <imbrandon> lookin
[17:57] <imbrandon> nope
[17:58] <hyperair> see, linux isn't doing the suspend.
[17:58] <hyperair> what machine is this?
[17:58] <imbrandon> x86
[17:58] <imbrandon> 32bit
[17:58] <hyperair> did you tweak something in the bios? perhaps a hardware-level suspend-to-whatever that doesn't tell the kernel it's doing it
[17:58] <hyperair> i mean vendor/model
[17:59] <hyperair> not architecture.
[17:59] <imbrandon> ahh via c7
[17:59] <hyperair> via? meh notorious rand.
[17:59] <hyperair> brand
[17:59] <imbrandon> no bios pm
[17:59]  * hyperair shrugs
[18:00] <hyperair> go poke some people in #ubuntu-kernel
[18:00] <hyperair> maybe they'll know something
[18:00] <imbrandon> no worries, i'll dig a little more, thanks for tryin
[18:00] <hyperair> i honestly haven't seen a machine that can suspend-to-ram and come back without the kernel noticing.
[18:00] <hyperair> save for virtual machines
[18:00] <hyperair> those can do weird things.
[18:00] <imbrandon> yea its def strange, i'm wondering if the nic is just going to sleep and walkin on kbrd
[18:01] <imbrandon> but that would be strange too
[18:01] <hyperair> check the cpu fan
[18:01] <hyperair> hard disk
[18:01] <hyperair> umm
[18:01] <hyperair> leds?
[18:01] <imbrandon> what about leds ?
[18:01] <hyperair> don't they blink in some way when suspended?
[18:01] <imbrandon> and its fanless :)
[18:01] <hyperair> i know my desktop's power led blinked when suspended
[18:01] <hyperair> as does my notebook's
[18:02] <hyperair> bah. fanless.
[18:02] <imbrandon> ahh no power is solid the whole time
[18:02] <imbrandon> hrm
[18:02] <hyperair> i don't think it's actually going through any PM
[18:02] <hyperair> stick a monitor to it
[18:02] <hyperair> headless debugging is a pita.
[18:02] <imbrandon> heh easier said then done, sa i said its been runnin years, its in the attic ceiling
[18:02] <imbrandon> lol
[18:03]  * hyperair groans.
[18:03] <imbrandon> :)
[18:03] <hyperair> can't you bring it down?
[18:03] <hyperair> it shouldn't be that huge a box, right?
[18:03] <imbrandon> yea i think that will be a weekend task
[18:03] <imbrandon> no very small
[18:03] <hyperair> yeah, see
[18:03] <imbrandon> like 10cm by 14cm
[18:03] <hyperair> just bring it down, stick it to a monitor
[18:03] <hyperair> i figured as much, when you said via c7 and fanless
[18:03] <imbrandon> but its very tucked away
[18:04] <hyperair> ouch
[18:04] <imbrandon> btw even fanless it runs like at 20c 99% of the time
[18:05] <imbrandon> love it so far, till now
[18:05] <imbrandon> lol
[18:05] <hyperair> imbrandon: a simple test: run a bash loop in a screen session calling date at 1-second intervals. if there is a lapse where it has "suspended" then you know it has really suspended.
[18:05] <imbrandon> hahahahahah yea did that
[18:05] <imbrandon> #!/bin/bash
[18:05] <imbrandon> for (( c=1; c<=1000000; c++ ))
[18:05] <imbrandon> do
[18:05] <imbrandon>         echo "Garbage Busy Work $c times..."
[18:05] <imbrandon>         sleep 1
[18:05] <imbrandon> done
[18:05] <hyperair> while date; do sleep 1; done
[18:05] <imbrandon> LOL
[18:05] <hyperair> heh
[18:05] <hyperair> well that works too =\
[18:05] <imbrandon> yea thought of that one
[18:06] <hyperair> imo mine's simpler
[18:06] <hyperair> and you get to see the actual lapse in seconds
[18:06] <imbrandon> its runs and counts, then "stops" about 1800 untill i pound the kbrd
[18:06] <imbrandon> then it resumes
[18:06] <imbrandon> like it never stoped
[18:06] <hyperair> use mine instead.
[18:06] <hyperair> check if there is a lapse.
[18:06] <hyperair> if there is a lapse of time, your timestamps will have a gap of more than one second
[18:07] <imbrandon> k
[18:13] <ScottL_> can someone make sure I'm not doing anything brain dead for packaging a Plymouth theme (I've done some packaging before)?
[18:13] <imbrandon> hyperair, hah i found the issue, not to fix the problem
[18:13] <hyperair> ?
[18:13] <imbrandon> seems the nic goes to sleep ( realtek ) with the new drivers
[18:14] <hyperair> lol
[18:14] <imbrandon> s/not/now
[18:14] <hyperair> imbrandon: well, check if someone has bisected your issue. otherwise try compiling kernels and bisecting it =p
[18:15] <imbrandon> yup
[19:08] <fagan> directhex: you around?
[19:09] <fagan> Are you going to make an application indicator for banshee?
[19:10]  * fagan doesnt mind making a plugin for it
[19:11] <jcastro> fagan: qense has one and has submitted it upstream
[19:12] <fagan> jcastro: nice I was wondering because its not in banshee for lucid
[19:12] <siretart> any kubuntu user around? in what package is the gtk style for qt application?
[19:12] <jcastro> yeah it's releasing this week sometime
[19:12]  * fagan loves low hanging fruit
[19:12] <jcastro> https://bugs.edge.launchpad.net/ubuntu/+source/banshee/+bug/518171
[19:12] <jcastro> if you want to test it and +1 it that would help
[19:12] <fagan> jcastro: any more that need porting
[19:13]  * fagan has some free time for some dev
[19:13] <jcastro> lots in universe I am sure
[19:13] <jcastro> fagan: Deluge would be nice!
[19:14] <fagan> Deluge sure ill go have a look and report back :)
[19:15] <fagan> Oh and do I remove the current notification area stuff when I port it?
[19:15] <fagan> Or just comment it out
[19:16]  * fagan just realises he could do that in a plugin anyway dumb question
[19:25] <jcastro> fagan: check the docks, it has a fallback mechanism for when indiscator session isn't running
[19:25] <jcastro> er, /docs/, not where boats live
[19:25] <fagan> Ah ok
[19:26] <jcastro> fagan: and remember it doesn't count until it's submitted upstream!
[19:26] <fagan> jcastro: could you help with that pretty please :)
[19:26] <fagan> Ill have a patch tomorrow
[19:27] <jcastro> fagan: https://bugzilla.gnome.org/show_bug.cgi?id=607800
[19:27] <jcastro> easy example. :D
[19:28] <fagan> Oh so I should just go to their bug tracker and say here, makes sense
[19:28]  * fagan doesnt push much bugs to projects that he doesnt know
[19:28] <fagan> Patches not bugs
[19:30] <fagan> crap the deluge guys dont allow the public to submit bugs it seems
[19:31] <fagan> Ill just ask on their list
[19:36] <jcastro> fagan: make sure you link to the page on the wiki
[19:36] <jcastro> it has all the info they'll need
[19:36] <fagan> Yep will do
[19:42] <jcastro> persia: they made it! (mongodb)
[20:17] <lfaraone> if a new upstream version is only a bugfix release, do we still need a FFE?
[20:20] <sebner> lfaraone:Nope
[20:47] <directhex> what dictates the ordering with which cdbs does its "debian/rules binary" stuff?
[20:48] <james_w> directhex: the phase of the moon?
[20:48] <directhex> james_w, sigh, yeah, that's my best lead so far :(
[20:49] <james_w> directhex: but it's make that will decide that
[20:50] <james_w> so, it will take in to account any dependencies between binary/* rules and things that they refer to
[20:50] <james_w> and then parallelise things as well as it can within those constraints
[20:50] <james_w> and then serialise the rest
[20:51] <james_w> and I'm not sure if there are any rules to the serialisation
[20:51] <directhex> nice theory
[20:51] <directhex> binary-install/libubuntuone1.0-cil:: binary-install/libubuntuone-1.0-1
[20:51] <directhex> why does the -cil package get done before the lib?
[20:53] <james_w> directhex: the binary part, or the binary-install part?
[20:53] <james_w> so
[20:53] <james_w> it may be that it is doing all the arch-dep stuff, then coming back for arch-indep?
[20:55] <directhex> james_w, i'd be happy if it was that way round
[20:55] <directhex> james_w, dh_clideps MUST be called after "dh_install -plibubuntuone-1.0-1". because cdbs calls dh_install individually for every binary, rather than just once.
[20:56] <soren> directhex: It'd be easier to help with a bit more context. Do you have the whole thing in bzr somewhere, for instance?
[20:56] <directhex> soren, i'll push what i have so far
[20:57] <soren> directhex: Cool.
[20:59] <directhex> lp:~directhex/libubuntuone/mono_packaging
[21:00] <directhex> your challenge, should you choose to accept it, is to make dh_clideps happen after debian/libubuntuone-1.0-1 has been filled with stuff, which is needed for libubuntuone1.0-cil_blah.deb to correctly have a dependency on libubuntuone-1.0-1_blah.deb
[21:02] <soren> directhex: You realise it doesn't say "binary-install/libubuntuone1.0-cil:: binary-install/libubuntuone-1.0-1" in there anywhere?
[21:02] <soren> I'm just saying..
[21:02] <directhex> soren, yeah, i removed it since it didn't affect it
[21:03] <directhex> was leaving it unmolested rather than leaving non-functional attempts in place
[21:04]  * soren installs a million build-deps
[21:04] <soren> give or take
[21:06] <soren> directhex: How can I tell that it failed?
[21:06] <directhex> soren, check the deps on the libubuntuone1.0-cil_blah.deb package, it should have libubuntuone-1.0-1 in there
[21:07] <soren> directhex: Ok.
[21:07] <directhex> soren, or check the build output for "dh_clideps: Warning: Missing shlibs entry: libubuntuone-1.0.so.1 or ubuntuone-sharp.dll for: ubuntuone-sharp.dll!"
[21:08] <soren> directhex: Alrighty.
[21:13] <c_korn> hello. can someone please check if this sync request is correct ? https://bugs.launchpad.net/ubuntu/+source/scilab/+bug/533746 requestsync crashed but it created the bug report.
[21:24] <soren> directhex: I'm curious why you put dh_clideps in binary-install, though.
[21:25] <soren> directhex: It's very much like dh_shlibdeps, is it not? Just for mono?
[21:25] <directhex> soren, where should it go? i don't really understand what cdbs does when and why
[21:25] <soren> directhex: Is it equivalent to dh_shlibdeps?
[21:25] <directhex> yes
[21:25] <soren> directhex: dh_shlibdeps is in binary-predep/blah.
[21:26] <soren> bah
[21:26] <soren> binary-predeb, I mean.
[21:27]  * soren <3 cdbs
[21:28] <directhex> soren, does that fix it?
[21:28] <soren> Haven't tried.
[21:28]  * mok0_ <3 cdbs too
[21:29] <directhex> weirdos ¬_¬
[21:29] <soren> directhex: A good trick if you're doing something like this is to look in the existing cdbs rules files for stuff that's similar to what you're doing.
[21:30] <soren> directhex: ...and put your stuff in a the same target.
[21:30] <directhex> soren, there's a lack of existing examples of cdbs-based mono bindings. a small number of libs, but not bindings
[21:30] <directhex> certainly not built at the same time as the dependent lib
[21:31] <soren> Well, in this case, the trick was to realise that dh_clideps does the same as dh_shlibdeps, and just mimic the behaviour around that.
[21:32] <directhex> soren, does that fix it?
[21:33] <soren> 22:28:41 < soren> Haven't tried.
[21:33] <soren> :)
[21:33] <soren> directhex: What does dh_cligacpolicy do?
[21:34] <soren> I doubt moving all of your existing binary-install/libubuntuone1.0-cil stuff to binary-predeb is going to be a good idea.
[21:34] <soren> the clistrip thing sounds like something you'd stick in binary-strip/blah
[21:34] <directhex> soren, nothing in this case, it's a noop unless there's a .cligacpolicy file
[21:38] <jdong> cd Documents
[21:39] <jdong> *grumble grumble* new theme active vs passive window contrast
[21:45] <soren> directhex: I've got other stuff to do. I hope I've helped you a bit.
[21:46] <directhex> i hope so too ;(
[21:46] <directhex> ta
[21:49] <directhex> doesn't help, as expected
[21:49] <soren> What did you change?
[21:50] <directhex> binary-predeb/libubuntuone1.0-cil::
[21:50] <directhex> 	dh_clideps
[21:51] <RAOF> directhex: I recently touched launchpad-integration; that does libs+bindings together.  Have you looked at it?
[21:51] <directhex> RAOF, no. that one had bad cli bindings too iirc?
[21:52] <RAOF> Yeah.  I fixinated them, though.
[21:52] <directhex> ooh!
[21:52] <directhex> src package name?
[21:53] <RAOF> launchpad-integration, IIRC.
[21:54] <directhex> argh, wasn't finding it as i was on p.d.o :)
[21:54] <soren> directhex: um...
[21:54] <soren> $ grep -E 'dh_(install -plibubuntuone-1.0-1|clidep)' build.log
[21:54] <soren> dh_install -plibubuntuone-1.0-1
[21:54] <soren> dh_clideps
[21:54] <soren> dh_clideps: Warning: Missing shlibs entry: libubuntuone-1.0.so.1 or ubuntuone-sharp.dll for: ubuntuone-sharp.dll!
[21:54] <soren> That's the order you wanted, right?
[21:55] <soren> dh_install takes care to move stuff from debian/tmp to debian/libubuntuone-1.0-1.
[21:55] <directhex> looks like it was dh_makeshlibs that i wanted first
[21:58] <directhex> RAOF, i notice you're using arch:any not arch:all
[21:59] <RAOF> directhex: That's an oversight on my part
[22:02] <directhex> RAOF, no joy :(
[22:02] <directhex> RAOF, can you take a look?
[22:07] <RoAkSoAx> when requesting a FFe sync request from debian, do I need to follow this exactly? https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze for new upstream versions or that's only when the package its been updated in Ubuntu (not syncing/merging)
[22:20] <lifeless> RoAkSoAx: new up stream is new upstream
[22:22] <RoAkSoAx> lifeless, so that means its only for packages that are new upstream versions that someone packages and does not sync from debian
[22:22] <lifeless> no, it means that it includes a sync of a new upstream from debian
[22:22] <lifeless> its a new upstream either way
[22:23] <RoAkSoAx> oh ok :)
[22:36] <directhex> argh
[22:47] <RAOF> directhex: I'll add that to my todo.
[22:49] <directhex> RAOF, if you're not immediately available, i'll keep hacking at it. it's holding up an upstream upload
[22:50] <RAOF> I'm going back to hacking f-spot.  If you get frustrated further I'll give it a look.
[22:52] <directhex> i'm reading cdbs source
[22:52] <RAOF> Uuurgh.
[22:58] <directhex> i got it ._.
[22:59] <directhex> by jove, he's got it!
[22:59] <directhex> jono, break out the champagne!
[23:01] <jono> directhex, eh?
[23:02] <Beaver> www.search2.net (new search engine)
[23:02] <directhex> jono, i've been fighting with cdbs for days to make the mono u1ms bindings package work
[23:03] <jono> ahhh right
[23:03] <jono> :)
[23:03] <directhex> i can get a working banshee u1ms into testers' hands within 24 hours of this hitting the archive
[23:13] <RAOF> directhex: Thank you for being awesome!
[23:13] <directhex> i need a nap
[23:13] <directhex> and/or more rum
[23:57] <RAOF> directhex: You're not going to be at UDS, are you?  Otherwise, I could buy you a beer :)
[23:58] <directhex> RAOF, can't. scheduling conflict


 @mitya57 Can I please get a second opinion on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3291/+build/15053268 ?
 @tsimonq2, Yes, you need to restore the delta.
[15:11] <lisandro> tsimonq2: are you using EGL on arm64?
[16:53] <mitya57> lisandro: yes
[16:54] <lisandro> I see
[16:55] <mitya57> lisandro: I would really like to make Debian and Ubuntu use the same variant of OpenGL on arm64, but you point out that there are arm64 devices with desktop OpenGL appearing, while in Ubuntu there are people using GL ES boards (like Raspberry Pi 3) and we don’t want to break them.
[16:56] <lisandro> yes, it's complicated
[16:56] <lisandro> and you can't build both variants I'm afraid
[16:57] <lisandro> *but* for most of the EGL cards I have seen out there you also need proprietary binary blobs while building Qt
[16:57] <lisandro> I don't know if the RPI3 falls into this category
[16:57] <lisandro> and you need them at *build* time :-(
[16:58] <lisandro> had I known that at the very beggining I think I would have kept Desktop OpenGL on all archs :-/
[16:59] <mitya57> In Ubuntu we are definitely building Qt without any proprietary blobs.
[16:59] <lisandro> so the question is: do you really benefit your users?
[16:59] <lisandro> the answer might be yes for some of them, of course
[17:00] <mitya57> Yes, that’s the answer :)
[17:00] <mitya57> Who doesn’t like that can use pure Debian :)
[17:00] <lisandro> in a sense it might be a benefit to have a delta, mind you
[17:01] <lisandro> it's a tricky position to be in
[17:01] <lisandro> I don't know what raspbian is doing currently
[17:01] <mitya57> This part of delta is quite small, so there is no problem having it


[06:10] <didrocks> good morning
[06:10] <jibel> Hi everyone
[06:12] <didrocks> salut jibel
[06:22] <jibel> Bonjour didrocks
[06:23] <oSoMoN> good morning desktoppers
[06:23] <pieq> Salut tout le monde !
[06:24] <pieq> jibel, is 19.10 beta out yet? Is it the same image as in http://iso.qa.ubuntu.com/qatracker/milestones/406/builds ?
[06:24] <didrocks> hey oSoMoN, salut pieq
[06:42] <jibel> pieq, yeah but it's broken, we need a new gnome-shell
[06:42] <jibel> pieq, bonjour :)
[06:43] <pieq> jibel, so should we wait to start testing?
[06:47] <jibel> pieq, actually latest image with the fix of ubiquity seems to be working so you can start testing.
[06:47] <jibel> pieq, it's build 20190926 on the tracker
[06:47] <jibel> (id 406)
[06:50] <oSoMoN> salut pieq, didrocks, jibel
[06:51] <pieq> jibel, merci ! downloading now
[06:56] <dupondje> Any idea's why a Qt software (keepassxc) resolution is broken on a HiDPi screen since 2-3 days (not many updates last days)
[06:56] <pieq> dupondje, on what version of Ubuntu?
[06:56] <pieq> and what version of keepassxc?
[06:57] <dupondje> Eoan
[06:57] <dupondje> 2.4.3+dfsg.1-1
[06:57] <dupondje> On Wayland btw, if that matters
[06:58] <pieq> dupondje, that's a lot of new software there :)
[06:58] <pieq> and Eoan is not even released yet, so it's moving a lot I assume
[06:59] <dupondje> its not moving that much anymore :)
[07:01] <dupondje> QT_AUTO_SCREEN_SCALE_FACTOR=0 keepassxc
[07:01] <dupondje> fixes it btw. weird
[07:04] <dupondje> aha found the cause :) nvm
[07:09] <pieq> dupondje, what was it?
[07:12] <dupondje> pieq: I had export QT_AUTO_SCREEN_SCALE_FACTOR=0 in my .profile, but some script created .bash_profile 2 days ago... which causes .profile not to be rread
[07:12] <dupondje> ah well :)
[07:15] <pieq> whoo, kernel panic on latest Eoan image
[07:26] <marcustomlinson> morning desktoppers
[07:27] <oSoMoN> morning marcustomlinson
[07:29] <didrocks> hey marcustomlinson
[07:31] <seb128> gooood morning desktopers
[07:31] <didrocks> salut seb128
[07:31] <marcustomlinson> hey seb128
[07:32] <seb128> lut didrocks, hey marcustomlinson, how are you today?
[07:32] <marcustomlinson> good thanks, it's friday :)
[07:33] <oSoMoN> salut seb128
[07:33] <didrocks> seb128: I'm fine, yourself?
[07:34] <seb128> lut oSoMoN, en forme ?
[07:34] <seb128> didrocks, I'm good, as marcustomlinson said it's sort of friday for me too :)
[07:35] <oSoMoN> la nuit fut courte, mais ça va plutôt bien
[07:35] <seb128> :-/
[07:35] <seb128> short night, long day, right? good luck!
[07:36] <oSoMoN> nah, days are always too short
[07:37] <seb128> they can also feel long when you lack sleep, but yeah
[07:38] <oSoMoN> I'm not feeling so badly sleep-deprived, fortunately
[07:52] <willcooke> moin
[07:53] <seb128> hey willcooke, how are you?
[07:53] <willcooke> hey seb128, feeling good that Trevinho found that lock up bug :)
[07:53] <willcooke> good work!
[07:53] <seb128> he's the man!
[07:53] <seb128> he and Laney rocked the fixes this week
[07:54] <willcooke> \m/  what a team
[07:54] <didrocks> hey willcooke
[07:54] <oSoMoN> good morning willcooke
[07:55] <willcooke> hihi
[07:55] <oSoMoN> I second this, great work by Trevinho and Laney
[08:00] <oSoMoN> chrisccoulson, thanks for publishing the firefox update!
[08:00] <Laney> morning
[08:00] <oSoMoN> and a reminder that the chromium-browser update for xenial and bionic is ready for publication
[08:01] <oSoMoN> hi Laney
[08:09] <Laney> hey oSoMoN
[08:09] <Laney> you well?
[08:09] <oSoMoN> yeah, all good on this side of the Pyrenees
[08:09] <oSoMoN> you?
[08:09] <seb128> hey Laney, how is it going?
[08:10] <Laney> hey seb128, you good too?
[08:10] <Laney> nice here, it is kind of sunny today for a change :>
[08:10] <seb128> Laney, I'm good :-)
[08:11] <seb128> still raining here, going to be that way for a while apparently...
[08:11] <Laney> :(
[08:12] <seb128> Laney, thx for ubiquity & gdm fixes you worked on this week, with the Trevinho fixes it feels like you are on top of the issues mostly atm :)
[08:14] <Laney> thanks
[08:14] <Laney> it's been a good one for fixing bugs that we introduced ;-)
[08:14] <Laney> I asked for ftp access to the gnome server, going to have to make upstream releases for gdm and stuff
[08:15] <seb128> ah, nice
[08:15] <seb128> halfline is on paternity leave I think (if I remember correctly what I read on IRC some days ago)
[08:15] <Laney> yes
[08:16] <Laney> so we sort of take over his stuff
[08:16] <Laney> 😈
[08:16] <seb128> b:)
[08:19] <seb128> (changing location, brb)
[08:53] <seb128> oSoMoN, what's the issue with the jsunit tests? it's not listed red on anything on update_excuses
[08:54] <seb128> why do we need to retry them?
[08:56] <oSoMoN> seb128, only the enigmail tests, not the jsunit ones
[08:56] <oSoMoN> but the trigger for the retry needs to be jsunit
[08:57] <seb128> oh, right, I read that the wrong way for some reason, sorry
[08:58] <oSoMoN> nw
[08:58] <seb128> oSoMoN, should that automatically happen as a reaction of the new version upload though?
[08:59] <seb128> ah, but the new jsunit is only in proposed
[08:59] <seb128> ignore that, doing the trigger :p
[08:59] <oSoMoN> thanks
[08:59] <seb128> done now
[09:36] <Trevinho> morning!
[09:36]  * Laney nods Trevinho
[09:38] <Trevinho> Laney: hhhhheeeeyy
[09:39] <Laney> what is up
[09:42] <Trevinho> Laney: good, happy to be able to find the cause for the lockup... thanks to your broken setup :-).
[09:42] <Trevinho> on that, do we have time to prepare salsa + ubuntu?
[09:42] <Trevinho> I quickly did a ppa but I can shape if we want in now
[09:43] <Laney> not for the beta I don't think
[09:43] <Laney> the iso works anyway, can wait for first reviews
[09:43] <Laney> imho
[09:44] <Laney> good work on that
[09:44] <Laney> 🤘
[09:45] <Trevinho> yeah ir does not reliably but should mostly do. up to you guys
[09:45] <Laney> go ping Carlos or someone ;-)
[09:46] <oSoMoN> Trevinho, I confirmed that packages in the silo fix the grab for me
[09:46] <oSoMoN> (and good morning, too!)
[09:47] <Trevinho> oSoMoN: buen día!
[09:47] <Trevinho> and good to hear
[10:01] <Laney> laney@nightingale> ssh<EMAIL_ADDRESS>[10:01] <Laney> Creating home directory for iainl.
[10:01] <Laney> got the elite access now
[10:17] <seb128> hey Trevinho, how are you? well done on figuring out the issue!
[10:17] <seb128> Trevinho, did you check if it also fix the 'dialog not responding' case from L_aney?
[10:19] <Trevinho> Laney: yeah it's nice... sometimes I would like to use it for doing releases that are waiting maintainers for ages, but I never risked 😅
[10:20] <seb128> Laney, welcome in the club :-)
[10:20] <Trevinho> seb128: nope, but hardly can be the same.
[10:20] <seb128> Trevinho, right...
[10:27] <Laney> unfortunate!
[10:27] <Laney> and it means I'm 10€ down ;-)
[10:53] <jibel> in 19.10 we removed the snap of gnome-system-monitor but in previous release the upgrader was installing the snap and removing the deb. What do we do now?
[10:55] <jibel> remove it from the list of snaps to transition and reinstall the deb is the snap is installed?
[10:55] <jibel> if*
[10:55] <Laney> does the normal release upgrade install the .deb?
[10:55] <jibel> no
[10:55] <Laney> because.......
[10:56] <Laney> it has a static list?
[10:56] <jibel> yes, and we have no way to know if the snap have been installed during an upgrade or manually and intentionally
[10:57] <seb128> if the deb and the snap are installed the deb is first in the path right?
[10:58] <jibel> let me check on a default installation
[10:59] <Laney> the code in ubuntu-release-upgrader checks if it is tracking the stable/ubuntu-XX.YY channel
[10:59] <Laney> which is good enough for 'was installed automatically'
[11:00] <Laney> (at least from a quick reading of it)
[11:00] <jibel> seb128, /snap/bin is last in $PATH; so the deb should be launched first
[11:02] <seb128> ignore me, Laney's reply is more useful :)
[11:02] <Laney> well it doesn't have support for removing snaps
[11:03] <Laney> but I think it could do that if it was decided that is work worth doing
[11:03] <jibel> or we keep the snap, just remove the package from the list.
[11:03] <Laney> yes of course
[11:03] <jibel> much simpler
[11:04] <jibel> and safe
[11:04] <Laney> half arsed
[11:04] <Laney> but sure
[11:04] <jibel> seb128, willcooke ^ WDYT ?
[11:05] <jibel> I'll file a bug anyway
[11:07] <seb128> kenvandine, ^ since you are the one who triggered the change :p
[11:07] <seb128> as long as we install the deb the users at least get the right experience
[11:08] <willcooke> hmm
[11:08] <seb128> I don't have a strong opinion on snap clean, if we can do it without too much work that would be nice, it's probably not important enough to make it a priority though
[11:08] <willcooke> I think making the upgrader remove the snap is better, but feels too late to make that work reliably?
[11:09] <Laney> because?
[11:10] <willcooke> just seems like a big change at this point
[11:10] <willcooke> but if you think its doable...
[11:10] <Laney> for snap in remove list: if snap installed, if snap tracking ubuntu/..., remove snap
[11:10] <Laney> dunno, might turn out to eb harder, but it doesn't *feel* like it would be to me
[11:10] <willcooke> oh
[11:10] <willcooke> well
[11:10] <willcooke> I thought it would be harder than that :)
[11:11] <Laney> that's basically what it is for upgrades
[11:11] <Laney> one second
[11:11] <Laney> https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeQuirks.py#L815
[11:12] <seb128> jibel, do you feel like having a go at doing the change to remove it?
[11:14] <jibel> please add your conclusion to bug 1845485
[11:14] <jibel> seb128, yeah after beta
[11:14] <Laney> do we have a comment in the seeds to sync that list in there btw?
[11:14] <Laney> not sure I knew about it before now
[11:14] <seb128> jibel, thx
[11:14] <Laney> yes
[11:14] <Laney> good!
[11:15] <jibel> in the seed it's just snap:<package>
[11:15] <seb128> jibel, thx for fixing the emoji font in minimal btw, I think it makes sense to have those even in 'corporate' installs nowadays
[11:16] <Laney> yeh, I was just wondering if the seed told you to update the upgrader as well
[11:16] <Laney> and it does :>
[11:17] <seb128> keeeeennnnn
[11:17] <Laney> maybe every snap line should have a comment on it :p
[11:18] <jibel> and a git hook to send you a reminder when one changed a line with snap:
[11:19] <Laney> yes, now we're thinking smart
[11:19] <jibel> well, in a few month AI will fix it for us
[11:20] <Laney> git hook to trigger a sentient robot to copy the text over
[11:22] <seb128> Laney, do you mind if I re-purpose your pango ffe bug as a version-blocker-ff one? (and if it's fine can you just unsubscribe release team so they don't get spammed)
[11:22] <seb128> I can open a new one if you prefer
[11:23] <Laney> yes sure, can you give me the number so I can unsubscribe the team?
[11:23] <seb128> Laney, https://bugs.launchpad.net/ubuntu/+source/pango1.0/+bug/1842643
[11:23] <seb128> thx
[11:23] <Laney> GONE
[11:23] <seb128> excellent! :)
[12:25] <Wimpress> didrocks jibel Is ZFS support going to feature in the beta?
[12:28] <jibel> Wimpress, no, not in the beta
[12:28] <jibel> Laney, did you have time to start reviewing the MP for zfs in ubiqutiy?
[12:33] <Wimpress> jibel: Thanks. Will it make final?
[12:47] <jibel> I hope so
[13:00] <GunnarHj> Hello seb128, Great that ubiquity is in shape again. :)
[13:00] <GunnarHj> But I'm still bothered by this attempt to add a language:
[13:00] <GunnarHj> https://launchpad.net/ubuntu/+source/localechooser/2.71ubuntu4
[13:00] <GunnarHj> It doesn't show up. Probably there is more into it. Do you possibly know what that would be?
[13:02] <seb128> GunnarHj, sorry but I don't, maybe check with #ubuntu-installer, or look to the /var/log/install/dm log? (there are some wsarnings there about languages iirc)
[13:03] <GunnarHj> seb128: Ok, I'll try those ways. Thanks.
[13:07] <seb128> np
[13:24] <Laney> jibel: not yet, been fixing other things, likely to be tomorrow
[13:32] <kenvandine> sigh...
[13:32] <willcooke> hi kenvandine!
[13:32] <kenvandine> hey willcooke
[13:33] <marcustomlinson> hey kenvandine, why the sigh?
[13:33] <kenvandine> the deb to snap to deb transition issue
[13:36] <marcustomlinson> ah right
[13:39] <GunnarHj> seb128: I was wrong: "Ślůnski" does show up in Ubiquity, and I could "Try Ubuntu" with it. :)
[13:39] <GunnarHj> As you said there are indeed a couple of complaints in /var/log/installer/debug, and AFAICT that's the usual Python complaints about certain locales. In this case it complains about bn_BD and szl_PL, and it's bug #1646260.
[13:39] <seb128> k
[13:42] <seb128> on that note I drop offline for some hours for travelling, see you later
[14:32] <hellsworth> good morning btw
[14:33] <didrocks> hey hellsworth
[14:35] <hellsworth> how are things didrocks?
[14:45] <didrocks> hellsworth: things are going well, yourself? :)
[14:46] <hellsworth> quite good. enjoying my mornnig coffee :)
[14:50] <didrocks> heh
[15:26] <hellsworth> my laptop is on 19.10. It's plugged into the power and I can tell that at least physically the power is recognized since the led next to the power port on the laptop is lit up. However, the battery icon in the top bar doesn't indicate that it's charging at all. Shouldn't there be some indication?
[15:26] <Laney> yes
[15:27] <Laney> does upower know it is (upower -d)?
[15:27] <hellsworth> nope. it says state: discharging
[15:28] <hellsworth> i have a meeting in 3 min and i think the battery will be fine either way for the 45 min duration
[15:29] <Laney> /sys/class/power_supply/BAT0/status ?
[15:29] <mgedmin> hellsworth: what does upower -d say about when the status was last updated?
[15:30] <mgedmin> I once had a scare when upower showed me low battery for about 60 seconds right after resuming my laptop from suspend (it was plugged in while suspended and was actually charged to 100%)
[15:47] <oSoMoN> I'm calling it a day, back for more tomorrow, those of you who are out tomorrow have a great week-end!
[16:07] <hellsworth> Laney, mgedmin here's the output of upower -d
[16:07] <hellsworth> https://pastebin.com/AuhkFFSV
[16:08] <hellsworth> so during my hangouts meeting, the battery icon didn't change and still says 97%. so i know that it IS charging.
[16:08] <hellsworth> otherwise the percentage would have dropped
[16:10] <hellsworth> Laney, $ cat /sys/class/power_supply/BAT0/status
[16:10] <hellsworth> Unknown
[16:10] <Laney> suspicious!
[16:10] <hellsworth> indeed
[16:21] <ogra> encrypted battery !
[16:22] <hellsworth> a reboot with power plugged in, shows that the battery is at 100% and charging. if I unplug the power, the charging icon goes away and it says the battery is at 97%
[16:22] <hellsworth> plugging the power back in, shows the battery is at 100% and charging again.
[16:23] <hellsworth> rebooting without the power plugged in reproduces the situation where there is no change if you plug in the power
[16:23] <hellsworth> i'm going to file a bug
[16:32] <hellsworth> https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1845532
[16:35] <Laney> I'd say to start with the kernel if the kernel's state is not right
[17:16] <hellsworth> Laney, I found lots of logs in journalctl that look like they could point to the root cause and attached them to the bug. Indeed many of them are kernel logs.
[17:37] <hellsworth> can i not edit my comments in launchpad?
[17:46] <sarnold> hellsworth: I don't think so, just the description and title. there's a 'hide' button but I've heard that it might only hide your posts from you. I've not been brave enough to click it on a 'real bug' to find out what happpens..
[18:20]  * kenvandine just filled a warranty claim on the SSD.  So annoying
[19:12] <hellsworth> sarnold, it looks like if i hide one of my comments, then that comment alone is just not displayed to others. i still see my hidden comment but it's grey'd out
[19:17] <sarnold> hellsworth: aha! thanks for testing :D
[19:25] <hellsworth> my pleasure! if i can't edit my comments, I want to at least be able to hide the ones that turn out to not be as helpful as I once thought it was :)
[21:32] <hellsworth> kenvandine, https://gitlab.gnome.org/GNOME/quadrapassel/merge_requests/15
[21:32] <gitbot> GNOME issue (Merge request) 15 in quadrapassel "snap: Update yaml to use GNOME extension" [Opened]
[21:38] <kenvandine> hellsworth: needs rebasing
[21:48] <hellsworth> done
[21:51] <willcooke> The new desktop beta iso is ready for testing if anyone has a mo
[21:51] <kenvandine> Thanks
[21:52] <hellsworth> ooh i'd like to give it a whirl
[21:52] <willcooke> ace, thanks hellsworth
[21:52] <willcooke> go here:  http://iso.qa.ubuntu.com/qatracker/milestones/406/builds/200088/testcases
[21:53] <willcooke> download the ISo from the link on that page to make sure you get the right one
[21:53] <willcooke> then pick a test from the list
[21:53] <willcooke> you can click on the test for instructions, and to see if anyone else is already doing it
[21:53] <willcooke> if you pick one, mark it as in progress, so we dont dupe too much
[21:54] <hellsworth> sounds good!
[21:56] <hellsworth> testing in qemu is ok?
[21:56] <hellsworth> or do all of these need to be on baremetal?
[21:57] <willcooke> vm is fine
[21:57] <willcooke> its good to get a mi
[21:57] <willcooke> mix
[21:57] <willcooke> I'd doing it on metal though
[21:58] <willcooke> ((I'm
[21:58] <willcooke> gah
[21:58] <willcooke> **I'm
[22:00] <hellsworth> how do you mark a line item as being in progress?
[22:02] <willcooke> click on the test and then at the bottom should be a form to fill in
[22:02] <willcooke> its possible that we need to add you to some more groups before that will work
[22:02] <willcooke> e.g. http://iso.qa.ubuntu.com/qatracker/milestones/406/builds/200088/testcases/1305/results
[22:02] <willcooke> scroll to the bottom, what do you see
[22:02] <hellsworth> oh i see. i was able to mark one as in progress
[22:04] <willcooke> oops, alt f4 the wrong keyboard :)
[22:15] <willcooke> hmmmm, either my USB stick is hosed, or something is very wrong
[22:15] <hellsworth> yeah i got a failed to boot from device
[22:15] <willcooke> hmm
[22:15] <hellsworth> but this is in virt-manager
[22:16] <hellsworth> i *just* setup qemu and virt-manager so i'm downloading 19.04 iso now to make sure that the vm setup is good, to be sure
[22:19] <hellsworth> no i had made a silly mistake pointing to the wrong iso. the build 200088 you pointed me to seems to boot
[22:21] <willcooke> hmm, well that wasnt good either.  My session crashed
[22:21] <sarnold> willcooke: you missed this while you were crashing < hellsworth> no i had made a silly mistake pointing to the wrong iso. the build 200088 you pointed me to seems to boot
[22:21] <willcooke> sarnold, ah!  nice one, thanks
[22:31] <hellsworth> willcooke, i'm trying http://iso.qa.ubuntu.com/qatracker/milestones/406/builds/200088/testcases/1307/results but when i boot the image i am booted to the "try ubuntu" or "install ubuntu" screen. F6 does nothing if i go down either path so i feel like i'm missing something here..
[22:32] <willcooke> hellsworth, ah, that's probably because you have or don't have secure boot enabled
[22:32] <hellsworth> do i need secure boot?
[22:32] <willcooke> I think that menu will only show up in non secure boot mode
[22:33] <willcooke> s'fine, let me test it on read hardware, it's probably easier
[22:33] <hellsworth> hmm ok i'll go look for another test case then
[22:34] <hellsworth> actually, i didn't realize the time. i need to go pick up my daughter from daycare. but i'll gladly pick up a test case tomorrow
[22:34] <willcooke> np, cheers hellsworth
[22:35] <hellsworth> "Install (manual partitioning re-using home partition) in Ubuntu Desktop amd64 in Eoan Daily " seems like a good one for non-secure boot vms :)
[22:36] <willcooke> yeah ,good plan
[22:37] <hellsworth> wait willcooke i'm off tomorrow (swap day)
[22:37] <hellsworth> i over volunteered myself
[22:37] <hellsworth> sorry about that
[22:38] <willcooke> np hellsworth, have a good one
[22:38] <sarnold> woot long weekend :D
[22:38] <hellsworth> in general though, i'm happy to test beta isos :)
[22:38] <willcooke> you say that now
[22:38] <willcooke> ....
[22:38] <willcooke> :)
[22:39] <hellsworth> i enjoy testing. girl scouts honor :)
[22:39] <willcooke> wait 'til it's the day before release at 4am
[22:39] <hellsworth> seriously though, next week i can help test the isos if you still need additional hands
[22:39] <hellsworth> :)
[22:39] <willcooke> cool, thanks
[22:39] <hellsworth> ok cheers!
[22:46] <willcooke> jibel, is the casper crash I just got when trying to use luks the one you mentioned earlier?
[22:55]  * willcooke 's house echos with the sound of "screenreader on"
[22:56] <willcooke> jibel, correction, the FDE does seem to work, it's "free software only" that shits the bed
[23:51] <willcooke> I give up, I can't think straight anymore.
[23:51] <willcooke> Thanks for testing Wimpress
[23:51] <willcooke> I think it's good enough for beta
[23:51] <willcooke> probably going to start late tomorrow


[14:13] <protonchris> @schedule
[14:13] <ubotu> Schedule for Etc/UTC: 13 Feb 13:00: Education Team | 13 Feb 21:00: Server Team | 13 Feb 22:30: Forum Council | 14 Feb 14:00: Desktop Team | 15 Feb 04:00: MOTU | 20 Feb 01:00: TriLoCo-Midwest
[14:22] <Xavier_Z> @schedule
[14:22] <ubotu> Schedule for Etc/UTC: 13 Feb 13:00: Education Team | 13 Feb 21:00: Server Team | 13 Feb 22:30: Forum Council | 14 Feb 14:00: Desktop Team | 15 Feb 04:00: MOTU | 20 Feb 01:00: TriLoCo-Midwest
[19:48] <boim> \h
[21:15] <Xavier_Z> @schedule
[21:15] <ubotu> Schedule for Etc/UTC: 13 Feb 13:00: Education Team | 13 Feb 21:00: Server Team | 13 Feb 22:30: Forum Council | 14 Feb 14:00: Desktop Team | 15 Feb 04:00: MOTU | 20 Feb 01:00: TriLoCo-Midwest