[00:00] <nekohayo> hmm any ideas?
[00:00] <jam> nekohayo: something about that machine
[00:00] <jam> and I don't think I have access to it
[00:00] <vila> jam: wow, you're damn right, on my Ubuntu box I see:
[00:00] <jam> lifeless, pool?
[00:00] <jam> poolie: ?
[00:00] <vila> ...vice.LaunchpadServiceTests.test_unknown_service   OK                   0ms
[00:00] <nekohayo> jam, what machine?
[00:00] <jam> nekohayo: the PQM machine
[00:01] <jam> things seem to run fine locally, but running very slow on our merge bot
[00:01] <jam> https://pqm.bazaar-vcs.org/
[00:01] <nekohayo> no I meant for http://ecchi.ca:8000/bzr-question-spiced-ham.htm :)
[00:01] <nekohayo> (unless this is related?)
[00:01] <jam> nekohayo: sorry, completely unrelated, I didn't see your IRC post at all
[00:01] <poolie> jam, hi
[00:02] <vila> hi poolie
[00:02] <nekohayo> (that is a big question that I wrote as a html page to avoid spamming :)
[00:02] <poolie> nekohayo: can you post it to the list instead, it looks like it will take some thinking about
[00:02] <jam> nekohayo: what do you mean by "specto used cvs, svn, and bazaar, all with branches that lost history between the switches"
[00:02] <jam> ?
[00:02] <nekohayo> jam, I mean that specto, across its lifetime as a project, used 3 different version control systems
[00:02] <nekohayo> and each time, we did not keep the history
[00:03] <jam> nekohayo: converting from svn and converting from CVS do not generate conversions that are compatible
[00:03] <jam> hence why you saw the big set of conflicts.
[00:03] <nekohayo> jam: uh? but the merge of the bzr-svn branch into the cvs one only created 4 minor conflicts (I think)
[00:04] <vila> jam, poolie: A new request arrived on pqm, but that's the only change, still at the same test... puzzling
[00:04] <jam> nekohayo: well, if you can post to the list, I agree with poolie, it is going to take a bit of thinking
[00:04] <nekohayo> merging the specto-woutc bzr branch into the new cvs+svn branch did the big conflicts though
[00:04] <nekohayo> ok
[00:04] <jam> if you can give some details about what is *in* the different branches, it would help.
[00:04] <jam> we have a phone call right now
[00:05] <jam> vila: different processes
[00:06] <vila> jam: I guess so. Well, time to sleep then, I'll see how it goes tomorrow :)
[00:24] <lifeless> jam: ?
[00:32] <keithy> Hi, I was using bzr ftp://
[00:32] <keithy> and it seams to use directories relative tot he root of the file system
[00:32] <poolie> i don't have any great ideas about pqm performance
[00:32] <poolie> i am seeing some tests failing inside pycurl
[00:32] <poolie> this is odd
[00:33] <keithy> but how does it manage that , when I login using ftp myself I dont see the root of the file system
[00:33] <bob2> keithy: can you cd / when you login using a ftp client?
[00:34] <keithy> ah.. it it appears so
[00:34] <keithy> duh
[00:34] <poolie> keithy: i think you can use //host/~/foo
[00:34] <poolie> if you wish
[00:34] <poolie> hello bob2
[00:34] <keithy> ty
[00:37] <spiv> jam: I have a test for your bug, sending it to the list
[00:43] <lifeless> the machine is not dedicated solely to bzr
[00:43] <lifeless> its possible there is some other load
[00:44] <jam> lifeless: I was wondering if you would have an idea why the PQM machine is taking 100+ ms for a test that runs here in <3ms
[00:44] <jam> lifeless: further, pqm seems a bit wedged
[00:44] <jam> It has been showing the same step of Vincent's patch for ~1hr
[00:44] <jam> spiv: thanks
[00:45] <poolie> spiv, i feel like we ought to have a coding standard about isinstance vs type etc
[00:45] <poolie> if only to avoid it being rehashed in every review
[00:45] <poolie> maybe also to document which one is fastest
[00:46] <jam> spiv: bb:approve
[00:46] <spiv> poolie: That sounds good to me.
[00:48] <lifeless> top - 00:48:14 up 220 days,  4:25,  1 user,  load average: 0.07, 0.06, 0.07
[00:48] <poolie> jeez firefox is flakey recently
[00:48] <poolie> lifeless: that's pqm?
[00:48] <lifeless> yes
[00:49] <lifeless> its running just the bzr test at the moment, no other things interfering
[00:49] <TFKyle> hmm, bb over IRC, interesting
[00:54] <abentley> TFKyle: please no
[01:07] <poolie> lifeless: so it seems like the test must be wasting time if it's running but the load avg is so low, like it's blocking on io or sleeping a lot
[01:07] <lifeless> yes
[01:14] <elmo> the machine's entirely idle; it's not blocking on io
[01:14] <elmo>  1  0   5392<PHONE_NUMBER>52 1489500    0    0     0     0  102    22  0  0 100  0
[01:14] <elmo>  1  0   5392<PHONE_NUMBER>52 1489500    0    0     0     0  103    26  0  0 100  0
[01:14] <elmo> ^-- vmstat output
[01:16] <poolie> thanks elmo
[01:16] <poolie> that's a bit fucked then...
[01:19] <lifeless> spiv: ping
[01:19] <poolie> could either of you maybe strace the process to get some idea of what it is doing?
[01:19] <lifeless> spiv: I would like you to be the reviewer for http://bundlebuggy.aaronbentley.com/request/%3C1209531548.29242.542.camel%40lifeless-64%3E if you would
[01:20] <spiv> lifeless: ah-hah.  I was just looking over that code yesterday to get a sense for what was coming :)
[01:20] <spiv> lifeless: So I'm happy to review that.
[01:23] <elmo> poolie: strace says it's in a futex and not much more
[01:58] <keithy> hello, can I break a lock on a repo?
[01:59] <spiv> Yep, "bzr break-lock PATH"
[01:59] <keithy> ty
[02:04] <poolie> elmo: thanks
[02:26]  * igc food
[02:34] <poolie> has anyone else seen bug 225020?
[02:35] <spiv> poolie: I have
[02:36] <spiv> poolie: I spent a while digging into without making much progress (except that I suspect libcurl is doing dumb things, like confusing actual errors with notifications about the exceptfds you can pass to select)
[02:37] <spiv> poolie: at the time, no-one else seemed to have heard of it, so I just assumed that my freshly-upgraded hardy system had something strange going on.
[02:37] <spiv> (I only upgraded to hardy a month ago)
[02:38] <spiv> poolie: "echo raise ImportError > pycurl.py" in the root of your bzr checkout is a workaround, of sorts.
[02:38] <poolie> :/
[02:38] <poolie> also, why didn't the robot link that bug, i wonder?
[02:39] <spiv> Is the robot in the channel?
[02:39] <spiv> I see ubuntulog, but not ubotu or whatever it is called.
[02:39] <poolie> ubugtu?
[02:41] <bimberi> ubotu is currently gone, I think that work is being done on replacements.
[02:41] <bimberi> Ref: https://lists.ubuntu.com/archives/ubuntu-irc/2008-April/000443.html
[02:41] <poolie> spiv, btw last night i started work on deprecating LockableFiles from a different direction and it went quite well
[02:41] <poolie> it may be i just haven't got to the hard part yet
[02:42] <spiv> poolie: oh, great!
[02:43] <poolie> bimberi: thanks for the reference, that's kind of unfortunate though
[02:45] <bimberi> poolie: np. And yes it is.  I've noticed an 'ubottu' in some other channels.  I guess #ubuntu-ops would be a good place to ask.
[02:48] <poolie> i don't know many of the people in that thread but it's an unfortunate sounding situation
[03:04] <poolie> spiv, maybe it only happens with -Werror and it actually reflects an error in the server code?
[03:06] <abentley> poolie: where do we stand with bzr 1.4?
[03:06] <poolie> it looks like we want to merge #214894 into it, i'm reading that and will do final today with only that change?
[03:07] <spiv> poolie: I think I saw the pycurl problem without -Werror.  I used strace and didn't see any sign of a problem on the server side, IIRC.
[03:08] <spiv> Ah, I think I still have the straces somewhere.
[03:08] <spiv> The straces also showed no error return from poll(2) either, IIRC.
[03:09] <abentley> "Should be represented as XXX"?
[03:09] <spiv> poolie: http://rafb.net/p/dlbvkD76.html
[03:09] <spiv> abentley: d'oh.
[03:11] <spiv> poolie: that paste is part of an strace of a test run.  Straight after that it starts re-reading .py files to build the traceback for the exception raised by pycurl.
[03:11] <poolie> abentley: what are you quoting?
[03:12] <spiv> poolie: but the server behaved correctly (and as expected), that test server does not allow POST
[03:12] <abentley> poolie: I'm quoting a comment from spiv's patch for #214894
[03:12] <spiv> My test had a half-written comment.
[03:13] <poolie> oh ok
[03:13] <poolie> abentley: pqm seems unreasonably slow today for unclear reasons
[03:13] <poolie> not sure if you saw before
[03:13] <poolie> :/
[03:13] <abentley> No, I wasn't sure what you guys were stracing.
[03:14] <poolie> i was going to put this text at the head of the release
[03:14] <poolie> http://rafb.net/p/JNXf7H59.html
[03:17] <poolie> spiv, my shelves turned up so after i send off this merge i will head to hornsby if that suits you
[03:17] <poolie> will probably lunch here first
[03:17] <spiv> abentley: I've fixed the XXX in the docstring in my branch, and thanks to PQM being so slow the corrected version will be merged.
[03:17] <spiv> poolie: sounds good
[03:17] <abentley> spiv: heh!
[03:17] <spiv> abentley: thanks for catching that :)
[03:17] <abentley> spiv: no problem.
[03:18] <abentley> I wish I'd had the option a few days ago when I accidentally merged the wrong branch.
[03:18] <spiv> Hmm, PQM isn't so much slow as wedged, AFAICS.
[03:39] <lifeless> poolie: ping
[03:41] <poolie> pong
[03:41] <poolie> lifeless: pong
[03:41] <lifeless> I'm trying to figure out store url escaping
[03:41] <poolie> k
[03:41] <lifeless> I seem to be getting double escaping
[03:43] <poolie> ok
[03:43] <poolie> sorry to interrupt you but pqm seems to be barely making progress at all
[03:43] <poolie> it is according to the web still working on the same job it was when i started this morning
[03:44] <lifeless> its hung on a futex
[03:44] <poolie> oh, hung as opposed to just spending lots of time in futexes?
[03:45] <lifeless> pqm@balleny:~$ strace -p 16075
[03:45] <lifeless> Process 16075 attached - interrupt to quit
[03:45] <lifeless> futex(0x1a30e90, FUTEX_WAIT, 0, NULL <unfinished ...>
[03:45] <lifeless> Process 16075 detached
[03:45] <poolie> maybe we should kill it and let the next job through then?
[03:45] <lifeless> done
[03:45] <poolie> thanks
[03:46] <poolie> so back to your escapism
[03:46] <lifeless> test_escaped_store
[03:46] <lifeless> has a test_weave in it
[03:46] <lifeless> as far as I can tell, it should be double escaping with bzr.dev
[03:48] <poolie> not sure what you're asking me - to check your logic, if this is a bug, why it is this way, ...?
[03:49] <igc> lifeless: wrt MutableTree.put_file_bytes_non_atomic, why "non_atomic" as a suffix?
[03:50] <lifeless> because its not atomic
[03:50] <poolie> igc, it means "don't do the rename-into-place thing"
[03:50] <poolie> people reading the file may see it half-written
[03:50] <poolie> could be good to put that in the developer guide
[03:51] <igc> poolie, lifeless: ah - ok
[03:52] <igc> the wt.put_file_bytes_non_atomic docstring refers to the MutableTree one but the latter doesn't exist
[03:52] <igc> I'll add it
[03:54] <lifeless> poolie: I'm trying to figure out what is going on
[03:54] <lifeless> poolie: e.g. store.filename(' ') -> '88/%2520'
[03:54] <lifeless> poolie: but the test looks for '88/%20' successfully
[03:54] <lifeless> my replacement mapper code returns the same result from filename
[03:55] <lifeless> but the test fails (because the file on disk is 88/%2520.weave)
[03:56] <lifeless> ah I think I have found it
[05:18] <LaserJock> is there a recommended way to use bzr to track a cvs repo? would cvsps work?
[05:21] <LaserJock> most of the tools I've seen seem to be made for one shot conversion, where I want to be able to track a CVS repo
[05:21] <lifeless> launchpad
[05:21] <lifeless> or cscvs which is what launchpad uses
[05:21] <LaserJock> well, yeah, launchpad could work if it was up-to-date
[05:21] <lifeless> it tries hard to handle just about any stupidity people do to cvs
[05:21] <LaserJock> but it frequently lags
[05:22] <LaserJock> maybe the best would be to just keep a close eye on the LP import and keep poking
[05:24]  * igc food
[05:24] <mwhudson> LaserJock: which import?
[05:24] <LaserJock> the one I want to track is about 5 months behind or so :/
[05:25] <LaserJock> mwhudson: https://code.launchpad.net/~vcs-imports/gchemutils/trunk
[05:25] <LaserJock> it's just difficult to have to keep track of LP
[05:25] <LaserJock> I end up tacking the CVS anyway just to make sure I'm not missing stuff
[05:27] <mwhudson> oh and gah, we lost all the code imports log files earlier on today
[05:27]  * mwhudson gives the import a kick
[05:27] <LaserJock> although in looking at the 4 imports that I'd use on a daily basis gchemutils is the only one that's not up-to-date
[05:28] <LaserJock> it's also the only one that is CVS, which may explain it
[05:28] <mwhudson> LaserJock: it's https://bugs.edge.launchpad.net/launchpad-cscvs/+bug/120977 :(
[05:28] <mwhudson> so it's not going to start working again until we get some time to fix that
[05:29] <mwhudson> (or someone else fixes it, cscvs is open source after all, but people who know enough about cvs are probably a bit thin on the ground)
[05:29] <LaserJock> bummer :/
[05:29] <mwhudson> yar
[05:30] <LaserJock> that's the one I especially would love to work with in bzr
[05:30] <LaserJock> as I can't make head or tails of CVS to save my life
[05:30] <LaserJock> but the project is very important to me
[05:30] <LaserJock> so I struggle on ;-)
[05:31] <LaserJock> right now I'm using git-cvs to track it
[05:31] <LaserJock> which works pretty well, but I'm trying to convert all my git stuff to bzr
[05:32] <LaserJock> mwhudson: is it possible to just start the import later?
[05:32] <mwhudson> LaserJock: if you run cscvs by hand maaaybe
[05:33] <LaserJock> this is one thing I keep running into with DVCS
[05:33] <LaserJock> I would verrrry rarely need to go to revision 1
[05:33] <LaserJock> but often times if something breaks somewhere in history the whole thing is screwed
[05:34] <LaserJock> it would be nice to just say "gimme the stuff from the last year"
[05:34] <LaserJock> if that makes any sense :-)
[05:36] <LaserJock> mwhudson: is there a way for users to see if a vcsimport is out of sync without having to get the original repo?
[05:36] <LaserJock> mwhudson: I think the value of LP code hosting goes way down if users can't be assured that they're getting the latest revision
[05:36] <mwhudson> LaserJock: well, the "Last imported: 28 weeks ago" on https://code.edge.launchpad.net/gchemutils/trunk is a pretty large clue
[05:37] <LaserJock> yeah, for that one sure
[05:37] <LaserJock> but there's nothing like a failure flag or something?
[05:37] <mwhudson> this should, and soon-ish will be, on the branch page
[05:37] <mwhudson> hm, no
[05:38] <mwhudson> probably should be though
[05:38] <mwhudson> LaserJock: file a bug about that?
[05:38] <LaserJock> ok
[05:38] <LaserJock> I'm just concerned
[05:38] <LaserJock> because when somebody says "are you building from HEAD?" I need to be able to confidently reply
[05:39] <LaserJock> not, "well let me go poke around to make sure LP is up-to-date"
[05:40] <LaserJock> I guess it's good enough for users
[05:41] <mwhudson> well, i can't really see how you can be sure
[05:41] <LaserJock> but if you're hacking on irc with fellow developers it's not really gonna work
[05:41] <mwhudson> i mean, the imports lag by a few hours on average
[05:41] <LaserJock> well, that's sort of my point
[05:42] <mwhudson> well, how can launchpad know it's out of date?
[05:42] <LaserJock> well
[05:42] <LaserJock> it can't exactly
[05:42] <mwhudson> there is a sort of plan floating around where launchpad should be able to subscribe to a commits mailing list
[05:42] <mwhudson> and will update whenever it receives a mail
[05:42] <LaserJock> but I wonder if you could somehow give a time since last import
[05:43] <mwhudson> but i don't think it's even written down, never mind scheduled
[05:43] <mwhudson> https://edge.launchpad.net/drupal/main -> "Last imported: 28 minutes ago"
[05:43] <LaserJock> bottom line though, LP vcsimports are not really designed for developers methinks
[05:43] <poolie> lifeless: hi, are transactions meant to be getting removed?
[05:44] <poolie> ie the control_files.get_transaction and so on?
[05:44] <lifeless> yah
[05:44] <lifeless> I didn't break api but I stopped their use in stores in 1.4
[05:44] <lifeless>  branch may still use them
[05:44] <poolie> ok
[05:44] <poolie> as i may have said yesterday
[05:45] <poolie> i think removing LockableFiles is becoming more important, to enable improvements in Remote
[05:45] <poolie> so if less stuff uses them, and we can either just delete them or at least have less to update
[05:45] <poolie> all the better
[05:46] <spiv> mwhudson: if launchpad had an API for "please mirror now", a 3rd-party could arrange for that to happen for themselves without waiting for the launchpad feature.
[05:46] <mwhudson> spiv: yes
[05:46] <mwhudson> spiv: it's on the cards
[05:49] <LaserJock> mwhudson: bug filed
[05:49] <awmcclain> Hey all... are there docs somewhere about how to log to .bzr.log? I'm trying to debug bzr-email.
[05:52] <spiv> awmcclain: "from bzrlib.trace import mutter; mutter('this goes to the log file')"
[05:52] <spiv> awmcclain: see the bzrlib.trace module in general
[06:56] <lifeless> poolie: I think having less stuff use them is good
[07:07] <poolie> lifeless: i want to bounce a testing idea off you
[07:07] <poolie> that is that we should make use of the lock taken/released events to assert that less than N locks are acquired in the blackbox test for push
[07:07] <poolie> eventually we want similar assertions on smaller levels
[07:08] <lifeless> such tests are one of the things I had in mind with the lock hooks
[07:08] <poolie> but since people sometimes add "oh and also" code to the cmd_ it might be good to cover it at a high level
[07:08] <poolie> me too
[07:08] <poolie> great
[07:13] <poolie> lifeless, was that actually merged yet?
[07:14] <poolie> abentley: BB is down :?
[07:21] <lifeless> poolie: dunno
[07:33] <bimberi> \o/
[07:34] <bimberi> bug 225020
[07:44] <lifeless> spiv: how did my branch look?
[07:50] <spiv> lifeless: Haven't looked yet, I've been pairing with poolie
[07:50] <spiv> lifeless: I expect to do it tonight and first thing tomorrow, though.
[07:51] <lifeless> cool
[07:54] <lifeless> poolie: I have the mapping code looking good; was rather confused by the apparent double-escaping
[07:54] <lifeless> poolie: turns out we return urls not paths from the public interface, even though it talks paths. This will get cleared up by my following work
[07:58] <lifeless> and with that, its halt() time for me. See you tomorrow.
[07:58] <lifeless> hi sabdf1, bye sabdfl :)
[08:46] <sabdf1> night lifeless
[12:58] <james_w> If I'm creating ghosts as part of an import I just add extra parents when needed correct? I don't need to add ghost records of any sort?
[12:58] <james_w> Also, just generating a new random revid is fine, as I can just look up the needed revid when I come to create the ghost later?
[13:42] <spiv> james_w: I think so.
[13:43] <james_w> spiv: thanks.
[13:45] <lamby> jelmer: I've just packaged (and pushed) bzr-gtk 0.94.0rc1 but the shiny log is now broken (and I don't know how to fix it) :'(
[13:45] <jelmer> lamby: Thanks!
[13:45] <lamby> jelmer: I did manage to patch a few other problems, which almost certainly need to go upstream.
[13:45] <jelmer> lamby: Shiny log being "bzr viz" ? :-)
[13:46] <lamby> Indeed. To be clear, it only breaks when you load it via olive-gtk.
[13:46] <jelmer> ahh, ok. I don't use olive so that must be why I've missed it
[13:47] <lamby> The other patches are in debian/patches on our alioth repo. Enjoy o/
[13:47] <jelmer> lamby: Cool, thanks again :-)
[14:02] <awilkins> jelmer: Confirm that "bzr viz" doesn't work via olive
[14:03] <awilkins> jelmer: I meant to put a bug up for it...
[14:05] <awilkins> What is abentley doing to the main BB server? It's always down...
[14:06] <abentley> awilkins: I'm trying to fix it.
[14:06] <awilkins> I suppose that's logical ;-)
[14:09] <abentley> Unfortunately, there appear to be bugs in the visitor tracking part of Turbogears that are threading bugs that I can't reproduce locally.
[14:20] <jelmer> abentley: btw, do you have any idea what could cause this<EMAIL_ADDRESS>[14:21] <abentley> Yeah, that could be an attempt to treat something as a merge directive that is really a bundle or a patch.
[14:22] <abentley> I ran into that a while back, but I can't remember whether I fixed it.
[14:24] <abentley> jelmer: are you up-to-date with my changes?
[14:24] <jelmer> I'm running my own branch, which has the RSS support but may not be up to date
[14:25]  * jelmer checks for missing revs
[14:28] <abentley> Looks like I fixed it in revno 242
[14:30] <abentley> It would be a merge request *without* a patch, actually.
[14:35] <jelmer> crap, updating actually broke bundlebuggy altogether
[14:43] <abentley> jelmer: I've changed the way mail is handled in BB, to deal with the fact that BB's been unstable.
[14:43] <abentley> Now procmail delivers mail to a mail_queue directory, and BB checks for new mail there.
[14:46] <abentley> jelmer: But it looks as if your problem is you haven't updated the database schema.
[14:47] <abentley> The migrate script should do that for you.
[18:11] <jelmer> abentley, thanks
[18:12] <abentley> jelmer: np
[18:18] <vila> abentley: do you have access to the pqm machine ? It looks like my last submission make it hang again >-/ (It did this morning lifeless killed it I guess)
[18:19] <abentley> vila: No, sorry.
[18:20] <vila> too bad, do you  remember *how* it run the test suite ? And/Or what its config is, I'm totally puzzled about what can cause this...
[18:20] <jelmer> abentley: Did you improve performance in bb by any chance?
[18:21] <jelmer> it seems significantly faster to me
[18:21] <abentley> jelmer: Yes, I have done some optimization.
[18:59] <abentley> jelmer: Also, you should find that your hacks to place BB's root at a sub-url are no longer necessary.  Please let me know if there's anything I've missed.
[19:00] <jelmer> abentley: it still redirects to localhost:8089 after voting using the web interface
[19:07] <abentley> jelmer: that uses the application root.  If you've got that configured correctly it should take you to the correct place.
[19:08] <abentley> jelmer: try configuring server.webpath
[19:11] <jelmer> abentley: it's the host name that it doesn't get right, the path in the request is fine
[19:12] <jelmer> is there an option for that?
[19:12] <abentley> yes.
[19:12] <abentley> I use: base_url_filter.on = True
[19:12] <abentley> base_url_filter.use_x_forwarded_host = True
[19:13] <abentley> You can also specify the base url yourself.
[19:13] <abentley> Are you running using dev.cfg or prod.cfg?
[19:13] <Peng> Wait, when using bzr+ssh, autopacking isn't done by the server?
[19:14] <abentley> Peng: Correct.
[19:14] <beuno> Peng, no, autopacking is always done client-side, AFAIK
[19:14] <Peng> Oh.
[19:14] <Peng> I thought it was done by the server.
[19:14] <Peng> Maybe someone said that it was a possibility (which it is), and I misinterpreted it.
[19:14] <abentley> That's how we'd like it to work, not how it works right now.
[19:17] <Peng> Yeah.
[19:17] <Peng> Huh.
[19:18]  * Peng leaves.
[19:40] <vila> lifeless: If (and/or when) you look at pqm, can you try to have a look at *where* selftest is hanging, I really have no clue on how to debug this :-/
[19:42] <vila> The only I can think about that can explain is a test order dependent bug since I changed the overall test suite order when merging in a single list the modules that were defining test_suite()  and those what were using LoadTestsFromModule...
[19:42] <vila> s/only/ only cause/
[19:43] <vila> Grr, I hate blind debugging :-(
[20:25] <Peng> Ack, now push-and-update is getting DeprecationWarnings in bzr.dev.
[20:25] <Peng> Thanks to install_hook.
[20:36] <Peng> Think it's worth enabling the "bzr://" smart protocol on a server?
[21:01] <ja1> Peng: push-and-update should be fixed for install_named_hook
[21:01] <ja1> as should bzr-email
[21:01] <jam> well, at least once my commit finishes
[21:01] <Peng> Yay.
[21:06] <Peng> Wait, when does push-and-update's hook come into effect?
[21:06] <jam> Peng: it has to register itself at plugin load time
[21:06] <jam> so it is calling install_hook all the time
[21:07] <jam> the hook isn't being called, but it needs to be installed
[21:07] <Peng> Yeah, but when does it actually do its thing? On every push?
[21:08] <jam> Peng: on every push it checks if the remote has a working tree, if it does, it then does 'ssh host bzr update path'
[21:08] <Peng> Huh.
[21:08] <jam> Peng: so it won't create WTs that aren't there, but if there is one, it tries to keep it up to date
[21:08] <Peng> I didn't know that.
[21:09] <jam> I think I also included a hacky workaround to get it to not complain about "this transport does not update the WT"
[21:10] <Peng> Yes, you did.
[21:39] <vila> jam: Do you know where I can find how pqm run the test suite ?
[21:39] <jam> vila: make check
[21:39] <jam> vila: so "Makefile" has the details
[21:39] <vila> jam: grrr, thanks a lot ;-)
[21:40] <jam> it should be something like "python -O -Werror ./bzr selftest" and "LANG=C ..."
[21:41] <vila> lol,     import docutils
[21:41] <vila> ImportError: No module named docutils
[21:41] <vila> :-)
[21:41] <vila> Bad vila
[21:48] <metameme> I'm new to bzr and my organization is switching to it from svn.  When using a centralized workflow, is it possible to have a post-commit hook like bzr-email be set up entirely on the server side, with zero client configuration?
[21:51] <jam> metameme: I believe we added a specific hook for it in bzr 1.4, if not, it will be in 1.5
[21:52] <jam> prior versions didn't quite have enough info
[21:52] <jam> ATM, bzr-email is not directly able to do it, because the hook is newer
[21:52] <metameme> jam: Okay, thanks.  It'll be a great feature to have.
[21:53] <jam> metameme: I believe someone already put together code with the older format, which runs as a cron script
[21:53] <jam> and just detects new revisions and emails them out
[22:05] <jelmer> abentley, how do I know whether I'm using dev.cfg or prod.cfg?
[22:11] <vila> jelmer, jam: did you run test-gtk lately ? One test is failing: test_diff_view
[22:12] <jam> vila: I don't think jelmer ever runs test-gtk, and I haven't done any hacking on it for a while
[22:12] <jam> the bzr-gtk project is *not* TDD
[22:12] <jam> bbiab
[22:12] <vila> hmm, bad Jelmer :)
[22:13] <vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
[22:14] <abentley> jelmer: If you use the bundled init script or do start-bundlebuggy prod.cfg or run start-bundlebuggy for an installed copy, you are using prod.cfg.
[22:15] <abentley> If you are getting lots of stuff spewed to the console, you are running dev.cfg.
[22:15] <jelmer> abentley: Looks like I'm using dev.cfg then :-)
[22:15] <jelmer> The base_url bits you mentioned seem to work, thanks!
[22:15] <abentley> No problem.
[22:16] <jelmer> it would be nice if these two settings were mentioned in the example dev.cfg for new bundlebuggy users..
[22:16] <jelmer> vila: Well, GUI unit testing is kinda hard
[22:17] <vila> jelmer: no worries, just joking, what about the other points ^
[22:17] <jelmer> vila: Which ones?
[22:17] <vila> anyway I'm hacking again on the '_' related problem, trying to implement it as _i18n as the last mail on the subject suggested, is that still the consensus ?
[22:18] <vila>  One test is failing: test_diff_view
[22:19] <vila> and, about the po files, how are you handling them ?
[22:19] <jelmer> abentley: Should mail_queue_location point to a mbox or maildir ?
[22:19] <vila> I tried genpot.sh but it broke and seems old
[22:19] <jelmer> vila: phanatic is handling all of the i18n stuff
[22:19] <jelmer> vila: We still need a PQM to make sure we don't get regressions like that
[22:19] <jelmer> lifeless, ping
[22:20] <vila> phanaric: ping (arf, not even online :)
[22:21] <vila> phanatic: ping (arf, not even online, but not a reason to typoed his nick :)
[22:25] <abentley> jelmer: It should point to a directory, not a maildir in particular.
[22:26] <abentley> You can point it at the maildir/new, if you like.
[22:29] <lamby> jelmer: Heh, fastest upstream merge evarr. (Thanks)
[22:48] <lifeless> jelmer: hi
[22:48] <lifeless> jelmer: pqm right?
[22:48] <jelmer> lifeless: you can read minds :-)
[22:57] <vila> lifeless: read my mind too, you'll find pqm :-/
[22:58] <lifeless> vila: no idea about your patch sorry
[22:59] <vila> lifeless: how about an interrupt to at least have a starting point on where it hangs ?
[23:00] <vila> Note that it is currently hanging for around 5 hours...
[23:00] <lifeless> the hang I saw it was waiting on a futex
[23:00] <lifeless> is it hung again?
[23:00] <vila> yes
[23:00] <lifeless> killed
[23:01] <vila> first time I thought it may have been the pqm, but now I'm really... killed ? Ghaa, how can I hope to debug it then :-(
[23:01] <lifeless> it runs within cron
[23:01] <lifeless> I can't pdb it when it hangs
[23:02] <vila> I see :(
[23:02] <lifeless> I can gdb but that is fiddly and much less useful
[23:02] <lifeless> it was waiting on futex
[23:02] <lifeless> that means its probably a server shutdown or some such
[23:02] <lifeless> this is your test-ids patch?
[23:03] <vila> the one changing test_suite() to load_tests()
[23:03] <vila> the only side-effect I see is that some tests are not run in the same order now, other than that....
[23:03] <lifeless> thats entirely possible to cause such an effect
[23:03] <lifeless> if we have an isolation bug
[23:04] <vila> I tried running all tests in isolation (i.e. one by one with --load-list) and so far nothing serious popped out
[23:04] <lifeless> I don't think you should ignore basic_tests ever
[23:05] <vila> basic_tests ?
[23:05] <lifeless> +    # since this module doesn't define tests, we ignore basic_tests
[23:05] <lifeless>      suite = doctest.DocFileSuite(*scripts)
[23:05] <lifeless> anyhow, assume that its ordering. You need to run two tests minimum to display an ordering problem
[23:05] <lifeless> one easy way to show such a thing is to invert the entire test order
[23:06] <lifeless> vila: also
[23:06] <vila> hmmm, pqm is running make check, running make check is ok...
[23:06] <lifeless> basic_tests is a suite
[23:06] <lifeless> you don't ever have to do
[23:06] <lifeless> suite = loader.suiteClass()
[23:07] <lifeless> suite.addTests(basic_tests)
[23:07] <lifeless> just use basic_tests directly.
[23:07] <lifeless> bb:tweak  :)
[23:07] <lifeless> you'll save lots of code
[23:08] <vila> right, I will do that anyway, but if it fixes the problem, I'll be really surprised
[23:09] <lifeless> this for loop
[23:09] <lifeless> +    for test in tests.iter_suite_tests(standard_tests):
[23:09] <lifeless> +        result.addTests(adapter.adapt(test))
[23:10] <lifeless> seems to be cropping up multiple times
[23:10] <vila> :-)
[23:10] <vila> Yup, I didn't want to stretch the patch, but I noticed it
[23:10] <lifeless> ok, I've read the patch end to end
[23:10] <lifeless> those are my comments; I can't see anything to cause a random hang.
[23:11] <lifeless> there are two causes i can think of:
[23:11] <lifeless>  - test ordering
[23:11] <lifeless>  - test parameterisation
[23:11] <lifeless> if its an ordering bug, one would expect that running the entire test suite in opposite order would *probably* show it
[23:12] <lifeless> so a simple patch that adds reversed(list(iter_suite_tests(test_suite))) to the end of bzrlib.test_suite()
[23:12] <lifeless> or just before the runner
[23:12] <lifeless> might be enough to trigger and show the problem
[23:13] <vila> I'll try that. Can you elaborate on the parameterisation cause ?
[23:13] <lifeless> test parameterisation - if the patch actually does change the semantics of one or more parameterised tests its possible that you're just causing a bug, but I didn't spot such a thing when I read the patch.
[23:15] <vila> Since the branch had a long live, I was paranoid about each merge and always checked that I got the same number of tests (that was one reason to keep that last patch in its own loom thread)
[23:15] <vila> Granted, number of tests was a simple metric, but
[23:15] <vila> no but
[23:17] <lifeless> :)
[23:17] <lifeless> back in a few minutes, shave & breakfast
[23:25] <vila> arf, arf, false hope:
[23:25] <vila> FAIL: test_selftest.TestTestIdList.test_test_suite
[23:25] <vila>     not equal:
[23:25] <vila> a = ['bzrlib.tests.blackbox.test_branch.TestBranch.test_branch',
[23:25] <vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
[23:25] <vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
[23:25] <vila>  'bzrlib.timestamp.format_highres_date']
[23:25] <vila> b = ['bzrlib.timestamp.format_highres_date',
[23:25] <vila>  'bzrlib.tests.test_transport_implementations.TransportTests.test_abspath(LocalURLServer)',
[23:25] <vila>  'bzrlib.tests.test_selftest.TestTestIdList.test_test_suite',
[23:25] <vila>  'bzrlib.tests.blackbox.test_branch.TestBranch.test_branch']
[23:32] <lifeless> spiv: when you arise, review ping
[23:34] <mwhudson> spiv: me too!
[23:34] <mwhudson> :)
[23:45] <vila> lifeless: selftest reversed just complete, except for the one test whose failure is understandable, nothing.   I'll dig the basic_tests route a bit just to check but if you can provide me with some data on pam, that may helps too (os/python versions, plugins ?).
[23:55] <lifeless> pam?
[23:55] <lifeless> if you mean pqm, its running dapper
[23:56]  * Peng looks at the topic.
[23:56] <Peng> Today today? Cool.
[23:56] <bob2> it said that yesterday, too ;)
[23:57] <Peng> The topic was set 23 hours ago.
[23:58] <vila> lifeless: s/azerty/qwerty/ :) yes pqm, python2.4 ?


[02:56] <kaStevie> Hello
[02:56] <kaStevie> I was just wondering if the design research on the software centre was available at all?
[03:18] <kaStevie> well, given I might be waiting a while for a response I may as well be m ore specific
[03:19] <kaStevie> I was currently looking for exactly who you are designing the software center for
[03:19] <hicham> for mere mortals
[03:20] <kaStevie> hicham: :) yes ofcourse
[03:21] <kaStevie> but more than mere mortals, is there some kind of archetype that is being designed for?
[03:28] <hicham> general users, not geeks :)
[03:29] <hicham> but I doubt this is the appropriate place to discuss that
[03:29] <hicham> software center isn't part of ayatana
[03:34] <kaStevie> would you know what it is part of?
[03:37] <hicham> I think #ubuntu will help you more than me
[03:40] <kaStevie> no one knows there, think I might just leave a note on the wikipage asking who owns the project / where I can get research if indeed any has been done and stuffs
[03:40] <kaStevie> thanks for your help
[03:45] <hicham> sorry, i am wrong
[03:45] <hicham> it appears that software management is part of ayatan
[03:45] <hicham> check out its page
[03:45] <hicham> http://wiki.ubuntu.com/Ayatana
[03:50] <kaStevie> is research done under the umbrella of ayatana usually made available?
[04:23] <hicham> yes, of course
[04:23] <hicham> it is open source :)
[09:23] <MrGoodbyte> Hi
[09:25] <MrGoodbyte> There is a problem in Unity. It doesn't update menu of an application even if it has changed. For example, MySQL Workbench's menu changes when you create an empty project
[09:26] <MrGoodbyte> but in Unity, it stays as it started
[10:01] <andyrock> good morning
[10:01] <hicham> morning
[10:02] <hicham> there are at least two rocks in ayatana : andyrock and didrocks
[10:03] <andyrock> hicham, didrocks has the copyright ;)
[11:47] <andyrock> compiz use glib main loop right?
[11:47] <andyrock> uses*
[12:26] <lamalex> andyrock, yah i believe so
[12:26] <andyrock> lamalex, thx
[12:54] <zniavre> good afternoon
[12:54] <zniavre> any chance to get notify-osd with border ?
[15:53] <zombie_> Bug#801931 Which package should I choose for this bug? Rite now I have set it to linux but I am confused.
[15:55] <zombie_> sry wrong channel
[15:57] <thumper> jcastro: ping?
[16:11] <kenvandine> ronoc, https://code.launchpad.net/~ken-vandine/indicator-sound/ifdef/+merge/66163
[16:11] <kenvandine> ronoc, i am applying that as a distro patch
[16:12] <ronoc> kenvandine, ah thanks, I'll make sure its in 0.7.3
[16:12] <kenvandine> thx
[16:31] <om26er> could anyone confirm bug 803029 in Oneiric ?
[16:33] <om26er> scrub slowly (incase you are trying to reproduce)
[16:36] <om26er> compiz is eating more than 10%cpu consistently on my revived-from-death netbook, Is there anything else I could do except for reporting the bug? like some logs etc?
[16:39] <om26er> Ok, its now back to normal after something like 15mins of cpu hog.
[20:11] <agent00tai> hi everyone, we'd like to use the unity panel service in our panel, is there any documentation on it?
[23:02] <jtn> Anyone got time to give me some pointers on how appmenu-gtk works?
[23:03] <jtn> I'm from Freeciv upstream. appmenu-gtk seems to be stealing some of our menubars in Unity, making the game unplayable. We'd like them back ;)
[23:04] <ajmitch> jtn: you can disable it per-application with 'export UBUNTU_MENUPROXY=0' before running it
[23:04] <ajmitch> though that's probably not the best option compared to having them just work :)
[23:05] <jtn> Sure -- we have this workaround. I'm after something more subtle, that will allow the main menubar to be indicator-ified while keeping the embedded ones where they belong.
[23:05] <jtn> All the gory details are at <https://bugs.launchpad.net/ubuntu/+source/freeciv/+bug/743265>.
[23:06] <jtn> In the appmenu-gtk source, I found it looking for a property "ubuntu-no-proxy". Perhaps I can decorate our menubars with this? Can anyone tell me how it's intended to be used?
[23:08] <jtn> The other thing that seems odd is that appmenu-gtk is suppressing the secondary menubars, but they don't show up in the output of "dbusmenu-dumper". Which suggests that something knows somehow how to distinguish the two kinds of menubar, but is losing one of them. Is that a bug in the appmenu stuff? (I could easily have missed something.)
[23:10] <ajmitch> I suspect that most people who could help are in the wrong timezone this week
[23:12] <jtn> Oh rats, are they all in Dublin?
[23:12] <jtn> Darn, we've got a release scheduled and I was hoping to put any workaround in.
[23:13] <ajmitch> I think a number of them are
[23:13] <ajmitch> Have you tried asking on the mailing list?
[23:13] <jtn> Not yet. I'll try that next.
[23:13] <jtn> thx


[02:54] <jose> wgrant: hey, around? I think I found something that could be classified as abuse
[02:59] <wgrant> jose: Hi.
[02:59] <jose> wgrant: mind if I pm?
[03:00] <wgrant> Sure.
[05:57] <ki7mt> Hello, is there anyone around that could help me troubleshoot a build failure? ALl goes well on pbuilder, but failes on Launchpad with an error: 'unknown': unknown terminal type.  I can't find anything on this error.
[13:28] <haniya> login to launcpad get long response
[15:39] <Laibsch> does LP recognize the github bug tracker?
[15:40] <Laibsch> I just tried to add https://github.com/blueman-project/blueman/issues/64 as the upstream ticket for #1283303 and it was refused
[15:42] <dobey> i don't think it does, no
[15:43] <Laibsch> :-/
[15:47] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/848666


[15:05] <Skyrider> Greetings all
[15:05] <Skyrider> I am in need of some help.. think my firewall, is... kinda? busted. It appears all allow rules in ufw works perfectly fine.. though, the deny/reject doesn't work at all.
[15:06] <Skyrider> I used a simple rule to deny my mobile IP to connect to the server, yet I can still load sites just fine.
[15:07] <teward> we'd need to see your rules you're trying to set up
[15:07] <teward> also UFW is specifically based on first-match so if your ALLOW rules are before your DROP/REJECT rules it will still allow
[15:08] <Skyrider> Anywhere                   DENY        <IP_ADDRESS> - is above the allow rules
[15:09] <teward> and you're *sure* your phone is using that IP actively?  (send your phone to https://ifconfig.co to find out)
[15:09] <teward> if it's NOT when it goes out to the 'net then that's why your rule doesn't work
[15:10] <Skyrider> According to that site, my mobile is using <IP_ADDRESS>
[15:10] <Skyrider> Which matches with the deny rule.
[15:11] <Skyrider> https://i.imgur.com/ZCQglP5.png
[15:14] <Skyrider> Even when I reload ufw, doesn't make much difference.
[15:16] <teward> `ufw status numbered` please - i think you actually do have a rule ordering issue
[15:16] <teward> (AND include the headers please)
[15:16] <teward> (Because reading that output is pain)
[15:16] <teward> just want to verify the numerical ordering is right
[15:17] <teward> because I just spun a container up with ufw rules, and did an allow rule for SSH but also a REJECT rule for my IP and it puts the SSH Allow above
[15:18] <teward> (which is important to note because it will match the 22 ALLOW rule first)
[15:19] <teward> also make sure your phone isn't using IPv6 if v6 is on your infra
[15:19] <Skyrider> https://paste.ubuntu.com/p/DhHby6f5F4/
[15:20] <Skyrider> Not sure why there are 2x 22'c, I'll erase that later on. But, I do believe the order is correct.
[15:21] <teward> probably because at one point you specified just port 22 which is any protocol
[15:21] <Skyrider> All reject/denies are above the allowed rules.. so.. I'm, honestly confused.
[15:21] <teward> so am I let me do some poking
[15:22] <teward> what's your box's version? 18.04?
[15:22] <teward> just to make sure i'm testing the right version :p
[15:23] <lordievader> Skyrider: Could you pastebin the output of `sudo iptables-save`?
[15:23] <teward> that as well
[15:24] <teward> because ufw might be doing a weirdness behind the scenes
[15:25] <teward> Skyrider: how're you testing the DENY rule?
[15:25] <teward> out of curiousity
[15:25] <teward> because `ping` isn't denied by ufw by default
[15:25] <teward> so you will always get false info from `ping`
[15:25] <teward> (just confirmed this in an 18.04 box)
[15:26] <Skyrider> ya, 18.04 and lemme grab the iptables rules. As testing, using mobile device to check my domains. Should be rejected.
[15:27] <teward> so, accessing it via HTTP and such then
[15:28] <Skyrider> yup
[15:28] <teward> ahhhhh okay i replicated your issue
[15:28] <teward> I *think* the ALLOW rules get placed in a higher priority in iptables
[15:28] <teward> which is stupid
[15:29] <Skyrider> https://paste.ubuntu.com/p/s8tMkSPzpx/
[15:29] <teward> somehow
[15:33] <lordievader> I guess it is the ufw-user-input chain
[15:33] <lordievader> Line 99
[15:34] <Skyrider> not local?
[15:34] <lordievader> Which happens before line 60 (reject), due to line 57 calling the ufw-user-input chain.
[15:37] <teward> lordievader: i think there may be other bugs...
[15:37] <teward> perhaps this is because i'm running in a container BUT
[15:37] <teward> with a REJECT on my IP and an ALLOW on 80 with apache2 installed it still permits me in
[15:38] <Skyrider> Interesting fact I just discovered.
[15:38] <Skyrider> The deny/rejection on IP didn't allow my mobile to connect to SSH.
[15:38] <teward> but did for HTTP?
[15:38] <Skyrider> Indeed
[15:38] <teward> i assume *caching* was eliminated as a factor
[15:38] <teward> because browsers are evil
[15:38] <teward> (my tests are with curl :)
[15:39] <teward> (which seem to suggest the HTTP Allow rule takes precedence)
[15:39] <Skyrider> Once I erased my cells IP rule, I was able to connect again.
[15:40] <Skyrider> I assumed all reject/deny were systemwide, even for http(s).
[15:41] <teward> they should be
[15:41] <teward> this seems like a bug
[15:41] <teward> but i need to verify somehow
[15:41] <teward> (ufw isn't doing logging right even at full levels)
[15:45] <teward> okay i think something's actually odd on your env
[15:45] <teward> because I realized I fatfingered a rule on my side
[15:45] <teward> and it's now working
[15:45] <teward> https://paste.ubuntu.com/p/H3p6F5PnH6/
[15:45] <teward> and a curl rejects to it
[15:45] <teward> (curl doesn't have a cache)
[15:46] <teward> Skyrider: they should be
[15:46] <teward> what you aren't doing is verifying if your browser is caching or not
[15:46] <lordievader> If you want a detailed answer why something went through or not look into the trace functionality of netfilter.
[15:46] <teward> nuke your browser cache
[15:46] <teward> and try again
[15:46] <teward> because browsers are NOTORIOUS with caching if you've gone to the page at least once
[15:46] <teward> Skyrider: readd your REJECT rule in the right spot and then erase your browser cache and try again on your phone
[15:46] <teward> chances are it'll reject
[15:46] <teward> and your browser was simply caching content
[15:47] <teward> (which is usually the case for browsers)
[15:48] <Skyrider> I shall try.. however, would like to add that last week I mentioned that a deny/reject rule I added with ip range kept scanning my sites.
[15:48] <Skyrider> Was forced to block the IP range through nginx instead.
[15:48] <teward> hmmm
[15:48] <teward> just as an FYI
[15:49] <teward> this is why I don't use ufw
[15:49] <teward> it has some... nuances...
[15:49] <teward> I just control everything via iptables directly :P
[15:49] <teward> ufw is nice, but it can be weird and glitchy
[15:49] <Skyrider> Ya.. I find iptables a bit... complicated.
[15:49] <teward> most users do unfortunately, hence why they use ufw.
[15:49] <teward> the problem I find is, ufw does a lot of other 'stuff' with its rules that can be glitchy
[15:49] <teward> and ufw logging is poor :P
[15:49] <jdstrand> if there are weird glitchy issues in ufw, please file bugs
[15:50] <teward> jdstrand: you mean like `ufw logging full` not actually logging anything anywhere?  :P
[15:50] <teward> (at least, in LXD containers)
[15:50] <Skyrider> I re-added the the IP, though no success. Gotta admit, I didn't clean the cache. But I went to forum pages that I never went to before on mobile, even private area's. Wasn't blocked a single time.
[15:50] <jdstrand> teward: that isn't ufw's fault. unprivileged containers don't have access to kmsg and that is where the kernel logs
[15:50] <teward> jdstrand: this is a privileged container ;)
[15:50] <teward> and it still can't access
[15:51] <jdstrand> again, that is the kernel, not ufw
[15:51] <Skyrider> Even created a new thread on the forums with my mobile :p, you can't cache that.
[15:51] <teward> hmm
[15:51] <teward> let me spin up a VM
[15:51] <teward> remove the kernel headaches from the equation for testing
[15:51] <weedmic> why not use iptables, then you can save it to a file and at any time run it to instantly set it the way you want?
[15:51] <teward> and get some niiice auditing to try and replicate this
[15:51] <teward> weedmic: because they find it 'complicated' :P
[15:51] <teward> most users do
[15:52] <jdstrand> logging is also complicated by journald
[15:52] <jdstrand> so depending on the release in the container, there may be some stuff going on with journald
[15:52] <weedmic> well, it's just a language (of sorts) - it's only got like 5 things in it - but I could see that - I find it easier than suse's gui for firewall
[15:52] <Skyrider> If there's something that is similar to ufw (in simplicity), but adds rules as iptables would.. I don't mind.
[15:53] <Skyrider> Never had any issues with ufw until a few weeks ago.
[15:53]  * jdstrand also notes that ufw uses iptables-restore syntax under the hood
[15:53] <jdstrand> (man ufw-framework)
[15:53] <jdstrand> Skyrider: please file bugs if there are issues
[15:53] <teward> wellllllllllll
[15:54] <teward> I was writing a python frontend to `iptables` that does much like what `ufw` does...
[15:54] <teward> but I got busy/bored/distracted
[15:54] <Skyrider> I could report a bug, but need to be sure that this isn't my fault XD
[15:54] <teward> jdstrand: well rsyslogd dumps it to /var/log/ufw.log and that oddly enough works
[15:54] <teward> Skyrider: let me set up a test env with logging, etc. give me a minute then i'll coopt you to do some testing
[15:55] <teward> *goes to the Cloud*
[15:56] <Skyrider> ^_^
[15:56] <jdstrand> teward: its gonna depend on what is available in the container, how the container is configured, how logging overall is configured, the kernel, etc. ufw does ship an rsyslog snippet, yes
[15:56] <teward> right
[15:56] <teward> but this is why i'm going to the Cloud and VMs for a full env
[15:56] <teward> thank you cloud VPS deployment xD
[15:56] <jdstrand> but the imklog
[15:57] <jdstrand> module from rsyslog might not be able to read the kernel logs
[15:57] <jdstrand> so, it can't put it in ufw.log
[15:57] <jdstrand> but again, lots of variables
[15:58] <jdstrand> the container host should still see it though
[15:59] <teward> yep which is why i'm spinning a cloud instance up to test with :p
[15:59] <teward> should help
[16:01] <Skyrider> Hopefully with results matching my issue... makes things easier.
[16:03] <teward> just takes a while to launch xD
[16:03] <Skyrider> Cloud aint that fast ey
[16:03] <teward> not as fast as I'd like but I don't use predeployed images :P
[16:03] <teward> I boot the ISOs and deploy my own settings :P
[16:19] <teward> Skyrider: check your PMs I sent you a location to go to
[16:42] <teward> jdstrand: i think we've narrowed it down
[16:42] <teward> but it's not a ufw bug
[16:42] <teward> it's how their android phone behaves with Internet
[16:42] <teward> (everything goes via Google Proxies for some reason)
[16:42] <teward> which makes sense if it's using stock Google Chrome on the Android :P
[16:42] <teward> Skyrider: ^
[16:57] <teward> as to why the /16 wasn't blocking I am unsure, because by all intents and purposes it shouold have
[16:57] <teward> can't rule out proxies at play though
[17:15] <jdstrand> teward: oh, interersting. yeah, clouds, their kernels and their logging infra can certainly affect things. good luck tracking it down!
[17:15] <teward> KVM VPS on OpenStack though...
[17:15] <teward> Thats full virtualization ;)
[17:18] <setuid> Need some Android Emulator running on top of an instance inside that OpenStack though :D
[17:18] <Skyrider> Guess my headless server is busted then
[17:30] <JanC> the "google proxies" = AMP stuff ?
[17:39] <teward> JanC: Not sure, but Skyrider had Google Data Saver on in their Chrome browser
[17:39] <teward> that was probably a factor
[17:52] <teward> jdstrand: but Skyrider DOES have something wonky up with their environment, even with the rules in the proper places it still allows connections.  Can't rule out caching, but something's up with their system
[17:52] <teward> not a ufw bug per se, maybe something specific to their config
[18:03] <jdstrand> Skyrider: note that connection tracking may be an issue. usually this indicates either other firewall software is installed and is competing with ufw or something is not configured correctly in the kernel. you can run 'sudo /usr/share/ufw/check-requirements' for the latter
[18:22] <Skyrider> jdstrand: Command requests to create rules.
[18:22] <Skyrider> teward: Does ufw override iptables rules by any chance?
[18:22] <teward> ufw *is* iptables rules
[18:22] <teward> it will overwrite any other loaded netfilter rules
[18:23] <teward> (which is iptables)
[18:23] <Skyrider> That, I know.. But I noticed ufw lines being used in iptables rule list.
[18:23] <teward> that's normal
[18:23] <Skyrider> Maybe just for naming purposes?
[18:23] <teward> because ufw *uses* netfilter/iptables under the hood
[18:23] <teward> it's UFW specifics for how it does its tables/namings/etc
[18:23] <teward> but it's still ultimately iptables, just a user-friendly frontend to manage the iptables rules
[18:23] <Skyrider> Maybe I should try to create an iptables rule denying my own ip address, directly from iptables.
[18:23] <Skyrider> Rather than ufw.. see if that works.
[18:23] <teward> disable ufw first, then apply a ruleset similarly.  I can help you write a ruleset as such if you want
[18:24] <teward> ufw will overwrite any iptables rules you add
[18:24] <teward> (for the record I use iptables exclusively, but i have reasons xD)
[18:24] <Skyrider> I assume "iptables -A INPUT -s IP-ADDRESS -j DROP" would work fine. Not sure the order it would add it though.
[18:24] <Skyrider> Maybe I should just use iptables, and use aliasses to make it more simpler for me.
[18:25] <teward> `iptables -I INPUT 1 -s IPADDRESS -j REJECT --reject-with icmp-host-unreachable` would be more instantaneously identifiable as a truly effective rule
[18:25] <teward> of course with sudo :P
[18:25] <Skyrider> ^_^
[18:25] <Skyrider> oki, ufw disabled.
[18:26] <Skyrider> What about the order?
[18:26] <Skyrider> Is there a command to set the order like ufw? sudo ufw insert x .. etc, etc, etc.
[18:26] <teward> the rule I provided adds to the top of the list and there's a default ALLOW by default in `iptables`
[18:26] <teward> `iptables -I`  - `-I CHAIN INDEX` Insert rule into specified chain at specified index/position
[18:27] <teward> in this case, INPUT is the chain (as expected) and INDEX is 1, meaning top of the chain]
[18:28] <teward> Skyrider: i'd be happy to give you a crash course in `iptables` syntax at some point :P
[18:29] <teward> if it turns out this deny/reject actually WORKS
[18:29] <teward> ... ops?
[18:29] <teward> ooops*
[18:29] <teward> i think they killed themselves... if they did i'll have to help them fix it
[18:29]  * teward reminds himself that ufw can be evil
[18:36] <Skyrider> *shrugs*
[18:36] <Skyrider> Forgot, that it would block me from .. .well, everything
[18:36] <Skyrider> lol
[18:36] <Skyrider> Was forced to reboot and reset the rules.
[18:37] <Skyrider> Interesting fact though that blocking my IP in iptables disconnected me almost instantly from everything.. while if I do the same on ufw, it didn't.
[18:37] <Skyrider> So my guess is.... ufw.. is, busted on my end.
[18:41] <jdstrand> teward, Skyrider: actually, ufw will *not* overwrite rules you have unless you specify MANAGE_BUILTINS=yes in /etc/default/ufw, which is not the default
[18:42] <teward> jdstrand: interesting.  so it'll what, append rules?
[18:42] <tds> Skyrider: that depends on where exactly you're adding the drop/reject rules - if they go before a rule using conntrack allowing existing connections, that will terminate all open connections, while after will only make them affect new connections
[18:42] <teward> last i checked ufw overwrites whatever I put in `iptables` when ufw is disabled
[18:42] <jdstrand> teward: no, it works on its own chains that are all prepended with ufw-*
[18:43] <jdstrand> teward: this is how it plays well with libvirt, etc which adds their own rules. but something like iptables-persistent or other things that assume they own the firewall can interfere with ufw
[18:43] <Skyrider> The rule I was provided to add in iptables disconnected all my connections.
[18:44] <Skyrider> Let me try again, but only adding the web ports instead rather than a global deny.
[18:44] <jdstrand> still, the advice is sound to disable ufw and see if something simple is working
[18:45] <Skyrider> "iptables -A INPUT -p tcp --destination-port {PORT-NUMBER-HERE} -j DROP" ?
[18:45] <Skyrider> err, no.. lacking ip
[18:45] <teward> Skyrider: `sudo iptables -I INPUT 1 -s IPADDRESS -p tcp --dport 80 -j REJECT --reject-with icmp-host-unreachable`
[18:45] <teward> same for 443 (though you can replace the index with `2`
[18:45] <teward> and that'll ONLY block traffic matching the source IP address heading to port 80 on TCP
[18:45] <Skyrider> Thanks :) lemme try
[18:45] <teward> (standard HTTP)
[18:46] <teward> my apologies for fubaring your access, but at least we know THAT worked xD)
[18:46] <Skyrider> Simple reboot fixed it XD.. why isn't iptables saved though?
[18:46] <Skyrider> With that, I mean.. saved on reboot ,etc.
[18:46] <jdstrand> teward: it depends on how your are disabling ufw. if you disable and do /lib/ufw/ufw-init flush-all or other low level things (or have MANAGE_BUILTINS=yes set), then yes, it will blow stuff away
[18:47] <teward> because it's not stored in a file anywhere, ufw when it reenables loads data from stored rules/data and reloads it into netfilter
[18:47] <teward> similar to how `iptables-persistent` does the same on boot (but assumes firewall ownership and blasts things apart)
[18:47] <Skyrider> oki, I dropped the connection on 80 and 443.. didn't work.
[18:47] <tds> Skyrider: iptables itself doesn't do anything for saving on boot, if you want that you need to install something like the iptables-persistent package
[18:47] <Skyrider> Well, it got added.. just didn't block my access on my web stuff.
[18:47] <jdstrand> do note that just because ufw doesn't stomp on the rules doesn't mean that rule ordering isn't in play. iptables rules are order-dependent. if the ufw chains are first, then ufw will work, if after, they may not (ie, -A (append) vs -I (insert))
[18:48] <teward> Skyrider: did you use DROP or REJECT?
[18:48] <teward> test REJECT
[18:48] <teward> instead of DROP
[18:48] <teward> this said, DROP should've worked too
[18:48] <teward> Skyrider: is this a VPS?  Is it containerized (LXD, OpenVZ) or full virtual (KVM)?
[18:49] <teward> Skyrider: also, make sure you're actually blocking the right IP (remember the google proxy evil?)
[18:49] <Skyrider>     Virtualization: kvm
[18:49] <jdstrand> Skyrider: how are you testing the connection? is the traffic going through the interface you expect to be firewalling? did you kill off any connection tracking (eg, sudo conntrack -D ...)
[18:50] <Skyrider> Not sure what conntrack is.
[18:50] <jdstrand> Skyrider: did you add the rules with -A (append) or -I (insert)?
[18:50] <teward> jdstrand: would that apply even if the first rule were a global matchall?  If they did `-I INPUT 1` like i suggested it'd have put it at first position in INPUT
[18:50] <jdstrand> Skyrider: it is also possible there are vps rules that are in front of your added rules
[18:51] <jdstrand> I see Skyrider used iptables -A INPUT...
[18:52] <teward> ah that might break it
[18:52] <Skyrider> Copy/pasted, ya :P
[18:52] <teward> Skyrider: did you use `iptables -A INPUT` or `iptables -I INPUT 1` like i suggested?
[18:52] <Skyrider> I copy/pasted your line
[18:52] <Skyrider> So.. with input 1.
[18:53] <jdstrand> Skyrider: with INPUT 1, it worked and blocked the connection?
[18:53] <Skyrider> -A INPUT -s xxxxxx/32 -p tcp -m tcp --dport 443 -j REJECT --reject-with icmp-host-unreachable - and another line with port 80 according to iptables -S
[18:53] <Skyrider> And no, it didn't block my web connection.
[18:53] <teward> show us the `iptables-save` output (Pastebin it please)
[18:54] <Skyrider> sure
[18:54] <tds> `iptables-save -c` ideally :)
[18:54] <teward> ^ that
[18:54] <Skyrider> >_>
[18:55] <teward> ... ooooooooooops i just broke my own email, stupid firewalls and NAT... *goes to fix*
[18:55] <Skyrider> https://paste.ubuntu.com/p/49hZ53dx4d/
[18:56] <teward> the only reason it'd be doing *that* is because your IP(s) accessing the site aren't what we think it is
[18:56] <jdstrand> Skyrider: how did you disable ufw?
[18:56] <teward> which is what was happening earlier with our tests skyrider
[18:56] <Skyrider> sudo ufw disable
[18:56] <Skyrider> Status: inactive
[18:56] <jdstrand> Skyrider: and you rebooted?
[18:56] <Skyrider> Reboot kept ufw disabled.
[18:57] <teward> jdstrand: shouldn't the first to input lines (24, 25) have caught regardless if the source IP matching was correct?
[18:57] <teward> 0:0 suggests that it never triggered/matched on sourceIP
[18:57] <teward> and since those rules are ABOVE the ufw rules, those should be matched regardless of UFW active/inactive
[18:57] <teward> at least per my nf understanding
[18:59] <jdstrand> Skyrider: that isn't what a disabled ufw looks like after a reboot
[18:59] <Skyrider> Don't look at me XD
[18:59] <jdstrand> (if it is disabled, after a reboot, it should have no ufw chains)
[19:00] <jdstrand> Skyrider: what release of ubuntu is this?
[19:00] <Skyrider> 18.04
[19:00] <Skyrider> I removed ufw and purged it.
[19:00] <Skyrider> ufw rules in iptables-save are still there.
[19:00] <Skyrider> At least, the ufw lines.
[19:00] <teward> jdstrand: just ran ufw in the command line in a container
[19:00] <teward> aaaaaaaaaand, the ufw rules are still there when disabled
[19:00] <teward> even on reboot
[19:00] <jdstrand> Skyrider: this is a container?
[19:00] <teward> except on reboot*
[19:01] <teward> jdstrand: confirming on a VM currently as well
[19:01] <teward> standby...
[19:01] <jdstrand> teward: ufw disable pre-reboot will leave chains in place, but empty them. on reboot, they won't be added
[19:01] <teward> that part i confirm
[19:02] <teward> Skyrider: you did `sudo ufw disable` and then restarted the server yes?
[19:02] <jdstrand> Skyrider: what is ENABLED set to in /etc/ufw/ufw.conf?
[19:02] <teward> because jdstrand *is* right - it won't add those rules if `ufw` was disabled when you rebooted
[19:02] <tds> Skyrider: did you install iptables-persistent or anything similar?
[19:02] <tds> if you did, that may have saved the ufw rules for you
[19:02] <teward> looks to me more like you just rebooted then did `sudo ufw disable`
[19:02] <jdstrand> tds: yes
[19:02] <jdstrand> tds: that is often a problem
[19:02] <tds> `grep ufw /etc/iptables/rules.v4` would tell you :)
[19:03] <teward> (and won't exist if it's not installed or manually created)
[19:03]  * jdstrand is reminded he needs to add iptables-persistent detection to /usr/share/ufw/check-requirements
[19:03] <teward> jdstrand: what's the underlying language for it?
[19:03] <teward> i might be bored enough to try :p
[19:05] <jdstrand> python3 for the ufw command, shell for early boot setup and iptables-restore syntax for rules
[19:05] <Skyrider> Ya, iptables-persistent is installed.
[19:05] <jdstrand> Skyrider: iptables-persistent and ufw do not work well together. choose one or the other
[19:05] <Skyrider> I only added it a few hours ago, when I was trying to fix all of this.
[19:06] <teward> remove iptables-persistent and reboot
[19:06] <teward> then add the `iptables` rule I stated
[19:06] <teward> this said
[19:06] <Skyrider> Do I have to reboot? :P
[19:06] <teward> jdstrand: my previous question stands.
[19:06] <teward> jdstrand: shouldn't the first to input lines (24, 25) have caught regardless if the source IP matching was correct?
[19:06] <teward> because of the ordering in INPUT
[19:06] <jdstrand> Skyrider: that's fine, but we can only debug what is happening right now
[19:07] <Skyrider> One moment, will disable/enable some services and reboot.
[19:07] <jdstrand> teward: yes, they should have
[19:07] <teward> jdstrand: one of the issues we ran into earlier with Skyrider was their device(s) were being routed via Google's Proxies
[19:07] <teward> as a result of datasaver, etc.
[19:07] <teward> when we blocekd the IP of their actual address that was in the access logs from the webserver they couldn't get to it
[19:07] <Skyrider> This time however, using my own browser on my main desktop system.
[19:08] <jdstrand> teward: so the incoming ip is NAT'd or something? that is going to make a source ip infeasible
[19:08] <Skyrider> Wait a sec...
[19:08] <teward> jdstrand: there's a few different factors
[19:08] <Skyrider> once I removed persistent, everything started to work
[19:08] <Skyrider> nvm..
[19:08] <teward> when their main computer connected and I blacklisted that in a live system it blocked them
[19:08] <Skyrider> Just slow connection XD
[19:08] <teward> but the tricky part here is that i can't verify what's going on on their main desktop
[19:09] <teward> jdstrand: i also can't rule out Proxy settings at play by ISP or some other VPN or proxy system at play
[19:09] <teward> in which case if they ARE indeed nat'd we'd have some... headaches with that and you're rightw e'd have to ignore source IP as a valid identifier (because NAT breaks it)
[19:09] <teward> case in point my IP currently, it shows as my home's IP instead of ym work's IP because I'm VPN'd through home, but HTTP Proxies would behave similarly for HTTP/HTTPS connections in some cases
[19:10] <teward> Skyrider: confirm you're still rejected on the test IP I provided earlier as well
[19:10] <jdstrand> sudo tcpdump -i <interface name> -s 0 -n -vv port 80
[19:10] <Skyrider> Not atm (not on my desktop)_
[19:10] <jdstrand> that will also be helpful on the server ^
[19:11] <jdstrand> Skyrider: just for your own debugging. you'll then see the IPs involved
[19:11] <teward> jdstrand: i'd agree with what jdstrand says :P
[19:11] <Skyrider> **rebooting**
[19:11] <teward> then attempt connecting yourself and see the IP(s)
[19:11] <teward> blehrewrherw9re
[19:11] <teward> *yawns*
[19:14] <teward> jdstrand: ewwww check-requirements is bash >.<
[19:14] <teward>  /bin/sh *
[19:14] <jdstrand> oh your question was about that. yes, shell
[19:14] <teward> one of my more hated languages
[19:14] <teward> behind Ruby and Perl
[19:15] <Skyrider> Okay, so..
[19:15] <Skyrider> Reboot done.
[19:15] <teward> (Ruby, Perl, pure Dash/sh, C, C++...)
[19:15] <Skyrider> iptables only shows 3 lines now.
[19:15] <Skyrider> input, forward and output.
[19:15] <jdstrand> heh, well, it works ok for that particular debugging purpose :)
[19:15] <jdstrand> Skyrider: ok, so you now have a completely clean slate
[19:16] <teward> jdstrand: oh fun fact: you might need to remove the python 2.* checks in this thing for focal if we're sure we're blasting Py2 away
[19:16] <teward> :P
[19:17] <Skyrider> I re-added the 80/443 rules.
[19:17]  * jdstrand notes that the ufw rules that were there before were all 'pass through' but it complicated the output. please, trying to reason around ufw and iptables-persistent at the same time is never good
[19:19] <jdstrand> teward: yes, ufw itself is all py3, etc, etc. I do need to drop the py2 packaging which I'll do before ff. note that check-requirements looks for any python, it just happened to find py2 on the system
[19:19] <jdstrand> Skyrider: and the connection is still not blocked?
[19:20] <Skyrider> Not yet.. just reminded server is using cloudflare.. lemme disable that.
[19:21] <Skyrider> sudo tcpdump -i <interface name> -s 0 -n -vv port 443 - Can I ignore the the machines IP?
[19:21] <Skyrider> Getting spammed with it.
[19:21] <Skyrider> A lot of them with cksum 0x8d69 (incorrect -> 0x0873), seq 1:194, ack 1, win 229, length 193
[19:22] <Skyrider> Specifically the "incorrect" part.
[19:25] <teward> jdstrand: https://paste.ubuntu.com/p/k5NPprmBv3/ in case you're curious *might* help, since those're the scripts iptables-persistent currently installs - if either of them exists then the package is installed :P
[19:25] <teward> it's a diff btw
[19:26] <teward> > server uses cloudflare
[19:26] <teward> well that explains a lot
[19:26] <teward> CloudFlare is equivalent to Proxies and VPN, it futzes the endpoint Source IPs
[19:26] <Skyrider> Side question.. if I allow a port to be used on a specific IP with iptables, does it block the rest?
[19:26] <teward> so you can't use `iptables` or `ufw` to filter on SourceIP if you're behind CloudFlare
[19:26] <teward> Which explains the problems you're having
[19:27] <teward> Skyrider: if you put the default policy to DROP or add a REJECT rule at the end of the rules as a default, then it will
[19:27] <Skyrider> Okay, that makes it different over UFW.
[19:27] <teward> no
[19:27] <teward> because iptables defaults is ALLOW
[19:27] <jdstrand> teward: re check-requirement, thanks :)
[19:27] <teward> ufw's 'default' policy is deny incoming ;)
[19:27] <Skyrider> Adding an accept port / ip rule through ufw, auto denies it for other ip's.
[19:27] <teward> jdstrand: yep, it's likely to need minor refinement.
[19:27] <teward> Skyrider: because the default policy is DROP
[19:27] <teward> in Ufw
[19:28] <Skyrider> Which I find, better.. in my opinion
[19:28] <teward> iptables doesn't have that unless you specify it as that, but that's a different discussion
[19:28] <teward> because you can *set* iptables to default-Deny
[19:28] <teward> which can cause issues if you're not careful
[19:28] <jdstrand> Skyrider: you can add 'and host <ip addr>'
[19:29] <Skyrider> Ah, that makes it better :D
[19:29] <Skyrider> Also... still doesn't block my IP >_>
[19:29] <Skyrider> ****web wise.
[19:29] <teward> Skyrider: if you're using Cloudflare then it won't
[19:29] <teward> to reiterate WHY:
[19:29] <teward> CloudFlare is equivalent to Proxies and VPN, it futzes the endpoint Source IPs
[19:29] <teward> because the traffic goes through CloudFlare's nginx proxy to try and mitigate DDoS and provide minor CDN functionality
[19:29] <Skyrider> Oh, I know. :)
[19:30] <teward> so... :P
[19:30] <Skyrider> Set it to DNS only
[19:30] <teward> and you're sure your computer sees the updated DNS?
[19:30] <Skyrider> Chrome / Firefox appears to be blocked now.. Internet explorer.. not so much.
[19:30] <teward> ... ewww IExplorer
[19:30] <teward> *shivers*
[19:30] <Skyrider> XD
[19:30] <Skyrider> Using it just for testing.
[19:30] <teward> Internet Explorer is evil and relies on Windows' DNS cache
[19:30] <teward> Chrome/FFox both do their own queries lol
[19:30] <Skyrider> Okay, soo... works now.. so all this time, cloudflare was the issue.
[19:31] <Skyrider> Really wish iptables would be smarter to check "behind" the proxy...
[19:32] <jdstrand> it can't. the info is gone from the packet
[19:33] <Skyrider> Fun times.. can't even use cloudflare XD
[19:33] <jdstrand> the T in NAT is Transalation. the host doing the translating rewrites the address before sending the packet on its way
[19:34] <teward> jdstrand: regarding iptables-persistent if that patch looks good I can turn that into an actual quilt patch and upload it.  but i don't want to touch things that're major-critical without second sets of eyes/testing :P
[19:34] <jdstrand> Skyrider: but the host doing the translating sees it. perhaps there is something in the cloudfare UI that allows you to block that ip
[19:34] <teward> also my shell is rusty so :P
[19:34] <teward> jdstrand: CF will pass a header called Ray-ID
[19:35] <teward> and XFF
[19:35] <teward> nginx can check XFF
[19:35] <teward> iptables can't
[19:35] <Skyrider> iptables sounds outdated :o
[19:35] <teward> i think you're confusing 'firewall' with 'proxy filtration'
[19:35] <teward> 'firewall' is good at the packets level
[19:35] <Skyrider> And yea, using multiple methods online to convert the proxy ip to the users real IP.
[19:35] <teward> NOT at the application level
[19:35] <jdstrand> teward: I'm doing uploads for Debian and Ubuntu in the coming weeks. thanks for the offer
[19:35] <Skyrider> Set it up in nginx as well.
[19:35] <teward> which is what XFF / RayID involves
[19:35] <teward> jdstrand: ack
[19:35] <teward> jdstrand: just, if you use the diff verbatim, please credit me :)
[19:36] <jdstrand> teward: of course
[19:36] <teward> (it's inspiration though if you have a better way, I just fast-hashed it together)
[19:36] <teward> ... DAMN YOU EMAIL
[19:36] <teward> ... seriously hate email sometimes, I broke it bad...
[19:36] <teward> *goes to fix his postfix and dovecot mail system*
[19:36] <jdstrand> and if I modify it, I'll still reference you 'based on...' or whatever makes sense
[19:36] <Skyrider> I do appreciate all you guys help and efforts btw!
[19:37] <teward> jdstrand: ack, thank you very much :)
[19:37] <teward> Skyrider: glad we could help, sorry that it took so long to debug
[19:37] <teward> Skyrider: yeah, if you're using CloudFlare you need to use web server level filtering/blocking for the traffic on those IP(s)
[19:37] <teward> if you're not, you can use `iptables`
[19:37] <teward> it's unfortunately the case of different levels of the TCP/IP stack being at play because of CF
[19:37] <jdstrand> or ufw ;)
[19:38] <teward> true :P
[19:38]  * teward has a habit of typing `iptables` :P
[19:38] <jdstrand> that is unfortunate, yes
[19:38] <teward> `iptables`/`ufw` work at one level of the TCP/IP stack (packet level), your webserver will operate at a more application-level filtration (so XFF header, etc. from Cloudflare so it IDs properly at endpoints for filtration)
[19:39] <teward> the second of those which is what you have to do when Cloudflare is in the equation
[19:39] <jdstrand> I suspect it makes since to use iptables(-persitent), ufw, or something on the server to block most stuff (ie, with rules to allow all 80, 443, etc) and then use cloudfare UI to blacklist certain IPs
[19:39] <jdstrand> s/since/sense/
[19:40] <teward> yep
[19:40] <teward> though unless you pay for CF your filtration there is limited
[19:42] <Skyrider> I find webmin.. weird.
[19:42] <Skyrider> The ufw chains still exists in its firewall rules.
[19:43] <teward> webmin is evil don't rely on it
[19:44] <Skyrider> At least rules are working..
[19:48] <Skyrider> What about nftables ? :P
[19:50] <jdstrand> Skyrider: did you 'dpkg --purge iptables-persistent'? maybe there are some lingering files that still fire on reboot
[19:51] <jdstrand> Skyrider: (or at the time of the removal, apt-get remove --purge iptables-persistent)
[19:51]  * jdstrand is confused. I thought Skyrider said after reboot it was empty...
[19:52] <Skyrider> Ya, the iptables -S said it did.. just webmin for some reason cached the old ufw chains.
[19:52] <Skyrider> I erased webmin though.
[19:52] <jdstrand> oh, I see. I don't know what it was doing
[20:01] <Skyrider> Wow iptables is sooo limited >_>
[20:03] <teward> for the record
[20:03] <teward> to properly protect systems
[20:04] <teward> you need IDS/IPS *and* firewalls
[20:04] <teward> and WAFs
[20:04] <teward> IDS/IPS to protect from signature based threats, firewalls for specific IPs, WAFs for HTTP/HTTPS level application filtering when CF and stuff are in play
[20:04] <teward> it's a lot more complex than just "Use a firewall"
[20:04] <teward> esp. when Cloudflare is involved
[20:08] <Skyrider> Indeed, sounds complicated :o
[20:09] <mybalzitch> whats a waf
[20:09] <Skyrider> dog? :p
[20:09] <mybalzitch> woof?
[20:09] <teward> Web Application Firewall
[20:09] <teward> something that operates at the HTTP/HTTPS 'application' level
[20:10] <mybalzitch> neat
[20:10] <Skyrider> eg ModSecurity.. seen that around.
[20:14] <Skyrider> Though, kinda sucks I have to compile nginx to include MC into nginx.


[03:11] <ojn> Martyn: after looking at the pictures online of it, it seems like the Pegatron that was handed out is actually using the same design as the Genesi Efika MX. Just slightly different stuffing options (no HDMI, less flash)
[06:33] <armin76> ojn: link? :)
[06:49] <Martyn> http://www.genesi-usa.com/products/efika
[06:49] <Martyn> (ah, google)
[06:58] <armin76> Martyn: oh well, i thought he meant pictures of the pegatron nettop, not of the efika :)
[08:48] <lool> ojn: Both the pegatron nettop you got and the efika thingies are built by pegatron AIUI
[08:48] <lool> It's very similar stuff
[14:18] <dpb> ogra: if you'll still accept that aptitude patch, here is one: http://koti.kapsi.fi/~dpb/tmp/rootstock-aptitude.patch.txt
[14:18] <ogra> for lucid or a PPA package
[14:18] <ogra> for karmic it's to late to add new features
[14:19] <dpb> there's new versions somewhere? I didn't find a link on the rootstock page...
[14:19] <ogra> (we release on thu. the archive is deep frozen)
[14:20] <dpb> sure, but is 0.1.3 the newest rootstock anyway?
[14:22] <ogra> should be, yes
[14:22] <ogra> http://bazaar.launchpad.net/~ogra/project-rootstock/trunk/changes
[14:23] <dpb> Gives me Internal Server Error
[14:23] <ogra> hmm, intresting, here too now
[14:23] <ogra> https://code.launchpad.net/~ogra/project-rootstock/trunk
[14:25] <dpb> Anyway, if you're willing to add that patch to upstream, that'd be great.
[14:26] <ogra> will, do, though i dont think its of any use once the whole thing is switched to tasksel
[14:31] <dpb> yeah..
[14:31] <dpb> when are you planning on doing that?
[14:31] <ogra> lucisd
[14:31] <ogra> *lucid
[14:32] <dpb> ok
[14:32] <ogra> it should bre integrated as closely with the normal ubuntu installer as possible
[14:33] <ogra> so we can make sure the resulting setup is as close as possible on one that would be installed from debian-installer or ubiquity
[14:33] <ogra> s/on/to
[14:34] <dpb> for me, Ubiquity is a firefox extension.. damn people using same names for stuff.. :S
[14:34] <ogra> yeah, complain at FF
[14:34] <ogra> the ubuntu installer is a few years older than the FF extension :)
[14:35] <dpb> Yeah, I just looked at that on wikipedia.. :)
[17:01] <Martyn> Morning
[17:19] <JamieBennett> Martyn: Evening ;)
[17:20] <Meizirkki> Morning Martyn / JamieBennett
[17:20] <Martyn> Hey hi.
[17:20]  * Martyn is in the middle of doing a cortex-A9 build.  This takes for fucking EVER
[17:20] <JamieBennett> :)
[17:21]  * JamieBennett is winding down for dinner before doing a whole lot more testing later
[17:24] <Meizirkki> Martyn, Cortex-A9 ?
[17:24] <Meizirkki> I thought it's coming 2010..
[17:24] <Meizirkki> what board?
[17:24] <Martyn> We already have models and prototype hardware
[17:25] <Martyn> PBX-A9 in my case, plus software sim (Fastmodel) of our new SoC
[17:25] <Martyn> We have quad core :)
[17:25] <Meizirkki> sounds good :)
[17:27] <JamieBennett> Meizirkki: Evening for you too no?
[17:28] <Meizirkki> Evening yes, but http://www.total-knowledge.com/~ilya/mips/ugt.html :D
[17:28] <JamieBennett> :)
[17:29] <JamieBennett> It must be dinner time, I have this page open at the moment and I don't know why :) - http://aht.seriouseats.com/archives/2009/10/the-burger-lab-the-fake-shack-how-to-make-shake-shack-burger.html
[21:47] <ojn> Anyone got a link to upgrade instructions jaunty->karmic for a redboot-based freescale board (i.e. babbage-like)?
[21:47] <ojn> They provided some URLs at the conference but I didn't write them down and the slides are not yet up :)


[19:07] <hunger> So for ubuntu phone dev I get a IDE, for desktop ubuntu I am supposed to use quickly?
[19:20] <odra> hunger: I dunno!
[19:20] <odra> hunger: Don't ask me complicated questions I can't answer!
[19:20] <odra> hunger: You are making me hungry.
[19:21] <hunger> odra: I was not asking you specifically. Just want to get the full picture of where this is headed:-)
[19:21] <odra> I don't know. I don't develop for ubuntu.
[19:21] <odra> I just happen to develop apps which happen to run on ubuntu.
[19:21] <odra> It is all a coincidence.
[19:21] <odra> By the way what is quickly?
[19:26] <JanC> hunger: you can use QtCreator for desktop apps too
[19:27] <JanC> or any of the other desktop IDEs
[19:27] <odra> Or notepad.
[19:28] <JanC> notepad is "somewhat" limited
[19:28] <odra> Or any of those text editing programs that are not called notepad.
[19:28] <odra> Really?
[19:28] <odra> Because I made an image viewer in gedit.
[19:28] <JanC> gedit is hardly comparable with notepad
[19:29] <odra> I'm not firing up wine just to edit a text file.
[19:29] <JanC> I hope so  :p
[19:29] <arpu> hello @all
[19:29] <odra> But I have, acidentally, many times.
[19:29] <arpu> can i use flash or air with the ubuntu sdk?
[19:29] <arpu> the problem is our app use rtmfp connections
[19:29] <odra> I don't even know why notepad shows up in the programs list. I don't know how to get rid of it either.
[19:31] <JanC> arpu: I suppose you can use Flash in web app style, but I'm not sure Flash is available on all Ubuntu mobile platforms
[19:32] <arpu> JanC, ok thx and on desktop?
[19:34] <JanC> well, x86 & amd64 certainly have Flash plugins available/usable
[19:34] <JanC> although maybe not the very last one
[19:35] <arpu> ok so i use the Qtwebkit browser to show my
[19:35] <arpu> flash app
[19:35] <dz0ny> arpu: librtmp also exists
[19:35] <arpu> dz0ny,  librtmp is not possible for p2p rtmfp connections
[19:36] <hunger> JanC: So what is the recommended way to write desktop apps nowadays? Preferably in a way that I can reuse (parts) of the code later on a phone.
[19:36] <arpu> hmm there are arm air so binarys i can use on android so it should work for ubuntu on arm too ?
[19:38] <JanC> hunger: I think it's hard to say what will or will not work once all infrastructure is ready...
[19:38] <dz0ny> arpu: that's true, flash for linux is not suported anymore. Maybe you could use Google implementation of flash(PPAPI), but that creates a lot of licensing problems I guess.
[19:38] <arpu> hmm so i need to find out how i can load the so files and play the swf  on ubuntu arm
[19:38] <hunger> JanC: Quickly seems to use something completely different. Looks like that is not the way to go then.
[19:39] <JanC> hunger: Quickly can be used with whatever framework
[19:39] <arpu> dz0ny,  but it should work on ubuntu arm with the air so libs
[19:40] <JanC> hunger: but I'm not sure if there are Quickly templates for Ubuntu Touch already
[19:41] <hunger> JanC: Is there any idea yet on how to port desktop apps to ubuntu touch? Or must I write everything from scratch?
[19:41] <JanC> I have no idea  ☺
[19:41] <JanC> actually, I think Qt/QML should work more or less OOTB
[19:42] <hunger> So I should use Qt on the desktop as well?
[19:43] <hunger> Good:-)
[19:43] <JanC> I think using other frameworks might work as well (either now or in the future), just that it's not tested at all
[19:44] <dz0ny> arpu:  I have no idea, officialy there is no support for Flash,Air on Linux from Adobe. Only updated flash runtime is from Google, which is bundled with Chrome.
[19:44] <JanC> well, Adobe still releases security fixes for the Flash plugin
[19:45] <arpu> dz0ny,  ok thx lot i know but air is  available  on android official
[19:45] <arpu> and i look at the soirce code from adobe air for android
[19:46] <arpu> its loading the so libs and play the swf files
[19:46] <arpu> some voodoo is done with the video and stagefridge
[19:46] <JanC> arpu: AFAIK Adobe is deprecating Air on all platforms though
[19:46] <arpu> JanC, ? on all platforms ? no
[19:47] <dz0ny> yep, the are moving to HTML5
[19:47] <arpu> no not for all  flash air is perfect for game development
[19:47] <arpu> http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
[19:49] <dz0ny> As of Adobe AIR 3, Adobe has discontinued support for Adobe AIR for Linux operating systems.
[19:49] <arpu> yes right for linux  x68
[19:50] <JanC> well, at least it won't work on desktops then
[19:50] <arpu> yes :/
[19:53] <JanC> if I understand correctly, RTMFP is similar to WebRTC?
[19:55] <arpu> yes/no :D  it uses udp
[19:55] <JanC> and/or maybe some other open protocols
[19:56] <arpu> rtmfp protocoll is open
[19:56] <arpu> http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-00
[19:57] <JanC> well, at least it's an open spec
[19:57] <arpu> its pefect for p2p games or video chat ...
[19:58] <dz0ny> arpu: Have you evaluated  websockets?
[20:00] <arpu> yes i built an chat text sample with websockets
[20:00] <arpu> but its not that perfext for real time gaming or video chats
[20:00] <JanC> I'm pretty sure WebRTC uses UDP-based streaming too
[20:37] <matge> Hey, I get "static bool QDesktopServices::openUrl(const QUrl&): The platform plugin does not support services" on the phablet
[20:38] <matge> which phablet repository does provide that platform plugin?
[20:38] <matge> so I can add openUrl functionality to it?


[05:12] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: OnlyOffice 7.0 Released with Form Filling, Windowed Mode + More @ https://www.omgubuntu.co.uk/2022/01/onlyoffice-7-0-released-with-form-filling-windowed-mode-more (by Joey Sneddon)
[14:20] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: What is the ‘Ubuntu Pro’ Banner in Software Sources About? @ https://www.omgubuntu.co.uk/2022/01/ubuntu-pro-banner-in-software-and-updates-tool (by Joey Sneddon)
[16:42] -SwissBot:#ubuntu-news- ::Planet:: Jonathan Riddell: Plasma 5.24 Beta Review Day @ https://jriddell.org/2022/01/19/plasma-5-24-beta-review-day/
[21:33] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: How to Install Papirus Icon Theme on Ubuntu @ https://www.omgubuntu.co.uk/install-papirus-icons-ubuntu (by Joey Sneddon)
[22:58] -SwissBot:#ubuntu-news- ::UbuntuOnAir:: Let's Collaborate on Content | UbuntuOnAir @ https://www.youtube.com/watch?v=-gvBQd-PJpc (by Ubuntu OnAir)


[01:23] <pwnguin> is there a good place to learn about how acpi, supend etc all fit together?
[01:24] <pwnguin> my laptop's acting a bit funky, and id like to get some of the extended buttons doing something useful
[01:33] <crimsun> mjg59 (Matthew Garrett) blogged about it some time ago.  You may also wish to check his Ubuntu Live and Linuxconf presentations.
[01:34] <pwnguin> ive read the article, but it's really not too detailed
[01:35] <crimsun> "the article" referring to...?
[01:35] <pwnguin> mjg's article on linux acpi
[01:35] <crimsun> which article?
[01:35] <crimsun> he has blogged several times.
[01:35] <pwnguin> state of linux acpi
[01:38] <pwnguin> im not really interested in cstates etc, but more of the linux userspace side of thinsg
[01:38] <pwnguin> things
[01:39] <crimsun> can you be more specific than "userspace"?
[01:39] <pwnguin> the flow of acpi events from kernel to actions taken
[01:40] <pwnguin> mostly acpid, but also the scripts surrounding it
[01:40] <crimsun> I'm almost positive mjg59 has archived it somewhere.
[01:40] <pwnguin> well ive gone through both his livejournal and advagoto stuff and i dont think ive seen it =(
[01:41] <crimsun> well, aside from reading mailing lists, you'll just need to ask him.
[01:41] <pwnguin> which mailing lists do you recommend?
[01:41] <crimsun> (and there's always the code if you want to dive right in)
[01:41] <crimsun> the linux acpi one
[01:44] <pwnguin> as an example, i have a toshiba convertible tablet. i'd like to get, among other things, automatic conversion working
[01:44] <crimsun> conversion being auto-rotate (xrandr)?
[01:45] <pwnguin> basically
[01:45] <pwnguin> and because x is wierd
[01:45] <pwnguin> rotating the input
[01:45] <crimsun> so start with xev and go forward
[01:46] <crimsun> and acpi-listen
[01:46] <crimsun> s/-/_/
[01:46] <pwnguin> well, i think first i need to finish a patch to nv
[01:46] <pwnguin> as it happens, it doesn't appear to support the correct rotation in xrandr
[01:47] <pwnguin> it supports 90 and 270
[01:47] <pwnguin> but not 180
[03:20] <cynics> hi, guy, anyone can run feisty on a instel 965 chipset based notebook
[06:36] <thedarkbg1> hi guys
[06:38] <thedarkbg1> i have a question
[06:38] <thedarkbg1> i just put ubuntu 6.06 on my laptop
[06:38] <thedarkbg1> and the sound isnt working
[06:38] <thedarkbg1> i looked into the configuration
[06:38] <thedarkbg1> and it says no enabled in the configuration
[06:38] <thedarkbg1> not enabled*
[06:38] <thedarkbg1> so how do i enable it
[06:38] <thedarkbg1> ?
[06:46] <crimsun> not a support channel.  What audio hardware do you have?
[06:47] <crimsun> It's likely already supported in alsa-driver 1.0.14 (final, not RC).
[06:56] <thedarkbg1> well
[06:56] <thedarkbg1> as its laptop related
[06:56] <thedarkbg1> i come here
[07:01] <thedarkbg1> sorry had to restart
[07:01] <thedarkbg1> did a mass update
[07:29] <gdselzer> di
[10:39] <lmosher> anyone around?


[01:15] <xcyclist> I have been using https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel, and for instance it says I should see 3 .deb files instead of dozens of files.
[01:16] <xcyclist> Ubuntu kernel builds appear to put out a bunch of stuff, .deb files, .udeb files, and a .tar.gz file, that I don't see specified in a document accurately.  Is there a document I SHOULD  be reading, or can I help updating one that is old?
[01:16] <xcyclist> Please advise how I can be most helpful in either asking a question, reading other documents, or updating inaccuracies.
[01:19] <tsimonq2> xcyclist: Your question's good enough to me, you're just asking in the wrong place. ;)
[01:19] <tsimonq2> xcyclist: Try #ubuntu or #ubuntu-kernel.
[01:20] <xcyclist> Ok.
[01:21] <xcyclist> Thank you.
[01:22] <tsimonq2> You're welcome. Have a good day.
[08:34] <cjwatson> enyc: thanks
[09:24] <juliank> mvo: command-not-found feedback: it is not particularly helpful if I accidentally type lsa. It tells me there are 17 similar ones and to try apt install <deb name>, but not which packages. http://paste.ubuntu.com/p/v5zsTgyYpP/
[09:24] <juliank> with lsx I get a list of commands and packages
[09:28] <mvo> juliank: oh, that is a bug
[09:29] <mvo> juliank: will fix
[09:29] <mvo> juliank: thank you!
[10:04] <cpaelzer> doko: I already had retriggered the ruby-libvirt test for libvirt with the right triggers (needs all proposed for the ruby things to work)
[10:05] <cpaelzer> doko: I see you later on triggerd one as-is (which will fail)
[10:05] <cpaelzer> doko: is there a way to cancel your test request from the queue?
[10:06] <cpaelzer> good: ruby-libvirt {"all-proposed": "1", "requester": "paelzer", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
[10:06] <cpaelzer> bad: ruby-libvirt {"requester": "doko", "triggers": ["libvirt/4.0.0-1ubuntu5"]}
[10:07] <cpaelzer> the second being about 7 pages below the former entry on http://autopkgtest.ubuntu.com/running
[10:20] <cpaelzer> anyone else knowing if/how one can cancel test retires?
[10:20] <cpaelzer> pitti: ^^ ping for being a subject matter expert
[10:23] <pitti> cpaelzer: https://git.launchpad.net/autopkgtest-cloud/tree/tools/filter-amqp
[10:23] <pitti> cpaelzer: but it needs to be run on the infra, i. e. only Laney, infinity, and a few others have access (not me any more)
[10:24] <pitti> there's no public API for it
[10:24] <cpaelzer> ok thanks pitti
[10:24] <pitti> it's usually not a biggie, just some wasted electrons
[10:24] <pitti> this makes more sense when one needs to remove a hundred wrong test requests
[10:24] <cpaelzer> I thought I've had cases where the second (bad) test will again make it not migrate
[10:25] <pitti> cpaelzer: I thought it wrote it so that "any pass wins", not "the latest result counts"
[10:25] <cpaelzer> ok, if that is true I feel better
[10:25] <pitti> but this is becoming a bit blurry, I'm afraid
[10:25] <cpaelzer> in the current case it is the last missing bit, so I assume it will be migrated before it gets to the second test anyway
[10:26] <Laney> I think that's right
[10:27] <pitti> on second look at https://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/tree/britney2/policies/autopkgtest.py#n165 , maybe I'm wrong
[10:28] <pitti> but in the worst case, just re-trigger your's again
[10:28] <pitti> uh, the queue is quite long right now
[10:29] <pitti> kde update ho
[10:31] <Laney> I'll just kill it out to be safe
[10:45] <rbasak> enyc: metadata_csum is enabled in Debian stretch I think?
[14:15] <doko> xnox: does xe-guest-utilities need a MIR?
[14:15] <doko> in supported-cloud seed
[14:16] <xnox> doko, it does
[14:16] <xnox> doko, i've started to fill one out, but it is incomplete.
[14:57] <ricotz> mdeslaur, hi, why is clamav depending on llvm3.9 while it ships an internal copy?
[15:00] <mdeslaur> ricotz: which release?
[15:01] <mdeslaur> debian typically strips out the internal llvm and uses the system one
[15:01] <ricotz> 0.99.4+addedllvm-*
[15:01] <mdeslaur> but when we backport for our earlier releases, the system llvm is sometimes too old, so we use the internal one
[15:02] <ricotz> mdeslaur, afaics this is a special ubuntu repack?
[15:02] <mdeslaur> yes, it's a special repack for our old stable releaes
[15:02] <ricotz> it used llvm3.9 on bionic which seems odd
[15:02] <mdeslaur> and I used it for bionic because debian is currently using a pre-release version
[15:02] <ricotz> is uses *
[15:03] <mdeslaur> only trusty actually uses the built-in llvm
[15:04] <mdeslaur> xenial and later use the system llvm
[15:05] <ricotz> I see, the version somehow suggested this is not conditional
[15:05] <mdeslaur> when we released 0.99.4, debian didn't have a tarball yet
[15:05] <mdeslaur> so I just used the same one I prepared for trusty, even though later releases didn't need the internal llvm
[15:07] <mdeslaur> looks like debian has a 0.99.4 tarball in stretch, would could use that for bionic, but meh
[15:07] <ricotz> ok, I also assumed this is a step to get rid of libllvm3.9 which is only used by libclamav7 in bionic
[15:11] <mdeslaur> I hadn't considered that
[15:44] <geofft> cyphermox: are there netplan packages for Debian? (or would you expect the dsc to build on Debian?)
[16:46] <cyphermox> geofft: I expect it would build on Debian fine, the only issue might be version numbers for Depends
[16:47] <cyphermox> I have yet to file a ITP for netplan.io in Debian.
[17:13] <nacc> Odd_Bloke: are you working on any ruby packages right now?
[17:28] <Odd_Bloke> nacc: Other than keeping an eye on autopkgtests to request retries, no.
[17:30] <nacc> Odd_Bloke: ok, i'll start trawling
[21:29] <nacc> slangasek: not urgent by any means, but samba 2:3.6.5-2ubuntu1 is unable to be extracted (dpkg-source -x) in modern Ubuntu, which means we can't get to a patches-applied state (cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850843). Do you have any ideas of what we might do there? We could simply not import that patches-applied version, and I think it would have no impact to our new algorithm.
[21:29] <nacc> But it would mean this one publishing event (or anything like it) isn't in our Git repo
[21:33] <slangasek> nacc: my empty stomach is suggesting options to me that may not be constructive ;)
[21:38] <nacc> slangasek: :)
[21:38] <nacc> slangasek: like i said not urgent, just something to mull over when/if you have time
[21:41] <nacc> slangasek: it doesn't *really* affect us, because we don't treat patches-applied imports as full failures (we figure it's a tooling thing and will get fixed by future fixes to dpkg/etc). However, in this case, there hasn't been much movement (possibly won't ever be) and it might make sense to provide some mechanism to deal with it. I think I'd be "ok" with a blacklist of source package, version tuples
[21:41] <nacc> that we know don't work
[21:41] <slangasek> nacc: yeah, that's probably reasonable in this case
[21:42] <slangasek> it's sort of like, yes this version number exists, but it's associated with a thing that's not actually a source package :P
[21:42] <nacc> slangasek: right
[21:42] <nacc> i'll file a bug to document the idea, at least
[21:44] <nacc> slangasek: and, since the patches-unapplied import does exist, it's possible to at least get the source package in Git and probably munge the patch so that it applies by hand
[21:45] <slangasek> yep, the main problem is that it doesn't tell you which way to munge it is the correct way
[21:45] <nacc> slangasek: yeah, in my mind the 'right' way would be to spin up precise, i guess and do it there :)
[23:02] <nacc> mdeslaur: fyi, LP: #1744148 updated, i've assigned the two security tasks to you and uploaded the php7.2 update to bionic
[23:04] <nacc> xnox: have you already fixed rails? Odd_Bloke mentioned you were working on it
[23:05] <xnox> nacc, rails is fixed; but fixed rails showed that ruby-spring is broke; just now fixed ruby-spring https://launchpad.net/ubuntu/+source/ruby-spring/1.3.6-2ubuntu1
[23:05] <xnox> nacc, then need to rerun rails (and rails-like) with all-proposed, to see if this ruby-spring fixes everything
[23:06] <nacc> xnox: ack, i was just leafing through ruby-defaults and there are a few *rails* pacakges with failures; i assume you'll retry?
[23:09] <nacc> xnox: ruby-turbolinks is agreat one, calls ruby2.3 explicitly  in it's dep8 test :)
[23:10] <nacc> xnox: ah Odd_Bloke already fixed that one, just nees a retrigger
[23:10] <nacc> it's a bit annoying that before the fixes were all in place, another ruby-defaults was uploaded
[23:10] <xnox> yeah, but oh well, doko didn't know we were actively looking and manually re-triggering half of the things with the right triggers.
[23:11] <nacc> yeah, it happens :)
[23:11] <xnox> and were hoping to migrate current ruby-defaults; before merging in a bug fix.
[23:12] <nacc> fun, ruby-turbolinks looks to just have raced (it's migrated already now acc'g to rmadison) the test rerun, so i'd let that settle and it can be retriggered without any extra flags
[23:13] <nacc> ruby-sexp-processor looks ugly... "[BUG] Stack consistency error"
[23:14] <nacc> ah fixed in debian, will sync
[23:14] <nacc> already synced, nm
[23:48] <mdeslaur> nacc: thanks! I'll work on them tomorrow
[23:49] <nacc> mdeslaur: thank you, let me know if you need anything