[04:15] <jose> popey, flexiondotorg: hey. I was wondering if you had time for a quick hangout to discuss ubucon latin america funding
[18:20] <CoderEurope> wheres the best place to ask for an ubuntu irc cloak ?
[18:21] <tsimonq2> CoderEurope: Probably #ubuntu-irc
[18:21] <CoderEurope> Ah Okay cheers tsimonq2 :-)


[09:58] <Trevinho> Hi, is there a way to dry-run upstart (session) to see the order of how things would be executed? So a way to simulate it?
[09:58] <Trevinho> (assuming that things are running properly)


[00:06] <binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
[00:31] <laprice> is there a way to override dch -i putting 'jaunty' as the release?
[00:31] <coppro> with a text editor?
[00:33] <Laney> man dch, there is a parameter for that
[00:33] <pochu> dch -D foo
[00:33] <laprice> OK, found it. thanks
[00:59] <laprice> So I have built the package, am I right in thinking that debsign goes out to a key repository because it gives me an error, and it never asks for my passphrase.
[01:01] <laprice> building it unsigned is fine for this pass, but I probably do need get the keys figured out so that I can build official packages for replicator :-)
[01:01] <james_w> it uses your local keyring
[01:02] <james_w> but it looks for a key with a UID which byte-for-byte matches what is in debian/changelog
[01:02] <james_w> you can tell it what key to use with the -k option, or make debian/changelog match a UID on the desired key
[01:05] <sooth> Are PPA packages signed with maintainer's key?
[01:06] <raof> No.
[01:20] <ScottK> Source is
[01:20] <nhandler> Ok, I am almost positive that there is something wrong with pbuilder (or the related packages) for intrepid
[01:22] <ScottK> nhandler: Then how come you're the only one with a problem?
[01:22] <ScottK> That I know of anyway....
[01:22] <nhandler> ScottK: I have no clue. But I just did a fresh install (again) with the same problem.
[01:22] <nhandler> Since I'm using the same pbuilderrc as some other people, I don't think that is the issue
[01:22] <ScottK> nhandler: Want my pbuilder wrapper script?
[01:23] <nhandler> ScottK: Let me see it. vorian already had me try one which failed
[01:23] <ScottK> After I saw you discuss this last, I made a new one with it.
[01:23] <ScottK> OK.
[01:24] <ScottK> nhandler: http://pastebin.com/f659051c5
[01:27]  * ScottK considers the very idea of php-gnupg as questionable.
[01:41] <nhandler> ScottK: The wrapper script failed too.
[01:42] <vorian> nhandler: which debootstrap are you using?
[01:42] <vorian> backport?
[01:42] <nhandler> vorian: Yeah, 1.0.10ubuntu1~intrepid1
[01:43] <vorian> hmmm
[01:43] <nhandler> I even tried the jaunty debootstrap a few days ago, but it didn't help
[01:46] <ScottK> nhandler: What error?  I've forgotten
[01:51] <tritium> wgrant: when you have a minute, please ping me re: MOTU Science team issues
[02:02] <nhandler> ScottK: Err http://archive.ubuntu.com jaunty/main libcwidget3 0.5.12-3ubuntu1 Could not resolve 'archive.ubuntu.com'
[02:02] <nhandler> (That comes up for all of the packages)
[02:04] <Hobbsee> ie hte /etc/resolv.conf in the pbuilder is wrong.  strange...
[02:39] <nhandler> Hobbsee: Is there any way to fix that? Since the chroot isn't created, I can't do a pbuilder login
[02:48] <StevenK> nhandler: You can run debootstrap by hand, and try and correct any problems it comes up with
[02:50] <nhandler> I'll give that a try StevenK
[02:52] <Hobbsee> nhandler: use pbuilder login --save-after-login?
[02:56] <mrooney> vorian: would you mind checking out my changes to http://revu.ubuntuwire.com/details.py?package=wxbanker when you have a minute?
[02:56] <ScottK> I dont think you can login until after its created.
[02:56] <Hobbsee> oh, the problem is creating it in the first place.  got it
[02:56] <mrooney> vorian: I found a package using the same icon set as I am, so that was super helpful :)
[02:58] <Hobbsee> nhandler: you're not running a local nameserver or anything, are you?
[03:24] <ScottK-desktop> nhandler: You don't happen to have the resolveconf package installed do you?
[03:24] <ScottK-desktop> Err resolvconf
[03:26] <Hobbsee> that too
[04:55] <jsmidt> I am going to ask what may sound as a dumb question but please be patient.
[04:56] <jsmidt> Both the PackageUpdate and MOTU/TODO encourage us to be merging and syncing.
[04:57] <jsmidt> The sync page asks that we only request syncs that improve Ubuntu.
[04:57] <jsmidt> But the reaity is there are several packages that would improve Ubuntu through bug fixes and new features.  It really is subjective.
[04:57] <jsmidt> What is the rule of thumb when making these requests?
[04:57] <ScottK> This is correct.
[04:57] <ScottK> It's a question of risk and benifit.
[04:58] <ScottK> Assessment of these is subjective and requires experience.
[04:58] <jsmidt> Should I just go to town and request anything I think would benifit Ubuntu?
[04:58] <ScottK> I'd suggest start small.
[04:58] <jsmidt> I'm only asking because it is a main todo and I want to be helpful.
[04:58] <ScottK> Pick a few and suggest them.  See how it goes.
[04:59] <ScottK> You're main job when you're new is learning.
[04:59] <ScottK> So don't go overboard with requests.
[04:59] <jsmidt> Okay, since I can't do the actual uploading and was scolded for doing debdiffs for syncs, should I at least upload a build log?
[04:59] <ScottK> Focus on picking what you think are important things and see what's good.
[05:00] <ScottK> You should definitely test build.  No need to actually upload the log.  The sponsor will test build it anyway.
[05:02] <jsmidt> ScottK, thanks.  "You're main job when you're new is learning."  I really am trying.
[05:02] <ScottK> Good.  Just keep at it.
[05:09] <binarymutant> if anyone has the time to review my package charm, http://revu.ubuntuwire.com/details.py?package=charm, I would be greatly appreciative. Thanks :)
[05:15] <raof> Ok, time to fix us some dbus permissions on packagekit.
[05:17] <jsmidt> Is there a way to get a feed for packages with a particular tag, like patch?
[05:28] <raof> jsmidt: I don't think so, but haven't dug into that particularly.
[05:31] <milli> ScottK: has a freeze date been set for Jaunty yet?
[05:32]  * milli would like to get Rails 2.2.2 in soon, with fixed depends
[05:33] <raof> milli: It'll be on wiki.ubuntu.com.
[05:33] <raof> https://wiki.ubuntu.com/JauntyReleaseSchedule
[05:35] <milli> raof: ty...  guess I need to hassle the Debian maintainer first...  there are security fixes beyond 2.1.0 that's in sid too...
[06:27] <StevenK> bigon: Can you please include more information in your sync requests? Having to dig up two changelogs and then compare changes is very tiresome.
[06:56] <stochastic> I'm trying to package my second package, but it relies on qmake so I'm not sure how to format the changes to the debian/rules file.  Are there any good qt packaging guides around?
[06:56] <Amaranth> stochastic: your best bet is to find another package that uses qmake
[07:27] <dholbach> good morning
[07:31] <iulian> G'morning dholbach.
[07:31] <dholbach> hiya iulian
[08:33] <dholbach> soren: I got ~ubuntu-motu merged into ~motu. It's done now.
[08:43] <slomo_> raof: could you merge/sync banshee 1.4.2, ipod-sharp 0.8.2 and podsleuth 0.6.4 from experimental? if you need to do any changes except changing libgnome2.0-cil to libgnome2.24-cil please tell me ;)
[08:46] <raof> slomo_: If you update f-spot, sure!
[09:14] <stochastic> I uploaded a fix to bug #211798 a few weeks ago but there's been no sign of activity since.  Do I need to mark the bug as fixed before the debdiff is accepted into the repos?
[09:16] <dholbach> thekorn, jpds: do you have any idea why the new grab-attachments (using lplib) do unzip zipped attachments (.diff.gz)?
[09:17] <DktrKranz> stochastic: no, unless your bug is already fixed in jaunty.
[09:17] <stochastic> DktrKranz, is there anything I can do other than wait now?
[09:19] <DktrKranz> stochastic: waiting is the key here. I could have a look this evening, since I've no UI here.
[09:19] <DktrKranz> *GUI
[09:20] <stochastic> Okay, I'm just making sure its not going under the radar for jaunty
[09:20] <DktrKranz> stochastic: if you're around this evening (europe timezone), please remind me :)
[09:23] <thekorn> dholbach, hmm, really? let me check, I'm sure I did not change anything related to handling of zipped files in this tool
[09:26] <thekorn> dholbach, it looks like it's a 'feature' of launchpadlib, zipped content is automatically unzipped
[09:30] <dholbach> narf :)
[09:33] <thekorn> go, report a bug!
[09:37] <RAOF> I always forget; if I upload a Banshee merge which build-depends on some new syncs, that's fine - it'll happily sit in dep-wait until the version is satisfied, yes?
[09:38] <persia> RAOF, As long as you're using unsatisfied versioned build-depends, it ought.  Worst case, it's just a rebuild for the build failure.
[09:38] <DktrKranz> RAOF: yes, unless there are broken inner dependencies, in that case a give-back is enough to have things done.
[09:38] <persia> (and we can do give-backs with the UI now :) )
[09:38] <RAOF> Oh, we can, can't we.  Yay!
[09:38]  * DktrKranz hugs persia
[09:39] <DktrKranz> "Yes, we can" (cit.)
[09:46] <DktrKranz> RAOF: if you need a hand to clear those, count on me. I want to be able to upgrade banshee again ;)
[10:10] <RAOF> DktrKranz: You're welcome to help.  The relevant bug is bug #314516
[10:17] <RAOF> The world has no right to be 30°C at 9pm.
[10:18] <dholbach> RAOF: 1°C here :)
[10:18] <jpds> It's 3*C here.
[10:18] <ogra> yeah
[10:18] <RAOF> dholbach: Trade you? :)
[10:18]  * ogra would love to be where RAOF is
[10:18] <RAOF> Sydney.  Sweet, sweaty, humid Sydney.
[10:23] <DktrKranz> RAOF: I know, I filed it ;)
[10:27] <DktrKranz> just I hadn't time to follow it
[10:29] <Quintasan> dholbach: I want to ask a question, it's related to yesterday's talk. Can I /msg you?
[10:37] <dholbach> Quintasan: sure
[10:41] <Quintasan> s the diffrence between Fix Commited and Fix Released?
[10:41] <Quintasan> crap :S
[10:42] <directhex> fix committed means the fix is published "somewhere". fix released means the fix is in a package in the archive in the right place
[10:42] <directhex> fr'example it might be fixed in a package's bzr branch or svn repo, but not yet pushed to a new package
[10:48] <RAOF> directhex: When's the mono packaging session tomorrow?
[10:48] <Quintasan> directhex: thanks
[10:49] <directhex> RAOF, it's at 8pm utc tonight
[10:49] <directhex> RAOF, you can translate that into foreign
[10:50] <RAOF> Ok, that's 7am at GMT+11.
[11:24] <ScottK> milli: It's mid feb.  Let me know about Rails.  I'd be glad to sponsor it.
[13:31] <morgs> Please remind me: I want to update a package to a new upstream version. What do I attach to the LP ticket: debdiff, or diff.gz?
[13:32] <dholbach> morgs: diff.gz, the debdiff is not really helpful, as it contains all the new upstream changes as well :)
[13:32] <morgs> dholbach: and a pointer to the upstream tarball, right?
[13:32] <dholbach> that'd help, if the package does not have a debian/watch file
[13:33] <morgs> dholbach: the upstream tarball is a tar.bz2 - I can put an orig.tar.gz somewhere, would that be better?
[13:33]  * dholbach hopes to do do some sponsoring during the Jam in Berlin later on
[13:33] <james_w> morgs: no need really, re-compressing a tarball is easy to do
[13:33] <morgs> OK, thanks
[13:34]  * dholbach nods towards james_w
[13:34] <dholbach> I personally always check the contents of the new proposed tarballs anyway
[13:34] <dholbach> one day... one fine glorious day - I know the sun will be shining brightly... we won't have the .orig.tar.gz limiation any more
[13:39] <persia> morgs, Please do have a get-orig-source rule and a README.source if the tarball is being recompressed.
[13:40] <persia> morgs, Also, if you're planning to push the same version also to Debian, and that orig.tar.gz has already been submitted, it's helpful to link to it to avoid any md5sum clashes.
[13:40] <morgs> OK
[13:40] <persia> conversely, if you're submitting to Debian later, and it goes into Ubuntu first, it's helpful to link to the Ubuntu orig.tar.gz for the Debian sponsor.
[13:40] <morgs> OK, thanks
[13:47] <mok0> hyperair: ping
[13:48] <mok0> hyperair, did you see the comments why codelite was rejected?
[13:48] <hyperair> mok0: rejected?
[13:48] <hyperair> mok0: i didn't see anything about it
[13:48] <mok0> hyperair: ah, you didn't :-)
[13:48] <hyperair> where?
[13:48] <mok0> I was rejected by archive-admin
[13:49] <mok0> s/I/It/ :-)
[13:49] <Laney> tsk tsk!
[13:49] <hyperair> eh? but why?
[13:50] <mok0> hyperair: https://lists.ubuntu.com/archives/ubuntu-archive/2009-January/024103.html
[13:50] <hyperair> i see
[13:51] <hyperair> so i make a get-orig-source rule that removes all of that?
[13:51] <mok0> hyperair: you need to repackage the tar-ball, they don't want all that crud in the archive :-)
[13:51] <mok0> hyperair: yes
[13:51] <hyperair> alrgiht
[13:52] <hyperair> and then do i need another two advocates to get it in?
[13:52] <mok0> hyperair: no I'll just re-upload
[13:52] <hyperair> okay
[13:53] <hyperair> basically only the dlls right?
[13:53] <mok0> hyperair: yes, all the binary files that don't belong on Linux
[13:53] <mok0> hyperair: he mentions an .exe file too
[13:53] <hyperair> eh?
[13:53] <hyperair> there is?
[13:54] <hyperair> yeah you're right
[13:54] <hyperair> so there's just dlls and exes?
[13:54] <mok0> I think, yes
[13:55] <mok0> hyperair: but check the tree carefully for irrelevant stuff
[13:59] <hyperair> mok0: there's a .a somewhere
[13:59] <hyperair> do i remove that too?
[13:59] <mok0> yes
[14:00] <mok0> hyperair: If the app doesn't build without it we're in trouble
[14:00] <hyperair> then i start bugging upstream
[14:00] <mok0> hyperair: :-) good boy
[14:01] <hyperair> heh
[14:02] <hyperair> mok0: are .ico files acceptable?
[14:02] <mok0> hyperair: Are they needed for the Linux version of the app?
[14:03] <hyperair> i'm not sure
[14:03] <hyperair> can linux even use .ico files?
[14:04] <mok0> hyperair: Aren't they desktop icon things for Windows?
[14:04] <mok0> hyperair: try getting rid of them & check if it hurts
[14:06] <hyperair> i'll check if they're in the debs
[14:06] <persia> hyperair, .ico files can be read by several applications, but can't be used in .desktop files natively.
[14:07] <hyperair> yeah i thought so
[14:07] <hyperair> but if it's in the source but not the debs is it really required to remove them?
[14:07] <persia> Not usually.  .ico files are sometimes the preferred source for modification.  We certainly have .ico editors in the archive.
[14:08] <hyperair> hm
[14:08] <hyperair> i see
[14:12] <hyperair> mok0: do i need to remove .bat files?
[14:12] <mok0> hyperair: yep
[14:12] <hyperair> and Makefile.win?
[14:12] <mok0> hyperair: everything related to windows
[14:12] <hyperair> *groan*
[14:13] <hyperair> there are so damn many things
[14:13] <mok0> hyperair: Bug upstream ;-)
[14:13] <hyperair> to release a separate source tarball for linux and windows?
[14:13] <mok0> hyperair: yes
[14:13] <mok0> hyperair: many projects do
[14:13] <hyperair> i think that'll require quite a lot of work on his part
[14:13] <hyperair> ._.
[14:14] <hyperair> the last time i tried getting him to do something on that scale, he took ages, and in the end i settled for using symlinks
[14:14] <mok0> hyperair: yeah, probably a bad idea
[14:14] <mok0> hyperair: note down the paths of all the files you remove in a file and make a script to do it
[14:15] <mok0> hyperair: or "find . -name \*.bat -exec rm {}\;
[14:15] <mok0> "find . -name \*.exec -exec rm {}\;
[14:15] <hyperair> mok0: yeah i'll do that, but right now, i'm still trying to get all the files
[14:15] <hyperair> there are dlls, exes, bats, Makefile.win
[14:15] <hyperair> among other things
[14:16] <mok0> hyperair: spread all over the source tree?
[14:16] <hyperair> geez, even pidgin's tarball has windows specific Makefiles in them, why didn't those get removed
[14:16] <hyperair> yes
[14:16] <hyperair> spread all over
[14:16] <mok0> hyperair: file a BTS bug about it :-)
[14:18] <Laney> Huh, isn't the problem just binaries without corresponding source?
[14:18] <hyperair> mok0: what's a BTS?
[14:18] <Laney> There's no need to remove any trace of the windows build
[14:18] <hyperair> oh
[14:18] <mok0> hyperair: Debians Bug Tracking System
[14:19] <hyperair> if it's just binaries without corresponding source, then .exe and .dll and .a should be enough
[14:19] <Laney> right
[14:20] <hyperair> and then what do i call the repackaged tarball?
[14:20] <Laney> if they're needed for the build then they should be created as part of it
[14:20] <hyperair> hoo boy
[14:20] <hyperair> looks like i'm going to ahve to bug upstream
[14:20] <hyperair> he's got a libcurl.a
[14:20] <hyperair> but no libcurl sources
[14:20] <Laney> can it use the system libcurl?
[14:21] <hyperair> lemme grep and see
[14:22] <hyperair> it seems the readme says to install the libcurl dev
[14:22] <hyperair> but ./configure doesn't seem to detect it
[14:22] <hyperair> no wait i found a function inside configure which detects it
[14:23] <hyperair> but it isn't called
[14:24] <hyperair> ah it seems it's a CURL for Windows
[14:24] <hyperair> i think i'll just rm -rf the whole folder than
[14:24] <hyperair> then*
[14:25] <hyperair> ..come to think of it i'm going to try and build without the whole sdk/ folder
[14:29] <mok0> hyperair: yikes that's a miss. You have to call the system curl
[14:29] <hyperair> mok0: no the curl folder seems to belong to windows
[14:30] <mok0> hyperair: ah ok
[14:30] <hyperair> mok0:  in the first placei d on't think it uses curl
[14:31] <mok0> hyperair: just add '~dfsg' to tarball name, after the version no. (That's tilde-dfsg)
[14:31] <hyperair> tilde eh?
[14:32] <hyperair> strange, i thought it was "."
[14:32] <persia> No, please, not tilde.
[14:32] <hyperair> heh
[14:32] <hyperair> .dfsg then?
[14:32] <persia> hyphen is much preferred, or even better, minus-sign.
[14:32] <hyperair> erm
[14:32] <hyperair> is there a difference between minus and hyphen?
[14:32] <mok0> persia: tilde will let any other version override it
[14:32] <persia> Yes.
[14:32] <persia> mok0, Yes, but do we want that?
[14:32] <persia> For dfsg, usually we don't.
[14:33] <Laney> I thought it was +dfsg usually
[14:33]  * hyperair sighs
[14:33] <mok0> persia: if upstream packages a tarball that confirms to dfsg without altering the version no
[14:33] <hyperair> that's very rare isn't it?
[14:33] <persia> Laney, That's common too.
[14:33] <mok0> persia: than you want to be able to override the package and still use the same version
[14:33] <persia> mok0, If upstream does that, they should have versions explained to them.
[14:34] <hyperair> mok0: and in the first place, i don't think he's about to package a dfsg tarball minus version change
[14:34] <hyperair> mok0: his version contains the svn revision stuck on it
[14:34] <hyperair> mok0: that's the 4-digit version after 1.0.
[14:34] <mok0> hyperair: kk
[14:35] <hyperair> persia: heh you know, the author of sigx released a tarball sigx-2.0.tar.bz2 twice, second time, setting a SONAME after i requested him to do so
[14:35]  * mok0 screams in pain
[14:35] <hyperair> lol
[14:36] <hyperair> well considering nobody actually does use sigx yet (i haven't seen any application which uses it, or any distro which packages it), i think that as long as he doesn't do it again it'll be fine
[14:36] <persia> hyperair, I do hope you asked the author to never repeat that, given the nature of web archives.  It breaks namespacing.
[14:36] <hyperair> persia: web archives?
[14:36] <Laney> The old tarball may have been archived elsewhere
[14:37] <hyperair> oh
[14:37] <hyperair> i see
[14:37] <mok0> persia: TBH, that's a problem with Debian's archive structure
[14:37] <persia> hyperair, archive.org for one.  There are others.  Also, there are uncountable caches, both visible and transparent.
[14:37] <mok0> persia: it really OUGHT to be able to handle name-space clashes
[14:37] <ScottK> mok0: Not accepting substitute tarballs with the same version name, but a different md5sum is a feature, even though it's painful.
[14:37] <persia> mok0, It's not archive-specific: it's related to the fact that if two binary blobs have the same name, it causes confusion.
[14:40] <persia> mok0, Yes, the real solution is to rearchitect browserspace to have persistent URNs for all binary blobs, and use URLs as redirectors for URNs, but that idea failed to catch on before the web left CERN years ago, and doesn't show any signs of getting better.
[14:41] <persia> with persistent links between URNs and blobs, adding a cryptographic check doesn't matter, and the archive could just have arbitrary version codes used to reference URNs for packages
[14:41] <persia> (and yes, a text file is also a binary blob, much as a square is also a rectangle)
[14:48] <dholbach> mok0: "primadonnas" :-)
[14:48]  * dholbach sniggers
[14:50] <tritium> Good morning, dholbach.
[14:51] <dholbach> hiya tritium
[14:54] <tritium> dholbach: I'm considering packaging http://ngspice.sourceforge.net/index.html for jaunty, as it has not been in an ubuntu repository since hoary, but I need to check on licensing issues.
[14:56] <rulus> Ik heb de vraag gekregen in welke mate details moeten gekend zijn van de verschillende entiteiten die kunnen voorkomen in het GRB en in de GRB-skeletbestekken.
[14:56] <rulus> GRB-producten: 1. Datamodellering: slide 10 tem 30 --> Is het hier de
[14:56] <rulus> bedoeling dat alle afkortingen en types van elk element gekend zijn?
[14:56] <rulus> En in hoeverre moet dit gedetailleerd gekend zijn? Of is het enkel
[14:56] <rulus> voldoende dat je kort kan zeggen wat alles is?
[14:56] <rulus> De verschillende soorten entiteiten die voorkomen in het GRB dienen gekend te zijn, maar de bijhorende afkortingen en alle mogelijke voorkomende types van een entiteit dienen niet in detail gekend te zijn.
[14:56] <rulus> Van elke entiteit dient er kort toegelicht te kunnen worden om welk object op het terrein het gaat of waar dit kan voorkomen. Daarom moeten niet alle geometrische eigenschappen, uitzonderingen, kenmerken... ten gronde gekend zijn.
[14:56] <rulus> GRB-producten : 4. GRB-GIS: slide 7 tem 29 --> Ook hier, in hoeverre
[14:56] <rulus> moet dit gekend zijn? Is het de bedoeling dat je weet hoe alles in GIS
[14:56] <dholbach> tritium: alright
[14:56] <rulus> voorgesteld wordt?
[14:56] <rulus> Deze slides hoeven niet in detail gekend te zijn. Ze dienen vooral ter illustratie van het GIS-product en tonen een mogelijke voorstelling van de verschillende entiteiten die reeds eerder uitgelegd werden. Qua te kennen leerstof, houden deze slides geen nieuwe elementen in.
[14:56] <rulus> GRB-skeletbestekken : 3. Opbouw: slide 41 tem 141 --> Hoe
[14:56] <rulus> gedetailleerd moet dit gekend zijn? Is het voldoende als je van elk
[14:56] <rulus> element weet wat het juist is en hoe het in een foto wordt
[14:56] <Laney> erm
[14:56] <rulus> voorgesteld? Of moet elk detail gekend zijn?
[14:58] <tritium> dholbach: is there any specific guidance on licenses?  ngspice has a heterogenous license, as it draws from different projects with different licenses, including LGPL, Old BSD, Public Domain, and New BSD.
[14:59] <dholbach> tritium: https://wiki.ubuntu.com/PackagingGuide has a chapter about licenses and debian/copyright
[14:59] <tritium> dholbach: thank you
[14:59] <dholbach> anytime
[15:05] <mok0> persia, ScottK, sorry I had to go AFK for a while
[15:06] <persia> mok0, No problems.  Happens to everyone
[15:06] <mok0> persia: I agree that publishing tarballs with different content but the same name is ... erhh... stupid
[15:07] <mok0> persia: but it happens
[15:07] <persia> Yes, but it shouldn't :)
[15:07] <persia> Anyway, there are lots of ways around it, just not aesthetically pleasing ones.
[15:07] <mok0> persia: I've just reviewed software, where the newest tarball has version 0.6, and an older one 1.0
[15:08] <mok0> persia: the uploader had quite a task writing a watch file :-)
[15:08] <persia> heh, I bet.
[15:09] <persia> perl regular expressions are *very* powerful, but man uscan doesn't provide much of a guide.
[15:09] <mok0> persia: yes, you sometimes have to work to get it to do what you want
[15:10] <mok0> persia: I think we ended up mangling 1.0 to 0.1 or something like that
[15:11] <mok0> persia: us packagers hate upstreams even more than developers hate users ;-)
[15:12] <persia> heh
[15:12] <persia> I'd probably have tried to somehow find the URL near the most recent date, but it might have taken me a week to get it right.
[15:13] <mok0> persia: we considered it, but the date was not systematically written on the web page.
[15:13] <persia> Ugh, even worse.
[15:13] <persia> Some things should just not be.
[15:13] <mok0> persia: and unfortunately, uscan can't get a tarball directly from the URL
[15:13] <mok0> persia: if it contains http://
[15:13] <persia> Needs to scrape a web page?
[15:14] <persia> Yes it can, as long as directory indexing is enabled, and there's no index page.
[15:14] <mok0> persia: I think so, I haven't been able to get the other thing to work
[15:14] <mok0> persia: it ought to be able to work like wget
[15:14] <persia> Uh, no.
[15:15] <persia> I needs a list of versions to compare.
[15:15] <persia> With a single URL, one can only get a single thing.
[15:15] <persia> With a regular expression, one needs to have a set of matching things as a filter.
[15:15] <mok0> persia: of course, d'Oh!
[15:15] <persia> Otherwise, one needs to iterate over the entire matched set, which takes until well after the heat death of the universe.
[15:15] <mok0> :)
[15:20] <ScottK> Still faster than Debian releases.
[15:21] <bddebian> Heya gang
[15:23] <mok0> hi bddebian
[15:23] <bddebian> Hi mok0
[15:24] <tritium> Hi bddebian.
[15:27] <bddebian> Heya tritium!
[15:27] <tritium> :)
[15:29] <ScottK> Heya bddebian.
[15:29] <bddebian> Hi ScottK
[15:32] <tritium> I'm a bit puzzled by bug 246506.  The debian bug status is "Fix Committed", but only because someone has privately packaged it, as far as I can tell.  It's not yet in Debian.
[15:33] <ScottK> tritium: It may be in Debian New too.
[15:33] <tritium> ScottK: I'm not familiar with Debian New.
[15:34] <tritium> Ah, found it.
[15:34] <broonie> tritium: When packages are uploaded to the archive they are initially reviewed for legal problems.
[15:34] <broonie> While that happens they're not downloadable.
[15:34] <ScottK> tritium: After a package is uploaded for the first time it goes into the New package queue (as broonie says)
[15:34] <tritium> broonie: oh, I see.  This one, having multiple licenses, would need that legal review.
[15:34] <tritium> The Debian Import Freeze has passed, correct?
[15:34] <ScottK> http://ftp-master.debian.org/new.html
[15:35] <broonie> tritium: All new packages get this review, you can't tell if the maintainer noticed everything without review.
[15:35] <ScottK> tritium: For auto sync, yes.  They can still be requested manually.
[15:35] <tritium> OK.  I don't find it in http://ftp-master.debian.org/new.html
[15:36] <rulus> I'd like to apologise for my paste earlier; I wasn't aware of the fact that Putty associated the middlemousebutton with paste. Sorry.
[15:37] <tritium> Thanks, broonie and ScottK.  How would you advise I proceed?
[15:38] <ScottK> tritium: You could email the owner of the ITP bug and ask them how soon the plan to upload it.  You might also look on mentors.debian.net.
[15:38] <tritium> It seems that "Fix Committed" isn't appropriate for it, if it's not even in Debian New.
[15:39] <tritium> ScottK: will do.  Can his package be brought into ubuntu directly, or should it come straight from Debian?  Should it be repackaged (by me)?
[15:40] <tritium> In the mean time, I'll contact the bug owner.
[15:40] <ScottK> If it doesn't come through Debian (and given the length of the New queue that's getting unlikely) then it'd have to go through REVU.  You could do that.
[15:40] <ScottK> Ideally they will give you access to the draft package and you don't have to change much.
[15:41] <tritium> ScottK: ok, thanks again.
[15:41] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
[15:42] <slytherin> tritium: check with motu science team if they are interested in helping you with ngspice.
[15:43] <tritium> slytherin: I'm technically still the administrator of that team, but I'm no longer MOTU.  I'm not sure the team is still active.
[15:43] <tritium> I've pinged wgrant about it, though.  Thanks.
[15:46]  * ScottK notes mok0 is interestedin science stuff too.
[15:46] <mok0> I am
[15:46] <ScottK> tritium: ^^
[15:46]  * tritium notes above ;)
[15:50]  * mok0 notes his name is no isotope
[15:50] <mok0> s/name/nick
[15:51] <mok0> tritium: the science team is sadly inactive
[15:52] <tritium> mok0: yes, if I pursue reinstatement as an MOTU again, I'd hope to focus on that team.
[15:52] <mok0> tritium: cool
[15:52] <mok0> tritium: the Debian science team is much more active
[15:52] <tritium> mok0: are you part of that?
[15:53] <mok0> tritium: yes
[15:53] <tritium> mok0: excellent
[15:53] <tritium> Have you seen anything about ngspice in particular on your mailing list or otherwise?  It's licensing is peculiar.
[15:53] <mok0> tritium: No, I haven
[15:54] <mok0> t
[15:54] <tritium> ah
[15:54] <slytherin> tritium: you may want to contact tuxmaniac. Although he is not MOTU, he is very enthusiastic about electronic related softwares.
[15:54] <mok0> tritium: can I see it somewhere? URL?
[15:54] <tritium> slytherin: oh, thanks for the tip.
[15:55] <mok0> tritium: and norsetto
[15:55] <tritium> mok0: debian bug here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489768
[15:56] <tritium> project page here: http://ngspice.sourceforge.net/
[15:59] <mok0> "The group developing ngspice has written to Berkeley's copyright holders asking to change the license to the new BSD, which has the incompatibility removed, but without success. "
[15:59] <mok0> I wonder if that means they refused, or that they didn't answer the request
[16:01] <tritium> Not sure.  Here's the COPYING file from the new ng-spice-rework-18 package that talks about the "heterogenous
[16:01] <tritium> " license: http://paste.ubuntu.com/108277/
[16:03] <mok0> tritium: OMG
[16:04] <tritium> mok0: pretty crazy, eh?
[16:05] <mok0> tritium: yeah
[16:06] <tritium> It seems I always pick the crazy stuff to try to package.
[16:07] <mok0> tritium: If UC decided to remove the advertising clause from their license, why wouldn't they accept that the old BSD license be changed in this case? It doesn't make sense
[16:08] <tritium> I agree.
[16:10] <mok0> tritium: it's the crazy stuff out there that left...
[16:10] <tritium> heh
[16:15] <mok0> ScottK, you want me to fake-sync ktranslator?
[16:15] <ScottK> Got to.
[16:15] <ScottK> Different orig.tar.gz
[16:15] <mok0> ScottK, how did that happen?
[16:17] <mok0> ScottK, problems with debian's repo?
[16:20] <ScottK> mok0: It's hard to say.  Sometimes upstream tarballs get published more than one place.
[16:20] <ScottK> mok0: It's not rare the first time we try to sync from Debian.
[16:21] <mok0> ScottK, this looks to be a new packaging, they didn't use the old ubuntu one
[16:21] <ScottK> This is not unusual either.
[16:21] <ScottK> So the trick is to see if there is any needed to be saved from our.
[16:21] <ScottK> our/ours.
[16:21] <mok0> ScottK, yes
[16:21] <mok0> ScottK, I will take care of it
[16:22] <ScottK> If so, then merge, but unless it's significant, just fakesync.
[16:22] <ScottK> Great.
[17:28] <mok0> ScottK, hrmph, ktranslator is a KDE3 program, and hasn't been updated in almost  3 years
[17:29] <ScottK> mok0: Does it need more than kdelibs?
[17:29] <mok0> kdelibs4-dev
[17:30] <ScottK> Then it's at least usable for now.
[17:31] <mok0> ok, I'll continue. /me is annoyed at this package because it doesn't build out of the box. I thought I checked that
[17:31] <soc> hi
[17:31] <soc> just wanted to say thank you for all your help getting ttf-droid into ubuntu!
[17:31] <mok0> soc: you
[17:32] <soc> it looks like it was included 2 days ago and is now generally available through synaptic after install
[17:32] <mok0> soc, you're welcome
[17:32] <soc> ah hi mok0!
[17:32] <soc> without you help i wouldn't have gotten my package into the shape it is now ..
[17:32] <hyperair> mok0: i've uploaded a new tarball of codelite to revu, along with the necessary changes regarding get-orig-source
[17:32] <hyperair> mok0: could you take a look?
[17:33] <mok0> hyperair: yes I'll take a look, after I've cracked the problem I am looking at ATM
[17:33] <hyperair> mok0: is it something i could help with?
[17:34] <mok0> hyperair: you mean you want to swap :-)
[17:34] <hyperair> eh?
[17:34] <hyperair> swap?
[17:34] <mok0> hyperair: I take codelite and you take ktranslator...
[17:34] <mok0> hyperair: I'll have it nailed soon
[17:35] <mok0> hyperair: It's a configure file built in maintainer-mode, so once the build goes "make" it decides to update everything
[17:37] <mok0> which is a pain
[17:41] <hyperair> ah i see
[19:12] <fransman> Can someone check there a updated package of flumotion in the cue.
[19:14] <fransman> I already did create a bug ticket for it, https://bugs.launchpad.net/ubuntu/+source/flumotion/+bug/319204
[19:21] <directhex> woo, mono session in classroom soon :o
[19:30] <Chris`> If there are many reviewers/advocates free, can you please review one of my packages? - http://revu.ubuntuwire.com/details.py?package=grdc
[19:33] <hyperair> nobody seems free these days =(
[19:34] <Chris`> hyperair: I know I try daily for reviews :p
[19:34] <Chris`> So much for aiming for the MOTU :p
[19:34] <hyperair> i've got three outstanding packages
[19:34] <jpds> Chris`: Does perl have to be in the build-deps?
[19:34] <jpds> hyperair: lies...
[19:34] <hyperair> jpds: fine, you're the only one free =p
[19:34] <Chris`> jpds: Yeah isn't it included?
[19:34] <hyperair> why does everyone ignore me then T_T
[19:34] <Chris`> It's for the pod manpage
[19:34] <Chris`> hyperair: jpds is my mentor, it's his duty ;)
[19:35] <hyperair> aah
[19:35] <hyperair> i should go and apply for mentoring as well
[19:35] <hyperair> =\
[19:35] <hyperair> how dyou apply?
[19:35] <jpds> Chris`: I think perl gets pulled it anyway (it's what most of the dh_* scripts are written in).
[19:35] <Chris`> jpds: I was told on the manpage tutorial to include Perl
[19:35] <hyperair> a standard pbuilder login has perl installed
[19:36] <Chris`> hyperair: https://wiki.ubuntu.com/MOTU/Mentoring/Junior_Contributor
[19:36] <jpds> Chris`: Hmm, ok. Did you know that you can seperate paragraphs in the long desc by have a " ." line?
[19:37] <Chris`> A what line?
[19:37] <jpds> As in: apt-cache show ubuntu-dev-tools
[19:37] <Chris`> Oh cool ok
[19:38] <Chris`> *changed*
[19:38] <Chris`> Anything else bad?
[19:38] <jpds> Chris`: Does the applet have to be called: grdc-gnome? Sounds a bit.. vague.
[19:38] <Chris`> jpds: That's what upstream called it :-/
[19:39] <Chris`> Should I mix it up or leave it as upstream wishes it to be?
[19:39] <jpds> irssi-otr is know as irssi-plugin-otr in Debian..
[19:39] <hyperair> damn, i seriously need to write a wiki page about myself?
[19:40] <Chris`> hyperair: I have :P
[19:40] <Chris`> hyperair: http://wiki.ubuntu.com/Chris
[19:40] <hyperair> thanks
[19:40] <hyperair> 17!
[19:40] <hyperair> damnit you're younger than me
[19:40] <Chris`> jpds: Perhaps grdc-gnome-applet?
[19:41] <hyperair> then there's always rainct -- a year younger than me, same amount of years using linux, and motu already!
[19:41] <Chris`> hyperair: I'm just using it as a progress tracker, more like a blog
[19:41] <hyperair> i see
[19:42] <jpds> Chris`: Not too sure, can't find a Debian GNOME policy on it.
[19:42] <Chris`> Safer to leave it as it is? :-/
[19:42]  * jpds would like gnome-applet-grdc, but can't find any packages which follow that.
[19:44] <Chris`> So other than the line break, anything worth changing?
[19:44] <jpds> Chris`: Would be nice to Suggest: the applet package.
[19:44] <Chris`> Ah, how does one go about that?
[19:44] <Chris`> Suggests: package?
[19:45] <jpds> Yep.
[19:45] <Chris`> *changed*
[19:48] <Chris`> I've uploaded the new grdc now
[19:52] <Chris`> jpds: it's uploaded now if you wanna add a comment/avocation :D
[19:55] <RainCT> hyperair: and jpds is even younger \o/
[19:58] <hyperair> RainCT: aren't you born in 1991?
[19:59] <RainCT> hyperair: yep
[19:59] <hyperair> RainCT: so is jpds
[19:59] <hyperair> and me in 1990
[19:59] <hyperair> the end of it
[20:00] <RainCT> hyperair: but there are some months between his and my birthday (which, btw, is in 2-3 weeks :D)
[20:00] <hyperair> heh.
[20:00] <hyperair> there are three months between yours and mine
[20:02]  * ScottK has children born in 1991.  Urgh.
[20:02] <jpds> RainCT: Can you poke grdc, looks good to me.
[20:02] <ScottK> Child anyway
[20:02] <RainCT> jpds: bad tab completion :P
[20:02] <hyperair> ScottK: heheheh
[20:02] <RainCT> lol
[20:02] <laga> i feel old.
[20:02] <laga> and i haven't become a MOTU yet ;)
[20:02] <RainCT> ScottK: tell them to become MOTU :P
[20:03] <hyperair> laga: awesome. let's race =p
[20:03] <Chris`> Count me in!
[20:03] <directhex> mono session now on! gogogo :p
[20:03] <hyperair> Chris` no fair you've got a headstart =p
[20:03] <laga> hyperair: how old are you? ;)
[20:03] <ScottK> RainCT: No, they aren't that interested in computers.
[20:03] <hyperair> laga: born 1990. i'm lazy to remember my age, or do the calculation
[20:03] <ScottK> My best hope is the 5 year old.
[20:03] <RainCT> directhex: is that a treath?
[20:04]  * RainCT runs
[20:04] <Chris`> I lied I'm actually 17 in a week but there's no point updating the wiki just for that
[20:04] <laga> hyperair: ah. i'm turning 22 this year, so i guess i'll have to lose.
[20:04] <hyperair> directhex: would you be so kind as to review a mono package for me? =p
[20:04] <directhex> RainCT, yes
[20:04] <directhex> hyperair, after the session, sure
[20:04] <directhex> hyperair, you can ask meebey, even! he's the debian mono pope!
[20:04] <hyperair> directhex: http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin thanks =p
[20:05] <RainCT> directhex: so you agree that mono is evil? \o/     :P
[20:05] <directhex> RainCT, yeah, but less evil than java
[20:05] <RainCT> hehe
[20:06]  * ScottK hugs his Python.
[20:06] <laga> how's java moar evil?
[20:06] <hyperair> directhex: agreed!
[20:06] <hyperair> laga: because java is longwinded and stupid
[20:06] <ScottK> laga: How much mono stuff in multiverse?
[20:06] <laga> i actually like java. :)
[20:06] <directhex> laga, because java lacks monkeys
[20:06] <directhex> ScottK, none
[20:06] <hyperair> laga: if you've got a good IDE, yeah it isn't that bad
[20:06] <laga> ScottK: uh, dunno.
[20:06] <ScottK> directhex: Yep.
[20:07] <laga> hyperair: i like eclipse. i wish there was a nice debugger for python (is there o ne?)
[20:07] <ScottK> laga: How much java stuff stuck in multiverse?
[20:07] <hyperair> laga: but when you're writing it on paper, you tend to hate SuperLongAndObscureNamespaces.SuperLongAndObscureSecondNamespace.SuperLongClassName
[20:07] <laga> ScottK: just wait for icedtea :)
[20:07] <directhex> why are none of you in #ubuntu-classroom then? :o
[20:07] <laga> hyperair: well, that'd be silly.
[20:07] <ajmitch> directhex: because we're sensible people
[20:07] <ajmitch> (and I just joined)
[20:07] <hyperair> laga: it's a written paper exam
[20:07] <laga> hyperair: actually, we will have an oral examination for this java class. :)
[20:08] <hyperair> oral?!
[20:08] <laga> hyperair: yes. :)
[20:08] <hyperair> i thought written programming was stupid, but oral sounds even more stupid ._.
[20:08] <laga> hyperair: heh. no, it'll be more about algorithms.
[20:08] <hyperair> System dot out dot printf open bracket ...
[20:09] <fransman> how do i set bug #319204 for need packaging ?
[20:09] <hyperair> doesn't seem like a need packaging bug
[20:09] <laga> hyperair: it'll be more more high-level stuff.
[20:09] <laga> hyperair: we implemented stuff like parsers and they probably want us to describe that
[20:09] <hyperair> laga: then that's fine i guess, but oral still sounds weird. don't programmers draft things out on paper for complex issuse?
[20:09] <laga> hyperair: we'll have time for that i suppose.
[20:10] <fransman> hyperair: what does it then?
[20:10] <laga> hyperair: AFAIR, we will also be graded on the home work we turned in. we did projects instead of lectures. the oral exam is just a bonus IIRC
[20:11]  * directhex thinks hyperair could learn useful things in this session
[20:11] <hyperair> directhex: eh wha?
[20:12] <directhex> hyperair, session on mono packaging in #ubuntu-classroom
[20:12] <directhex> that's better!
[20:12] <hyperair> it seems...quiet
[20:12] <RainCT> directhex: is that transition also on Debian?
[20:13] <directhex> gnome#? ehm... sort of. the offending gnome# is in experimental, but we're not currently building things against it
[20:13] <directhex> poke slomo for that
[20:19] <khashayar> §
[20:21] <khashayar> Hi all. I've built a package for pencil (http://www.les-stooges.org/pascal/pencil/), and I'm currently down to only one lintian warning, missing man page. Is it frowned upon to upload it to revu in its current state? (I'm just not going to do the man page tonight).
[20:22] <RAOF> khashayar: You're welcome to upload to revu and solicit comments about the rest of the packaging.
[20:22] <khashayar> RAOF: Thanks. I'll do that.
[20:23] <RAOF> khashayar: Make sure to add a comment to the effect that you're not after advocation, just comment, and you'll write the man page before asking for it to be uploaded.
[20:23] <hyperair> khashayar: i generally upload to revu whenever i've gotten some major changes done, and only when i've fixed all my lintian stuff i start asking for comments
[20:24] <khashayar> hyperair: OK. So suggest I write the manpage first before uploading?
[20:24] <hyperair> khashayar: just upload first
[20:24] <hyperair> khashayar: you can always reupload if you make changes
[20:25] <khashayar> hyperair: OK. Thanks.
[20:25] <hyperair> revu-ers seem so scarce that if you upload within a week or so of your previous upload you're almost bound to get no comments, unless you've bugged someone to do so
[20:31] <Chris`> hyperair: Talking of bugging... RainCT you there? :)
[20:32] <hyperair> Chris`: ?
[20:32] <RainCT> Chris`: yes, but I'm busy :(
[20:32]  * Chris` bugs RainCT for just one more advocate
[20:32] <Chris`> OH ok don't matter
[20:49] <mok0> hyperair, you are right, revuers are very scarce. There's less than a handful of MOTUs that do any work there
[20:49] <mok0> hyperair: looking at codelite now, btyw
[20:49] <hyperair> mok0: ah thanks =)
[20:49] <wgrant> tritium: Yes, we are rather completely inactive. I see no problem with you remaining an admin.
[20:50] <tritium> wgrant: Thanks.  :)  You realize my MOTU-ship expired, though, right?
[20:50] <wgrant> tritium: I do.
[20:51] <tritium> wgrant: Thanks.  :)
[20:51] <hyperair> MOTU-ship expires?
[20:51] <RainCT> hyperair: you can renew it clicking on a link
[20:51] <tritium> hyperair: on launchpad, I didn't renew in time
[20:51] <hyperair> i see
[20:51] <RainCT> mok0: btw, I wanted to tell you something..
[20:52] <RainCT> mok0: you rock!! :P
[20:52] <mok0> RainCT: heh
[20:52]  * hyperair thinks so too
[20:52] <tritium> wgrant: please don't hesitate to ask me to help out, if there's something you need done
[20:52] <mok0> Thanks guys
[20:52]  * tritium just met mok0 today, but would agree that he rocks :)
[20:54] <hyperair> mok0, your friendly neighbourhood buildd ;)
[20:55]  * Chris` has silently observed mok0 over the past week and thinks given enough time, he may fall in love with mok0 :(
[21:01] <hyperair> lol
[21:14] <mok0> hyperair: I can't see where you do the repackaging of the tarball
[21:14] <hyperair> mok0: debian/rules
[21:14] <hyperair> mok0: and debian/copyright, see X-something
[21:15] <mok0> hyperair: in the clean target?
[21:15] <hyperair> mok0: get-orig-source
[21:15] <hyperair> there should be a target
[21:15] <hyperair> after clean
[21:15] <mok0> uh, I may have the wrong version here
[21:15] <hyperair> lol
[21:15] <hyperair> http://revu.ubuntuwire.com/revu1-incoming/codelite-0901221833/codelite_1.0.2674+dfsg-0ubuntu1.diff
[21:16] <hyperair> heheheheheg
[21:18] <mok0> hyperair: got it now
[21:19] <hyperair> okay
[21:42] <hyperair> mok0: could you look at this please? i've fixed the stuff you mentioned in your previous comment http://revu.ubuntuwire.com/details.py?package=bansheelyricsplugin
[21:50] <tdomhan> can the merge-o-matic not be used after the DebianImportFreeze?
[21:51] <pochu> tdomhan: it can, but you need a good reason to perform a merge
[21:51] <pochu> bug fixes are good reason, btw ;)
[21:58] <tdomhan> so MOM still checks for new versions in the debian repos? because I can't find any files of the package I'm interested in, mhhhh or indicates this, that the packages is being synced? mhh
[22:09] <hyperair> mok0: thanks
[22:11] <hyperair> jpds: you free for a review? =p
[22:11] <jpds> hyperair: About to go to bed, what is it so I can look at it in the morning?
[22:12] <mok0> hyperair: got another batch of comments for you
[22:13] <tdomhan> it's about the package gpsbabel, in the current debian unstable repo it is version 1.3.6-3, the jaunty version is 1.3.5. shouldn't merge-o-matic create it's corresponding files?
[22:13] <hyperair> jpds: http://revu.ubuntuwire.com/details.py?package=sigx
[22:13] <hyperair> jpds: and http://revu.ubuntuwire.com/details.py?package=vazaar
[22:13] <hyperair> mok0: ah i saw, thanks
[22:13] <hyperair> mok0: should i document it in codelite then?
[22:14] <mok0> hyperair: I've already uploaded. Let's see if it gets into the archive this time. If it does, you can prepare an update of the package fixing that
[22:14] <jpds> hyperair: OK; will look at both when I can tomorrow morning.
[22:15] <hyperair> jpds: thanks
[22:15] <hyperair> mok0: okay
[22:15] <hyperair> mok0: then how do i submit it?
[22:16] <hyperair> mok0: also the get-orig-source issue seems to happen only if you've already got an orig tarball
[22:16] <mok0> Normally, you prepare a debdiff and get that sponsored through LP
[22:17] <mok0> hyperair: let's worry about that later
[22:17] <hyperair> okay
[22:18] <hyperair> mok0: by the way, regarding the get-orig-source target... how should i fix it? uscan refuses to download again if it detects a orig.tar.gz of the correct version
[22:19] <mok0> Yikes 129 packages awaiting review... that's +19 from a week ago.
[22:19] <mok0> hyperair: ah, is that what happens?
[22:20] <hyperair> mok0: yes
[22:21] <hyperair> mok0: otherwise it works.
[22:21] <hyperair> mok0: perhaps i should just put &&?
[22:21] <mok0> hyperair: I'd suggest not calling uscan in the target
[22:21] <hyperair> why not?
[22:21] <hyperair> mok0: ^
[22:21] <mok0> hyperair: than you'd have to do that first, and wouldn't need to run get-orig-source
[22:22] <hyperair> what?
[22:22] <hyperair> do uscan first?
[22:25] <mok0> hyperair: yeah, so the operator would have to run it manually.
[22:26] <mok0> hyperair: perhaps, in the get-orig-source target, you could run a uscan --report-status, if the version is up-to-date, bail out
[22:27] <mok0> hyperair: nice little problem to keep you awake tonight
[22:28] <hyperair> mok0: more like this morning
[22:28] <hyperair> mok0: it's 6.30AM and the sun's going to rise soon
[22:29] <hyperair> mok0: anyway the operator doesn't have to run uscan manually. in fact, it's better if uscan wasn't called manually
[22:29] <mok0> hyperair: oh... did you get up early, or didn't you get to bed?
[22:29] <hyperair> haven't gone to bed yet
[22:29] <hyperair> class at 12.30PM
[22:29] <mok0> yikes
[22:29] <hyperair> and i'm multitasking between some packages and an accounts tutorial =p
[22:30] <mok0> phew
[22:30] <hyperair> i'm trying to get this done so i don't have to travel half the country with the textbook this weekend (i'm heading back home for chinese new year)
[22:31] <hyperair> anyway about the lintian error
[22:31] <hyperair> i figured out what's wrong
[22:31] <mok0> hyperair:  the dll one?
[22:31] <hyperair> dh_clifixperms wasn't being called because i hooked it onto common-binary-predeb-arch, instead of -indep
[22:31] <hyperair> yeah the dll one
[22:31] <mok0> hyperair: ah, good!
[22:31] <hyperair> yep
[22:32] <hyperair> so i've fixed that issue.. and the copyright issue..
[22:32] <hyperair> just add dots right/
[22:32] <mok0> yep
[22:32] <mok0> simple
[22:32] <hyperair> hmm come to think of it codelite's didn't have dots
[22:32] <hyperair> and then about the get-orig-source..
[22:32] <mok0> hyperair: I missed that, dang
[22:32] <hyperair> heheh
[22:32] <hyperair> i'll jhave to fix that in all of my other revu packages
[22:33] <mok0> great, thanks. It's not a problem yet, because copyright is in principle free-format
[22:33] <hyperair> yeah
[22:33] <hyperair> well lintian will start complaining later on
[22:34] <hyperair> on a side note.. what do i do about the issue with uscan?
[22:34] <mok0> But if you choose the machine-readable format, it should of course be correct. It's just, there's no software to check it yet
[22:34] <hyperair> it dies when there's a tarball existing
[22:34] <hyperair> otherwise it works
[22:34] <mok0> hyperair: of course you could rm -f the tarball first :-P
[22:34] <hyperair> if you rm the ../bansheelyricsplugin_0.6.orig.tar.gz
[22:34] <hyperair> hmm
[22:35] <hyperair> would that be a good idea?
[22:35] <hyperair> hmmm
[22:35] <hyperair> yeah i think i should do that
[22:35] <hyperair> which means yet another change to implement for codelite as well
[22:35] <hyperair> the error happens there too
[22:35] <hyperair> lool
[22:35] <mok0> hyperair: what about uscan --report can you use that first ?
[22:35] <hyperair> nope
[22:35] <hyperair> that one reports the status as up to date as long as your debian/changelog has the said version
[22:35] <mok0> uscan is not really advanced enough
[22:36] <hyperair> it's pretty cool already
[22:38] <mok0> hyperair: yes, but it should be more scriptable
[22:39] <hyperair> yeah
[22:39] <hyperair> true
[22:39] <hyperair> the --report thing isn't exactly very parseable
[22:39] <hyperair> though --dehs is scriptable
up to date</status>
[22:40] <hyperair> with the use of grep and sed, you could extract that out
[22:40] <mok0> hyperair: yes that could be done
[22:41] <hyperair> yeah but it reports up to date as long as your debian/changelog has an up to date version
[22:41] <mok0> hyperair: but why haven't I seen this problem before?
[22:41] <hyperair> why..
[22:41] <hyperair> probably because they used wget?
[22:42] <hyperair> also according to the bpp, get-orig-source must be callable from any directory.
[22:42] <hyperair> it's entirely possible that they didn't provide for that
[22:42] <mok0> hyperair: put a dh_checkdir call in it
[22:42] <hyperair> anyway i've uploaded another version
[22:42] <hyperair> what's dh_checkdir?
[22:43] <hyperair> there isn't a manpage
[22:43] <hyperair> command not found. hmm
[22:43] <mok0> dh_testdir sorry
[22:43] <hyperair> ah that
[22:44] <hyperair> i don't see any real application for it in get-orig-source
[22:44] <mok0> hyperair: it makes sure you only call the script from $topdir
[22:45] <hyperair> mok0: but you're supposed to be able to call it from other directories
[22:45] <hyperair> mok0: and it's supposed to dump the orig.tar.gz into your current directory, no matter waht it is
[22:45] <mok0> hyperair: that way it will work right no matter what dir it's called from :-)
[22:46] <hyperair> =\
[22:46] <mok0> uscan will drop it in $topdir/..
[22:46] <hyperair> yeah
[22:47] <hyperair> uscan drops it in $topdir, and then get-orig-source does its fancy stuff wherever it likes, dumps your resulting orig.tar.gz into your current dir, and then cleans up
[22:49] <hyperair>    This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory.
[22:49] <hyperair>  This target may be invoked in any directory, and should take care to clean up any temporary files it may have left.
[22:49] <hyperair> there we go
[22:50] <mok0> hmm
[22:50] <hyperair> mok0: anyway there's a new upload
[22:50] <mok0> hyperair: ok thanks
[23:02] <hyperair> my my what a pretty sunrise
[23:02]  * hyperair yawns
[23:06] <tritium> Hello.  If my launchpad team membership expired, is there a way to reactivate it?  I understand that MOTUs can activate/deactive themselves now?
[23:07] <mok0> tritium: AFAIK you need to apply for MOTUship once more
[23:07] <mok0> tritium: Of course you could try writing MC asking to have your MOTUship reactivated
[23:08] <tritium> mok0: I may do that.  You're not aware of any changes to the team membership rules to allow activating/deactivating at will, as schedules permit?
[23:08] <mok0> tritium: no
[23:09] <tritium> mok0: ok, thanks.
[23:12] <hyperair> mok0: i need to document the repackaging in debian/changelog?
[23:13] <hyperair> mok0: i thought it was only necessary in debian/copyright
[23:15] <mok0> hyperair: it's a bit confusing. Honestly, I don't think it logically belongs in copyright, but it's in the policy.
[23:15] <maco> is it intentional that there's no spim in jaunty, or has it just not been gotten around to yet?
[23:15] <mok0> hyperair: however, if it's in changelog, it's certain to be noticed by other people who come along and do stuff to the package
[23:15] <hyperair> mok0: i see. okay then. there's a new upload
[23:16] <mok0> hyperair: f.ex. if upstream suddenly provides a tar.gz file, it is good to be able to see there what you did
[23:16] <hyperair> mok0: ah. right.
[23:16] <mok0> hyperair: if you promise to go to bed, i will ack it :-)
[23:17] <hyperair> mok0: heh yeah i'll go to bed now
[23:17] <maco> oh....its not in intrepid either. what happened to spim?
[23:17] <hyperair> good uh morning
[23:18] <mok0> heh
[23:18] <mok0> Midnight here, I gotta go soon too
[23:18] <hyperair> heh.
[23:18] <mok0> Have to get up early
[23:18] <tritium> Good night, mok0.
[23:18] <hyperair> bye
[23:36] <Chris`> mok0: Thanks for that mail to the mailing list :D


[10:22] <rmg51> Morning
[10:34] <JonathanD> Morning.
[11:19] <ChinnoDog> morning
[11:24] <JonathanD> Hows it going?
[11:26] <ChinnoDog> Tired. Sleepy. Getting some work in ahead of schedule today so I can take time out later when I need it.
[11:33] <JonathanD> Fun times.
[13:00] <lazyPower> Morning everyone o/
[13:14] <teddy-dbear> Morning peoples, dogs, turkeys, hamsters and everything else
[13:28] <lazyPower> Do we have a December meetup scheduled?
[13:28]  * lazyPower has been lazy and not checked the wiki
[13:30] <teddy-dbear> we have meetups?
[13:32] <lazyPower> Allright, that settles it :) I Want to schedule a virtual meetup. Time for me to make good on my offer that i put on the table for my ubuntu membership
[13:32] <lazyPower> who do i have to petition for scheduling?
[13:35] <jedijf> no one
[13:36] <jedijf> list - forums - hear - announce - do
[13:36] <jedijf> list == mailing list
[13:36] <jedijf> kiss
[13:36] <jedijf> hear == here ...lol coffee
[13:37] <jedijf> keep it within the /topic times if possible just cause can't remember who can actually change topic
[13:37] <jedijf> lazyPower: ^^^^ 6'ish lines
[13:37] <lazyPower> jedijf: o/ Thanks for the reply
[13:37] <jedijf> Topic set by pleia2 or just petition pleia2 to change topic LOL
[13:38] <lazyPower> I'll get some topic notes together and multi-submit to a few different meetup groups i'm part of
[13:38] <lazyPower> expect details early to mid next week
[13:38]  * jedijf expects nothing; life is more exciting that way
[13:38] <lazyPower> fair enough :)
[13:39] <teddy-dbear> and I'll do what I usually do
[13:39] <lazyPower> teddy-dbear: does it involve pie and coffee?
[13:39] <teddy-dbear> sit here and look way cute :-D
[13:39] <jedijf> lazyPower: one thing...8:30 is late for me....7'ish pm to 8 is about the end....but that's just me
[13:39] <lazyPower> because im' feeling the urge to fetch some pie and make coffee
[13:39] <jedijf> and there is always backlog; so no worries
[13:40] <lazyPower> jedijf: i think thats fair. start at 6:30 for pre-show and organizational matters -  7pm for actual presentation
[13:40] <lazyPower> Anywho i'll sketch this up and get it posted to the list
[13:40] <teddy-dbear> pie, yes coffee, no
[14:12] <lazyPower> http://theoatmeal.com/comics/email_monster
[14:12] <lazyPower> nailed it
[14:13] <pleia2> to see everyone who can change the topic: /msg chanserv access #ubuntu-us-pa list
[14:14] <pleia2> not many who are active anymore, so just let me know who I should add
[14:48] <jedijf> pleia2: add myself and lazypower.....i didn't look
[14:51] <jedijf> damn, i guessed wrong
[14:56] <lazyPower> \o/
[14:56] <lazyPower> achievement unlocked - ability to /title
[14:56] <lazyPower> next unlock in.... 600k xp
[15:00] <ssweeny> that's a non-trivial amount of xp
[15:04] <lazyPower> that was the idea :)
[15:17] <ssweeny> lazyPower, when are we having our yinzer warthogs meetup? :)
[15:18] <lazyPower> ssweeny: let me fire off an email to you and lisa
[15:18] <lazyPower> lisa and I tried this back in August - but i got pulled into USENIX
[15:20] <lazyPower> ssweeny: harpoons fired
[15:21] <ssweeny> lazyPower, awesome
[15:21] <jedijf> the last yinzer meetup was a success iirc - it has been a while though
[15:22]  * ssweeny organized a release party with the wplug years ago
[15:22] <jedijf> by yinzer i mean real yinzer, not a yinzer comes east
[15:22] <ssweeny> was that it?
[15:22] <jedijf> ssweeny: probably
[15:22] <jedijf> corporate hamburgery beer joint iirc
[15:22] <ssweeny> yeah fox and hound
[15:22] <jedijf> that's it
[15:22] <ssweeny> went rather smoothly
[15:24] <jedijf> best case now is wait for travelling pleia2 to land in your area and plan an event around it
[15:24] <lazyPower> ssweeny: last meetup i went to centinel and a couple others had fond memories of the installfest
[15:24] <jedijf> got that wedding thing out of the way, so now we can have real events
[15:24] <lazyPower> apparently you set a pretty high bar for me to meet
[15:24]  * ssweeny doesn't remember doing that much really
[15:25] <lazyPower> i think being present, an excited about the subject matter was a win.
[15:25] <ssweeny> well i certainly did that
[15:26] <lazyPower> I really want to explore the option of doing a virtual meetup via hangouts on air
[15:27] <lazyPower> i think we have an opportunity to grow discoverability and approachability if we pull it off.
[15:29] <lazyPower> and we get cool talking heads in a box to boot if we do physical space meetups in conjunction
[15:35] <ssweeny> would this be targeting locals or more of a general community thing?
[15:46] <lazyPower> I wanted to start by bridging the gap between pit and philly
[15:47] <lazyPower> the LOCO is mostly philly region peoples - and attending any kind of monthly meetup is difficult for me between time and capital constraints - so a virtual meetup would make it available to anyone with internet access and a relatively modern browser
[15:47] <lazyPower> it was part of the campaign i based my ubuntu membership on
[15:48] <ssweeny> nice
[15:48] <lazyPower> https://wiki.ubuntu.com/LazyPower <-- roll that beautiful bean footage
[16:08] <ssweeny> that is one nice wiki page
[16:12] <lazyPower> ssweeny: i've got the developer of the owncloud charm's ear - is the phone team still working on/with the owncloud scope?
[16:13] <ssweeny> lazyPower, there is a community team working on owncloud support in general
[16:14] <lazyPower> Where can I direct him to interface with them?  Thanks for the heads up
[16:16] <ssweeny> sure thing
[17:09] <pleia2> 09:09:21 -ChanServ(ChanServ@services.)- You are not authorized to execute this command.
[17:09] <pleia2> we need freelancer317 :\
[17:09] <pleia2> he's the only one who can add ops, jedijf - care to email him?
[17:21] <waltman> wow, lots of activity today!
[17:27] <lazyPower> waltman: this is only the beginning *queues epic background music*
[17:38] <pleia2> (also, until then, I can change the topic, so lmk)
[20:00] <jedijf> pleia2: will do - email and am radio :)


[01:49] <thumper> babbageclunk: do you have a few minutes for a python question?
[01:55] <thumper> or anyone else really who has done testing recently in pylibjuju
[01:58] <tlm> I did a little bit thumper but hardly an expert
[01:58] <thumper> I'm just having issues with the python path
[01:59] <thumper> it is grabbing a version in .local/lib
[01:59] <thumper> when I set a python path
[01:59] <thumper> it fails on an import for toposort
[01:59] <thumper> and I'm not sure why
[02:15] <tlm> this is what I do
[02:16] <tlm> python3 -m venv .venv; source .venv/bin/activate; python setup.py egg_info && pip install -r juju.egg-info/requires.txt; pip install asynctest ipdb mock pytest pytest-asyncio pytest-xdist Twine git+https://github.com/johnsca/websockets@bug/client-redirects#egg=websockets && pip install urllib3==1.25.7 && pip install pylxd
[02:16] <tlm> harry gave me that when I worked on it. That covers all dependencies from memory
[02:24] <wallyworld> babbageclunk: if you had time before eod, a look at https://github.com/juju/juju/pull/11189 would be gr8
[02:34] <babbageclunk> wallyworld:  looking
[02:36] <tlm> what version of go mock are we suppoed to use wallyworld? See a lot of changes when I generate due to version bump
[02:37] <wallyworld> yeah, that can happen. it's hard because builds use go 1.10, CI uses 1.12 I think. i normally just ignore gomock changes when doing a review
[02:41] <tlm> wallyworld, hpidcock: i did a tidy up for basic structure. Have a look at https://github.com/juju/juju/pull/11190
[02:42] <wallyworld> ok
[02:45] <hpidcock> tlm: might be good if the rbac mapper follows the worker interface
[02:45] <tlm> it's going to be used inside of worker thats why I opted out and stuck to kube convention
[02:45] <tlm> but easy change
[02:46] <tlm> can do
[02:46] <wallyworld> why getRBACLabels2 ?
[02:46] <hpidcock> I dunno, maybe wallyworld has stronger opinions on it
[02:46] <tlm> I need to break out that function off of the struct but haven't got around to it. Just to illustrate
[02:46] <tlm> not staying
[02:46] <wallyworld> ah no worries, ta
[02:47] <wallyworld> yeah, so typically we do prefer workers in juju to encapulate the management of go routines
[02:48] <tlm> np, it's an easy fix. Functionally will still remain the same
[02:49] <wallyworld> all juju go routines/workers are typically started via the dependency engine or as a child worker of another worker, managed by the runner abstraction
[02:49] <wallyworld> yup
[02:54] <wallyworld> tlm: so we could use a watcher abstraction over the informer event stream (like we did in the other pr) and use a standard worker loop to process those watch events
[02:55] <tlm> not really, our current watcher implementations are not adequate for this type of problem
[02:56] <babbageclunk> wallyworld: why have Enqueue and EnqueueV2 on the same API? Shouldn't everything just use EnqueueV2 (if that's what's on the best API)?
[02:56] <wallyworld> babbageclunk: older clients still need enqueue
[02:56] <babbageclunk> Right, but wouldn't they talk to the old facade?
[02:57] <babbageclunk> (that's why we have them)
[02:57] <wallyworld> usually but there's still legacy actions CLI not behind the feature flag that uses enqueue
[02:57] <wallyworld> it's only the CLI behind the feature flag that uses v2
[02:58] <wallyworld> when 2.8 beta1 will have both CLIs
[02:58] <wallyworld> so we need to support both until juju v3
[02:58] <babbageclunk> Oh, so those commands that use the old method will still be available on the next-released juju CLI?
[02:58] <wallyworld> yeah :-(
[02:58] <wallyworld> as we can't change CLI until v3
[02:59] <wallyworld> and new stuff is opt in till then
[02:59] <babbageclunk> still seems like a weird way to do it - we can change the API internally while keeping the cli the same
[03:00] <wallyworld> how? they return different structs
[03:00] <wallyworld> and the new struct has less info
[03:00] <wallyworld> we also have AddMachineV2 (rom memory) for similar reasons
[03:01] <wallyworld> maybe it's gone now
[03:03] <wallyworld> babbageclunk: or maybe i'm on crack and am missing something?
[03:04] <wallyworld> tlm: what calls enqueueServiceAccount ?
[03:05] <babbageclunk> wallyworld: I think really I just don't like that the new method is called EnqueueV2 - it's the one that we're going to be stuck with when the legacy method is removed once the feature flag goes away.
[03:06] <wallyworld> we can rename it then
[03:06] <tlm> the event handlers, I have just fixed that up
[03:06] <tlm> my cleanup had the old code in it
[03:06] <babbageclunk> Might make more sense to rename the old one to LegacyEnqueue and have this one as Enqueue in the most recent facade version.
[03:06] <wallyworld> babbageclunk: i could call it EnqueueOperation
[03:06] <babbageclunk> yup, that would work too
[03:07] <babbageclunk> I'll put that in a comment
[03:07] <wallyworld> ok
[03:11] <wallyworld> tlm: modulo seeing the revised code, i still think we can wrap the informer event handler as a notify watcher, and use a std juju worker to update the uuid->app mapping, but i could be wrong also
[03:13] <tlm> perhaps, I can explain it over HO when you are free if you would like
[03:23] <wallyworld> tlm: coffee time, give me a few minutes
[03:24] <tlm> no rush
[03:36] <wallyworld> tlm: free now?
[03:37] <tlm> roger
[03:54] <wallyworld> thumper: can you remind me - the isResponsible flag - does that ensure we only have one of those workers it wraps per controller?
[03:54] <wallyworld> or babbageclunk?
[04:07] <babbageclunk> wallyworld: ask again?
[04:07] <wallyworld> babbageclunk: ty for review btw :-)
[04:07] <wallyworld> just checking
[04:07] <babbageclunk> hang on, reminding myself...
[04:08] <wallyworld> i think if we pass controller agent tag (or machine tag of controller) as the claimant we just get one of that worker that is wrapped
[04:08] <wallyworld> tjust want to confirm
[04:09] <babbageclunk> yeah, that's right - it tries to claim the lease for that entity and if it fails the flag is false, so any downstream workers won't run
[04:10] <wallyworld> babbageclunk: awsome ty
[04:10] <wallyworld> we want one k8s client cache per controller
[04:10] <wallyworld> the worker maintains it and different model workers use it
[04:11] <wallyworld> the isresponsible worker
[04:11] <babbageclunk> yeah, sounds like the isResponsible decorator is what you want
[04:12] <tlm> thanks, will try that for wiring this up
[04:14] <babbageclunk> wallyworld: oh, hang on - isResponsible is for 1 worker per model across n controllers, the machine-agent-level flag is the ifPrimaryController one
[04:15] <wallyworld> we want one per controller
[04:15] <babbageclunk> but the model level workers might be running in a controller that isn't the primary controller agent, not sure whether that's a problem
[04:15] <wallyworld> i think we can set the claimant flag to the controller agent though right?
[04:16] <wallyworld> i think isresponsible is what we want, can always test to be sure
[04:16] <babbageclunk> jump in a hangout? I think we might be talking at cross-purposes
[04:16] <wallyworld> ok
[07:50] <wallyworld> stickupkid: hey, 2 things, i'd love a review on a totally mechanical PR to move some unused/deprecated code out of the way https://github.com/juju/juju/pull/11191
[07:50] <wallyworld> also, https://bugs.launchpad.net/juju/+bug/1856832
[07:50] <mup> Bug #1856832: neutron-openvswitch charm lxc profile not getting set with correct configuration <juju:Triaged> <https://launchpad.net/bugs/1856832>
[07:51] <wallyworld> i ran a test of a single unit and it worked bu then the reported said it happens when deploying a bundle
[07:51] <wallyworld> so seems like it could be some sort of race
[07:51] <wallyworld> but win o'clock here so ran out of time to dig further
[07:51] <wallyworld> *wine
[07:51] <stickupkid> haha
[07:51] <stickupkid> win sounds better
[07:52] <wallyworld> no, wine :-)
[07:52] <stickupkid> i hate wine
[07:52] <stickupkid> i'll have a look once I'm up and running, taking dogs for a walk first
[07:55] <wallyworld> no worries, i got a dinner guest here so got to go afk
[09:19] <stickupkid> manadart, I'm picking up a bug today, I'll catch up on the openstack cidr issue after that
[09:20] <manadart> stickupkid: Ack. I am working on the consuming side of my last patch. I might look at yours with a mind to testing if I get through it today.
[09:20] <stickupkid> manadart, yeah, go for it
[09:28] <flxfoo> Hi all
[09:29] <stickupkid> flxfoo, hi
[09:29] <flxfoo> I have a little issue with `mysql-shared` on a percona-cluster (x3)... a webserver charm is not doing what it is suppose to do
[09:29] <flxfoo> the status on mysql-shared is joining
[09:30] <flxfoo> the webserver is connectiong to percona charm and send data, but then wait for an answer
[09:30] <flxfoo> not sure where to look at
[09:30] <flxfoo> ideas are welcome
[09:31] <stickupkid> flxfoo, this might help https://discourse.jujucharms.com/t/debugging-charm-hooks/1116
[09:31] <stickupkid> flxfoo, failing that, I would log on to the charm machine/container and ensure it can access the outside
[09:32] <stickupkid> flxfoo, or check if the relation is up correctly
[09:32] <flxfoo> stickupkid: thanks will give it a read thanks
[09:32] <flxfoo> stickupkid: thing is we use the exact same charm on dev platform, which is working fine
[09:32] <flxfoo> on production difference is cluster members is more than 1 :)
[09:33] <flxfoo> and communicate through private network without issue
[09:33] <flxfoo> everybody is happy except the charm relation :)
[09:40] <flxfoo> find that in debug log: host is not in access-network xxxx ignoring
[09:41] <flxfoo> ips are on different subnet
[09:44] <flxfoo> stickupkid: do you know how I would change the interface they would communicate for that relation? (if ever you know)
[09:44] <stickupkid> flxfoo, I don't unfortunately
[09:50] <stickupkid> flxfoo, if you want better exposure maybe drop an new topic on https://discourse.jujucharms.com/
[09:54] <flxfoo> stickupkid: ok thanks
[09:55] <flxfoo> little quick one: how can I see which relations are available in a charm
[09:55] <flxfoo> stickupkid: I think my issue is that the two leaders are not communicating on the same subnet...
[09:56] <stickupkid> flxfoo, juju status --relations
[10:26] <achilleasa> is it possible to access a unit name from its tag?
[10:27] <achilleasa> .Id() seems to apply a transformation
[10:31] <stickupkid> i thought Id didn't do that
[10:40] <achilleasa> stickupkid: for units it replaces last '-' with '/'
[10:40] <achilleasa> no prob; just have to pass the name as an extra arg
[10:51] <nammn_de> manadart: rick_h opened a bug where one should be able to use the spaceID in `show-space` . While at it I wasn't sure whats the best way to solve this from API param sense.
[10:51] <nammn_de> On the cmd part I could decide between sending an int or a tag. On the Apiserver part I could use that information to either search by id or by name. Wdyt?
[10:54] <nammn_de> Or we can just stick with the entity Tag. And in case it does not work out on the apiserver tag, try to search by id
[10:59] <achilleasa> stickupkid: turns out that for the api call I am interested in 'Unit' means 'Tag' :D
[11:03] <stickupkid> why doesn't this create three containers in lxd, it only does one? juju deploy cs:~juju-qa/bionic/lxd-profile-without-devices-5 --to lxd -n 3
[11:12] <stickupkid> this does the same thing... juju add-unit lxd-profile -n 3 --to lxd
[11:12] <stickupkid> annoying
[11:29] <nammn_de> manadart: I thought something along this line https://github.com/juju/juju/pull/11195/files
[11:37] <manadart> nammn_de: A space ID is actually a valid space name, so you can drop the extra DTOs and keep it as `params.Entities`.
[11:38] <nammn_de> manadart: ah, yes. But I would need to parse it on the apiserver to check whether I call byName or byID
[11:39] <manadart> nammn_de: This also means that testing for an integer is not enough. We'll just have to query both ID and name. Unique=return, Multiple=error with instructions to disambiguate, Nothing=not found.
[11:40] <nammn_de> manadart: rgr
[11:45] <achilleasa> looking for someone to pair with me in deciphering the way that errors are handled when flushing the hook ctx
[11:50] <stickupkid> wallyworld, I'm struggling to get a reproducer for 1856832
[13:07] <manadart> stickupkid: https://github.com/juju/juju/pull/11194
[13:07] <rick_h> morning
[13:08] <manadart> Morning rick_h.
[13:09] <stickupkid> manadart, i'll look into this
[13:12] <rick_h> stickupkid:  what about if you did --to lxd,lxd,lxd ?
[13:12] <rick_h> stickupkid:  I think the thing is that it reads the list of --to thinking it'll be like --to 0,1,2
[13:12] <rick_h> so it treats each target as one at a time
[13:12] <stickupkid> rick_h, it may well be, but it's very strange
[13:13] <rick_h> stickupkid:  I understand it is in that case, but -n3 --to=0 you don't want three of them on the same machine as well
[13:13] <stickupkid> rick_h, it not intuitive
[13:13] <rick_h> yea, for the lxd case it's not agree
[14:28] <stickupkid> hml, this is interesting esp. because it's on the openvswitch 3, which is causing the problemshttps://paste.ubuntu.com/p/qhbzKTNNzz/
[15:05] <nammn_de> rick_h: in for a cr on column ordering? https://github.com/juju/juju/pull/11193
[15:05] <rick_h> nammn_de:  rgr, will do
[15:05] <nammn_de> manadart: cr on ID/Name search for show-space? https://github.com/juju/juju/pull/11195
[15:06] <nammn_de> stickupkid: opened the LP bug https://bugs.launchpad.net/juju/+bug/1862376
[15:06] <mup> Bug #1862376: tests: status output branches output -> race condition <juju:New> <https://launchpad.net/bugs/1862376>
[15:30] <stickupkid> nammn_de, nice
[15:36] <hml> stickupkid: looking at the pastebin now.
[15:39] <nammn_de> manadart: I can remember why i didn't export ConstraintsBySpaceName and used tag conversion instead.
[15:39] <nammn_de> Reason was that the  doc `constraintsWithID` is not exported. Should I just export that type instead?
[15:39] <hml> stickupkid: ln 28 looks like a side effect of the neutron-openvswitch unit not coming up correctly with the profile changes
[15:41] <manadart> nammn_de: Let me take a look.
[15:42] <manadart> nammn_de: BTW, can you get a fix up for this? https://pastebin.canonical.com/p/qxsDM3hwZ9/
[15:47] <stickupkid> hml, exactly
[15:47] <stickupkid> i'll report back
[15:48] <hml> stickupkid: there are other errors too in there, not just the 1 unit
[15:49] <hml> stickupkid: is this a MAAS setup?
[15:50] <stickupkid> hml, quick ho?
[15:50] <hml> stickupkid: sure
[16:04] <nammn_de> manadart: will do!
[16:14] <nammn_de> manadart: fixed the test by ensure ordering with sorting. I think that was the problem
[16:15] <nammn_de> Did you take a look regarding constraints thing? Should have applied the rest. Not 100% sure about your last comment though, added a comment.
[16:45] <stickupkid> manadart, what's wrong with #11194 it's not building with github correctly
[16:45] <mup> Bug #11194: auto-fsck after 30 boots can be problematic on a laptop <laptop-mode (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/11194>
[16:46] <stickupkid> bot fail!
[16:47] <manadart> Not sure. Will look Monday.
[16:47] <stickupkid> just close it and reopen the PR


[14:42] <lol768> Hi there, I'm interested as to when https://lists.x.org/archives/xorg-devel/2016-July/050321.html will become available in Ubuntu's X server package?
[14:44] <lol768> Do I need to file a bug report even if upstream have already fixed this?
[14:44] <lol768> VirtualBox is pretty much intermittently unusable with Ubuntu for me
[14:45] <lol768> Or rather to reword: running Ubuntu inside VirtualBox is intermittently problematic for me to the extent that the guest OS becomes unusable
[15:52] <tjaalton> lol768: is it in 1.18.4?
[15:54] <lol768> I'm not entirely sure, I know the patch was accepted but I can't find a trace of any sort of commit in the VCS
[15:55] <tjaalton> then it's not fixed upstream, until applied
[15:56] <lol768> "This has now been fixed in the upstream X server"
[15:56] <lol768> https://www.virtualbox.org/ticket/15511
[15:56] <lol768> https://www.virtualbox.org/ticket/15511#comment:25
[15:57] <tjaalton> yes and is in 1.18.4 so yakkety has it
[15:57] <lol768> Right but that's not released yet
[15:58] <lol768> will it be backported to Xenial?
[16:00] <tjaalton> eventually
[16:00] <tjaalton> there's another sru pending which will be handled first


 @tttomat19, Welcome!
 @wxl23, Yes, broadcom here; ie: BCM43142
 sometimes i have to use nmcli to connect
 https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx
 @wxl23, thanks
 That's only supported by the proprietary driver which you have to explicitly install
 noted
 no worries
 That's true across all of the Ubuntu flavors and derivatives
 Which is to say it's not an LXQt and/or Lubuntu issue
 noted
 Most distros won't ship proprietary software. That said, it's a general Linux issue
 Or rather an issue with Broadcom not generally supporting open source
 @Sam, but i think that im facing the same problem like sam the network applet not quit intuitive because it only said connected
 *quite
 that's why i usually have to use nmcli rather than network applet
 I would expect erratic or incomplete behavior from the chip given the fact that whatever driver you might be using doesn't fully support it.
 What driver are you using?
 checking
 vendor: Broadcom Corporation
 Ok so you are running the right thing if you're on Xenial or later
 So if there is a bug, figure out how to clearly reproduce it, and then file a bug report.
 yes 16.04
 In other words, you should be able to follow the exact same steps on a freshly installed system and see the exact same results
 It also might be wise to try a newer version and see if it has the same problem
 17.10 is a good start?
 I'm sure the applet has been updated and I know the wl driver has been
 Yep
 https://www.youtube.com/watch?v=Vhh_GeBPOhs
 @Dave K, Welcome!
 it's been awhile since I've been actively contributing but hopefully on the "better late than never" side I thought I would try to reconnect and see whether I can be helpful now that things have calmed down in my life
 @drkokandy, Awesome :D