[06:50] <eddyMul> persia: just adding check:: doesn't seem to do the trick. hm...
[06:52] <persia> eddyMul: CDBS only checks for check with makefile.mk.  You might want something different for setup.py.  If it's not obvious, you can always brute-force with build/django:: (or whatever).
[06:54] <eddyMul> persia: I'm trying to sort out the sequence of events...
[06:55] <eddyMul> persia: ideally, the check should be performed... after building, before installing....
[06:55] <eddyMul> persia: (maybe?)
[06:57] <persia> eddyMul: CDBS uses makebuilddir, configure, build, install, binary by defaul, and processes overrides after the internal rules, so if you have a build:: override, it should run between build and install, which is a standard place to test.  For some tests, between install and binary may be better (it depends on the tests).
[06:59] <eddyMul> persia: thanx. I'll try with build/django::   (now the buildcore.mk target "depgraph" makes more sense...)
[07:01] <Hobbsee> persia: did you know if it was for *all* metapackages, or just -desktops ?
[07:01] <eddyMul> persia: the target is executed. Now, I'll work on having the tests run properly. I plan to steal code from Gentoo's ebuild (is that "lega"?)
[07:01] <eddyMul> s/lega/legal/
[07:01] <persia> Hobbsee: I didn't check.  Do you want me to look at the code again?
[07:02] <Hobbsee> persia: if it wont take you long, looking would be good
[07:02] <Hobbsee> persia: i may well have screwed up this code, but it is actually coming out correctly, i think
[07:02] <persia> eddyMul: Depends on the license (and I know nothing about Gentoo licensing).  Also, you may get more informative responses (read: not limited by my knowledge) by asking the channel generally, rather than just me.
[07:02] <persia> Hobbsee: redownloading the code now...
[07:04] <persia> Hobbsee: The only reference seems to be "debian/apt.conf.autoremove:  Install-Recommends-Section "metapackages";" (which I think ends up in /etc/apt.conf.d/).  I'm interpreting this as looking at the section only, and ignoring the name of the package.
[07:04] <Hobbsee> fair enough
[07:06] <eddyMul> persia: the Gentoo ebuild is GPL v2
[07:07] <persia> eddyMul: OK.  What license covers each of python-django and the Ubuntu packaging?
[07:07] <eddyMul> where can I find the Ubuntu package's license?
[07:07] <persia> eddyMul: It should be listed in debian/copyright
[07:08] <eddyMul> no "generic" license detected
[07:08] <eddyMul> :(
[07:09] <eddyMul> persia: Django itself is BSD.
[07:10] <persia> eddyMul: I wouldn't recommend using the ebuild packaging, unless you have a really good reason, as GPLv2+BSD=GPLv2, which might annoy someone wanting to hack on Django who uses Ubuntu.
[07:11] <eddyMul> persia: interesting...
[07:11] <eddyMul> but Gentoo packages Django (a BSD app) using a GPLv2 ebuild
[07:11] <eddyMul> what are debian/rules licensed under?
[07:11] <persia> eddyMul: Right.  So Gentoo distributed Django is GPKv2
[07:12] <persia> eddyMul: Depends on the package - see debian/copyright.
[07:12] <eddyMul> i c
[07:12] <eddyMul> so, Debian's stance is: the debian/rules license follows the package's license.
[07:12] <eddyMul> ?
[07:12] <man-di> persia: your interpretation is highly debatable
[07:13] <persia> eddyMul: Unless otherwise specified in debian/copyright
[07:13] <man-di> when the build system is GPLv2 that doesnt make the software GPL
[07:13] <man-di> persia: as the build-system is not linked to the software
[07:14] <man-di> persia: your interpretation would imply that everything you build with GNU make must be GPL
[07:14] <eddyMul> man-di, persia: my point is asking the question is because I want to steal Gentoo's code that runs Django's test suite.
[07:14] <persia> man-di: A couple days ago, discussion here (not an authoritative place), indicated that packaging under one license combined with content under another license as part of the build process generated a combined work, licensed as required.
[07:14] <minghua> man-di: bug eddyMul is talking about stealing patches, so persia is in some part correct
[07:14] <persia> man-di: No - it's the the license of the tools used, but the license of the wrapper scripts and extra content.
[07:14] <man-di> persia: the FSF is not of this opinion
[07:15] <persia> man-di: Which opinion?  Now I'm confused.
[07:15] <man-di> persia: extra content is another issue, but not the normal packaging framework for a package
[07:15] <eddyMul> if it helps, the code I'm planning to steal is the src_test function in http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/django/django-0.96.ebuild?rev=1.3&view=markup
[07:16] <man-di> minghua: not for the software, for the build system
[07:17] <man-di> eddyMul: I wouldnt say this function alone is copyrightable
[07:17] <persia> man-di: OK.  Taking the specific example of a debian-format package.  I have a single binary object, containing several items: some control data (packaging license), some upstream data (upstream license), and some binaries that may have been built including patches, or other modifications as a result of processing debian/rules, for which I believe the license of a combined work applies.
[07:17] <minghua> man-di: Okay, I was wrong.  You guys continue discussing if GPL build-system + BSD code = GPL binary package
[07:18] <man-di> persia: for patches you are rigth, but nor for debian/control or simple debian/rules
[07:19] <eddyMul> I'm sorry if my questions leads to a messy discussion...  :(
[07:19] <persia> man-di: Hmm.  OK.  I can see that.  I'm not sure of the definition of a patch, and my opinion is probably wider than yours, but I can agree in the simple case where it just works.
[07:19] <man-di> eddyMul: legal issues are hard,
[07:20] <persia> eddyMul: No worries.  It's good to ask.
[07:20] <man-di> eddyMul: and all should be aware of them
[07:20] <man-di> eddyMul: IMO it would be okay to just use that function
[07:20] <man-di> eddyMul: nobody will sue you for it
[07:20] <persia> eddyMul: I'm also agreeing with man-di that src_test() is probably too small to copyright, especially as it's just a wrapper for upstream code, and trivial to duplicate.
[07:20] <eddyMul> man-di: :)
[07:21] <eddyMul> persia, man-di: got it. I will Debian-ize it, then... :)
[07:21] <eddyMul> persia, man-di: As you probably figured out, I switched from Gentoo to Ubuntu    :)
[07:22] <man-di> eddyMul: you came to the light ;-)
[07:31] <eddyMul> can I put bash here documents inside a makefile?
[07:31] <eddyMul> currently, make is not liking it... :(
[07:33] <man-di> eddyMul: why not put setting.py directly into the package?
[07:33] <persia> eddyMul: Probably easier to create a debian/tests.py (or whatever) (techinically yes, but the syntax is immensely ugly).
[07:35] <eddyMul> man-di, persia: I'll try that. BTW, I assume the "current directory" is the parent directory of debian/. Am I right?
[07:35] <sacater> sorry to bother, does anyone know what the program is called that appears as "Disk Usage Analyzer"?
[07:35] <eddyMul> sacater: baobab?
[07:35] <man-di> Adri2000: yes
[07:35] <persia> sacater: grep in /usr/share/applications is a handy way to get the answer as well.
[07:35] <eddyMul> sacater: I think it's in gnome-system-utils (or -tools, or something like that...)
[07:43] <sacater> thanks
[07:48] <eddyMul> persia, man-di: it appears as if the target build/python-django is being run twice. hm....
[07:54] <eddyMul> if a package failed its testsuite, should I stop the build process? (currently, it's continuing the build)
[07:55] <minghua> my personal opinion is it should
[07:56] <eddyMul> minghua: should: abort or continue?
[07:56] <eddyMul> minghua: I noticed that python2.5 continues despite errors (but someone turned of the check, unless it's run by buildbot)
[07:57] <minghua> shoud abort
[07:57] <eddyMul> minghua: how can I abort a makefile. Do I "exit"?
[07:57] <persia> exit 1
[07:58] <minghua> normally, any command that returns non-zero should abort the build process
[07:59] <eddyMul> minghua, persia: very cool. I didn't know that. Thanx.
[08:00] <man-di> eddyMul: I would say it should but I maintain some packages where the testsuites fail on some archs, its sometimes really horror to have it enabled
[08:00] <eddyMul> man-di: I understand.
[08:02] <minghua> I would prefer "run-testsuite || true" if possible in that case, and ship the test results in binary package.  But that's just me.
[08:03] <StevenK> Personally, I run Linda's testsuite at build time. But it's arch: all, and uses pure-python modules.
[08:05] <eddyMul> minghua: I don't think I understand what you mean by "ship the test results in binary". Can you elaborate more on that?
[08:06] <minghua> eddyMul: The testsuite usually has a output about which tests passed and which failed.  Put this result in the binary package(s) you build, so that users can know which tests failed.
[08:07] <eddyMul> minghua: I c. And thats goes into.... /usr/share/doc/package?
[08:07] <minghua> eddyMul: yes
[08:08] <eddyMul> minghua: I c. Thanx for clarifying that.
[08:50] <porthose> Hey MOTU's:  would you please review ampache http://revu.tauware.de/details.py?upid=5830, I have made some major changes to it and would appreciate comments thank you
[08:51] <minghua> porthose: Did you see the mail Jordan sent to mailing list?
[08:51] <porthose> yes I did
[08:52] <porthose> that is why I just want comment
[08:53] <porthose> just wanting to see if I screwed anything up with the changes I made.
[08:59] <persia> porthose: You'll probably do better getting comments from Debian mentors than from Ubuntu MOTUs for a Debian-targeted package, as there are subtle differences of which most of us are now entirely aware.  Aside from that, consider using ampache.dirs and ampache.install to take advantage of dh_install (instead of using install -m).  Wildcards are accepted.
[08:59] <porthose> cool, thank you
[09:01] <persia> Umm..  Rather than "now entirely aware", I intended to say "not entirely aware".  Sorry.
[09:10] <minghua> BTW I remember the "using dh_install" point is raised on debian-mentors list already.
[09:12] <porthose> good night all
[10:43] <dholbach> good morning
[10:46] <BugMaN> hi dholbach!
[10:46] <dholbach> hi BugMaN
[10:49] <jussi01> morning all!
[10:49] <dholbach> hi jussi01
[10:49] <jussi01> hello dholbach
[10:55] <Hobbsee> morning dholbach!
[10:56] <dholbach> hiya Hobbsee
[11:17] <Fujitsu> Well, Dell is even less reliable that I thought.
[11:17] <Fujitsu> Apparently, 10 to 15 working days equates to 2 working days.
[11:17] <Fujitsu> They are the masters of accurate estimation.
[11:17] <Hobbsee> heh
[11:18] <persia> Fujitsu: That's called "Setting appropriate expectations", and is encouraged in certain communities.
[11:19] <jussi01> lol
[11:19] <Fujitsu> persia: You'd think they could estimate a little better than that, though.
[11:19] <persia> Fujitsu: Be glad.  I've actually seen date-sorted outboxes to ensure that sign-off always takes the three days mandated by the compliance documentation (wouldn't want to send things out early, you know).
[11:19] <jussi01> Fujitsu: its _up to_ 10-15 working days...
[11:20] <Fujitsu> jussi01: I didn't see an `up to' anywhere... and shouldn't that be up to 15 days?
[11:20] <Fujitsu> Aha.
[11:20] <jussi01> well thats what we were taught to say... anyway...
[11:21] <Fujitsu> persia: How... odd.
[11:22] <persia> Fujitsu: Yes.  The original idea was to allow for things not to be signed on weekends, or when people were sick, etc.  The idea aged badly, in the interests of specific job security.
[11:27] <jerome_> persia : hello
[11:28] <persia> jerome_: Hi.  I was just looking at bug 78367 and thinking of you.
[11:28] <jerome_> persia : for the fakesync in bug 122839 what debdiff should i join ?
[11:28] <ubotu> Launchpad bug 78367 in mosml "extend mosml package to include optional libraries (patch included)" [Wishlist,New]  https://launchpad.net/bugs/78367
[11:28] <ubotu> Launchpad bug 122839 in sjfonts "Please sync sjfonts (universe) from Debian unstable (main)" [Wishlist,Invalid]  https://launchpad.net/bugs/122839
[11:28] <jerome_> persia : did something wrong ?
[11:29] <persia> jerome_: For 122839, we need a debdiff against the current Ubuntu packaging, including all of the Debian changes, and a new changelog entry "fakesync from Debian...", with details.
[11:29] <jerome_> persia : ok I'm on it
[11:30] <jerome_> is there a howto for fakesync ?
[11:30] <persia> jerome_: 78367 needs a real revision candidate, with changelog updates, etc.  Also, it needs digging to make sure all the library dependencies are correct, etc.  I'm not at all familiar with Moscow ML, but given your comment, I hoped you might be.
[11:30] <jerome_> persia : not at all, just tested the patch :)
[11:30] <persia> jerome_: Oh well.  Thanks anyway.
[11:31] <persia> jerome_: I can't find a howto on fakesync.  There was an informal lesson on IRC a month or so ago: let me find a log.
[11:32] <jerome_> persia : thx, it's just to know exactly how to report a good fakesync request
[11:35] <persia> jerome_: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-05-25.html, starting from about 04:08.  If you want to pull from this and drop some hints in https://wiki.ubuntu.com/MOTU/Packages/Merging, it would be greatly appreciated.
[11:36] <persia> jerome_: Note that that one didn't turn out to actually be a fakesync, but it still walks though the process fairly well.
[11:36] <jerome_> persia : ok
[11:37] <jerome_> persia this debdiff is ok ? http://paste.stgraber.org/1955
[11:39] <persia> jerome_: Almost.  You'll want to include the changelogs from both 2.0.2-0ubuntu1 and 2.0.2-1, followed by 2.02-1ubuntu1 with your changes (or just a note that it's a fakesync).
[11:40] <jerome_> persia : in the debdiff ?
[11:41] <persia> jerome_: In your local 2.0.2-1ubuntu1 revision candidate, from which you will generate the debdiff.
[11:41] <jerome_> persia : understood :)
[11:42] <jerome_> persia : and it should be named -1build1 as it's a fakesync no ?
[11:42] <StevenK> It's a fakesync because the orig's differ?
[11:43] <persia> jerome_: Yes.  My apologies.  You want 2.0.2-1build1.
[11:43] <persia> StevenK: Yes.
[11:43] <jerome_> StevenK : yep
[11:43] <StevenK> Then I use -1ubuntu1, and mention that it's a manual merge
[11:44] <jerome_> StevenK : you put this in the changelog ?
[11:44] <persia> StevenK: That's at variance with the only doc I can find (IRC session).  Also, "manual merge" vs. "fakesync".  Is there something I'm missing?
[11:44] <minghua> persia: I think -1build1 is wrong
[11:45] <minghua> persia: because next time -2 will be autosynced and fail
[11:45] <persia> minghua: I'm also surprised: but I was taking http://people.ubuntu.com/~fabbione/irclogs/ubuntu-motu-2007-05-25.html "04:22crimsunnext, we add a new Ubuntu changelog entry. Because it's a fakesync, the version will use build1, not ubuntu1, as a suffix." as my guide.
[11:46] <minghua> persia: I believe there are more than one reason for fakesync
[11:46] <minghua> but I didn't read the log
[11:46] <persia> minghua: Also, I've never seen an autosync for a XbuildY version.
[11:46] <minghua> I think I have
[11:47] <minghua> (but can't think of an example from top of my head)
[11:47] <jerome_> so how should i process ?
[11:48] <persia> minghua: I can't think of a positive example (as I always assume that there are sync bugs I don't see), but my negative example is that at the beginning of a dev cycle, when debian import is running unrestricted, the XbuildY revisions show up in the merge queue, and don't go away until someone prods them.
[11:48] <afflux> can some motu please review this? http://revu.tauware.de/details.py?upid=5843
[11:52] <DarkSun88> Hiall
[11:54] <minghua> persia: Okay.  Since you are the mentor in this case, it's your word.  And crimsun is seldom wrong.
[11:55] <jerome_> persia : so what should i do ?
[11:57] <persia> jerome_: I'm not entirely comfortable giving official advice without further discussion, as I've found that StevenK is generally correct about most things.  On the other hand, I agree with minghua that crimsun is seldom wrong.  If I were doing it, I'd have used 1ubuntu1 by default, but that's not necessarily correct.
[11:58] <jerome_> persia : ok i'll do it with -1ubuntu1
[11:58] <minghua> the thing is, as long as you keep a close watch on the package, -1build1 or -1ubuntu1 won't make much difference
[11:59] <StevenK> Most things. Gee, thanks. :-P
[12:00] <StevenK> Heh
[12:00] <minghua> as a linda user, I would hope the author is generally correct about most things, too :-P
[12:00] <jussi01> lol
[12:01] <StevenK> No, it's all lies!
[12:01] <Hobbsee> lies and propoganda!
[12:01] <StevenK> With a few statistics thrown in. :-P
[12:02] <jerome_> persia : should i put in changelog for 1ubuntu1 that orig tarball changed ?
[12:05] <persia> jerome_: I don't think you need that.  I'm looking for a good fakesync example now.
[12:06] <jerome_> persia: thx
[12:09] <persia> jerome_: ffmpeg (3:0.cvs20070307-4ubuntu1) is one example.  There are surely others, but most are quickly subsumed by new upstream revisions.
[12:10] <persia> (I'm not sure it's a great example - might have been a merge)
[12:10] <jerome_> persia : ok thank you, got to go to have lunch, I will take care of that later.
[12:11] <persia> jerome_: x264 (1:0.svn20070309-4ubuntu1) is a better example.
[12:18] <minghua> persia: I don't know details, but my Debian apt-listchanges generate mails in plain text.
[12:19] <persia> minghua: That's what I expected it to do, but that's not what is in my mailspool.  It may be because I use a UTF8 locale, and so mailx forces the encoding so as to fit through 7bit gateways.
[12:21] <persia> afflux: 5843 commented
[12:21] <minghua> persia: Even in my spool directory it's plain text, and I use en_US.UTF-8.  Perhaps an exim4-vs-postfix thing.
[12:21] <persia> minghua: quite possibly.  In any case, grep isn't as useful as I'd like (for me).
[12:21] <minghua> Hmm
[12:22] <minghua> persia: it's Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit though...
[12:23] <minghua> Now I think I know why some non-ascii characters are messed up in apt-listchanges mails
[12:24] <persia> minghua: Hmm..  I'm getting Content-Type: text/plain; charset="utf-8" and Content-Transfer-Encoding: base64.  I'm suspecting differences in /usr/lib/sendmail implementations now: it appears to be the result of differences in handling text/plain for 8-bit locales.
[12:25] <minghua> persia: In case you file a bug, let me know. :-)
[12:27] <persia> minghua: For me, it's user error (I shouldn't try to search a mailspool with grep - that's what mail readers are designed for).  For you, I think it's a bug with exim4.  Try postfix locally: if you get clean non-ascii characters in your changelogs (but it's all base64), file a bug.
[12:27] <minghua> persia: Makes sense, will do.
[12:41] <afflux> persia: thanks for your comment. You mentioned a "debian/README.Debian-source"... should this really be called README.Debian-source or rather README.Debian?
[12:43] <persia> afflux: README.Debian-source.  README.Debian is installed for end-users (as /usr/share/doc/foo/README.Debian.gz).  README.Debian-source is only in the source package, and contains notes of interest to developers, but not to users (like the answer to the question "How was this orig.tar.gz generated?" or "Why does the packaging use the "experimental" branch in SVN, rather than the "stable" branch for the snapshot?", etc.)
[12:43] <afflux> ah, right. thanks ;)
[12:50] <afflux> persia: updated: http://revu.tauware.de/details.py?upid=5844
[12:52] <persia> afflux: Advocated.  Nice job.]
[12:52] <afflux> thank you :)
[12:53] <persia> As it's REVU day (for much of the world anyway), someone else should take a look at it as well.
[12:58] <minghua> Hmm, so we have a 1.3K .orig.tar.gz and 3K .diff.gz, huh?
[12:58] <Hobbsee> hehe
[12:58] <gnomefreak> is DaD the list of merges done already?
[12:58] <Hobbsee> impressive
[12:58] <persia> minghua: Take a look at the upstream.  It's an interesting release paradigm.
[12:58] <Hobbsee> gnomefreak: they're the outstanding ones
[12:58] <gnomefreak> hmmmmmm
[12:59] <gnomefreak> why is mine outstanding (looks deeper
[01:03] <jmg> heh
[01:04] <jmg> dough
[01:04] <minghua> persia, afflux: A comment: in debian/README.Debian-source, "The source package contains a patch...".  I think the patch is in .diff.gz?
[01:04] <persia> minghua: Good catch.
[01:05] <minghua> persia, afflux: That's a rather confusing statement to me.
[01:05] <minghua> I know technically, both the .orig.tar.gz and .diff.gz belong to the source package, but still.
[01:05] <minghua> Especially the previous paragraph is talking about .orig.tar.gz.
[01:05] <gnomefreak> DaD is lying to me :(
[01:07] <gnomefreak> where does DaD get the newer version from?
[01:07] <Adri2000> gnomefreak: what's the problem?
[01:08] <minghua> persia: And since I am commenting, I don't see the point of having Build-Depends-Indep.
[01:08] <gnomefreak> Adri2000: DaD is saying that a new version of nspluginwrapper is out and ftp.debian.org doesnt list it neither does anywhere i can find
[01:09] <Adri2000> gnomefreak: DaD is currently using ftp.fr.debian.org. I think the ftp.debian.org mirror is having some problems.
[01:09] <gnomefreak> Adri2000: ah ok ty
[01:09] <persia> minghua: It's pure python, so it's architecture all, so build-dependencies are supposed to be in build-dep-indep.
[01:10] <minghua> persia: I know, but your are never going to build arch-dependent packages anyway, so why the differentiation
[01:10] <gnomefreak> Adri2000: ther eit is
[01:10] <gnomefreak> Adri2000: thanks
[01:10] <minghua> persia, afflux: Also, if you want to call gksudo in the .desktop file, you'd better depend on it (or at least recommend).
[01:10] <persia> minghua: I have no idea, but lintian complains otherwise.  Also, you should probably bug afflux about this: it's new to me.
[01:11] <minghua> persia: That's all right, I am not that curious anyway.
[01:12] <minghua> persia: For things I am rather sure, I am also pinging afflux.
[01:13] <persia> minghua: OK.  No problem.  It just confused me.
[01:14] <persia> Adri2000: Could you add a note to DaD indicating the alternate mirror?  Latency from here to ftp.fr.debian.org is horrid, but otherwise I'm just annoyed.
[01:22] <jerome_> persia: this is the debdiff between the -1ubuntu1 and the debian one, is it ok now ?
[01:22] <persia> jerome_: Um.  Define "this".
[01:23] <jerome_> persia: true :)
[01:23] <jerome_> http://paste.stgraber.org/1963
[01:23] <jerome_> that's better now :)
[01:26] <persia> jerome_: 1) because this requires the Ubuntu orig.tar.gz, you need to debdiff against Ubuntu (as opposed to a merge, where you debdiff against Debian).  2) I'm really not sure about the maintainer mangling.  If you keep it, it's more of a merge (which isn't necessarily bad) than a sync.  Otherwise, I'd expect something more like the x264 1:0.svn20070309-4ubuntu1 changelog.
[01:27] <jerome_> persia : I will correct this
[01:27] <mruiz> hi all
[01:29] <persia> Does anyone else have an opinion on maintainer mangling for fakesyncs?  Does the fact that we now manually mangle source maintainers render the concept of fakesync obsolete?
[01:29] <mruiz> If my upstream version is a file with extension "tar.bz2" or "tgz"... What I have to do?
[01:30] <jerome_> mruiz :
[01:30] <jerome_> bunzip2 foo-x.y.z.tar.bz2
[01:30] <jerome_> gzip -9 foo-x.y.z.tar
[01:30] <StevenK> mruiz: tgz is the same as tar.gz
[01:30] <persia> mruiz: For tgz, you just rename it.  For tar.bz2, you need to reprocess it.  See https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball for more information on the recommended procedures for reprocessing.
[01:31] <jerome_> then rename it
[01:31] <mruiz> thanks guys
[01:33] <minghua> persia: I am not aware of any?
[01:35] <jerome_> persia : so I don't put the maintainer change in changelog ?
[01:35] <persia> minghua: dpkg > 1.10.24 and devscripts > 2.9 handle tar.bz2 just fine.  Other things don't.
[01:35] <gnomefreak> if debian used our change to a package and added some more its a simple take debians and add changelog entry and build?
[01:36] <minghua> persia: Oh.  I never tried.
[01:36] <persia> jerome_: If you put in the change, it's a merge (and gets processed like a merge, except that you want to diff against Ubuntu, because you will use the Ubuntu orig.tar.gz).  If you don't put in the change, it's a fakesync.  I'm not sure which is correct.
[01:37] <jerome_> persia : but in both cases I have to put ubuntu-motus as maintainers no ?
[01:37] <persia> jerome_: No.  In the former case, you change the maintainer.  In the latter case, the buildd changes the maintainer.
[01:38] <jerome_> persia : ok
[01:38] <jerome_> persia : let's to do it totally as a fakesync then
[01:44] <mruiz> persia: What is the idea to create a symbolic link between foo.tar.gz and foo.orig.tar.gz ?
[01:46] <persia> mruiz: I suppose mv would work just as well, actually.  There just needs to be a foo.orig.tar.gz in that directory.
[01:46] <mruiz> :-)
[01:48] <persia> mruiz: Looking at the page, you could even just redirect into orig.tar.gz, for a shorter debian/rules.  Also, don't forget about debian/README.Debian-source.
[01:49] <DktrKranz> when have some time to spend, could you please have a look at http://revu.tauware.de/details.py?upid=5757 ? thank you.
[01:49] <afflux> minghua, persia: so I should remove the paragraph from the README.Debian-source that mentiones the patch and add gksudo as Depends?
[01:49] <jerome_> persia : this one should be better : http://paste.stgraber.org/1965
[01:50] <Takesinn> Ey
[01:50] <Takesinn> Is someone working on Enemy Territory?
[01:51] <afflux> minghua, persia: Or rather change the paragraph from "The source package contains a patch" to "I added a patch"?
[01:51] <persia> jerome_: Regarding the format, that looks fine to me.  If you're confident, push it back into the queue (remember to retitle the bug, and set the status to something other than "Invalid".
[01:51] <mruiz> persia: about the names... my upstream filename is Foo-XX-src.bz2 and the directory created is Foo-XX, but the last version is foo-xx...
[01:52] <jerome_> persia : ok thx
[01:52] <jerome_> go to go now
[01:52] <jerome_> coming back soon
[01:52] <minghua> afflux: "I added a patch" would be fine
[01:53] <persia> mruiz: In general, asking the channel is better than asking a person, as you'll get a wider response.  Specifically, I don't understand what you are asking.
[01:54] <mruiz> thanks persia
[01:56] <mruiz> in my case, the last version of the package has a directory called "foo-xx". The new version is "Foo-xx". Any problem?
[01:58] <broonie> dpkg-source will smash the directory name in the .orig.tar.gz anyway.
[01:58] <persia> mruiz: I think dpkg might be smart enough to process that anyway, but I'm not sure.  Give it a try.
[01:58] <minghua> what's the name of the default ubuntu package manager? update-manager?  adept for kubuntu, right?
[01:59] <persia> minghua: gnome-app-install and adept-installer
[02:00] <minghua> persia: do you have to know if they keep logs and if yes, where the log is?
[02:00] <StevenK> dpkg keeps logs.
[02:01] <persia> minghua: I don't know, but upon further review, update-manager and adept-manager seem to also be part of the default solution.
[02:01] <minghua> okay, I'm dealing with bug 122863 now
[02:01] <ubotu> Launchpad bug 122863 in texlive-bin "package texlive-base-bin 2007-11 failed to install/upgrade: post-installation script spawns thousands of processes" [Undecided,New]  https://launchpad.net/bugs/122863
[02:02] <minghua> I doubt the reporter still have the dpkg log, even if he does, it's probably rather difficult to figure out the package versions
[02:05] <afflux> minghua, persia: okay, updated: http://revu.tauware.de/details.py?upid=5845
[02:06] <minghua> persia: Thanks BTW :-)
[02:06] <persia> afflux: Thanks for the quick turnaround.
[02:10] <minghua> persia, afflux: gksudo is in the gksu package, not gksudo package (which doesn't exist)
[02:10] <minghua> (at least that's the case in Debian)
[02:10] <afflux> gaaaah
[02:11] <minghua> afflux: and as you need to reupload anyway -- don't use "-rm debian/grub-choose-default.8", use rm -f instead.
[02:12] <Hobbsee> persia: you'd better make sure you're checking licence stuff.
[02:12] <Hobbsee> persia: otherwise Mithrandir might eat you.
[02:12] <jerome_> persia : bug 122839, does it look better now ?
[02:12] <ubotu> Launchpad bug 122839 in sjfonts "Please fakesync sjfonts (universe) from Debian unstable (main)" [Wishlist,New]  https://launchpad.net/bugs/122839
[02:12] <persia> Hobbsee: That's my problem.  When the license is clean, I get overexcited.
[02:12] <Hobbsee> heh
[02:13] <minghua> Hmm, Hobbsee has a point
[02:13] <afflux> uploaded: http://revu.tauware.de/details.py?upid=5846
[02:13] <minghua> persia, afflux: Upstream source says GPL v2.  debian/copyright says GPL v2 or later.
[02:14] <minghua> persia: sorry :-(
[02:14] <Hobbsee> persia: it's always a good day for REVU.  for someone other than Hobbsee to review.
[02:15] <persia> minghua: No, it's good.  If I'm not checking carefully enough today, I need to find something more broken to comment about (or contribute in a different way).  Uploading broken things just means more work for archive admins.
[02:15] <Hobbsee> hi white!
[02:15] <persia> Hobbsee: but today is REVU Day.  We decided that in the meeting.  Don't you remember?
[02:15] <white> long time no see
[02:15] <StevenK> Hey white!
[02:15] <white> . o O(actually never, but ...)
[02:15] <white> hi :)
[02:16] <Hobbsee> persia: vaguely.  i cant keep track fo days
[02:16] <Hobbsee> white: heh.  you should come to a conference that we're at, then.
[02:16] <white> which one?
[02:16] <StevenK> According to Hobbsee, days are things that happen to other people.
[02:16] <white> i will come back to melbourne first :)
[02:17] <Hobbsee> white: whichever :)
[02:17] <white> my horror flight trip leaves duesseldorf on sunday morning
[02:17] <white> Hobbsee: come to debconf
[02:17] <white> or is there any fance ubuntu conference in australia?
[02:17] <Hobbsee> white: there's LCA eventually.  dont think there's anything in au, ubuntu-wise though
[02:17] <Hobbsee> debconf is over, isnt it?
[02:18] <StevenK> Debconf finished about a week ago
[02:18] <white> i could talk about "sponsoring for debian aka poking StevenK " :)
[02:18] <white> but next years debconf is coming :)
[02:18] <StevenK> And I could talk about "Killing rogue DDs for fun and profit."
 :-P
[02:20] <man-di> white: not with a 13 days old child at home
[02:20] <man-di> StevenK: sear is missing but the rest is up
[02:20] <white> male or female?
[02:20] <StevenK> man-di: Nice!
[02:20] <man-di> white: male
[02:21] <white> hmm then give him a football and let him run around the house ten times
[02:21] <man-di> StevenK: eris is caught in debian NEW queue, that is one reason why I wait with sear
[02:21] <StevenK> man-di: Ah ha.
[02:21] <StevenK> cyphesis-cpp is all okay?
[02:21] <man-di> white: hehehe. I wonder if you could walk when 13 days old
[02:22] <white> oh, i read 13 years, sorry :)
[02:22] <StevenK> I seriously doubt the tyke can hold his head up, let alone his whole body. :-P
[02:22] <white> well then the best is to wait until he is 1,5. Then it is probably getting better :)
[02:22] <man-di> StevenK: should be, but I dont fixed the postgres issue yet
[02:22] <white> ah sigfood :)
[02:23] <StevenK> man-di: Is it worth merging/syncing cyphesis-cpp?
[02:23] <man-di> StevenK: its 4 upstream versions newer, so its worht to merge it
[02:24] <StevenK> man-di: Okay, adding that onto my list after curl. :-)
[02:24] <man-di> StevenK: cool, thanks for the heads up and solving the ubuntu side of issues
[02:25] <StevenK> I'm always happy to give MOTUs and myself less work in future. :-)
[02:26] <gnomefreak> is there a reason why dad lists a merge and merges.ubuntu.com doesnt?
[02:26] <StevenK> MoM has a blacklist, and DaD doesn't.
[02:27] <gnomefreak> blacklist?
[02:27] <man-di> StevenK: I'm no MOTU nor a MOTU Hopeful :-)
[02:29] <persia> man-di: No, but you're a valuable contributor to MOTU activities :)
[02:30] <man-di> persia: when you say so, I try my best
[02:30] <persia> gnomefreak: Some things shouldn't be merged or synced, even when it looks like they should.
[02:30] <man-di> persia: Thanks for the compliment
[02:30] <gnomefreak> persia: ones that shouldnt be merged would be on m.u.c?
[02:30] <gnomefreak> wouldnt*
[02:31] <persia> gnomefreak: Right.  Anything on the blacklist doesn't appear.
[02:31] <gnomefreak> ah ok
[02:32] <Adri2000> DaD lists 89 merges while MoM lists 37, so it's more than just a blacklist. perhaps MoM uses the broken debian mirror?
[02:33] <persia> Adri2000: likely (as it is the official, authoritative mirror).
[02:34] <man-di> persia: if it uses ftp.debian.org, it was outofdate lately for some time (and its not the authoritative mirror)
[02:34] <persia> man-di: No?  I thought ftp-master was restricted, and ftp.d.o advertised as authoritative.
[02:34] <persia> (at least p.qa.d.o depends on it)
[02:35] <minghua> I don't think ftp.d.o is authoritative, it doesn't even have all arches
[02:38] <minghua> well, probably I was thinking about http://www.debian.org/mirror/list-full
[02:38] <afflux> minghua, persia: anything else left beside the copyright issue for grub-choose-default? ;)
[02:38] <minghua> there, under ftp.debian.org: "Comment: This is -NOT- the primary server, it is as good as all other Push-Primary mirrors!"
[02:39] <persia> afflux: Two copyright issues: 1) no COPYING in orig.tar.gz, and 2) GPLv2 vs. GPLv2 or later in debian/copyright.  Plus, you might have issues due to the truncated header in the source file.
[02:40] <minghua> afflux: I've mentioned dependency on gksudo and "-rm" in debian/rules
[02:40] <afflux> minghua: yes, this is fixed with 5846
[02:41] <afflux> persia: well, the upstream doesn't provide any COPYING file. What to do with that?
[02:41] <persia> minghua: Thanks.  I've been using the wrong mirror :)
[02:41] <persia> afflux: Talk with upstream.  You may need to insert it (but I don't know if that's allowed).  tar.gz is good.
[02:42] <minghua> afflux: Nothing from me for now then.  I'm going offline soon, ping me or send an email<EMAIL_ADDRESS>if you still need an advocate later.
[02:42] <afflux> thanks minghua
[02:44] <man-di> persia: ftp-master is authoritive and restricted
[02:44] <persia> man-di: Right.  It's the concept of Push-Primary that I was missing.
[02:45] <man-di> persia: all other just more or less uptodate mirrors
[02:45] <man-di> persia: ah
[02:46] <persia> man-di: I was previously under the impression that ftp.d.o was Push-Primary, and that everything else was Push-Secondary.  I've since been disabused.
[02:46] <persia> (or leaf, but these have always been more obvious)
[02:48] <xxxxx1> morrrning all :)
[02:49] <minghua> Hmm, I learned a new word "disabuse" :-)
[02:50] <persia> minghua: It's not as popular as it might be, but handy.
[02:51] <persia> Hobbsee: Yes, but you don't usually get to perform the first, and the second is just contrary
[02:51] <Hobbsee> heh
[02:51] <Hobbsee> "usually"
[02:51] <Hobbsee> now that all depends
[02:52] <Hobbsee> now if i had a window near work...
[02:52] <StevenK> antidisestablishmentarianism is only used by people wanting to show off. :-P
[02:52] <Fujitsu> StevenK: Oh, you don't regularly use it in sentences?
[02:52] <StevenK> persia: A friend of mine replaced a server at his place of work and called it "defenestrated".
[02:52] <Hobbsee> perhaps that's what i should name my other machine, instead of OnFire
[02:52] <StevenK> Heh.
[02:53] <StevenK> The old install on that hardware was NT 4, hence the name. :-P
[02:53] <persia> StevenK: Nah - when you defenestrate a server, people should know for quite a ways about.
[02:53] <persia> Ahhh....
[02:53] <StevenK> Fujitsu: No, and I can't see you doing it, either.
[02:54] <NeilW> I've uploaded 'vim-rails' to REVU. Comments appreciated. Be gentle though - it's my first time :-)
[02:54] <Hobbsee> jsgotangco: so you're a spammy-iCon now, are you?
[02:54] <jussi01> lol
[02:54] <jsgotangco> lol
[02:55] <Fujitsu> persia: But German has too many insanely long compound words.
[02:55] <Hobbsee> yeah, but that's not english.  that looks german.
[02:55] <minghua> So what do you say about Chinese that doesn't have spaces between words?
[02:55] <persia> Fujitsu: That's the point: keeping them straight.
[02:55] <StevenK> No, Finnish is much better for that.
[02:55] <persia> minghua: Saves paper?
[02:55] <minghua> persia: no, just the way we speak
[02:56] <minghua> In Chinese, all chracters are single-syllable, so no point for spaces.
[02:56] <persia> minghua: Hmm..  I hear inflection in spoken Chinese tounges.  Anyway, back to testing this sync.
[02:58] <jussi01> ahh, now persia, stop it... :P
[03:00] <minghua> persia: Doesn't inflection mean changing pronunciation of a word during speech, instead of changing rhythm?
[03:01] <persia> minghua: Probably.  I don't remember exactly, and realise that a debate of Chinese typography is very far from the things I intended to be doing this evening.
[03:01] <minghua> persia: Sure. :-)  Sorry for dragging you away.
[03:02] <persia> minghua: No need to be sorry - it's just that things that interest me that I haven't thought about in a while tend to pull me from things that interest me that I've been thinking about recently.
[03:06] <minghua> Uh-oh.  Tollef just sent a mail about REVU and licenses.
[03:08] <RainCT> keescook: what's about advocate now, since you said it does work for you?
[03:10] <gnomefreak> does the grab-merge.sh script work if package in not in MoM?
[03:12] <gnomefreak> s/in/is
[03:13] <white> man-di: did you have some time to test new foo2zjs?
[03:13] <man-di> white: not yet
[03:13] <gnomefreak> i run the script and all it does is delete everything in that dir.
[03:14] <Hobbsee> gnomefreak: no it doesnt.  wlel, it does as you say
[03:14] <gnomefreak> it doesnt work still?
[03:14] <gnomefreak> hmmmmmm
[03:15] <Hobbsee> if the package is nto in MoM - what is the intended result?
[03:15] <gnomefreak> its in dad
[03:15] <persia> gnomefreak: I think there's a different grab-merge script for DaD, if you want that.  See the DaD page.
[03:15] <gnomefreak> looking ty
[03:16] <gnomefreak> ah yes there is
[03:18] <viviersf> how can you force a package to update before another package
[03:18] <persia> viviersf: Why do you need to update in a certain order?
[03:20] <gnomefreak> viviersf: dpkg --configure packagename?
[03:22] <white> man-di: i am doing some reviewing now
[03:22] <viviersf> persia, i added a new package, but in order for it to work correctly a buggy old package needs to be updated
[03:23] <persia> viviersf: For that case, you probably want Depends: old-buggy (>= fixed-version) and Conflicts: old-buggy (< fixed-version).
[03:23] <viviersf> persia, cool
[03:30] <man-di> white: cool
[03:43] <white> man-di: review done, you got mail as well :)
[03:45] <man-di> white: thx
[03:46] <StevenK> man-di: MoM can't see that cyphesis-cpp has been updated due to ftp.d.o being braindead, so I'll hold off on the merge/sync until MoM can.
[03:47] <man-di> StevenK: okay
[03:48] <StevenK> I saw it on #debian-devel.
[04:04] <mruiz> ping dholbach
[04:05] <dholbach> mruiz: pong
[04:05] <mruiz> hi dholbach, how are you today? I sent you an email about a package to review ;-)
[04:07] <xxxxx1> hi dholbach
[04:07] <dholbach> mruiz: fine fine - how are you?
[04:08] <dholbach> mruiz: yes, I received your mail, unfortunately it wasn't the only one over the weekend
[04:08] <dholbach> mruiz: I got several thousands of mails, I'll see that I get around to do the review quickly
[04:08] <dholbach> mruiz: in the the meantime you can ask in the channel or on ubuntu-motu-mentors@ for a review, if you don't mind
[04:08] <mruiz> dholbach, no worries :-)
[04:08] <dholbach> but I promise, I'll try to do it soon
[04:09] <mruiz> I'm patient
[04:29] <mruiz> I'm packaging a torrent client that depends on libtorrent. In the Ubuntu archive I found the package "libtorrent10" and I have to upgrade it. Why this package is not called just "libtorrent"?
[04:45] <dholbach> mruiz: best to update it then
[04:45] <dholbach> mruiz: talk to bluekuja - he's part of the torrent team
[04:45] <mruiz> thanks dholbach
[04:45] <dholbach> np
[04:46] <mruiz> is the same project name, but they are different
[04:46] <mruiz> the package in the archive (libtorrent10) doesn't work for me (in this case)
[04:47] <dholbach> best to agree with bluekuja on a solution for that
[04:47] <mruiz> yes
[04:47] <mruiz> BSD license is allowed ?
[04:48] <ScottK> mruiz: Yes
[04:48] <ScottK> dholbach: Did you get a chance to finish looking into the clamav API changes for 0.90.x
[04:49] <dholbach> ScottK: no, I had no time on the weekend to look into it- but the changes are too large to make a list of them on a wiki page easily
[04:49] <dholbach> I think it's best to try to build them in a chroot and see what happens
[04:50] <dholbach> I know this is not ideal, but the most realistic option before doing archaelogical studies on clamav
[04:50] <ScottK> dholbach: OK.  I had been thinking based on your quicklook during the meeting that if the changes (not additions) to the API were some return code changes, maybe we could patch the old return codes back in for Dapper and not have to backport all the rdepends...
[04:52] <dholbach> lots of other stuff changed to
[04:52] <dholbach> too
[04:52] <dholbach> it had 60K lines of changes
[04:56] <ScottK> dholbach: I'm not suprised.  I was just trying to focus in on what affected interoperability with other packages.
[04:58] <dholbach> we should just try to build the dapper apps against the gutsy clamav in a chroot
[04:59] <dholbach> I think that should be entirely possible to do, so everybody can grab 1-2 source packages
[04:59] <dholbach> did you set up a wiki page with that?
[04:59] <ScottK> dholbach: I set up a stub of one and started a team to make it easier to coordinate.
[05:00] <ScottK> dholbach: I didn't have a lot of time over the weekend either.
[05:00] <ScottK> dholbach: https://launchpad.net/~ubuntu-clamav
[05:00] <dholbach> good good, if we announce that on ubuntu-devel with some instructions, that should make it easier
[05:02] <Sp4rKy> a va le reboot
[05:02] <Sp4rKy> alo ?
[05:02] <Sp4rKy> y'a quelqu'un ?
[05:02] <Toadstool> Sp4rKy: ECHAN
[05:02] <Sp4rKy> oups
[05:02] <Sp4rKy> sorry
[05:02] <Toadstool> hi everybody
[05:03] <Sp4rKy> Toadstool: hi
[05:04] <sommer> ScottK about the clamav team are we focussing on Dapper?
[05:05] <sommer> I should have some time over the 4th to look into it, but I'm still not 100% clear on where to start.
[05:05] <ScottK> sommer: That's where the greatest need is at this moment.  Not exclusively.
[05:06] <ScottK> sommer: Step one is for me to get a draft package for a clamav 0.90.3 backport to Dapper out for people to use.  I should get that done tomorrow.
[05:06] <ScottK> sommer: Step two is to test different packages that use clamav against this package and see which work and which don't.
[05:06] <sommer> ScottK: cool if you need some testing help let me know.  I setup a test of the Server edition this weekend.
[05:06] <ScottK> Step three is to prepare backports of the packages that don't work.
[05:07] <ScottK> Step four is massive backport of all this cr$p at the same time so nothing (promise) breaks.
[05:07] <ScottK> Step five: Move to Edgy, rinse, repeat.
[05:08] <ScottK> In the meantime, people running Feisty can check the rdpends and make sure nothing got missed during Feisty development (I know clamtk did and I've already asked for a backport).
[05:08] <ScottK> jdong: Are you around?  Any chance of getting the clamtk backport for Feisty approved soon?
[05:09] <ScottK> And just to keep in interesting, clamav 0.91 is at rc2 and will enable a bunch of anti-phishing stuff, so stand by for more fun.
[05:10] <sommer> Ya I thought it looked like 0.91 would be out soon.
[05:10] <ScottK> dholbach: Once I have the clamav package for dapper ready for people to use for building/testing, what would be the best way to publish it for people to use?
[05:10] <sommer> do you know if there are API changes between 0.90 and 0.91?
[05:10] <sommer> I assume there are if they're adding anti-phishing.
[05:11] <ScottK> sommer: I doubt it, but haven't checked the docs.  I'd guess additions, but not changes.
[05:11] <sommer> ah...thats cool.
[05:25] <dholbach> ScottK: just uploade the source packag somewhere - people can built it on their arch in that chroot then
[05:26] <ScottK> dholbach: OK.  I'll do that.  I'll put an i386 binary up too just to save trouble.
[05:26] <dholbach> great
[05:31] <ScottK> sommer: If you have a few minutes (I'm on my way out the door), it'd be nice if you would take the information I gave you above and add it to the MOTU/clamav wiki page.
[05:31] <sommer> ScottK: sure no problem.
[05:32] <sommer> another quick question...is the source for you Dapper package in a public Version Control somewhere?
[05:32] <ScottK> sommer: No.  It'll be the current Gutsy package with a couple of changes in debian/control to make it build on Dapper.
[05:33] <sommer> cool...I'll just be patient.
[05:37] <geser> ScottK: re bug #15485: what's missing? the gpg-agent should get started through Xsession.d
[05:37] <ubotu> Launchpad bug 15485 in gnupg2 "kmail don't ask the phrase for gpg-encrypted mails" [Medium,Confirmed]  https://launchpad.net/bugs/15485
[05:37] <ScottK> geser: The missing bit to get it automatically is you have to add "use-agent" to ~/.gnupg/gpg.conf.
[05:38] <ScottK> geser: See my mail to devel-discuss.
[05:50] <geser> ScottK: that proposal sounds reasonable
[06:03] <mok0> I have several packages sitting in REVU, ready and awaiting review. Most have already been through one or more cycles
[06:21] <bmm> After being rejected by the archive due to licensing issues, there is a new release of ccbuild using libgcrypt instead of another MD5 implementation. So any MOTU please take some time to look at http://revu.tauware.de/details.py?upid=5850
[06:48] <dholbach> mruiz: sent a comment on the package
[06:49] <mruiz> thanks dholbach
[06:49] <dholbach> anytime
[06:55] <mruiz> why this package (amsn) is not xx-YubuntuZ in previous versions?
[06:55] <dholbach> you mean the 'dfsg' bit?
[06:55] <dholbach> that means that the tarball was repacked
[07:18] <jerome_> i've just downloaded the source package of pommed in gutsy, in debian/changelog there are only entries for debian unstable, how can it be that there are no ubuntu ones ?
[07:24] <jerome_> davromaniak : alors ce perfparse ?
[07:25] <davromaniak> j'ai abandonn perfparse pour tenter avec rrdtools
[07:35] <nixternal> is there a security doc somewhere? I have a package I need to get security fixes in (>= Dapper). I have done this before, but I want to be clear on the steps if possible
[07:39] <giskard> nixternal, https://wiki.ubuntu.com/SecurityUpdateProcedures?highlight=%28security%29
[07:39] <nixternal> thanks giskard
[07:39] <giskard> try to search security on wiki.u.com
[07:40] <nixternal> I did, overlooked that one
[07:48] <keescook> nixternal: ping me or pitti when you're reading to go; I'm going to be afk for about 20 hours, so if you can't reach either of us, either send email to<EMAIL_ADDRESS>or the motu mailing list (or open a security-related bug).  :)
[07:49] <nixternal> I am going to do all 3 :)
[07:49] <nixternal> thanks
[07:49] <keescook> sounds good to me.  :)
[07:49] <keescook> out of curiosity, what package is it?
[07:53] <nixternal> KVIrc
[07:53] <nixternal> 2 simple lines for the parseIrcUrl() function to sanitize a couple of characters in their scripting module
[07:58] <tsmithe> hmm where's Mez... i need to congratulate him. asleep methinks
[08:10] <mruiz> hi all
[08:10] <mruiz> I need to rename a directory ( I changed the name of the package, but I need to change the name of the dir as well)
[08:10] <mruiz> How I can do it ?
[08:12] <mruiz> How can I do it ? ;-)
[08:25] <vijay2000> Hi all, can anybody tell me how to decrpyt a encrypted message
[08:25] <vijay2000> gpg --decrypt filename.txt is throwing the following error
[08:26] <vijay2000> gpg: decrypt_message failed: unexpected data
[08:30] <nixternal> keescook: bug 123595 if you are still around
[08:30] <ubotu> Bug 123595 on http://launchpad.net/bugs/123595 is private
[08:43] <crimsun> mruiz: e.g., mv old new && tar cf new_foo.orig.tar new/
[08:45] <mruiz> crimsun, and I have to comment it in debian/README.Debian-source
[08:46] <cbx33> hi guys
[08:46] <cbx33> anyone around to offer a little help?
[08:48] <crimsun> cbx33: depends what you need.
[08:48] <nixternal> messing with security patches, I forgot all about my laundry :/
[08:48] <nixternal> hiya cbx33
[08:50] <mruiz> crimsun,  Is needed to comment it in debian/README.Debian-source ?
[08:51] <crimsun> mruiz: for a source package rename and/or directory rename?  Not for the latter, no; for the former, it depends if you've made any additional changes.
[08:51] <cbx33> well
[08:51] <mruiz> thanks crimsun
[08:52] <cbx33> http://codebrowse.launchpad.net/~petesavage/vcs-frenzy/trunk/files/petesavage%40ubuntu.com-20070630095338-6p7c56m6x2gmlb5y?file_id=debian-20070510150647-t31jnlawshlxkqvc-1
[08:52] <cbx33> this is my debian dir
[08:52] <cbx33> the source pacakge builds fine
[08:52] <cbx33> dh_pysupport: debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy doesn't contain modules for any supported python version
[08:52] <cbx33> but i get that error when pbuilding
[08:52] <cbx33> any ideas?
[08:55] <cbx33> is there a way to get pbuilder not to delete everything so I can inspect it?
[08:55] <cbx33> --debug didn't work
[08:56] <iAmaranth> add a hook
[08:56] <iAmaranth> i'm stuck on OS X while my laptop gets fixed so i can't tell you how :)
[08:57] <cbx33> oh
[08:57] <cbx33> like a pause
[08:57] <crimsun> https://wiki.ubuntu.com/PbuilderHowto#head-977029f996a60ad77d13293f40d6adbc8da99652
[08:57] <mruiz> bye all
[09:00] <cbx33> trying now
[09:00] <cbx33> thanks crimsun
[09:03] <cbx33> ok
[09:03] <cbx33> so the prblem isn't there
[09:03] <cbx33> this is driving me nuts
[09:07] <cbx33> ok
[09:07] <cbx33> I'm just inspecting the build directory
[09:07] <cbx33> pete@misato:/var/cache/pbuilder/build/11601/tmp/buildd/vcsfrenzy-0.1.0/debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy$ ls -la
[09:08] <cbx33> -rw-r--r-- 1 1234 1234    0 2007-05-10 07:42 __init__.py
[09:08] <cbx33> drwxr-xr-x 2 1234 1234 4096 2007-07-02 20:06 plugin
[09:08] <cbx33> so
[09:08] <cbx33> why is it failing
[09:08] <cbx33> dh_pysupport: debian/vcsfrenzy/usr/lib/python-support/vcsfrenzy doesn't contain modules for any supported python version
[09:08] <cbx33> with that error message?
[09:10] <cbx33> google has nothing on that error message
[09:51] <ScottK> geser: It might be nice to have a reply on devel-discuss to that effect (i.e. sounds reasonable).
[09:52] <ScottK> crimsun: Welcome to Maryland (I assume).
[10:20] <geser> ScottK: was a bit a hurry, will reread it again and mail to devel-discuss
[10:21] <ScottK> geser: Thanks.
[10:21] <geser> it would be good to fix it in the next gnupg2 upload which to needed for the libcurl4 -> libcurl3 backtransition
[10:32] <bmm> Any MOTU, ccbuild is looking for it's first advocate again but now for the new version of the source. If you have time, please look at http://revu.tauware.de/details.py?upid=5850
[10:46] <cbx33> hi guys
[10:47] <cbx33> if I have a package I want to create
[10:47] <cbx33> and it needs to compile 1 .cpp
[10:47] <cbx33> with a line gcc -Wall -I/usr/include -o phimage-bin phimage.cpp `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` -L/usr/X11R6/lib -lX11 -lglut -lGL -lGLU -lm -g
[10:47] <cbx33> can that just go into the rules file....
[10:47] <cbx33> if so....where and once it's done.....where will the file be created?
[10:48] <geser> cbx33: sure, why not
[10:48] <geser> it will probably end in $(CURDIR)
[10:50] <cbx33> so if I then wanted to make a .install file
[10:50] <cbx33> where would it find it
[10:50] <cbx33> or I suppose
[10:50] <cbx33> hmm
[10:50] <cbx33> ?
[10:51] <cbx33> geser, would that be in debian/
[10:51] <geser> debian/rules is called from the source-directory, so I assume that your compiled file will end there
[10:52] <mok0> cbx33: If it's a .cpp you need to compile with g++
[10:52] <cbx33> oh
[10:52] <cbx33> how come it works ok with gcc
[10:52] <geser> gcc is clever enough to use g++ on an .cc file
[10:52] <cbx33> it's a .cpp
[10:53] <geser> or a .cpp file
[10:53] <cbx33> ok
[10:53] <cbx33> cool
[10:54] <geser> if you want to test why a stage at package build fails you can call it directly
[10:55] <geser> debian/rules build or which target you need
[10:59] <cbx33> if I was building a package
[10:59] <cbx33> and it has to copmile
[10:59] <cbx33> is build-essential a good dep to have?
[11:04] <geser> you should have build-essential installed but don't build-depend on it (every package has an implicit B-D on it)
[11:06] <ajmitch> morning
[11:08] <nixternal> g'morning ajmitch
[11:08] <ScottK> Good morning ajmitch.
[11:08] <geser> morning ajmitch
[11:08] <mok0> cbx33: you can compile with gcc but not link
[11:09] <mok0> cbx33: you need to use g++ to link a C++ program
[11:09] <ScottK> mok0: Which of your packages on REVU is most ready/would you prefer to have looked at?
[11:09] <mok0> Scott: lemme look
[11:10] <mok0> ScottK: you looked at kaksi before, it failed in your pbuilder, but I fixed the Deps. http://revu.tauware.de/details.py?upid=5662
[11:11] <mok0> ScottK: great, thx
[11:12] <ScottK> mok0: Does it build in pbuilder now
[11:12] <ScottK> ?
[11:20] <cbx33> how big generally does a pbuilders cache get whilst it's building?
[11:22] <cbx33> hmmm
[11:22] <cbx33> in my package i just made it said gcc wasn't found
[11:22] <cbx33> what package do i need to install to get it?
[11:22] <cbx33> i mean
[11:22] <cbx33> as a build dependency?
[11:25] <geser> gcc is part of build-essential which doesn't have to be added to build-depends
[11:25] <geser> cbx33: you mean the pbuilder apt-cache? or the pbuilder chroot?
[11:26] <mok0> ScottK: Yes it builds for me. (Sorry, I was away)
[11:26] <cbx33> chroot
[11:26] <cbx33> geser
[11:26] <cbx33> ahh ok
[11:26] <cbx33> building now
[11:26] <geser> it depends on how much space the build-depends need
[11:26] <cbx33> ydh i guess
[11:27] <cbx33> had a funky idea was all
[11:27] <cbx33> for people with lots of RAM
[11:27] <geser> you need space for the expanded base.tar.gz plus the installed build-depends
[11:27] <ScottK> mok0: No problem.  I'm building it now.
[11:27] <cbx33> g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:27] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \
[11:27] <cbx33> g++:  : No such file or directory
[11:27] <cbx33> ???
[11:28] <geser> cbx33: I've seen packages needed over 300 MB of space for the build-depends
[11:28] <cbx33> ouch
[11:28] <cbx33> this one readhes 175Mb
[11:28] <geser> add also space for the files generated during the build
[11:28] <cbx33> why is it dying like that?
[11:29] <geser> cbx33: is that from a builder or from your develeopment environment?
[11:29] <cbx33> builder
[11:29] <cbx33> it builds fine elsewhere
[11:29] <cbx33> infact earlier it was trying to build
[11:30] <mok0> cbx33: I get errors like that when trying to build on an NFS mounted disk
[11:30] <cbx33>         g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:30] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \
[11:30] <cbx33>          -L/usr/X11R6/lib -lX11 -lglut -lGL -lGLU -lm -g
[11:30] <cbx33> is that wrong?
[11:30] <cbx33> in my rules file
[11:30] <cbx33> before i added the freeglut3 dependency it was ok
[11:31] <mok0> cbx33: you probably need  freeglut3-dev not freeglut3
[11:31] <cbx33> i have that
[11:31] <cbx33> as a build dep
[11:31] <cbx33> i meant freeglut3 in general
[11:31] <cbx33> :p
[11:32] <mok0> ok
[11:32] <mok0> cbx33: check out your pbuilder environment with a package from the repo that is known to build (choose a small one)
[11:33] <cbx33> hmmm
[11:33] <cbx33> ok
[11:33] <cbx33> as I say
[11:33] <cbx33> twas ok
[11:33] <cbx33> hmmm i know what I'll try too
[11:33] <cbx33> my hook should let me try to copmile from within my build environment
[11:34] <geser> cbx33: you could also login into your pbuilder and check why g++ isn't installed
[11:34] <cbx33> well
[11:34] <cbx33> it was
[11:34] <cbx33> how do i do that?
[11:34] <cbx33> it did it for gcc too
[11:34] <cbx33> dpkg-parsechangelog: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
[11:34] <cbx33> debian: warning: no utmp entry available and LOGNAME not defined; using uid of process (0)
[11:34] <cbx33> dh_installdocs
[11:34] <cbx33> dh_installexamples
[11:34] <cbx33> g++ -Wall -I/usr/include -o phimage phimage.cpp \
[11:34] <cbx33>          `pkg-config --cflags gtkmm-2.4` `pkg-config --libs gtkmm-2.4` \
[11:34] <cbx33> g++:  : No such file or directory
[11:34] <cbx33> make: *** [install]  Error 1
[11:34] <cbx33> pbuilder: Failed autobuilding of package
[11:35] <cbx33> root@misato:/# gcc
[11:35] <cbx33> gcc: no input files
[11:35] <cbx33> root@misato:/# g++
[11:35] <cbx33> g++: no input files
[11:35] <cbx33> root@misato:/#
[11:35] <cbx33> from the chroot
[11:35] <geser> pbuilder login
[11:35] <geser> and you shouldn't build it in the binary target but in the build target
[11:35] <cbx33> ok
[11:36] <cbx33> W: no hooks of type F found -- ignoring
[11:36] <cbx33> root@misato:/# g++
[11:36] <cbx33> g++: no input files
[11:36] <cbx33> root@misato:/#
[11:36] <cbx33> g++ is installed
[11:37] <geser> argh, it's definitely to late for me
[11:37] <mok0> cbx33: Don't you have to cd to some dir before doing the compile?
[11:37] <geser> it's not the shell complaining but g++ itself
[11:37] <cbx33> ahhh
[11:37] <geser> is the \ in the second line correct?
[11:38] <cbx33> no idea
[11:38] <mok0> the backslash means continues next line
[11:38] <mok0> there must not be a space after et
[11:38] <mok0> s/et/it
[11:39] <geser> g++ complains that it can't find the file " "
[11:39] <mok0> looks like you may have to get rid of it
[11:39] <cbx33> ahhh
[11:39] <cbx33> ok
[11:39] <mok0> :-D
[11:39] <cbx33> might have solved it then
[11:39] <cbx33> thank you
[11:47] <ScottK> mok0: +1 on kaksi.  Looks good to me.
[11:49] <ScottK> geser: Do you have time to look at http://revu.tauware.de/details.py?upid=5662.  It looked good to me, so it's looking for #2.
[11:49] <mok0> ScottK: Thx!
[11:49] <ScottK> mok0: Thank you for contributing.
[11:49] <mok0> ScottK: kssh was rejected today, due to some license issue
[11:50] <Kmos> ScottK: gambas has synced by seb128
[11:50] <ScottK> mok0: Oops.  I checked licensing more closely on kaksi.
[11:50] <ScottK> mok0: Let me know when kssh is ready to be uploaded again.
[11:51] <mok0> ScottK: OK. The license stuff is difficult. He said that COPYING should be in the orig.tar.gz, but I don't know what he means by that.
[11:51] <mok0> Should _I_ put the license files in?
[12:01] <geser> mok0: no, the orig.tar.gz should contain a copy of the license
[12:02] <geser> usually the license file is called COPYING or sometime also LICENSE
[12:02] <mok0> geser: then upstream must do it?
[12:05] <geser> yes
[12:06] <mok0> that could be problematic
[12:08] <mok0> Often upstream authors don't care about the legalese
[12:10] <ScottK> mok0: The best solution is to ask upstream to release an update with the file.
[12:10] <ScottK> mok0: If they won't, then you can repack the orig.tar.gz to include it.
[12:12] <ScottK> mok0: See http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz for documentation on how you repack orig.tar.gz.
[12:13] <mok0> ScottK: I'll try to get in contact with him
[12:14] <mok0> I'd better send him the files (it's several licenses)
[12:14] <mok0> ... or perhaps a patch
[12:15] <ScottK> mok0: kaksi has a copy of the GPL in it, so it's not a problem for that one.
[12:16] <DarkSun88> Hi all
[12:19] <mok0> ScottK: but it does have unconventional clauses in the .c files :-(
[12:21] <mok0> ScottK: ... and not in _every_ file


[02:10] <derekv> will Schneier attend the key signing party?
[02:20] <_stink_> oo
[02:20] <_stink_> that would be a prize.
[14:55] <cmaloney> jrwren: Thinking I should have bought an Amiga back in the day rather than the HDD upgrade for my Atari 8-bit.
[14:55] <cmaloney> but I never would have come to that conclusion back in the day. :)
[16:25] <cscheib> cmaloney: that's a lot of years of regret to come to terms with
[18:05] <_stink_> haha
[20:01] <gamerchick02> hey has anyone in here tried Mate?
[20:02] <gamerchick02> Ubuntu Mate is now an official version for the 15.04 release, so that's cool. i'm thinking of giving it a try
[20:08] <cmaloney> cscheib: Yeah, I'm a slow learner.
[20:11] <gamerchick02> cmaloney, about what?
[20:11] <gamerchick02> you're a smart dude...
[20:13] <cmaloney> gamerchick02: "Thinking I should have bought an Amiga back in the day rather than the HDD upgrade for my Atari 8-bit."
[20:14] <cmaloney> gamerchick02: "but I never would have come to that conclusion back in the day. :)"
[20:14] <gamerchick02> hah, ok yes
[20:14] <cmaloney> Posted earlier
[20:14] <gamerchick02> sorry i just popped online. was in Flint most of the afternoon
[20:14] <cmaloney> Yeah, no worries.
[20:15] <cmaloney> Just playing with an Amiga emulator and realizing a) it was the spiritual successor to the 8-Bit machines that I kept going for 15 years
[20:15] <gamerchick02> cool!
[20:20] <cscheib> flint, sounds like a violent afternoon
[20:21] <gamerchick02> no we were at the Lady's Oriental Shrine installation. it was very nice.
[20:23] <gamerchick02> and it was actually really safe downtown. i dunno. i felt fine. it's over by Halo Burger and Greater Flint Arts Council on Saginaw Rd.
[20:27] <cscheib> haven't really been back to Flint since I became a college dropout in 05 (go Kettering)... Halo Burger sounds pretty tasty right now.
[20:27] <gamerchick02> dude. i'm a graduate of Kettering
[20:27] <gamerchick02> A or B section?
[20:27] <cscheib> B
[20:27] <gamerchick02> ah.
[20:27] <gamerchick02> i was A
[20:28] <gamerchick02> CompSci?
[20:28] <cscheib> CompEng
[20:28] <cmaloney> At least it wasn't a C section.
[20:28] <gamerchick02> LOL you're funny cmaloney
[20:28] <gamerchick02> :-P
[20:28] <cmaloney> That just yanks the degree right out of ya.
[20:29] <gamerchick02> you'll be here all week, try the fish, right?
[20:29] <cmaloney> Nah, the fish sucks
[20:30] <cscheib> good school, I just don't get along well with traditional education
[20:30] <gamerchick02> fish is good.
[20:30] <gamerchick02> traditional education isn't for everyone
[20:33] <gamerchick02> it is for me sort of. i dunno. i've been thinking of going back and getting a masters in mechanical engineering
[20:34] <gamerchick02> http://ubuntuforums.org/showthread.php?t=2259859 this is cool. Mate is resurrecting PPC hardware
[20:35] <gamerchick02> and it works on an Amiga one X1000
[20:35] <gamerchick02> apparently
[20:38] <gamerchick02> i'm thinking of giving Mate a go. it looks neat. i like unity well enough but i guess i want something different. and since i keep everything for ubuntu in dropbox, i'll be able to install that on ubuntu mate and have most all the things i need. so that's cool
[21:06]  * derekv plays with impress.js because just because
[22:04]  * derekv *evil laugh*
[22:04] <derekv> 3d <video> tags
[23:22] <gamerchick02> new irc program...
[23:58] <jrwren> cmaloney: you got that A1000 running?
[23:58] <jrwren> cmaloney: you definitely should have. A1000 was an awesome machine.


[03:10] <mup> PR snapd#10758 opened: image/image_linux.go: add newline <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10758>
[05:00] <mborzecki> morning
[05:43] <mardy> 'morning!
[06:04] <mborzecki> what a mess with boltdb, upstream was forked once, then since coreos became part of rh, it got moved again
[06:05] <mborzecki> some distros have packages of the intermediate location (at github/coreos), but not the new one at etcd
[06:05] <mborzecki> and ofc go get github.com/coreos/bbolt fails because github redirects coreos to etcd-io for this repo go get github.com/coreos/bbolt
[06:05] <mborzecki> https://paste.ubuntu.com/p/nHbSR4V5qK/
[06:26] <mardy> mborzecki: about your suggestion for the systemdTooOldError: should I actually make it public (and probably call it TooOldError, since we have the package prefix anyway)?
[06:28] <mborzecki> mardy: probably doesn't need to be public, if you really want to check if it's that specific error you can have `func IsSystemdTooOld(err error) { _, ok := err.(*systemdTooOldError); return ok }` ?
[06:28] <mardy> mborzecki: your suggestion would actually allow us to use systemd.EnsureAtLeast() here too: https://github.com/snapcore/snapd/blob/master/usersession/userd/privileged_desktop_launcher.go#L98-L110
[06:28] <mardy> but that requires the error to be public, I guess
[06:29] <mardy> mborzecki: ah, ok, if you think that IsSystemdTooOld() is better, I'll go with that
[06:53] <mborzecki> hmm broke remodel, fixed remodel
[07:04] <pstolowski> morning
[07:14] <mardy> pstolowski: hi!
[07:16] <mvo> good morning pstolowski and mardy and mborzecki
[07:16] <mborzecki> mvo: pstolowski heya
[07:21] <mup> PR snapd#10688 closed: configcore: add read-only netplan support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10688>
[07:21] <mup> PR snapd#10757 closed: build-aux: stage libgcc1 library into snapd snap <cherry-picked> <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10757>
[08:12] <mardy> mvo: hi!
[08:18] <mborzecki> even dropped a little reactor of remodel tasks, meh that code was nasty, still is but a just a little less
[08:38] <mwhudson> mvo, mborzecki: how often does the snapd snap get updated in stable, out of curiousity?
[08:39] <mvo> mwhudson: in theory every 4 weeks, in pratice it's a lot more volatile because we recently got a lot "dot" releases for customers
[08:39] <mwhudson> mvo: ok
[08:40] <mvo> mwhudson: why (just out of curisoity)
[08:40] <mwhudson> mvo: somehow that libgcc_s.so.1 thing is making snapd autopkgtests fail
[08:41] <mwhudson> https://autopkgtest.ubuntu.com/packages/s/snapd/impish/amd64
[08:41] <mvo> mwhudson: oh, we will do a new 2.52 soon, I can also upload out-of-band releases to impish if that is needed (but in a meeting right now so let's chat in a bit what I can do to help :)
[08:41] <mwhudson> mvo: it's really the snapd snap, not the package in impish (afaict)
[08:42] <mvo> mwhudson: uh, ok
[08:45] <mwhudson> at least that's what https://bugs.launchpad.net/snapd/+bug/1943077 says
[08:45] <mup> Bug #1943077: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s <update-excuse> <snapd:New> <openssh (Ubuntu):New> <squashfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1943077>
[09:11] <mup> PR snapd#10725 closed: o/hookstate: require snap-refresh-control interface for snapctl refresh --proceed <Needs Samuele review> <Refresh control> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/10725>
[09:41] <mborzecki> mvo: thanks for updating snapcore/bolt, i've updated https://github.com/snapcore/snapd/pull/10754 and we'll see how it fares now
[09:41] <mup> PR #10754: tests/lib/prepare-restore: make sure that package build is done without network access <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[09:47] <mup> PR snapd#10759 opened: tests: be more robust against a new day stepping in <Created by mardy> <https://github.com/snapcore/snapd/pull/10759>
[09:48] <mvo> mborzecki: \o/
[09:48] <mvo> mborzecki: our of curiosity, was a "go get -u" enough for tihs?
[09:49] <mborzecki> mardy: cannot approve your pr sorry 🙂 you're missing a reference to https://www.youtube.com/watch?v=NaGLVS5b_ZY
[09:49] <mborzecki> mvo: heh no, had to go get -u github.com/snapcore/bolt@master otherwise it just picked another tag with v1.3.x
[09:50] <mvo> mborzecki: oh nice, good to know!
[10:01] <laney> quick one (I'm ok filing a bug if there isn't one). seeding is failing on a new impish install like this: https://paste.debian.net/1211056/ - is this known, and can anyone provide me with a workaround for now? :-)
[10:02] <mborzecki> laney: does /etc/apparmor.d/abstractions/base exist?
[10:04] <laney> mborzecki: erm WTF
[10:04] <laney> laney@sherwood:/etc/apparmor.d/abstractions$ ls -l
[10:04] <laney> ls: cannot access 'base': No such file or directory
[10:05] <laney> and... -????????? ? ?    ?       ?            ? base
[10:05] <mborzecki> laney: hmm https://packages.ubuntu.com/impish/amd64/apparmor/filelist there is /etc/apparmor.d/abstractions/base, borked fs?
[10:06] <laney> looks like something weird happening here
[10:06] <laney> let me poke, thanks for the pointer
[10:08] <mborzecki> mvo: so not it's looking for: https://github.com/canonical/go-sp800.90a-drbg
[10:10] <mborzecki> apparently it's needed by secboot, but it's listed in go.mod, so why earlier go mod vendor did not fill that dependency?
[10:10] <mvo> mborzecki: that is interessting, I have no idea why it's missing from go mod :/
[10:11] <mvo> mborzecki: maybe conditional somehow via buildflags?
[10:11] <mborzecki> mvo: well it's listed there as an indirect dependency, but i'm not sure why go mod vendor has not fetched the repo
[10:11] <mardy> mborzecki: :-D
[10:57] <mup> PR snapd#10760 opened: o/snapstate: support ignore validation flag on install/update <⛔ Blocked> <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10760>
[11:17] <mborzecki> mvo: ok, so i got something about that build problem, we have a buch of `//go:generate` which invokes go run, or runs a script (update-pot) which in turn runs go install without all the flags
[11:22] <jdstrand> amurray: hey, mentioning this as a reminder to folks of why we might not autoconnect something that most snaps don't need even if on the surface it seems like it wouldn't be a problem: https://ubuntu.com/security/CVE-2021-3612 (joystick interface)
[11:34] <mardy> mvo: can you merge this? https://github.com/snapcore/snapd/pull/10653 Or should I rather retry the build, since if failed on so many machines (looks like I hit a multitude of unlucky situations :-D)
[11:34] <mup> PR #10653: mount-control: step 1 <Needs Samuele review> <Created by mardy> <https://github.com/snapcore/snapd/pull/10653>
[11:47] <amurray> hey jdstrand :) - that is a great example - I recall asking you that very question once and you explained it really well at the time
[11:47] <mup> PR snapd#10761 opened: o/snapstate: optimize conflicts around snaps stored on conditional-auto-refresh task <Refresh control> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10761>
[12:27] <mup> PR snapd#10762 opened: o/servicestate: Update task summary for restart action <Created by mardy> <https://github.com/snapcore/snapd/pull/10762>
[12:57] <mup> PR snapd#10763 opened: tests: pre-cache snaps in classic and core systems <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10763>
[13:34]  * pstolowski lunch
[13:43] <jdstrand> amurray: oh, heh, I forgot we discussed that, hehe. Yeah, any device is kernel attack surface. I can't recall a CVE in the joystick driver before this one, but I'm always like "but what if there was one?" :)
[14:05]  * cachio afk
[14:07] <mup> PR snapd#10741 closed: interfaces/block-devices: support to access the state of block devices <Skip spread> <cherry-picked> <Created by woodrow-shen> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10741>
[14:13] <ijohnson[m]> @bboozzoo hey I was wondering would it "simplify" things if we just imported github.com/etcd.io/bolt directly in our go.mod, then used the "replace" directive on specific distros that don't have a package for that module to redirect our import of that module to one that is installed locally via distro pkg? I don't recall the semantics around replace working with modules that declare themself as a differently named module
[14:15] <mborzecki> ijohnson: yeah, that could work, we may need to patch some things on fedora maybe?
[14:15] <mborzecki> worth a try anyway
[14:15] <ijohnson[m]> yeah I was just wondering if that would be easier to add/remove that go.mod line than to mess around with the fork and things
[14:19] <mborzecki> ijohnson: also, despite having go.mod inside the repo, we can build without modules for now, tbh i don't see how go upstream will make building packages across various linux distros withouth either patching go.mod to update versions automatically or allowing people to disable modules altogether
[14:20] <mborzecki> especially as some distros are really adamant to vendoring random dependencies
[14:28] <mborzecki> ijohnson: (cc mvo) i've pushed a patch to https://github.com/snapcore/snapd/pull/10754 please take a look, once it lands LP builds will hopefully be fine again
[14:28] <mup> PR #10754: packaging, tests/lib/prepare-restore: build packages without network access, fix building debs with go modules <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[14:28] <ijohnson[m]> @bbo
[14:29] <ijohnson[m]> gah
[14:29] <mvo> mborzecki: nice, thank you
[14:29] <ijohnson[m]> @bboozzoo thanks will take a look
[14:29] <ijohnson[m]> I like fluffychat as a snap matrix client but it doesn't seem to do username autocomplete via the tab key which is unfortunate
[14:30] <mborzecki> ijohnson: i use element web interface, and sometimes gnome client called 'fractal'
[14:31] <ijohnson[m]> I used to use element but I wanted to try out something else, element works pretty well though
[14:31] <ijohnson[m]> I'll have to give fractal a try though
[14:34] <ijohnson[m]> ah nice well fractal does seem to do username autocomplete with tab key so that's nice, but fluffychat looks a bit nicer IMHO
[14:37] <mardy> pstolowski: you are the servicestate expert, I guess: do you know what I should do in the unit tests, so that snapstate.Get() will return a snap? (it returns err here)
[14:38] <pstolowski> mardy: sure. snapstate.Set(...), you will find plenty of that in other unit tests
[14:39] <pstolowski> mardy: sometimes some tests have helpers that create snap.yaml on the disk *and* entry in the state, but often it needs to be done manually
[14:40] <mardy> pstolowski: thanks, I'll try with snapstate.Set() first
[14:43] <mup> PR snapd#10758 closed: image/image_linux.go: add newline <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10758>
[14:46] <ijohnson[m]> @cachio hey is the snap run failure you were mentioning only happening on impish + debian sid or is it happening on other systems too?
[15:13] <mup> PR snapd#10742 closed: tests: update nested tool - part1 <Run nested> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10742>
[15:21] <ijohnson[m]> @mvo can you land https://github.com/snapcore/snapd/pull/10732? the failures are unrelated
[15:21] <mup> PR #10732: tests/lib/nested.sh: split out additional helper for adding files to VM imgs <Simple 😃> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10732>
[15:21] <mvo> ijohnson[m]: sure
[15:21] <ijohnson[m]> thanks
[15:23] <mup> PR snapd#10732 closed: tests/lib/nested.sh: split out additional helper for adding files to VM imgs <Simple 😃> <Run nested> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10732>
[15:44] <miguelpires> cachio hey, can you help me with the translation linting spread test? https://github.com/snapcore/snapd/pull/10756/files#diff-5720a79fd79b88cebcc680e6914186981e330df7bc933261176bed1f42a1fb1d
[15:44] <mup> PR #10756: cmd/snap: only log translation warnings in debug/testing <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10756>
[15:48] <miguelpires> I installed language-pack-pt to reproduce the issue so I guess that's what's missing from the spread env. But in the same test there's a test with "LANG=de", not sure why one works and the other doesn't
[16:43] <ijohnson[m]> /nick ijohnson|lunch
[16:44] <ijohnson[m]> well that didn't work
[16:45] <ijohnson[m]> /nick ijohnson|lunch
[16:45] <ijohnson[m]> hmm so only element seems to know about /nick it seems :-/
[16:47] <ijohnson[m]> huh so actually all this time, element was just changing the matrix display name in the matrix bridged room, that never actually propagated to IRC at all
[16:56] <ogra> ijohnson[m], so no lunch ofr you then ...
[16:57] <cachio> miguelpires, hi, sorry for the delay, I was having lunch
[16:57] <cachio> let me take a look
[16:58] <cachio> ijohnson[m], I saw that on debian sid and also in uc20 tests when I run beta validation
[17:02] <cachio> miguelpires, so, in which system is it failing?
[17:03] <cachio> because I don'r see error in the execution logfs
[17:08] <cachio> ijohnson[m], have you seen that one?
[17:08] <cachio> https://paste.ubuntu.com/p/9nJv3W46M7/
[17:11] <miguelpires> cachio no worries, thanks for helping me with this. It's not failing but I expected it to. It fails locally because I have the language pack with a incorrect translation and I assume the spread env doesn't have it. But the same spread test also expects assumes that LANG=de works, so I'm not sure
[17:13] <cachio> miguelpires, what should can do there is to add "exit 1" before the line echo "Lint translated commands"
[17:13] <cachio> and yo uexecute spread -deubg
[17:14] <cachio> so then you will have a debug session and you can run the line and see the output
[17:15] <cachio> I see that you are redirecting the output to /dev/null
[17:15] <cachio> but the best you can do there is to debug the line
[17:15] <cachio> does it make sense?
[17:17] <miguelpires> Yes, I'll try that then. Thanks!
[17:24] <cachio> I would try without redirecting to /dev/null the output
[17:24] <cachio> so NOMATH receives the input
[17:25] <cachio> miguelpires, still don't know why it fails locally
[17:25] <cachio> perhaps could be because another error?
[17:27] <ijohnson[m]> @cachio I've only seen the snap-run failure on sid and impish, I haven't seen it on uc20, do you have logs of the uc20 failure ?
[17:27] <cachio> ijohnson[m], yes, one second
[17:27] <ijohnson[m]> @cac
[17:28] <ijohnson[m]> @cachio the issue with uc20-create-partitions is known it just randomly happens sometimes
[17:28] <mup> PR snapd#10763 closed: tests: pre-cache snaps in classic and core systems <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10763>
[17:31] <cachio> ijohnson[m], https://paste.ubuntu.com/p/9jBtBNfnng/
[17:31] <ijohnson[m]> thanks looking now
[17:31] <cachio> it is a log from a rpi4
[17:36] <ijohnson[m]> hmm I can't reproduce that in a uc20 amd64 VM
[17:36] <ijohnson[m]> I wonder if it's arm specific
[17:37] <cachio> ijohnson[m],  let me check other logs
[17:39] <cachio> ijohnson[m], in amd64 is working properly
[17:40] <cachio> specifically in pi4
[18:03] <ijohnson[m]> @cachio I can't reproduce that issue on my arm64 rpi4
[18:04] <ijohnson[m]> https://pastebin.ubuntu.com/p/Kr8SgXpfNZ/
[18:04] <ijohnson[m]> granted that's edge snapd not beta
[18:04] <ijohnson[m]> let me try with beta channel snapd
[18:05] <ijohnson[m]> same onbeta channel too
[18:12] <miguelpires> @cachio I used -debug like you mentioned and there were only a couple of language-pack installed. After installing all, the linting worked and caught the bad translation so it's working as  Thanks =)
[18:29] <cachio> miguelpires, nice
[18:30] <cachio> miguelpires, so
[18:30] <cachio> to install dependencies you cant do apt install
[18:31] <cachio> because that won't work on other oss than ubuntu or debian
[18:32] <cachio> you need to add that here https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L537
[18:32] <cachio> and also the fedora package in pkg_dependencies_fedora function
[18:33] <cachio> and the same for amazon, opensuse and arch
[18:33] <cachio> so this will be installed when the test start
[18:35] <cachio> ijohnson[m],  I use image from stable but update snapd to beta
[18:35] <cachio> refresh
[18:35] <ijohnson[m]> hmm
[18:35] <ijohnson[m]> I'm not sure what image that was on
[18:35] <ijohnson[m]> (for my run)
[18:35] <cachio> https://storage.googleapis.com/snapd-spread-tests/images/pi4-20-beta/pi.img.xz
[18:36] <cachio> this is the image
[18:36] <cachio> this is where it fails
[18:37] <cachio> pi 107
[18:37] <cachio> core20 1084
[18:37] <cachio> pi-kernel 339
[18:37] <cachio> snapd 13269
[18:37] <ijohnson[m]> cachio: oh wait my device was on uc18 not uc20
[18:37] <cachio> this is the last image for 2.52
[18:37] <ijohnson[m]> I'll have to reflash with uc20 to test
[18:37] <cachio> ok
[18:37] <ijohnson[m]> cachio: so is it reproducible just running that snap run command ?
[18:38] <ijohnson[m]> or is there more setup needed to make it fail with the segfault?
[18:41] <cachio> ijohnson[m], just running -> snap run --strace="invalid" test-snapd-sh.sh -c 'echo hello'
[18:42] <cachio> so having that snpa installed
[18:42] <cachio> should be enough
[18:42] <ijohnson[m]> ok, that's what I was trying but obviously I wasn't hitting the bug as I was actually on uc18 not uc20
[18:42] <cachio> hehe
[18:42] <cachio> np
[18:43] <ijohnson[m]> I'll try again with a uc20 image later, I need to work on 360s now
[19:10] <mborzecki> heh, sid still failed in https://github.com/snapcore/snapd/pull/10754/ the package built successfuly but prepare failed anyway :/
[19:10] <mup> PR #10754: packaging, tests/lib/prepare-restore: build packages without network access, fix building debs with go modules <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[19:12] <mborzecki> ehh it's because i disabled the generator, so somehow the package still ended up with unknown version, even though mkversion is ran earlier :/
[19:33]  * cachio afk


[00:15] <mup> Bug #1654432 opened: Unable to deploy ga kernel on node-details page <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1654432>
[00:45] <mup> Bug #1654450 opened: MAAS shouldn't show newer kernels when edge kernels are added <MAAS:Triaged by ltrager> <https://launchpad.net/bugs/1654450>
[09:21] <mup> Bug #1654515 opened: Feature Request: Custom post-deploy (cloud-init or preseed) scripts per node linked to tags <feature> <MAAS:New> <https://launchpad.net/bugs/1654515>
[15:04] <sponik> Hi
[15:04] <sponik> Anyone here that can answer few questions ?
[15:05] <pmatulis> sponik, dunno, just ask
[15:10] <sponik> When configuring MaaS subnet for PXE under fabric that has its own interface with specific IP that specific IP have to be set as gateway for PXE to boot and access repose for ubuntu correctly ? Can Subnet gateway be set to gateway on firewall and still work correctly ?
[15:15] <pmatulis> sponik, the gateway is simply the gateway that will be assigned to the nodes when they boot
[15:15] <pmatulis> sponik, just try and see
[15:19] <sponik> I did try config with gateway beeing on MAAS rack controller and all work fine for provisioning. When I try to set gateway of the firewall do be default gateway for subnet with internet access it breaks as it cant access ubuntu cloud init data.
[15:20] <pmatulis> sponik, ok i get it
[15:20] <sponik> In production environment you have to have gateway set to MaaS server is not a best solution for internet traffic controll access ? is there same good aproach to this ? Each server have 8 nics and first is set to be PXE and IPMI and then rest are for other actual networks.
[15:22] <sponik> Application interface should carry default gateway rather then PXE server that is in my case 2nd NIC
[15:23] <pmatulis> sponik, the node traffic will need to be routed through the maas machine or configure a possible 2nd network card on the node
[15:27] <sponik> I can apply ansible script that carry 2nd network card configuration but also change gateway and that will break then MaaS access and PXE handling. I can configure 2nd interface and leave gateway to be MaaS IP on that subnet but then I have to add all static routes if I want my traffic get back to source networks that initial communication toward 2nd Network card interface. That is a lot of network management. Is there better way to sol
[16:10] <mup> Bug #1653797 changed: [2.1.2] Unable to deploy ureaahead errors <cdo-qa> <MAAS:Incomplete by cgregan> <https://launchpad.net/bugs/1653797>
[16:11] <mup> Bug #1645644 opened: ntp not using expected servers <cloud-init:New> <cloud-init (Ubuntu):Incomplete> <maas (Ubuntu):New> <https://launchpad.net/bugs/1645644>
[21:38] <mup> Bug #1645644 changed: ntp not using expected servers <cloud-init:New> <cloud-init (Ubuntu):Confirmed> <maas (Ubuntu):Invalid> <https://launchpad.net/bugs/1645644>


[01:41] <Glamdesk> Okay. I'm confused. I'm almost entirely certain I'm running lubuntu 16.04, but (I'm trying to use Xephyr to do something with Wine that has been notoriously difficult to do any other way for a decade or more) when I try to use startlxde, it says, The program 'startlxde' is currently not installed.
[01:41] <Glamdesk> Isn't lubuntu using lxde?
[13:25] <slipttees> Hi guys
[13:26] <slipttees> Where call script in local user after logout?
[13:28] <slipttees> run script in logout session
[13:29] <slipttees> for current user
[14:22] <demophobia> Please revise the help.ubuntu.com/community/Lubuntu/InstallingLubuntu page as it is apparently 4 years old
[18:59] <demophobia> How do I get wireless internet working in lubuntu?
[18:59] <demophobia> I have a Dell D620 using Lubuntu LTS (i think 16)
[18:59] <demophobia> (16.04)


[18:14] <jay_> Hello. I'm interested in somehow getting involved with the accessibility team. I'm not sure exactly how I could help out - perhaps with application testing - but I'd like to do what I can.
[18:17] <jay_> Would anyone be able to point me in the right direction to get plugged in and involved?
[18:22] <AlanBell> hi Arcitens
[18:23] <Arcitens> hi
[18:23] <Arcitens> how are you doing?
[18:25] <AlanBell> not too bad, you wanted to get involved in accessibility
[18:25] <AlanBell> which is great
[18:25] <AlanBell> in the topic there are links to the mailing list and the wiki area
[18:26] <Arcitens> yes, I've looked at the wiki a little bit, including the testing page
[18:32] <Arcitens> I'm interested in helping with application testing, but I'm not sure how or where to get started. I'm also interested in helping with wherever there needs help.
[19:10] <AlanBell> one thing that is coming up is testing of the new unity interface in Natty
[19:11] <charlie-tca> And we would like help with testing that, including trying to write up what works and filing bugs for what doesn't
[19:13] <Arcitens> Ok. I might be interested in that. I'm also interested in testing applications, since that also goes beyond Ubuntu.
[19:16] <Arcitens> But either way how would I get involved?
[20:10] <Arcitens> Ok. I'm going to head out. I'll be back tomorrow. Looking forward to getting involved.
[20:11] <charlie-tca> AlanBell: Do we need to make a list of things to test? or can we just create a wiki page and let testing happen?
[20:35] <Pendulum> charlie-tca: I think we need a good sense from TheMuso about what he thinks are most likely things to test
[20:36] <Pendulum> and then create a priority list so that we know at least the most important things get tested
[20:37] <charlie-tca> Okay. Right now, we know most things are broken in Natty, but we could have tests run on applications using Maverick. At least that was my thought


[02:38] <tsimonq2> PabloRubianes: Thanks! :)
[07:49] <MooDoo> morning
[21:26] <rashi-dido> Hello I would like to chat with someone about some ubuntu issues, please.
[21:26] <CrazyLemon> rashi-dido join #ubuntu for ubuntu support
[21:26] <wxl> rashi-dido: are you looking for support?
[21:26] <pleia2> this channel is for organizing local events in your area, if you want support for the operating system you should /join #ubuntu
[21:27] <wxl> his issues may relate to locos
[21:27] <rashi-dido> Thank you
[21:27] <wxl> everyone settle down :)
[21:27] <wxl> his/her i shoudl say
[21:27]  * wxl curses patriarchy
[21:33] <rashi-dido> Is this the proper place to ask for help with ubuntu issues?


[12:40] <cjohnston> mhall119: for what its worth, you can count me out of pretty much anything until atleast tuesday.
[12:55] <mhall119> tuesday of next week?
[12:56] <mhall119> or tuesday of UDS?


[19:05] <uni4dfx> where can i find the latest ubuntu/debian builds?
[21:25] <SpamapS> uni4dfx: https://launchpad.net/ubuntu/+source/upstart
[21:26] <uni4dfx> ah but those are really outdated
[21:26] <SpamapS> those are the latest *ubuntu* builds
[21:26] <uni4dfx> well yeah, i was just hoping for v1.1
[21:27] <SpamapS> So are we. :) The delta got a bit out of hand last cycle.. hopefully that will be resolved soon.
[21:28] <uni4dfx> any clue whether they will be ready til june?
[21:28] <uni4dfx> or at least IN june
[22:27] <SpamapS> Not sure. I know that there's an ongoing effort to push the Ubuntu-only changes into the 1.x branches... but it has hit a number of roadblocks.


[16:32] <tyhicks> hello
[16:32] <mdeslaur> \o
[16:33] <leosilva> o/
[16:33] <tyhicks> #startmeeting
[16:33] <meetingology> Meeting started Mon Oct 30 16:33:18 2017 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:33] <meetingology> Available commands: action commands idea info link nick
[16:33] <tyhicks> The meeting agenda can be found at:
[16:33] <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:33] <tyhicks> [TOPIC] Weekly stand-up report
[16:33] <tyhicks> jdstrand: you're up
[16:33] <jdstrand> hey
[16:33] <jdstrand> * finalize snappy-debug fixes (based on sprint feedback)
[16:33] <jdstrand> * follow through on some policy updates for 2.29
[16:33] <jdstrand> * layouts reviews (as needed)
[16:33] <jdstrand> * various followups for two reported regressions in udev tagging/device cgroups
[16:33] <jdstrand> * verify uhid interface is working correctly after udev tagging
[16:33] <jdstrand> * look into broadcom-asic-control interface bug where interface is not connected if the module doesn't exist
[16:33] <jdstrand> * continue uid/gid seccomp arg filtering as have time
[16:34] <jdstrand> that's what I plan to work on this week ^
[16:34] <jdstrand> mdeslaur: you're up
[16:34] <mdeslaur> I'm on CVE triage this week
[16:34] <mdeslaur> and I'm working on quagga updates
[16:34] <mdeslaur> I'll be picking up something else after that
[16:34] <mdeslaur> that's about it
[16:35] <mdeslaur> sbeattie: you're up
[16:35] <sbeattie> I'm in the happy place this week
[16:35] <sbeattie> I've got a couple leftover tasks from the apparmor online sprint to finish up
[16:36] <sbeattie> kernel updates should be happening this week, so I need to finish some signoff tasks and publish USNs for those
[16:36] <sbeattie> I have openjdk-8 updates from tdaitx to test and publish
[16:36] <sbeattie> after all that, I'll try to pick up another update or two
[16:36] <sbeattie> that's it for me. tyhicks?
[16:37] <tyhicks> sbeattie: I think CVE tracking for snaps should still be a high priority for this week
[16:37] <tyhicks> I'm in the happy place this week
[16:37] <tyhicks> I'm still trying to get to eCryptfs kernel patch review
[16:38] <tyhicks> then I'll start working on squashfs image reproduceability
[16:38] <tyhicks> I also have some embargoed issues
[16:38] <tyhicks> sarnold: you're up (jj is out)
[16:38] <sbeattie> tyhicks: fair point.
[16:39] <tyhicks> sarnold isn't here yet
[16:39] <tyhicks> chrisccoulson: you're up
[16:39] <chrisccoulson> I've got a chromium update to test and publish
[16:40] <chrisccoulson> There was also an unscheduled firefox release last week which I wasn't aware of until after it happened. I'm not sure yet whether to ship that
[16:40] <chrisccoulson> Then I've got to get rust updated to 1.21
[16:40] <leosilva> wee, rust updates.
[16:40] <chrisccoulson> I'd like to think I'd get time to do something else this week, but that hasn't worked very well in recent weeks
[16:41] <chrisccoulson> that's me done
[16:41] <chrisccoulson> leosilva, yeah, fun ;)
[16:41] <ratliff> I'm in the happy place this week.
[16:41] <ratliff> I have some writing assignments. When those are done, I want to work on integrating InfluxDB into our KPIs.
[16:41] <ratliff> on to you, leosilva
[16:42] <leosilva> I'm bug triage this week.
[16:42] <leosilva> I did push some USN this morning
[16:42] <leosilva> I have some bug to investigate in bug triage role
[16:42] <leosilva> besides that I'll do my usual hunting for pkg to update.
[16:42] <leosilva> That's all for me.
[16:42] <leosilva> tyhicks: it's back to you!
[16:43] <tyhicks> thanks!
[16:43] <tyhicks> [TOPIC] Highlighted packages
[16:43] <tyhicks> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[16:43] <tyhicks> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:43] <tyhicks> https://people.canonical.com/~ubuntu-security/cve/pkg/git-hub.html
[16:43] <tyhicks> https://people.canonical.com/~ubuntu-security/cve/pkg/guacamole-client.html
[16:43] <tyhicks> https://people.canonical.com/~ubuntu-security/cve/pkg/revelation.html
[16:43] <tyhicks> https://people.canonical.com/~ubuntu-security/cve/pkg/ruby-rack.html
[16:43] <tyhicks> Does anyone have any other questions or items to discuss?
[16:43] <tyhicks> https://people.canonical.com/~ubuntu-security/cve/pkg/ettercap.html
[16:43] <tyhicks> [TOPIC] Miscellaneous and Questions
[16:45] <tyhicks> jdstrand, mdeslaur, sbeattie, ChrisCoulson, ratliff, leosilva: Thanks!
[16:45] <sarnold> sorry I'm late, I lost track of time
[16:45] <ratliff> thank you, tyhicks!
[16:45] <tyhicks> #endmeeting
[16:45] <meetingology> Meeting ended Mon Oct 30 16:45:41 2017 UTC.
[16:45] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-10-30-16.33.moin.txt
[16:46] <sbeattie> tyhicks: thanks!
[16:46] <tyhicks> sarnold: go ahead and mention your plans for the week and I'll include them in the wiki page
[16:47] <sarnold> tyhicks: community this week, there's the spice-vdagent to finish up, pcp review, apparmor patche review if necessary, and an embargoed issue
[16:47] <sarnold> thanks tyhicks :)
[16:47] <tyhicks> thanks!
[16:50] <mdeslaur> thanks tyhicks