[00:14] -ubottu:#ubuntu-news- ::omg!ubuntu:: Impression (Linux Image Writer) Now Supports In-App ISO Downloads @ https://www.omgubuntu.co.uk/2023/11/impression-image-writer-for-linux-now-downloads-isos-too
[00:22] <Bashing-om> guiverc: Finaky mouse button did not help in figuring out the correct syntax for embedding the URL :(
[00:29] <guiverc> but ya got there so :)
[03:23] -ubottu:#ubuntu-news- ::planet:: Ubuntu Blog: Podcast: Data in AI @ https://ubuntu.com//blog/podcast-data-in-ai
[03:23] -ubottu:#ubuntu-news- ::planet:: The Fridge: Ubuntu Weekly Newsletter Issue 812 @ https://fridge.ubuntu.com/2023/11/06/ubuntu-weekly-newsletter-issue-812/
[06:03] <luna_> did issue 812 got dragged back?
[06:04] <guiverc> dragged back?  issue 812 was 'published' & we're on 813 now
[06:04] <guiverc> https://discourse.ubuntu.com/t/ubuntu-weekly-newsletter-issue-812/39856
[06:04] <luna_> guiverc: ah seems the wiki version does not work
[06:04] <luna_> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue812 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue811
[06:05] <guiverc> we're no longer using the wiki; you can find recent issues at https://discourse.ubuntu.com/c/uwn/124 and even read the current WIP (813) as it advances
[06:06] <luna_> guiverc: alright thanks got confused as http://distrowatch.com links to the wiki version that does not work but then i know its moved to discourse thanks
[06:07] <guiverc> i'm not aware of what is at distrowatch sorry.. not a ubuntu site
[06:11] <guiverc> I've modified some text at https://wiki.ubuntu.com/UbuntuWeeklyNewsletter  (link to https://discourse.ubuntu.com/c/uwn/124 for current issue; feel free to 'review', 'edit' as required  (current issue section amended)
[06:15] <luna_> perfect
[06:15] <guiverc> thanks luna_ :)
[06:32] <guiverc> luna_, do you recall what link at distrowatch had you go to wiki?
[06:33] <guiverc> (if it's a page we can edit; I'll edit... otherwise I can ping distrowatch owner/maintainer if outside our control... they've responded before to lubuntu requests..)
[06:37] <luna_> under Latest Newsletters
[06:38] <luna_> don't thnk you can edit it but you can email them at<EMAIL_ADDRESS>[06:38] <luna_> guiverc: do you want me to do it or do you want too?
[06:44]  * guiverc stepped outside briefly ... I've not found it (yet) but if you're happy to email distrowatch about change, please go ahead luna_ ; that would be appreciated :)
[06:45] <luna_> sure will do
[06:46] <guiverc> Thank You luna_ ; it's greatly appreciated
[06:46] <luna_> np
[06:50] <luna_> email sent
[06:51] <guiverc> found it - https://distrowatch.com/dwres.php?resource=podcast-mobile  ;  contained link to https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue812  ... will now search for anything we maintain that shows https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue812
[06:53] <guiverc> first search no results... alas we'll need to update "Archive: You can always find older Ubuntu Weekly Newsletter issues at: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Archive"
[07:03] -ubottu:#ubuntu-news- ::fridge:: Ubuntu Weekly Newsletter Issue 812 @ https://fridge.ubuntu.com/2023/11/06/ubuntu-weekly-newsletter-issue-812/
[07:09] <Bashing-om> guiverc: I have noted in the archive we have moved.
[07:11] <guiverc> Bashing-om, the page I altered (one of anyway) you'd altered further down; but it still reported 811 as latest issue on wiki towards top  ( https://wiki.ubuntu.com/UbuntuWeeklyNewsletter?action=recall&rev=1014 )
[07:12] <guiverc> that page is still untidy, still refers to https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue812 i just noted :(
[07:12] <Bashing-om> guiverc: 811 was the last WIKI - due to me manualkly making it up.
[07:13] <guiverc> probably only "Wiki page as listed above at: Issue 812" needs to be removed then.
[07:14] <guiverc> i've altered ARCHIVE section in template; also you'll have been notified of 813 amended likewise; review at your convenience & adjust/correct etc
[07:15] <guiverc> that 812 ref. so far the only link I've found that mentions 812 that distrowatch maybe 'scraped' for their site??  (could also be elsewhere that I've not found)
[07:15] <Bashing-om> guiverc: and we need to update "current issue: to now direct to Discourse :(
[07:16] <guiverc> I just made it 'static' with link to Wiki page as listed above at: Issue 812 intentioanlly in attempt to avoid manual edits  (thus the ~messy WIP mention)
[07:41] <Bashing-om> guiverc: It is the " <<Include(UbuntuWeeklyNewsletter/Header)>> " that we need to edit to now go to DSiscourse rather than the old WIKI810 issue. But not tonight - I too tired to think straight and frustrated fighting this bad mouse button.
[07:43] <guiverc> ack.. which page?  (I think i edited something you had locked & missed the lock warning - sorry Bashing-om !)
[07:43] <guiverc> we do have ref to https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas for making suggestions; that should be updated to discourse (somewhere)
[07:44] <guiverc> go to bed Bashing-om ; there is always tomorrow
[07:51] <Bashing-om> guiverc: Yeah on the lick - I seen the conflict and cancelled my edit - the "currentissue" token in the wiki.ubuntu.com/UbuntuWeeklyNewsletter page is what now needs the attention.
[07:51] <Bashing-om> lock/lick*
[07:52] <guiverc> sorry about that Bashing-om
[07:54] <guiverc> & thanks
[07:54] <Bashing-om> guiverc: I am off to bed - we catch up on these later - I do plan on replacing this mouse tomorrow !
[07:55] <guiverc> (reddit is support only now; no point posting uwn there as i see it (given now offtopic))
[07:55] <guiverc> :)
[07:56] <Bashing-om> guiverc: Uh huh on reddit - we can replace reddit with Mastodon :)
[08:06] <Bashing-om> guiverc: In addition - Template and IRC channel tokens also need updating.
[08:08] <Bashing-om> guiverc: Gone - will catch up on my morrow.
[15:06] -ubottu:#ubuntu-news- ::omg!ubuntu:: Fedora Workstation 39 Released with GNOME 45, Linux 6.5 + More @ https://www.omgubuntu.co.uk/2023/11/fedora-workstation-39-features-download


[05:17] <hikiko> hello
[05:17] <hikiko> is it possible to run mir-u8 on a vm? (and which one?)
[05:17] <hikiko> I tried virt-manager yesterday but it doesn't seem to have hardware acceleration by default
[05:18] <duflu> hikiko: Hi. In theory, yes anpok did some work on that but only one or two hypervisors work. I'm not sure which
[05:19] <hikiko> :D
[05:19] <hikiko> thanks duflu
[05:19] <hikiko> I'm going to ping him
[05:20] <duflu> hikiko: He'll be on soon
[05:21] <duflu> hikiko: Oh Mir has doc/* for it
[05:21] <duflu> doc/setup_kvm_for_mir.md  doc/setup_vmware_for_mir.md
[05:22] <hikiko> https://unity.ubuntu.com/mir/setup_kvm_for_mir.html
[05:22] <hikiko> :)
[05:22] <hikiko> ok let's see
[05:23] <hikiko> alright that's what I did but with 4.4.0-18-generic
[05:24] <hikiko> and didn't build krm-next
[05:24] <duflu> hikiko: The web docs are always old (represent the last Ubuntu release) so check the source
[05:24] <hikiko> alright :)
[05:24] <hikiko> thanks duflu
[05:24] <duflu> No worries
[07:01] <hikiko> installed :D
[07:01] <hikiko> I have u8 running on virt-manager \m/
[07:11] <anpok> using kms-swrast or using vt-d?
[07:25] <hikiko> anpok, lsmod doesn't show any of them
[07:25] <hikiko> I see qxl, drm_kms_helper
[07:26] <anpok> ok kms swrast .. I was recently messing around with forwarding graphics cards to kvm directly.. by disabling them on the host..
[07:26] <anpok> and ran into assertions in qemu
[07:27] <hikiko> do I have to do that to experiment with u8?! :s
[07:27] <anpok> nah
[07:27] <hikiko> :D


[00:02] <kerly> now I will go to close this session to try open from terminal ntfs-config to try again from the first user that is "wachin"
[00:06] <kerly> No, I can't access to my others partitions
[00:06] <kerly> Some of yours have the same question
[00:07] <kerly> Call to my, wachin, not kerly, kerly is the other user that I create, from that try to access to my other partitions
[00:07] <kerly> but not is possible
[00:07] <kerly> UbuntuStudio 14.04 x86
[03:29] <bruno> ola algum brasileiro ai?
[03:30] <cfhowlett_> !brazil
[14:53] <rasda> hi. has anyone here tried bitwig studio with ubuntu studio 14.04 yet?
[15:10] <wachin> Hi to all UbuntuStudio users and dev.
[15:11] <wachin> yesterday i will try to have access from other user that I create with the name kerly, but from this user can't have access to my others partitions
[15:12] <wachin> Well, this day here con UbuntuStudio 14.04, I try to have to use the script to open the webcam from mplayer
[15:13] <wachin> the script say this: mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video1
[15:13] <wachin> I use a WebCam Logitech, with UbuntuStudio 12.04.4 and 14.04 all fine
[15:13] <wachin> but with 14.04 the image of the video is very small
[15:14] <wachin> some of yours have the same question
[15:23] <wachin> there seems to be a problem in accessing this Logitech C110 webcam in UbuntuStudio 14.04
[18:44] <devin> I am trying to run Arduour and am now getting the following error: "Could not reconnect to the Audio/MIDI engine"
[18:54] <devin> Really do not know what I am doing, but I just tried this: https://bugs.launchpad.net/ubuntu/+source/jack-audio-connection-kit/+bug/108718 ...to no avail.
[19:07] <devin> So I tried this $gksudo gedit /etc/security/limits.conf and received "The program 'gksudo' is currently not installed. You can install it by typing:
[19:07] <devin> sudo apt-get install gksudo is currently not installed
[19:07] <devin> "
[19:08] <devin> Should I just install it, or would I be creating more problems? (I'm sure I got into this trying to solve a different problem)
[19:08] <devin> Thank you for any entertainment of thought on the matter. I'll help others with learning curve once I get on some good footing.
[19:25] <devin> (Read that there is no significant diff between gksudo and sudo command) Found nothing unusual in config file.)
[19:31] <zequence> devin: Don't tamper with realtime rights, if you're on Ubuntu Studio
[19:32] <zequence> Does ardour complain that you don't have realtime privilege?
[19:33] <zequence> devin: Always start jack first, then your jack application
[19:33] <zequence> !proaudio
[19:37] <devin> zequence - no, ardour does not mention anything about realtime privilege.  By "jack", do you mean qjackqtl? I do not think I have to have this open on my other computer, which has similar setup now. I'm puzzled.. thanks again.
[19:41] <zequence> devin: qjackctl is a gui control application for the jack server
[19:41] <devin> I tried starting jack first and then Ardour. Still no luck. I think I am going to sit down and put both computers side-by-side and see what is similar/different with audio preferences. I don't see any audio connection options on Jack on this PC, but I swear there are options on my other "stable" (just luck) version.
[19:44] <devin> In the Jack Messages, I see this "(qjackctl:3284): Gtk-CRITICAL **: IA__gtk_widget_get_direction: assertion 'GTK_IS_WIDGET (widget)' failed". Does this mean anything important?
[19:45] <devin> Also, "Server state" is "Stopped".
[19:51] <zequence> devin: Just make sure you have selected the right audio device. Don't select input and output separately. Set those to "default"
[19:51] <zequence> devin: Then, select your audio device in "interface"
[19:52] <zequence> devin: Reboot, if you want, to make sure you don't have stuff running in the background
[19:52] <zequence> devin: Can't stay with you now. Gotta watch some hockey. I'm on here every day, so if you keep logged in and ask a question, you will get an answer
[19:54] <devin> Thank you! You all should know that my goal with this is to bring Linux into schools. I am music teacher and I think that the whole environment/philosophy of this stuff is great for education. Thanks!
[21:54] <bert__> hello du studio
[21:57] <bert__> au revoir


[21:46] <ux> hello
[21:47] <ux> installed xubuntu , it has bugs
[22:08] <brainwash> hi ux
[22:09] <brainwash> you should report bugs on launchpad
[22:09] <brainwash> or do you have any specific question?


[00:26] <AfC> lifeless: where did you upload your GPG key? It's still not on any of the public keyservers.
[00:27] <lifeless> subkeys
[00:35] <igc> morning
[00:36] <lifeless> hi
[00:36] <mwhudson> hi igc, lifeless, AfC
[00:39] <igc> hi guys
[00:43] <distatica> Let's say I made two revisions a moment ago, the last one I want to keep, the first one I made changes that I don't want anymore. What options do I have now? I don't want to revert back two revisions and lose the changes I made, but I'm not sure how to handle that.
[00:43] <distatica> I'm a bzr / programming newbie, for what it's worth.
[00:45] <lifeless> distatica: the easiest thing is just to undo the changes you don't want
[00:45] <lifeless> and commit
[00:45] <distatica> you mean manually? Just go in and remove those and then make a new commit?
[00:45] <distatica> Or do you mean there's a way to undo a revision?
[00:46] <lifeless> you can undo a revision
[00:46] <lifeless> but as you're new to bzr I suggest not doing that until you've got some more experience
[00:46] <distatica> ok
[00:46] <lifeless> just edit your files and make them the way you want, and do a commit
[00:47] <distatica> could I make the last commit a patch, revert back and apply that patch? Or am I just getting too complicated?
[00:47] <distatica> For the record, I can undo these changes in about 20 minutes of work, so it's not a major critical issue, I was just going to learn how to do it while I'm here, unless I don't have the knowledge yet to perform it.
[00:48] <lifeless> so
[00:49] <lifeless> if you've shared the branch with someone you can't really ever delete the fact that you /did X/
[00:49] <lifeless> think of bzr as a journal
[00:49] <distatica> ok
[00:49] <lifeless> once shared with people they have the journal
[00:49] <lifeless> you can't erase from their copy
[00:49] <lifeless> if you haven't shared it with people you can rip the most recent page  in your journal out
[00:49] <lifeless> and then write on a new page
[00:50] <lifeless> the way you'd pop two commits off is:
[00:50] <lifeless> bzr uncommit
[00:50] <lifeless> bzr shelve --all
[00:50] <lifeless> bzr uncommit
[00:50] <lifeless> bzr shelve --all
[00:50] <lifeless> now, bzr unshelve
[00:50] <distatica> so, if I make 3 commits, revert back 1, and then share the repo, the log will only show 2 commits?
[00:50] <distatica> ok
[00:50] <lifeless> will put the most recent shelved changes up ready for editing
[00:51] <lifeless> yes, though 'revert' doesn't affect the journal at all; 'bzr uncommit' does
[00:51] <distatica> oh I see
[00:51] <lifeless> (the shelve --all, unshelve pair is a no-op, you could just do uncommit, shelve --all, uncommit to get to the same state)
[00:51] <distatica> this is an issue I've been having, being a non-programmer some of my commits are... well pointless. :) It's just me screwing around with one thing, doesn't work, go back, try another.
[00:51] <lifeless> anyhow, at this point in my example, you'd change things so they are you want, the commit
[00:52] <lifeless> bzr unshelve
[00:52] <lifeless> and bzr commit again
[00:52] <distatica> ok
[00:52] <lifeless> and you're back nearly-where-you-started but with the commit 2 back changed
[00:52] <lifeless> so back to the journal analogy
[00:52] <lifeless> if someone has been reading your journal
[00:52] <lifeless> its not pointless ;)
[00:52] <lifeless> if they haven't, if its private notes, then its fine to just change your mind
[00:53] <distatica> ok, that's great news actually -- I had asked this question from someone a while back and got the impression (most likely due to my own ignorance) that once it was there it was set in stone and that was that.
[00:54] <lifeless> the key thing is sharing
[00:54] <distatica> yeah, once it's gone then it's stone.
[00:54] <lifeless> once you've done that its more tricky :)
[00:59] <distatica> great, thank you.
[01:11] <igc> lifeless: does that mean that stacked branches are implicitly standalone?
[01:14] <lifeless> igc: not sure what you mean by that
[01:14] <igc> lifeless: when you said "we explicitly don't stack in shared repos"
[01:14] <igc> what did you mean exactly?
[01:14] <lifeless> so
[01:15] <lifeless> in principle a branch can be stacked, while in a shared repo
[01:15] <lifeless> but our ui code says 'oh, you have a shared repo, we won't stack'
[01:15] <lifeless> so it should be unusual, but its not impossible, to encounter a stacked branch in a shared repo
[01:15] <lifeless> I think we'll probably make it very common when we overhaul how we manage branches
[01:15] <igc> ok
[01:16] <lifeless> but thats a different discussion
[01:16] <igc> right
[01:21] <igc> lifeless: on another topic, that commit file patch has been reworked as we discussed
[01:21] <igc> I know you're really busy ...
[01:21] <lifeless> thanks
[01:21] <igc> but if you're happy with it, I'll land it fro 1.15 today
[01:22] <lifeless> I appreciate the ping
[01:22] <lifeless> my day is:
[01:22] <lifeless> 1) slides, deadline is today
[01:22] <lifeless> 2) final prep for trip
[01:23] <lifeless> 3) all other stuff
[01:25] <AfC> lifeless: ah, there it is now.
[01:25] <AfC> mwhudson: morning :)
[01:29] <jml> poolie: you know how you say you use the register-branch API -- how exactly do you authenticate with that?
[01:39] <jml> bzr alias snt="snt"
[01:40]  * jml corrects the typo and tweetoblags.
[01:48] <poolie> jml: i think it uses https auth
[01:49] <poolie> hello all
[01:49] <poolie> i'm basically getting ready to go and doing slides today
[01:49] <poolie> lifeless: i approved your patch as you probably saw
[01:49] <jml> poolie: yes.
[01:49] <jml> poolie: and it prompts you for your Launchpad password?
[01:50] <poolie> i think so
[01:50] <poolie> it's so 2006 :)
[01:50] <poolie> also, saying "it's so x" is so 2006 :)
[01:50] <lifeless> poolie: I landed it as you may have seen :)
[01:51] <jml> poolie: I'm actually waiting for a revival of "c'mon, it's the nineties!"
[01:51] <jml> poolie: I may be waiting a while.
[02:05] <spm> jml: so long as we skip the 80's revival. there are some places that should be left in the past.
[02:22] <lifeless> spm: when doves fly
[02:23] <spm> lifeless: ha! 'twas more the vison of the 80's "BIG" hair and warrick kapper style shorts that terrifies
[02:23] <jml> lifeless: also when they cry.
[02:25] <lifeless> it a myth
[02:34] <bob2> shudder
[03:06] <fullermd> jelmer: ping
[03:12] <jelmer> fullermd: pong
[03:13] <fullermd> Is there some reason you chose malloc.h rather than just using stdlib.h in the pyrex rio stuff?
[03:17] <lifeless> igc: ping
[03:17] <lifeless> igc: I didn't see a new merge request for that branch; did you simply push up changes?
[03:27] <igc> lifeless: I did push the changes and ...
[03:27] <igc> I tried to tell lp that it needs a new review
[03:27] <igc> but the latter didn't seem to do much :-(
[03:27] <lifeless> I've filed a bug
[03:28] <lifeless> one thing I've seen already
[03:28] <lifeless> the def check inner function
[03:28] <lifeless> thats very opaque style
[03:28] <lifeless> it would be clearer to either just do self.assertEqual(x,  ...) 3 times
[03:29] <igc> I just copied what was there from memory
[03:29] <lifeless> I realise this is kindof trivial, but we had 100 line tests that looked like that once
[03:29] <lifeless> and it was fugly
[03:34] <fullermd> jelmer: FreeBSD malloc.h has been #error'ing since 2001 (and #warning'ing since 1994) and pointing grumpily at stdlib.  Builds fine for me with that change.
[03:37] <jelmer> fullermd: I've sent a merge req
[03:40] <fullermd> Rox.  jelmer++
[03:41]  * jelmer longs back to the days when statements had to be terminated with semicolons and malloc lived in malloc.h
[03:47] <fullermd> When men were real men, women were real women, and small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri?
[03:54] <lifeless> igc: ok reviewed
[03:54] <igc> lifeless: thanks
[03:55] <lifeless> igc: I'mvery glad you factored it out, because now I'm sure there was something really wrong earlier ;)
[03:56] <lifeless> igc: and yes, I've just checked your older code
[03:57] <lifeless> so the problem is, you don't actually force include missing parents
[03:57] <lifeless> they aren't being generated from iter_changes
[03:57] <lifeless> so you'll have to iter_changes the *entire tree* if the user uses specific files
[04:00] <lifeless> igc: If you want to chat about this, I'm happy to do so
[04:00] <igc> lifeless: thanks. I'll take a look soon
[04:06] <lifeless> igc: I'm going to nose down on presentations
[04:06] <lifeless> igc: you may need to ring me :P
[04:06] <igc> ok
[04:58]  * igc lunch
[05:34] <lifeless> so the good news is we saturate my link very happily branching bbc over the smart server
[05:39] <lifeless> igc: did my review make sense?
[05:40] <igc> lifeless: just got back from lunch - I'll take a look now
[05:46] <igc> lifeless: so, I might be stupid but I still don't see the problem ...
[05:46] <lifeless> ok
[05:46] <igc> iter_changes only needs to return changed parents, not all of them
[05:46] <lifeless> right, but unless its looking at parents it won't return them, because iter_changes has a bug
[05:46] <igc> i.e. if a parent isn't in iter_changes, then it isn't needed in apply_delta IIUIC
[05:47] <igc> lifeless: but it *is* looking at parent right now
[05:47] <lifeless> how?
[05:47] <igc> it looks at the whole tree, then post-filters
[05:48] <lifeless> ow
[05:48] <lifeless> I'm really torn
[05:48] <igc> nad osutils.parent_directories doesn't need to return the root
[05:48] <igc> at the os level, '' doesn't make sense
[05:48] <lifeless> well, other code would be cleaner if it does - as you are making sure you have [''] always
[05:49] <igc> also, my change to when record_titer_changes was deliberate ...
[05:49] <igc> and the comment still hold exactly as is btw
[05:49] <igc> I benchmarked to decide when it was the right thing fwiw
[05:51] <lifeless> why the (len(self.parents) < 2 and not self.specific_files and not self.exclude)
[05:51] <lifeless> clause?
[05:51] <igc> because for non-chk formats, ...
[05:52] <igc> it's slower than the current code otherwise
[05:52] <igc> at least on Emacs
[05:53] <igc> I'm happy to extend the comment along those lines
[05:53] <lifeless> So this means tha the self.specific_files and self.exclude processing with record_iter_changes is _slower_ than the old full-tree code path
[05:54] <lifeless> and that its only faster with record_iter_changes on chk repositoreis because the chk code is able to compensate
[05:54] <lifeless> I appreciate that you've got it going faster
[05:54] <igc> yes, according to my measurements
[05:54] <lifeless> I'm really worried that the other changes, such as the reinstance of files_across_trees are going to make it harder for someone to come bacj and fix bug 347649 properly
[05:54] <igc> it was consistently slower - 08. vs 04 or something like that
[05:54] <lifeless> as they will have to basically undo this patch to fix it
[05:55] <lifeless> on the other hand I don't want to block performance improvements
[05:55] <igc> lifeless: I did look at trying to remove the file_across_trees bit but ...
[05:55] <igc> it broke the test suite cos ...
[05:55] <lifeless> do you have any suggestion about how we can do both things?
[05:55] <igc> we trap for bogus include paths
[05:56] <igc> and iter_changes doesn't see those
[05:56] <lifeless> file_across_trees is a problem because it upcassts the dirstate to an inventory - its spectcularly slow
[05:56] <lifeless> emacs is what 20K files?
[05:57] <igc> just checking, we're talking about the _set_specific_file_ids() method yes?
[05:57] <lifeless> yes
[05:57] <igc> emacs is 8K from memory
[05:57] <igc> 100K revisions but ...
[05:57] <igc> that doesn't matter myuch here
[05:57] <lifeless> ok, so 16K inventory entries
[05:58] <lifeless> I don't feel good about this code
[05:58] <lifeless> so I'm going to recuse my self as a review at this point; I don't want to block you, and I haven't managed to open your eyes to why the layering is a problem or matters so much
[05:59] <lifeless> I'll be effectively offline for 2 weeks, and I don't like the idea of you being blocked for that long.
[05:59] <igc> I see and agree with the desire for one iter_changes call covering ...
[05:59] <igc> legal filename checking, strict checking and collecting results
[06:00] <igc> but I don't see it being necessary to get there in a single step
[06:01] <lifeless> I bet you cold cache specific file commits will be way slower with your patch
[06:01] <lifeless> particularly on the large trees I've been working up to - 50K and 100K files
[06:02] <igc> slower than now or slower than possible?
[06:02] <lifeless> slower than now
[06:02] <lifeless> I could be wrong
[06:03] <lifeless> but what you trade off is some unoptimised code (CHKRepository.add_inventory) for some optimised code that does a lot of IO (WT.iter_changes of everything)
[06:04] <igc> I'll throw together the OOo tree and benchmark on it
[06:05] <lifeless> cold cache will be key to see the disk IO impact
[06:05] <lifeless> I can suggest a completely different approach if you just want to make it faster in the interim
[06:05] <igc> lifeless: design wise, I have a question ...
[06:05] <igc> if we delegate specific_file prcoessing to iter_changes ...
[06:05] <lifeless> (an approach I wouldn't feel unhappy about)
[06:06] <igc> how we we accurately insert the parents after the fact?
[06:06] <igc> s/we/can/
[06:06] <igc> we don't have all the info?
[06:06] <lifeless> igc: iter_changes is allowed to jump around
[06:06] <lifeless> igc: it already does this for renames
[06:07] <lifeless> iter_changes has built into it the logic of find_ids_across_trees
[06:07] <lifeless> anyway
[06:07] <lifeless> if you want something easy
[06:07] <lifeless> add a parameter to finish_inventory called 'basis_inventory'
[06:07] <lifeless> and if use_record_iter_changes is False in commit
[06:07] <lifeless> pass self.basis_inventory to finish_inventory
[06:08] <lifeless> and in finish_inventory do:
[06:08] <lifeless> if self.repository._format._commit_inv_deltas
[06:08] <lifeless> delta = self.new_inventory._make_delta(basis_inventory)
[06:09] <lifeless> self.repository.add_inventory_by_delta(basis_inventory, basis_inventory.revision_id)
[06:09] <lifeless> ^
[06:09] <lifeless> this will work around finish_inventory being overly slow in CHK repositories when not using record_iter_changes
[06:10] <lifeless> and as you'll already have a basis_inventory it should be nigh free
[06:11] <igc> lifeless: ok, I'll play with that next week and try it on some larger data sets
[06:12] <lifeless> igc: I would expect that to be ~= to what you have today, and deal with cold cache and other situations much better
[06:12] <lifeless> no where near as fast as fixing iter_changes
[06:12] <lifeless> I would expect a fixed iter_changes to smoke everything
[06:14] <lifeless> as for what to do in iter_changes to handle parent dirs
[06:14] <lifeless> I would keep a minimal set of directory items output
[06:14] <lifeless> and a 'we need a parent of X' queue
[06:14] <mtaylor> morning lifeless
[06:14] <lifeless> at the end of the normal loop, if there 'we need a parent of X' is non-empty
[06:15] <lifeless> we do the normal loop on just the missing parents
[06:15] <lifeless> without recursion
[06:15] <lifeless> hi mtaylor
[06:15] <lifeless> 25 minutes to branch samba with bzr
[06:15] <lifeless> 16 with git :(
[06:15] <lifeless> I think the difference is entirely size
[06:16] <lifeless> as both saturated my link
[06:16] <mtaylor> lifeless: I had to use hg ove the past few days for something - hated every second
[06:16] <lifeless> mtaylor: :)
[06:16] <igc> lifeless: right, and it's the lack of recursion support that makes it hard to tack these on now
[06:17] <igc> lifeless: btw, there is a genuine use case for filter_iter_changes_by_paths() beyond commit: post processing the output from Inventory.iter_changes()
[06:18] <igc> and anything else that looks the same but doesn't take the specific_files parameter
[06:18] <lifeless> igc: Sure, I wouldn't have suggested a generic function if I didn't think it could be useful generically ;)
[06:18] <lifeless> igc: that said, I think Inventory.iter_changes should take specific_files :)
[06:19] <igc> with chk_maps, I'm pretty sure we get the lot and post-filter much like this
[06:20] <igc> lifeless: anyhow, thanks for the feedback & have fun at uds/allhands
[06:20] <lifeless> I'd like to have a toolkit of iter_changes iterator filters
[06:20] <lifeless> quite separately from making commit awesome
[06:21] <igc> lifeless: I was thinking along those lines too
[06:21] <lifeless> but the only way to avoid excess IO is for iter_changes to know that it should skip over things
[06:21] <lifeless> which the sepecific + exclude params are needed or
[06:21] <lifeless> *for*
[06:23] <igc> when dirstate.iter_changes() supports exclude as a parameter, I'll be far more interested :-)
[06:24] <lifeless> I'd like it if someone other than John and I did that
[06:24] <lifeless> we've got a bunch of talented people
[06:24] <igc> we do
[06:25] <igc> and it's a talent knowing which bits of code to leave to the experts :-) :-)
[06:25]  * lifeless snorts
[06:25]  * lifeless looks around for that beaker of expert-juice
[06:25] <igc> I've read the dirstate code multiple times and it still makes my head spin :-(
[06:25] <lifeless> the C version is a lot clearer
[06:26] <lifeless> we got to use functions
[06:26] <lifeless> they help ;)
[06:26] <igc> yes :-)
[06:26] <lifeless> If you want to poke at iterchanges a bit and send mail asking for clarification please do
[06:26] <lifeless> it will be an asset to have you understand it
[06:28] <lifeless> though, does our medical cover self inflicted insanity?
[06:34] <lifeless> igc: I have another hidden motivation
[06:34] <lifeless> I want to make the commit code radically simpler
[06:34] <igc> lifeless: I'm all for that
[06:34] <lifeless> by having it be _just_ policy on top of iter_changes + CommitBuilder
[06:35] <lifeless> policy+ui
[06:35] <igc> though it's pretty good but one particular bit now
[06:35] <igc> and that bit is around the pointless-commit checking
[06:35] <lifeless> yes
[06:35] <igc> I think some of check_pointless() ought to be pushed down into builder.any_changes()
[06:36] <lifeless> yes, or removed
[06:36] <lifeless> uhm
[06:36] <lifeless> any_changes is kindof pure
[06:36] <lifeless>  I don't think it should be saying 'no' if there are changes
[06:37] <lifeless> also
[06:38] <lifeless> check_pointless should also catch pointless merge commits
[06:38] <lifeless> if you know what I mean
[06:39] <igc> that "initial commit is just a root directory" stuff seems to look way too much into the builder for my liking (was my point)
[06:40] <igc> anyhow, back to other stuff
[06:40] <lifeless> sure
[06:40] <lifeless> I agree
[07:31] <vila> hi all
[07:32] <lifeless> hi
[07:40] <jml> lifeless: how go the talks?
[07:53] <lifeless> good
[07:53] <lifeless> gc one nailed I think
[07:53] <lifeless> bvg one nearly full-draft
[08:29] <knielsen> is there an algorithm that given a bzr revision number will provide the revision number of the parent (leftmost parent in case of merge changeset) ?
[08:29] <Peng_> beuno or mwhudson: ping
[08:29] <knielsen> ie. N -> (N-1), but what about composite revision numbers?
[08:30] <lifeless> knielsen: X.Y.Z->X.Y.(Z-1) forall Z > 0
[08:30] <lifeless> knielsen: X-1 for all X.Y.Z, Z=0
[08:30] <lifeless> If I remember correctly ;)
[08:30] <fullermd> Sounds like an XY problem question, though.
[08:31]  * lifeless looks around for the muzzle
[08:32] <fullermd> I told you, wait 'till she leaves town.
[08:32] <lifeless> :P
[08:32] <knielsen> lifeless: hm, thanks, but doesn't that sound too simplistic?
[08:32]  * knielsen thinking
[08:32] <lifeless> knielsen: if you want it to be complex, I can come up with some extra stuff
[08:33] <vila> X.Y.Z->X.Y.(Z-1) forall Z > 1 X-1 otherwise (we don't have Z=0 AFAIK)
[08:33] <Youssef> Hi all!
[08:33] <Youssef> is there an admin?
[08:34] <vila> knielsen: but relying on revnos is fragile, why don't you just access the revision map and take the first parent /
[08:34] <vila> s!/!?!
[08:34] <Peng_> I hate time zones.
[08:34]  * vila talking perl again :(
[08:34] <knielsen> vila: yeah, just wondering
[08:34] <Peng_> Whoever invented time zones had no respect for programmers. :(
[08:35] <vila> Peng: go to North Pole and turn around if you don't like the current TZ
[08:35] <knielsen> vila: I prefer revid:'s myself, but most of the world seems to be using revision numbers without considering that they can change at each merge
[08:35] <Youssef> please guys respond me!
[08:35] <Peng_> Youssef: I admin things, but probably not what you're interested in.
[08:36] <Youssef> lol
[08:36] <Youssef> okauy
[08:36] <Youssef> yesterday i asked what is the difference between
[08:36] <Youssef> create a checkout and make a local copy of the branch
[08:36] <vila> knielsen: there are not supposed to change in a given branch, not even a trunk one where other branches are merged into if you use append_revisions_only
[08:37] <fullermd> Time zones are an artifact of diurnal slavery.  Liberate thyself!
[08:38] <knielsen> vila: well, if two people branch from revision N, and each commit revision N+1, then at least one of the commits will change the revision number when you merge ;-)
[08:38] <lifeless> vila: you're wrong ;)
[08:38] <lifeless> vila: the parent of the first commit on a branch is a mainline rev
[08:38] <Youssef> Peng_:
[08:38] <Youssef> ???
[08:38] <Peng_> fullermd: I did, but the rest of the planet hasn't followed along, so I still have to deal with it.
[08:38] <Peng_> Youssef: Probably the difference between "bzr checkout' and "bzr branch". See ToirtoiseBZR's docs and "bzr help".
[08:39] <fullermd> Peng_: Their fault then.  Apply beatings until behavior is modified.  Making bail is left as an exercise for the reader.
[08:40] <Youssef> Mmhhhh... okay thanks
[08:40] <Peng_> fullermd: I can't beat up everyone.
[08:40] <vila> knielsen: not inside a given branch, on trunk the first to push will even keep the same revno as his local branch
[08:40] <Peng_> Wait, I only have to beat up all Bazaar users. That's significantly easier, but still impractical.
[08:41] <vila> lifeless: wrong about Z=1 or about revno stability ?
[08:42] <lifeless> vila: Z=1
[08:42] <knielsen> vila: didn't know about append_revisions_only, want to check that ... but what I mean is if I eg. branch from an old revision of lauchpad directory, commit locally, merge tip of the launchpad branch, and finally push the result to the launchpad branch, all intervening revision numbers will change
[08:42] <knielsen> right?
[08:42] <lifeless> knielsen: yes
[08:43] <vila> knielsen: yes
[08:43] <lifeless> knielsen: this is used to control presentation of history
[08:44] <vila> knielsen: either your manage history presentation from trunk or you force your local history upon others
[08:44] <vila> the later doesn't scale very well
[08:45] <knielsen> well, actually I prefer to always use revid: when sending revision references to others (or tags of course) ...
[08:45] <knielsen> but I don't understand what you mean with "manage history presentation from trunk" ?
[08:45] <knielsen> sounds like there is some documentation somewhere that I would like to read to learn about this ;-)
[08:46] <vila> knielsen: you mean you're voluntering to write it ? Great ! :-)
[08:47] <knielsen> lifeless: right, just did a simple example of multiple branching/merging, and I got 1.1.2 as the parent of 1.2.1, so the issue _is_ a bit more complex (as it must necessarily be)
[08:47] <knielsen> vila: I might actually, but I will have to learn it first ;-)
[08:47] <vila> knielsen: the left-hand side history for a given branch is shown by 'bzr log -n1'
[08:47] <knielsen> probably I will check into the source code
[08:48] <vila> i.e. you get the commit messages for the commits done on that branch only, not the commit messages for the merged revisions
[08:49] <vila> managing history presentation from trunk then means that you chose proper commit messages when merging and generally do only commits for merges in trunk
[08:50] <vila> *but* if you push on trunk, you end up with series of commits for each feature or bugfixes, not a synthetic view, but a detailed one
[08:51] <knielsen> vila: yes. Exactly
[08:51] <vila> it's a highly subjective matter
[08:52] <knielsen> vila: well, the underlying problem is an automatic tool that monitors a public branch for changes, and eg. builds and tests each new revision, or does some other action
[08:53] <knielsen> vila: and often I see the tools or people providing notifications in the form of the revision number of the new revision
[08:53] <vila> knielsen: we call that a gatekeeper
[08:53] <lifeless> knielsen: huh?
[08:53] <lifeless> 1.2.1 descending from 1.1.2 ?
[08:54] <lifeless> oh, its the newer form, the original had the drop-2 items property
[08:54] <knielsen> vila: but the revision number is actually not suitable for this in the general case. Just knowing the revision number does not allow you to do anything really reliably, as when you look at the branch that revision number may rever so something else entirely
[08:54] <knielsen> vila: so the solution is to use revision id's, of course...
[08:55] <lifeless> knielsen: long lived branches often set the append only flag
[08:55] <lifeless> which means the revnos are stable
[08:55] <knielsen> lifeless: yes, I want to check up on that flag, wasn't aware of it. sounds useful
[08:55] <lifeless> bzr help configuration, I believe
[08:55] <knielsen> I guess I will look into the source to learn more at some point
[08:56] <fullermd> To be precise, it's not so much that the flag keeps the revnos stable, as that it prevents you from doing the things that make them change.
[08:57] <vila> fullermd: right
[08:58] <knielsen> lifeless, vila: anyway, thanks a lot for you comments, quite useful
[09:19]  * igc dinner
[11:15] <bialix> jelmer: I have a couple questions about bzr-git
[11:15] <bialix> 1) does it can work with github? at least for branch/pull
[11:15] <bialix> 2) why you has marked it as incompatible with Windows?
[11:27] <jelmer> bialix: it works with github
[11:28] <jelmer> bialix: it's not been tested on Windows yet, and I'm aware of some places where we should be converting / to \
[11:33] <bialix> jelmer: re Dulwich: does C-extensions (_object.c and _pack.c) is used now?
[11:33] <jelmer> bialix: they're optional
[11:34] <jelmer> bialix: patches to fix the windows issues are very much welcome btw
[11:34] <bialix> I've fixed setup.py to compile them, but _pack.c cannot be compiled with MSVC right now (MSVC lacks stdint.h)
[11:34] <bialix> jelmer: I have interest in bzr-git
[11:34] <jelmer> bialix: you can steal the stdint.h replacement from bzr-svn
[11:34] <bialix> perhaps I need to work with some github projects, so
[11:35] <bialix> ok, I'll look to bzr-svn then
[11:36] <bialix> jelmer: how you prefer to get patches: by mail or via LP merge requests?
[11:36] <jelmer> bialix: by email
[11:36] <bialix> ok
[11:49] <awilkins> lifeless: Did you speak to me earlier? I have an alert but my scrollback doesn't contain it
[11:51] <awilkins> lifeless: I either had an obscure bug or suffered from an MD5 collision in my packs... I think the bug is far more likely
[11:55] <lifeless> awilkins: bug, windows specific
[11:55] <lifeless> fail during inserting a pack
[11:55] <lifeless> then do the same pull again
[11:55] <lifeless> fail the second time because we can't rename over the file
[11:55] <awilkins> lifeless: Aha, yes, I got that
[11:56] <lifeless> can you file a bug:)
[11:56] <awilkins> Definitely, I was watching with a FS traceer
[11:56] <awilkins> I think the fail may either have been a permissions thing or a result of that jailbreak bug
[11:56] <awilkins> Although it recurred after I fixed the jailbreak, move the repo, made a new one, and pushed all the branches into it
[11:57] <awilkins> 'twas always a particular pack, I recognised the MD5 each time
[11:57] <lifeless> yes
[11:57] <lifeless> odd to have it happen again ><
[11:58] <lifeless> reproducible?
[11:58] <lifeless> [and have you filed a bug for the rename handling of it on windows? :)]
[11:58] <awilkins> Gimme a chance...
[11:59] <lifeless> :P
[12:00] <awilkins> I saw it write the pack and then write it again in the same session
[12:00] <lifeless> oh? depends on what you mean by that
[12:00] <lifeless> older clients write to packs by doing append many times
[12:00] <awilkins> I still have the nagging thought that it could have been an MD5 collision but that would be rather silly
[12:01] <awilkins> This was a 14.1 client writing to a 14.1 server over HTTP HPSS
[12:01] <lifeless> so that does a single post
[12:01] <lifeless> if it was an md5 collision a different error
[12:01] <lifeless> would have been reported
[12:01] <lifeless> one that says 'lucky you' in essence
[12:02] <awilkins> Does it even check?
[12:02] <lifeless> yes
[12:02] <lifeless> welllll
[12:02] <lifeless> there are checks about this
[12:02] <awilkins> The trace (which I didn't save, sorry) had the offending pack created and written in "packs" then in upload, then it tries to rename it from upload to packs and fails
[12:03] <awilkins> Maybe I'll do it again when I'm back in the office
[12:03] <awilkins> Right now I have an annoying deadline I'm going to miss
[12:03] <lifeless> oh
[12:04] <lifeless> might be a suspend/resume bug
[12:04] <awilkins> Of the session?
[12:04] <lifeless> yeah, stateless server - saves in progress pack as <hash>.pack in uplaods
[12:05] <lifeless> then does the final rename to ../packs in a separate hpss call
[12:05] <awilkins> That rename is the bit that fails - shouldn't it be doing all the pack writing like that and not creating files in "packs"
[12:06] <awilkins> Hmmph, I can't branch 1.14 from lp
[12:07] <awilkins> Error received from smart server: ('error', "'AbsentContentFactory' object has no attribute 'get_bytes_as'")
[12:07] <awilkins> I've been getting that for 3 days now
[12:07] <lifeless> try with sftp
[12:07] <lifeless> if that works we need to repair the branch
[12:08] <lifeless> smart server wants more data in stacked branches
[12:08] <lifeless> repair is a bit wrong; just push a tad more data into it
[12:08] <awilkins> Looks like a missing bit of API
[12:08] <lifeless> bzr branch nosmart+bzr+ssh://b.l.n/~bzr/bzr/bzr.dev
[12:11] <awilkins> Got a 'str' object has no attribute 'get' trying sftp
[12:11] <awilkins> I think that might be bzr-svn though
[12:12] <jelmer> awilkins: yeah, that's a known issue fixed in 0.6
[12:19] <awilkins> Ok, the problem occurs in the finish() method of NewPack
[12:30] <jelmer> vila: are you aware of the python-webdav module?
[12:34] <vila> jelmer: never heard about it
[12:36] <jelmer> vila: python-based webdav server implementation
[12:37] <jelmer> vila: I'm looking at it for bzr-svn server side testing
[16:30] <bialix> jelmer: ping
[16:30] <jelmer> bialix: pong
[16:31] <bialix> jelmer: if you don't like my test command I'll keep it for myself in my own branch
[16:31] <bialix> so other patches I'll prepare in another branch
[16:32] <bialix> what I should do?
[16:32] <jelmer> bialix: Please keep it separate
[16:32] <bialix> ok
[16:33] <bialix> jelmer: are you ok to put test files into temp subdir?
[16:35] <mxpxpod> jelmer: around?
[16:35] <jelmer> mxpxpod: hi
[16:35] <mxpxpod> I'm getting an error trying to push to a branch using bzr-svn
[16:35] <mxpxpod> SubversionException: ("'/svn/support/!svn/bc/5/branches/1.0' path not found", 160013)
[16:35] <jelmer> bialix: ideally check for TEMPDIR environment variable and if that doesn't exist, tempdir subdir
[16:36] <jelmer> mxpxpod: can you give a bit more context?
[16:36] <mxpxpod> jelmer: do you want my .bzr.log?
[16:36] <jelmer> mxpxpod: yeah, can you mail that perhaps?
[16:36] <bialix> jelmer: on Windows there are $TEMP and $TMP. Also I can use tempdir python std lib
[16:36] <mxpxpod> jelmer: yup, where would you like it emailed to?
[16:36] <jelmer> mxpxpod<EMAIL_ADDRESS>[16:37] <jelmer> bialix: ah, yeah, python std lib tempdir sounds like a good idea
[16:37] <bialix> ok
[16:37] <mxpxpod> jelmer: sent
[16:50] <bialix> jelmer: do you did rebase of my forst patch?
[16:50] <mxpxpod> jelmer: let me know what you figure out...
[16:50] <bialix> s/forst/first/
[16:51] <jelmer> bialix: yeah, I dpushed it
[16:51] <jelmer> bialix: dulwich is maintainer in parallel in both git and bzr
[16:51] <bialix> :-(
[16:51] <jelmer> mxpxpod: no email yet
[16:51] <jelmer> s/maintainer/maintained/
[16:52] <mxpxpod> jelmer: check your spam... it's from<EMAIL_ADDRESS>[16:53] <bialix> jelmer: even file-ids are not preserved :-(
[16:53] <bialix> should I send to you plain diffs then?
[16:54] <jelmer> bialix: no, please by all means do send bundles
[16:54] <jelmer> bialix: dpush will preserve whatever it can in git
[16:54] <jelmer> bialix:
[16:54] <jelmer> bialix: it will retain author/committer, commit message and multiple commits and the merge graph
[16:54] <bialix> I have a lot of coinflicts
[16:54] <jelmer> sorry about that
[16:54] <jelmer> it would've been the same with a plain diff though
[16:55] <bialix> :-/
[16:55] <jelmer> at some point bzr-git will start supporting push
[16:56]  * bialix need to figure out how to best handle this in the future
[16:56] <jelmer> mxpxpod: still nothing, can you try<EMAIL_ADDRESS>?
[16:56] <mxpxpod> jelmer: yeah
[16:57]  * jelmer dinner
[16:58] <mxpxpod> jelmer: sent
[16:59]  * bialix waves
[17:01] <jelmer> mxpxpod: that worked
[17:01] <jelmer> mxpxpod: please file a bug
[17:01] <jelmer> mxpxpod: there is one somewhere there
[17:01] <jelmer> mxpxpod: 0.6 ?
[17:01] <mxpxpod> jelmer: 0.5.4
[17:30] <awilkins> jelmer: Do you still have to use svn-push or can you just use push for new branches that don't exist in the target repo?
[17:30] <awilkins> (for 0.5.4)
[17:31] <SamB> awilkins: I don't think svn-push still exists ?
[17:34]  * awilkins reads the help and answers his own question
[17:34] <awilkins> SamB: It's there, but the help says it just tells you to use push
[17:34] <awilkins> It's going to be a long push anyway, many MB of data over a rather slow upstream
[17:34] <awilkins> I do find myself wishing it was a bit more chatty
[17:34] <awilkins> It's just sitting there eating bandwidth and some feedback would be nice :-)
[17:34] <awilkins> If only so I can tell when I've hit my ISP cap and it's throttled me :-)
[17:35] <SamB> doesn't it show you the progress ?
[17:35] <SamB> and transfer rate ?
[17:35] <awilkins> SamB: The other transports do, but this one isn't
[17:51] <jam> mneptok: I heard you were looking for me
[18:01] <awilkins> Yegods I hate having a slow upstream
[18:06] <mneptok> jam: i am!
[18:06] <mneptok> jam: got time to look into a bug that's blocking some MariaDB work?
[18:07] <mneptok> jam: https://bugs.launchpad.net/bzr/+bug/375898
[18:07] <mneptok> !botsnack
[18:09] <jam> mneptok: I have not specifically looked at that yet, if you give me a bit I'll have a peek
[18:11] <mneptok> jam: at your leisure, sir.
[18:11] <mneptok> jam: thanks for the mental bandwidth :)
[18:30] <jam> mneptok: so is re-doing the merge of pbxt an option?
[18:31] <knielsen> jam: that's certainly an option. The merge described in the bug was just a test, and since there were problems it has been put on hold
[18:31] <jam> because I'm guessing that doing something like "bzr merge-into/bzr join" is going to be a lot easier
[18:33] <knielsen> jam: we were not aware of the bzr join functionality, but it looks interesting (and what is bzr merge-into?)
[18:33] <jam> knielsen: 'lp:bzr-merge-into' is a plugin that merges a project into a subdirectory of another project
[18:34] <jam> 'bzr join' is a built-in command to do the same thing, but as written has specific requirements as to repo formats, etc
[18:35] <knielsen> jam: sounds like this would be better, using a supported way to merge a subproject rather than the hackish/abusish approach from the bug...
[18:35] <jam> knielsen: so from what I could see, you are merging everything in, but you get some filename conflicts, so you move them out of the way, do the global merge, then merge them back in
[18:35] <jam> sorry,
[18:35] <jam> rename them to where you really want them
[18:36] <knielsen> yes, sounds right
[18:37] <jam> let me give it a poke, since I should have what you need here
[18:38] <knielsen> hm, bzr docs says `bzr join` requires that the tree to be joined be first split out with `bzr split`... but won't that prevent commits from the original subproject tree to be pullable into the new joined tree?
[18:38] <knielsen> well, I should try it and see
[18:39] <jam> knielsen: well, I've used 'merge-into' before to maintain a nested structure
[18:39] <knielsen> jam: ok, I'll look into that as well
[18:39] <jam> the only known issue is that newly added files in the root of the subproject
[18:39] <jam> will show up in the root of the outer project
[18:39] <jam> rather than in the subdir
[18:39] <jam> otherwise, things should flow fine
[18:39] <jam> knielsen: what rev of maria should I try to use?
[18:39] <jam> (just before the pbxt merge)
[18:40] <jam> ah, I think I found it
[18:41] <knielsen> jam: you can use the<EMAIL_ADDRESS>of lp:maria
[18:41] <jam> k, i used<EMAIL_ADDRESS>since that was in the bug report
[18:41] <jam> looks about the same :)
[18:42] <knielsen> jam: just out of curiosity, do you think the "ERROR: No final name for trans_id 'new-1'" is a bzr bug, or caused by user abuse?
[18:42] <jam> (At first glance Pidgin decided to turn : Paul into a smiley face, so it wasn't obvious)
[18:42] <knielsen> heh
[18:43] <jam> knielsen: it *is* a bug, but whether it was introduced at the 'combine' step, or at the new merge time...
[18:43] <knielsen> jam: right...
[18:44] <knielsen> jam: there is a _lot_ of add/rename/modify going on on top of each other on the same files, so lots of potential for borner case bugs.
[18:45] <knielsen> s/borner/corner/
[18:46] <Tak> is there a way to explicitly close a branch? (bzrlib)
[18:47] <jam> Tak: del branch
[18:47] <jam> knielsen: I'll post my approximate steps
[18:47] <Tak> aha, thanks
[18:47] <knielsen> jam: cool, thanks
[18:49] <Tak> hmm, how does that work when I have a tree and/or a revisiontree that I've obtained from that branch?
[18:49] <Tak> do I need to del them all?
[18:53] <jam> Tak: well, you need to get rid of all references to the branch
[18:53] <jam> I'm not sure how you got a "tree" from the branch, though certainly a revtree via repository
[18:53] <jam> I doubt the revtree references the branch, but it would reference the repository
[18:54] <jam> knielsen: update posted to 375898
[18:54] <Tak> ok, so I need to nuke everything that might reference the branch
[18:54]  * knielsen looking
[18:54] <Tak> I suppose Branch.close() wouldn't be considered in the future? ;-)
[18:55] <jam> knielsen: I can say that after doing the recipe I mentioned
[18:55] <jam> I can do: "bzr merge lp:pbxt"
[18:56] <jam> and the files changed are in storage/pbxt/... and mysql-test/suite/pbxt/...
[18:56] <knielsen> jam: right, that's cool
[18:56] <knielsen> jam: I'll definitely try it out and see how it works
[18:57] <knielsen> jam: With the original merge I did, the but shows up when merging a single changeset from lp:pbxt, but merging all of lp:pbxt worked like you tested on the new merge. So will be interesting to compare
[18:58] <jam> knielsen: can you give the cherrypick you want me to try?
[18:58] <jam> (note that I won't have applied your individual patches yet)
[18:58] <jam> but we still shouldn't get 'no name for new-1' sort of stuff
[18:59] <jam> we could give conflicts, etc, but that error is an internal bug
[18:59] <knielsen> jam: I did `bzr branch<EMAIL_ADDRESS>lp:pbxt to-be-merged and then merged from the to-be-merged branch.
[19:00] <jam> knielsen: that would be a complete merge, not a cherrypick, at least as far as I can see
[19:00] <jam> you aren't specifying an explicit base
[19:00] <jam> what you just mentioned should be equivalent to:
[19:00] <jam> bzr merge -r<EMAIL_ADDRESS>lp:pbxt
[19:01] <knielsen> jam: that might be the same as cherry-picking revid:revid:paul.mccullagh<EMAIL_ADDRESS>- I'm not sufficiently knowledable with bzr to know (it's a single commit)
[19:01] <jam> and at least here, I get:
[19:01] <jam> $ bzr merge -r<EMAIL_ADDRESS>../pbxt
[19:01] <jam>  M  mysql-test/suite/pbxt/r/type_varchar.result
[19:01] <jam>  M  mysql-test/suite/pbxt/t/type_varchar.test
[19:01] <jam>  M  storage/pbxt/src/ha_pbxt.cc
[19:01] <jam> All changes applied successfully.
[19:01] <knielsen> jam: basically, I'm merging the next single commit on lp:pbxt ...
[19:01] <knielsen> jam: right, so it works!
[19:03] <jam> knielsen: with the range you gave, I get the same result "All changes applied successfully"
[19:03] <jam> and it doesn't count as a cherrypick
[19:03] <knielsen> jam: right, so in the merge in the bug report, the two first files are actually deleted in the merged mariadb tree ...
[19:03] <jam> because<EMAIL_ADDRESS>is in your ancestry already
[19:03] <knielsen> jam: and bzr says something strange: +N mysql-test/suite/pbxt/r/type_varchar.result.OTHER
[19:03] <knielsen>     +N mysql-test/suite/pbxt/t/type_varchar.test.OTHER
[19:03] <jam> knielsen: well "Contents conflict in ...." is "You deleted X, but OTHER modified it, Conflict"
[19:04] <jam> so we version the latest version of the OTHER (as .OTHER)
[19:04] <jam> since you can "bzr revert .....OTHER" if you want to preserve your delete
[19:04] <jam> or you can "mv x.OTHER x" if you want to restore the file
[19:04] <knielsen> jam: right. In any case the conflicts are correct
[19:04] <jam> [I'm not particularly fond of versioning foo.OTHER, but I understand why it was chosen.]
[19:05] <jam> that said, the "No final name for trans_id 'new-1'" is still a bug
[19:05] <knielsen> of course
[19:05] <jam> I don't know how it thinks it wants to version a file, with no real file-id
[19:05] <jam> and obviously no filesystem path
[19:06] <jam> knielsen: anyway, I can probe directly into the bug, or I can say "use merge-into" to do this sort of thing, and we can punt for now
[19:06] <jam> I'd like to get back to working on my presentation for next week, if that is ok
[19:07] <knielsen> jam: yes, agree. Using merge-into is in any case much better, thanks a lot for that hint.
[19:08] <knielsen> jam: so I will look into merge-into to solve our problem. And then later when you or someone else get back to look at the bug, I hope you will have the necessary information to debug it
[19:09] <knielsen> jam: I gave the 3-step sequence to reproduce from public launchpad trees, with revid:s to make sure they stay stable, so hopefully that will be sufficient
[19:09] <knielsen> jam: in any case, thanks a lot for your time and help!
[19:14] <vxnick> hi all - I'm trying to bzr push a branch to a remote server via sftp, but I get the message "This transport does not update the working tree of: <repo location>"
[19:15] <Tak> that's just a warning
[19:17] <vxnick> Tak: it doesn't push anything though - it says "no new revisions to push" even when I bzr add them
[19:17] <vxnick> do I need to commit before I push or something?
[19:24] <knielsen> vxnick: yes, you need to commit before you push. push transfers only committed changes.
[19:25] <vxnick> knielsen: ah ok - I was under the impression that checkout/commit were distinct from pull/push
[19:35] <kfogel> I'm running bleeding-edge bzr.  I'm initting a new repository (new project); I'm tempted to use format 1.14 or 1.14-rich-root -- I would use brisbane-core, but apparently it's not in trunk yet?  So, anyone advise for/against 1.14?
[20:20] <xnox> bzr: ERROR: Must end write group before releasing write lock on CHKInventoryRepository
[20:20] <xnox> Please help. This is on bzr pull from svn
[20:54] <xnox> it seems to me there is a race condition between pull and repacking of revisions on rich-root svn repo's with regards to write lock. That's on bzr 15
[21:41] <jfroy> hello


[01:50] <pleia2> going to just bullet-point blogosphere
[01:54]  * pleia2 uses updated scripts from nhandler, woo
[02:28] <nhandler> pleia2: Any issues with them?
[02:28] <pleia2> nhandler: just ran the loco one so far, lgtm
[02:29] <pleia2> Unit193: link check? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue431
[02:29] <pleia2> and sending off to editors
[06:49] <Unit193> https://wiki.ubuntu.com/MeetingLogs/Security/201508 might be, or FP.  Sorry can't confirm myself.
[07:11] <PaulW2U> Above link fixed
[13:17] <mhall119> pleia2: do you need me to do something with https://bugs.launchpad.net/uwn/+bug/1487595 or has nhandler gotten the data from the API?
[15:22] <nhandler> mhall119: I think I am good (unless pleia2 wants any changes made to my current version of the script)
[16:00] <pleia2> nope, lgtm
[17:38] <PaulW2U> editorial review done
[17:39] <pleia2> thanks, was nice to see jim pitch in again this week too


[21:04] <Olafurh> Looks like Icelandic mirror is.archive.ubuntu.com is broken (Hosted by Opin Kerfi) and they are slow to fix it... Can it be demoted and another promoted?


[06:09] <dscassel> Finally read the meeting backlog!
[06:09] <dscassel> Insomnia is helpful sometimes.
[06:10] <BobJonkman> Meeting logs should put you right to sleep
[06:12] <dscassel> It's helping!
[21:04] <BobJonkman> Downloading Turnkey Etherpad: http://www.turnkeylinux.org/updates/new-turnkey-etherpad-version-120
[21:05] <BobJonkman> Maybe try using that as the collaborative editing platform for the Page Polishing Party this weekend: http://loco.ubuntu.com/events/ubuntu-ca/2275/detail/
[23:48] <dscassel> BobJonkman: did you saw this, right? http://youtu.be/gj9FT1cirW0?t=41m51s
[23:48] <dscassel> s/did//
[23:53] <BobJonkman> I haven't done seen it yet, but I can did do that now.
[23:54] <BobJonkman> I'm also having a bad/good time with http://pad.ubuntu.com/
[23:55] <BobJonkman> I've got a fresh pad, but when I tried to create a team ("Canada") it threw an error during the creation.  So http://canada.pad.ubuntu.com doesn't yet exist
[23:55] <dscassel> I've only used it for UDS...
[23:55] <dscassel> you probably just don't have permission.
[23:55] <BobJonkman> If anyone cares to join me: http://pad.ubuntu.com/WMV9byyQAX
[23:56] <BobJonkman> I logged in through launchpad, but I guess I need moar power
[23:56] <dscassel> Huh. "The domain canada is already in use."
[23:57] <dscassel> I can't either.
[23:57] <dscassel> meh. whatever.
[23:57] <BobJonkman> I just got some 500 error, which redirected me back to my own site (anything invalid from my domain >is< my domain, as far as my DNS  resolver is concerned


 @ahoneybun, Because more is less. Except when it's not. Which is is about the time the offer is up and they charge you up the butt for stuff you didn't want in the first place.
 Yea it's not too bad right now
 10 days until #Ubuntu 17.10 (Artful Aardvark) is released. Plenty of time to organise a release party!
 https://plus.google.com/+Ubuntu/posts/JGKwfXBzo8r
 Yep there is
 Anyone up for Orlando on the first weekend in November? The same Uno's Pizza
 What happens in orlando?
 We normally drive up on a Saturday and return on Sunday. Just a Pizza Party with those who can make it
 Ooh nice, sounds like fun
 If my schedule allows it I'll join in
 That looks like it was fun
 We had a good turn out last year
 We can get a turnout like that at a park, like we did last time.
 it was more for people in central and north who couldn't drive all the way down to that park
 that park one was pretty fun, I still have that intel computer from winning that android game
 :D
 The 1st half of the year release party is local, the 2nd one is up a bit higher
 I mean, we can get some PI 3/ Pi 3 Zeros and give them away.
 Cool. It seems the last 2 have been in Orlando
 Yes, it makes it easy for those who live outside of the Broward County area to come
 They get left out of most of the events
 giant train ride to orlando
 We are SoFlo, right?
 @RazPi, I wish but it wont be ready for that just yet. Maybe next year
 @AdamOutler, Most of the Ubuntu Fl group is but the group is not limited to South Florida. @itnet7  and @Abrerr are in Central Fl
 Hm, amtrak is 37$ one way
 Then again Keith's car has wifi
 but we could do a vpn in the train car
 I can fit 4 in my car (+ myself) and the entire ride up would be about $60.00
 We also dont need to worry about transportation/etc while up there
 Yeah that's a good point
 I'm not so much worried about cost I thought you might have more fun if you didn't have to drive all the way up
 Actually Orlando Trips are nothing, a few hours of driving
 I used to drive up there at least twice a month when I was a Disney pass holder
 oh man
 The Pizza Place (Uno) is also reasonably priced and they have some pretty good food
 @KMyers i was going through some stuff on my desktop and cleaning it up.  I saw you have a business card 3d print?
 I did make one
 Can i see?
 I dont have one with me right now
 They are pretty easy to make
 Ewww... I touched a Mac
 Wow, you need hydrocortizone
 What happened?
 @AdamOutler, I found a bag of fake Halloween decorations
 Gah!  I thought I did that from my personal one
 Removed
 Lol


[08:32] <BlackDex> admin0: there are some ways by adding/changing the curtin installer scripts if i'm correct. But not easy.
[08:36] <BlackDex> admin0: You can check this article, maybe it will help you: https://insights.ubuntu.com/2017/06/02/customising-maas-installs/
[10:11] <admin0> BlackDex, thanks
[10:11] <admin0> checking
[10:45] <admin0> BlackDex, exactly what i needed
[10:45] <admin0> many thanks
[12:31] <BlackDex> admin0: yw :)
[15:12] <mup> Bug #1749210 opened: node powered off after reboot from rescue mode <amd64> <apport-bug> <uec-images> <xenial> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1749210>
[15:14] <mup> Bug #1749210 opened: node powered off after reboot from rescue mode <amd64> <apport-bug> <uec-images> <xenial> <MAAS:New> <maas (Ubuntu):New> <https://launchpad.net/bugs/1749210>
[16:09] <mup> Bug #1741013 changed: [Wishlist] Ability that can add custom cloud-init configuration <cpe-onsite> <MAAS:Invalid> <https://launchpad.net/bugs/1741013>
[17:09] <mup> Bug #1749246 opened: nodes boot into 4.13 (hwe kernel) with no minimum kernel set <amd64> <apport-bug> <uec-images> <xenial> <maas (Ubuntu):New> <https://launchpad.net/bugs/1749246>
[17:12] <xygnal> roaksoax: ping
[17:15] <mup> Bug #1749246 opened: nodes boot into 4.13 (hwe kernel) with no minimum kernel set <amd64> <apport-bug> <uec-images> <xenial> <MAAS:Incomplete> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1749246>
[17:21] <mup> Bug #1749246 changed: nodes boot into 4.13 (hwe kernel) with no minimum kernel set <amd64> <apport-bug> <uec-images> <xenial> <MAAS:Incomplete> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1749246>
[17:39] <mup> Bug #1749246 opened: nodes boot into 4.13 (hwe kernel) with no minimum kernel set <amd64> <apport-bug> <uec-images> <xenial> <MAAS:Incomplete> <maas (Ubuntu):Incomplete> <https://launchpad.net/bugs/1749246>
[18:48] <xygnal> mpontillo: ping
[18:52] <roaksoax> xygnal: pong
[18:58] <xygnal> roaksoax:  json outputs in that bug report for you. needs review and next stepzn
[18:58] <xygnal> 1744765
[18:59] <roaksoax> xygnal: I saw, thank you. Were you able to try a test environment in hardware?
[19:01] <xygnal> no. my team is not convinced you have enough evidence to prove it as a vmware issue so they have not been in a hurry to try it.
[19:02] <xygnal> do you have a technical theory WHYn
[19:02] <xygnal> ?
[19:03] <xygnal> we dont see any indication of perf issues on the box itself.
[19:03] <xygnal> just the app, which by itself, consumes all memory regularly.
[19:04] <xygnal> even with 8 threads now,  no change.
[19:05] <xygnal> cli commands are still quick
[19:05] <xygnal> only UI impacted
[19:11] <roaksoax> xygnal: are you running xenial? or are you running a newer version ?
[19:16] <xygnal> 16.04.3
[19:16] <xygnal> yes xenial
[19:19] <jtcressy> Does anyone know why a MAAS controller would fail to set a static IP on an interface? Once I set the interface to an IP, the physical adapter is never changed (verified with ip addr show) and upon reboot, the controller shows the interface as unconfigured. What's wrong?
[19:21] <mpontillo> xygnal: sorry for slow responses; I'm swamped with other work
[19:21] <mpontillo> xygnal: when you say "by itself", are you saying that even if there are zero users of the web UI, there are still issues?
[19:22] <mpontillo> jtcressy: at what point does it change? how are you setting the static IP?
[19:23] <jtcressy> Nodes>Controllers>(my only controller)>Interfaces>(second ethernet adapter)> edit physical
[19:24] <jtcressy> Am I wrong in assuming that the MAAS server would change the IP configuration of interfaces on the server it's running on?
[19:24] <roaksoax> jtcressy: the maas controller doesn't change interface configuration
[19:25] <roaksoax> jtcressy: is this a physical interface ? have you restarted maas-rackd again ?
[19:25] <jtcressy> It is a physical interface
[19:25] <jtcressy> So, then what I need to do is configure the interface via /etc/network/interfaces and then maas will be able to use it?
[19:26] <jtcressy> (fyi the way I have this setup is one interface is management network that provides dhcp and the other interface is the rack that the controller should provide DHCP to)
[19:27] <xygnal> i double  checked this and even maas cli takes ages to complete a machines read.
[19:28] <xygnal> er no..
[19:28] <xygnal> not ages.... 120 seconds
[19:29] <roaksoax> xygnal: yeah that's a non issue with the cli
[19:30] <roaksoax> known*&
[19:32] <mpontillo> jtcressy: yes, for controllers MAAS uses the interfaces as-configured.
[19:33] <xygnal> only the ui is slow.  monsterously slow. even takes several minutes to see a node page. like, just a single node's page.
[19:41] <jtcressy> yaaay stuff works after doing all the static assignment stuff in etc/network/interfaces
[19:51] <jtcressy> How can I reconfigure dhcp? machines timeout on trying to get tftp
[19:59] <jtcressy> PXE E32: TFTP open timeout
[19:59] <jtcressy> commissioning node just sits there spinning and doing nothing
[20:00] <jtcressy> have wireshark open and I see the TFTP requests on the wire. maas server just doesn't reply atall
[20:01] <mup> Bug #1749281 opened: MAAS 2.3 does not revert system proxy back to original state when MAAS is removed <MAAS:New> <https://launchpad.net/bugs/1749281>
[20:06] <jtcressy> Wait, do I have to manually install an OS on machines before I can commission it?
[20:14] <mpontillo> jtcressy: once you enable DHCP in MAAS, machines that boot from your DHCP-enabled VLAN should enlist automatically. are you saying MAAS is responding to DHCP but not TFTP requests? are you using any kind of network filtering, DHCP forwarding, or third-party DHCP server, or are your machines just booting directly onto a DHCP-enabled VLAN?
[20:15] <jtcressy> the machines are directly getting DHCP from the maas machine
[20:16] <jtcressy> absolutely zero network filtering. I have a gateway at the '.1' address of the network which is declared accordingly on the maas server
[20:16] <jtcressy> maas server is at '.2' with a static address
[20:16] <jtcressy> and that '.2' address is declared as the dhcp address for the maas controller
[20:16] <mpontillo> jtcressy: can you pastebin the output of /usr/lib/maas/maas-test-enlistment?
[20:18] <jtcressy> mpontillo: https://pastebin.com/wJUjUYNL
[20:19] <mpontillo> jtcressy: er, I meant for you to execute the script so I could see its output; sorry if that wasn't clear
[20:19] <jtcressy> oh ok
[20:20] <jtcressy> mpontillo: https://pastebin.com/1C70p445
[20:22] <jtcressy> mpontillo: FYI, I just checked 'netstat -tnap | grep LISTEN' and port 69 does NOT show up in the output!!!!
[20:23] <mpontillo> jtcressy: well, looks like the TFTP server is responding and serving up bootloaders - at least when the test script runs. you can see that TFTP is indeed responding, so not sure why your command doesn't see it.
[20:23] <mpontillo> jtcressy: I would try `sudo dpkg-reconfigure -plow maas-rack-controller`and make sure that the URL specified is a URL that the booting machines will be able to reach
[20:24] <mpontillo> jtcressy: by default it uses `localhost`, which tries to determine the URL for enlisting nodes to use automatically - this doesn't always work
[20:26] <jtcressy> ok, i set the api address accordingly
[20:27] <jtcressy> rebooting a node still results in tftp timeout and a bunch of node -> maas controller tftp read requests on the wire
[20:27] <jtcressy> What should I do when TFTP is apparently *non-functional* ?
[20:29] <mpontillo> jtcressy: is there anything else about your setup that might be unusual? your pastebin proved that TFTP works to some extent; the `maas-test-enlistment` script basically uses `curl`to mimic what the bootloader does, and you can see the MAAS TFTP server responding
[20:30] <jtcressy> but this is weird.... netstat shows that port 69 is NOT listening, so how did the script verify that tftp was working?
[20:31] <mpontillo> jtcressy: well, that's why I was wondering if there was something unusual in your setup. ;-)
[20:31] <jtcressy> I installed this maas server from the "install maas region controller" option at the boot prompt of the installer ISO
[20:32] <jtcressy> and running this all in vmware shouldnt affect it as long as i have the networking in order, which I've verified using wireshark
[20:33] <jtcressy> and the fact that they can communicate with maas via dhcp
[20:33] <mpontillo> jtcressy: netstat doesn't show udp ports in LISTEN mode; if you grep your netstat for "udp" you will most likely see the open ports
[20:34] <mpontillo> jtcressy: for example, I see `udp        0      0 <IP_ADDRESS>:69            <IP_ADDRESS>:*                           10842/python3` on my test MAAS
[20:34] <jtcressy> just 'netstat -na | grep udp' ?
[20:34] <mpontillo> jtcressy: I used `netstat -anp | grep udp`
[20:35] <mpontillo> jtcressy: did you enable `ufw` when you installed the server? if so, try turning it off?
[20:36] <jtcressy> ok, 69 shows up in netstat with udp now
[20:37] <jtcressy> didnt touch ufw
[20:37] <mpontillo> jtcressy: ok. well, you could copy the maas-test-enlistment script to another machine to test if it works from somewhere else across the network. if you pass it a hostname or IP address as a parameter, it will query a remote MAAS
[20:38] <mpontillo> jtcressy: so far you've proved that TFTP is up and running on the MAAS server, but you haven't proven you can talk to it over the network
[20:39] <jtcressy> working on it. rebooting it for good measure, then going to try tftp from my host system
[20:41] <jtcressy> tftp works from my host system
[20:43] <jtcressy> *and* this is to the IP that the commissionable nodes are supposed to be talking to
[20:47] <jtcressy> I just don't understand why '.191' is completely ignored from tftp requests, when '.1' is answered for tftp requests.
[20:50] <jtcressy> Ok, i'm noticing one thing. I filtered my wireshark for just tftp packets to compare it directly. When running tftp from my host machine, it initially talks to the maas server on port 64
[20:50] <jtcressy> but the node keeps trying port 69
[20:50] <jtcressy> the node also trys port 74
[20:50] <jtcressy> oh, forget what I said. I was reading the wrong field
[20:51] <jtcressy> both of them are reading port 69
[20:57] <jtcressy> mpontillo: I see another discrepancy: My host is requesting type "netascii" while the node is requesting type "octet"
[20:57] <jtcressy> so, netascii works and octet does not
[21:00] <mpontillo> jtcressy: netascii vs. octet shouldn't matter; MAAS will always return the same response regardless.
[21:00] <mpontillo> jtcressy: when you say .191 is ignored and .1 is answered, what do you mean?
[21:00] <jtcressy> <network address>.1 i.e "<IP_ADDRESS>"
[21:03] <jtcressy> supposedly, there is a hosts.allow file somewhere on the ubuntu server but i don't know where it is
[21:15] <jtcressy> mpontillo: ran tcpdump on the maas controller for port 69 and watched the node request pxelinux.0 and the maas controller just never responds https://pastebin.com/rQ08vDvq
[21:19] <mpontillo> jtcressy: weird, and yet when you use the script (or something like `curl -s`?) it replies?
[21:20] <jtcressy> yep
[21:20] <mpontillo> jtcressy: is the MAC seen by the PXE address known to MAAS? you might check /var/log/maas/*.log for any clues
[21:20] <jtcressy> I just ran tftp <IP_ADDRESS>, then get pxelinux.0 from my macbook and it also works
[21:20] <jtcressy> i'll check the maas log. the mac address is known to maas
[21:21] <mpontillo> jtcressy: is <IP_ADDRESS> configured on ens38?
[21:22] <jtcressy> yes
[21:22] <jtcressy> <IP_ADDRESS> is my macbook
[21:22] <jtcressy> and <IP_ADDRESS> is the node, and the node got this IP from the maas server via dhcp
[21:23] <mpontillo> jtcressy: what is the output of `ip r g <IP_ADDRESS>` on the MAAS server?
[21:23] <jtcressy> <IP_ADDRESS> dev ens38  src <IP_ADDRESS>      cache
[21:24] <jtcressy> neither /var/log/maas/maas.log or ''/rackd.log say anything when I reboot my node and do pxe again
[21:26] <mpontillo> jtcressy: anything unusual in regiond.log that corresponds?
[21:26] <jtcressy> Nope just a bunch of HTTP 200 logs
[21:43] <mpontillo> jtcressy: if you run the tcpdump while one of the working nodes on that network requests the file, how does the output differ? I know tftp switches ports for the data transfer, so it's not clear to me if the 'port 69' filter would catch everything
[21:44] <jtcressy> No, tcpdump does not catch whether or not tftp actually works, I just used it to verify that the maas server was receiving it from the network
[21:45] <jtcressy> what DOES verify when tftp work, is when i see about 200 packets flow across the network that I can see via wireshark
[21:46] <jtcressy> What I need to know is if the tftp server that maas runs ever discriminates. This is the only thing I can think of, and I cant find ANY tftp logs at all
[21:47] <jtcressy> mpontillo: Found this, reading through it... https://bugs.launchpad.net/maas/+bug/1465000
[21:47] <mpontillo> jtcressy: it doesn't discriminate with regard to the boot loader, but it does return a custom pxelinux.cfg depending on which node booted
[21:49] <jtcressy> but it fails to even send pxelinux.0 so that can't be it.
[21:49] <mpontillo> jtcressy: that was why I asked about interface configuration and routing; setups with the same subnet configured on more than one interface could cause this type of issue
[21:49] <jtcressy> But that's exactly what I don't have. ens33 has <IP_ADDRESS>/24 and ens28 has <IP_ADDRESS>/24. They are completely different networks
[21:50] <jtcressy> ens38*
[21:50] <mpontillo> jtcressy: what version of MAAS are you running?
[21:51] <jtcressy> 2.3
[21:51] <jtcressy> MAAS version: 2.3.0 (6434-gd354690-0ubuntu1~16.04.1)
[22:03] <roaksoax> what it would be interesting to see is what the virtual network in esxi is doing
[22:03] <roaksoax> also, jtcressy can you connect to the tftp server?
[22:03] <roaksoax> manually ?
[22:04] <roaksoax> and get files from it?
[22:05] <roaksoax> from the internal vmware network ?
[22:05] <roaksoax> also, are there anu other dhcp servers in the vlan ?
[23:20] <jtcressy> roaksoax: Sorry, i'm back. Yes, i can contact tftp via the virtual network using my host machine. maas is the only machine giving out dhcp on the lan.