[00:37] is this a known thing? https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1700826 [00:37] Launchpad bug 1700826 in ubuntu-meta (Ubuntu Xenial) "please include numactl on the ubuntu-server iso" [Undecided,New] [00:37] (I can update the seed, but I want to make sure it's agreed upon before) [00:57] hey folks [00:57] who here knows git well? :D === Guest77276 is now known as karstensrage [04:46] cyphermox: i'll ask at our standup tmrw [05:22] good morning === marlinc_ is now known as marlinc === [PARTY]Varka3rd is now known as [PARTY]Varka === JanC_ is now known as JanC === zerocool is now known as Guest52849 === zerocool is now known as Guest1374 === zerocool is now known as Guest87551 [12:55] <[J]oules_> local ubuntu 16.04 acting as syslog server for LAN. rsyslog.conf is setup for udp and tcp on port 514 to enable syslog server. ufw is disabled. iptables -nL shows accept for the 3 default chains. However no lan device/computer is able to communicate with this ubuntu server. [12:58] At all, or only the rsyslog service? [12:58] [J]oules_: ^ [12:58] different vlans ? [12:58] firewall between them [12:59] <[J]oules_> no vlans [12:59] FW's between them ? [12:59] how are you checking connectivity ? [13:00] <[J]oules_> trying to debug sip phone. have sip phone syslog pointing to this ubuntu 16.04. disabled ufw and rebooted. don' [13:00] <[J]oules_> see anything in /var/log/syslog, /var/log/messages from phone at all [13:01] <[J]oules_> changed sip phone syslog to send to remote centos server, remote centos shows logs from sip phone [13:02] <[J]oules_> just dont want those logs going to remote server. want them to come to this local ubuntu server [13:07] [J]oules_: Could you answer my quesiton? [13:08] question even [13:09] <[J]oules_> lordievader: since rebooting only see very few entries in syslog and messages like: Jul 13 09:01:42 myomie colord[1430]: (colord:1430): Cd-WARNING **: failed to get session [pid 3889]: No such device or address [13:09] <[J]oules_> Jul 13 09:09:01 myomie CRON[3928]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean) [13:09] <[J]oules_> thats it [13:10] That was not my question... is there any network response when pinging it from another host, for example? [13:11] <[J]oules_> i can ping the ubuntu server, ssh to it, cannot telnet port 514 to it [13:11] What does nmap report about that port? [13:11] <[J]oules_> nmap not installed [13:12] <[J]oules_> from other server on lan: ping myomie [13:12] <[J]oules_> PING myomie.internal (192.168.25.15): 56 data bytes [13:12] <[J]oules_> 64 bytes from 192.168.25.15: icmp_seq=0 ttl=64 time=0.306 ms [13:12] Could you install nmap and check? [13:12] <[J]oules_> telnet myomie 514 [13:12] <[J]oules_> Trying 192.168.25.15... [13:12] <[J]oules_> telnet: connect to address 192.168.25.15: Connection refused [13:12] <[J]oules_> yup [13:13] Also, use some pastebin service for pasting console output. [13:14] <[J]oules_> lordievader: do you know the syntax to nmap port 514? [13:14] [J]oules_: Assuming you want tcp: `nmap -p 514 ` [13:15] <[J]oules_> thx [13:15] <[J]oules_> 514/tcp closed shell [13:16] <[J]oules_> if iptables shows accept for everything, ufw shows disabled why is it blocked? [13:16] <[J]oules_> i tried before to open 514/tcp and it still did not help [13:16] <[J]oules_> fw status [13:16] <[J]oules_> Status: inactive [13:19] Could you pastebin the output of 'sudo iptables-save' and 'sudo ss -tnl'? [13:28] jamespage: most of the pike failures for CI are due to needing the new python-sphinx [13:29] jamespage: I checked with the maintainer and he said he's planning on uploading but will be a few weeks [13:44] nacc: ta [13:46] hello [13:47] anyone knows why https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1699010 is marked for lxd instead of lxd/lxcfs? [13:47] Launchpad bug 1699010 in lxd (Ubuntu) "process start times offset by host uptime" [Undecided,Fix released] [13:47] and if there is some kind of SRU in progress for xenial? [13:49] <[J]oules_> https://www.irccloud.com/pastebin/PunCQwY1/ [13:50] hey hey [13:50] <[J]oules_> lordievader: i see 514 is not listed [13:50] lordievader: heya :) [13:53] lordievader: do u know git? [13:54] I am encountering some silly error yet to see what is it [13:55] <[J]oules_> lordievader: i take it that since this ubuntu server is not listening on 514 is the reason. Question then is, how to get it to listen on port 514? [13:55] you can install use ufw [13:55] easy to use [13:56] then you cal simply sudo ufw allow 514 [13:56] :) [13:56] and it will auto adjust iptables rules [13:56] u can also allow in only or out only and to a specific ip and or protocol [13:58] <[J]oules_> hehehe: i did that before ... ufw allow 514/tcp and ufw allow 514/udp and no syslog messages were coming in [13:59] you using ossec? [13:59] then you need to open 1 more port [14:00] 1514? [14:00] you can google which port :D [14:01] <[J]oules_> i am not using ossec [14:02] well then why u need 514 open? [14:02] <[J]oules_> just whatever installs with ubuntu server [14:02] whatever what? [14:02] <[J]oules_> because we need to debug a device on LAN [14:02] whats it called? [14:02] well then open it and thats it [14:02] :D [14:02] <[J]oules_> the iso for ubuntu 16.04 [14:02] yes fine [14:02] <[J]oules_> there was no extra security added [14:02] thats fine [14:02] you can add it yourself [14:02] :) [14:03] <[J]oules_> add what? [14:03] whatever u want to add [14:03] security wise [14:03] <[J]oules_> you mean even if ufw/iptables is disabled it still blocks? [14:04] <[J]oules_> put it this way, how to get it to listen to 514 ? [14:04] [J]oules_: run a service that binds to port 514 [14:04] <[J]oules_> from what i read .... [14:04] have a firewall rule to include port 514 as allowed [14:04] you can't send traffic to a port that doesn't have something to receive the data - that's the core issue there. [14:04] to have something listen on <= 1024 you usually need to run something as root [14:05] <[J]oules_> rsyslog [14:05] <[J]oules_> https://www.irccloud.com/pastebin/ZXy2gFy2/ [14:05] yes what teward said :D [14:05] use common sense dude [14:06] [J]oules_: that usually doesn't run as root, IIRC. you may need to use a higher port number like 10514, and then set up a local port-forward for the firewall [14:06] <[J]oules_> everything i searched said to enable rsyslog with what is in the p/b and restart rsyslog [14:06] hehehe: that's not necessary, please refrain from rudeness. [14:06] common sense is rude? [14:06] dude get lost [14:06] :) [14:06] >.> [14:06] this is why I hate IRC sometimes [14:06] <[J]oules_> no kidding [14:07] <[J]oules_> usually because the answer is not known [14:07] Joule simply do something like ssh root@example.com -p514 from any other box [14:07] :) [14:07] -p is port [14:07] wait nope [14:07] <[J]oules_> teward: the firewall ufw/iptables is disabled [14:08] <[J]oules_> hehehe: i showed earlier, telnet port 513 connection refused [14:08] <[J]oules_> hehehe: i showed earlier, telnet port 514 connection refused [14:08] <[J]oules_> sorry [14:08] yep [14:08] <[J]oules_> port 514 [14:08] 1 moment :) [14:10] <[J]oules_> getting rsylog working on a centos server which is remote works, but dont want these logs going remote [14:10] <[J]oules_> basically same setup with rsyslog.conf and restarting rsyslog [14:10] <[J]oules_> for some reason on ubuntu its like pulling teeth [14:10] https://superuser.com/questions/397892/utility-to-open-tcp [14:11] [J]oules_: you may want to use a higher port. [14:11] such as 1051X, because <= 1024 usually has issues [14:11] [J]oules_: is the system you're working on ubuntu or centos? [14:11] [J]oules_, usually it is "uncomment 4 lines in rsyslog.conf, restart rsyslog" [14:11] because if it's not ubuntu i'mma throw you to the ##linux channel. [14:12] nc -4 -k -l -v localhost 1026 [14:13] <[J]oules_> the box is ubuntu, i am chatting here from it [14:13] <[J]oules_> ubuntu 16.04 LTS [14:13] [J]oules_, http://paste.ubuntu.com/25082196/ ... uncomment these four lines (the ones without spaces after the hash sign) in rsyslog.conf and restart rsyslog (works everywhere here ...) [14:13] and on the sending machine, create a file in /etc/rsyslog.d/ containing one line: [14:14] *.* @remote.server:514 [14:14] where "remote.server" is the machine from the first step [14:14] <[J]oules_> https://www.irccloud.com/pastebin/jHiUD2K7/ [14:14] it isnt different in ubuntu than in any other machine [14:14] s/machine/linux distro/ [14:15] Joules lol next time say it clearly - I want to send syslog to other machine [14:15] not I want to test some lan device :D [14:15] did you try dropping the "AllowedSend [14:15] er [14:15] for a test ? [14:17] <[J]oules_> just did it now ogra_ and restarted rsyslog [14:17] <[J]oules_> nothing different [14:18] weird, never had any probs with that [14:18] provide copy of your firewall rules on both machinese [14:18] :) [14:18] machines [14:18] or use ufw [14:18] do you have any other modifications of the syslog config ? [14:18] <[J]oules_> i did enable ufw and enabled 514/UDP and 514/TCP and it still did not work [14:18] ufw oki [14:18] *oki [14:19] any reason to run ufw ? [14:19] Joules and why 514? [14:19] ufw is easier [14:19] thats all [14:19] sigh [14:19] hehehe, you are not being helpful [14:19] Joules you simply want to send syslog from 1 machine to another? [14:19] [J]oules_, any reason to run a firewall on that machine ? [14:19] <[J]oules_> https://www.irccloud.com/pastebin/S6cCJ2Sy/ [14:20] (assuming it sits in a LAN that is firewalled anyway from the outside world) [14:20] <[J]oules_> this ubuntu server is also my workstation. It's behind a mikrtotik router. It is not blocking LAN <-> LAN [14:21] Joules so what exactly do you want to do? [14:21] sure, but hopefulls WAN->LAN ;) [14:21] *hopefully [14:21] <[J]oules_> hehehe: have my sip phone send it logs via syslog to this ubuntu server/workstation [14:22] oki [14:22] <[J]oules_> like i mentioned before, if i set the syslog on the phone to send to one of our pbx's it logs just fine. All our pbx servers are either centos 6 or centos 7 [14:23] <[J]oules_> just this ubuntu server [14:23] <[J]oules_> i think i will just create a centos 7 vm on this ubuntu server via virtualbox [14:23] <[J]oules_> this is too much of a PITA [14:23] https://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ [14:23] nah dont give up [14:23] dont be such quitter :D [14:25] [J]oules_, http://paste.ubuntu.com/25082249/ ... just uncommenting the four lines and restarting syslog gets me this on 16.04 [14:25] [J]oules_, theer must be something additionally that stops rsyslog from opeing the port [14:26] <[J]oules_> i do have those lines uncommented [14:26] <[J]oules_> hehehe: /etc/default/syslogd does not exist [14:26] <[J]oules_> ogra_: agreed, just dont know what it is [14:27] yeah ... [14:27] <[J]oules_> one thing for sure, this ubuntu box is not listening on port 514 udp/tcp [14:27] well, if you tinkered with firewall stuff it might be related ... though then i would expect at least some complaint from syslog in the logs that it cant bind to the port or some such [14:28] <[J]oules_> ok i will turn on ufw and then show you [14:28] pastebin /etc/rsyslog.d/50-default.conf [14:28] :) [14:28] <[J]oules_> https://www.irccloud.com/pastebin/uUW6redV/ [14:28] <[J]oules_> yet nothing comes in... [14:29] sudo netstat -anp|grep :514 [14:29] ? [14:29] <[J]oules_> https://www.irccloud.com/pastebin/PwXrSVWQ/ [14:29] this is on receving box? [14:29] does your host actually listen ? [14:29] post your 50-default.conf :D [14:29] to double check [14:30] <[J]oules_> sudo netstat -anp|grep :514 [14:30] <[J]oules_> [lnb@myomie]:/var/log> [14:30] <[J]oules_> nothing [14:30] so rsyslog definitely doesnt listen [14:30] <[J]oules_> correct [14:30] then its setup error [14:30] as simple as that [14:30] anycomplaints in syslog when you restart it ? [14:30] *config [14:30] <[J]oules_> https://www.irccloud.com/pastebin/vr8LHekq/ [14:31] <[J]oules_> i think that rsyslogd should be -r not -n [14:31] did u use *.* @syslogserverhostname:514 ? [14:32] rbasak: I think samba's ubuntu/zesty-devel is behind in the git repository: rmadison shows 17.04.3, but git has 17.04.2 if I'm not mistaken [14:32] and restart service? [14:32] [J]oules_, it is -n here as well [14:32] http://www.randomhacks.co.uk/how-to-configure-an-ubuntu-server-to-log-to-a-remote-syslog-server/ [14:32] :) [14:32] read this :) [14:33] <[J]oules_> hehehe: that log to REMOTE [14:33] <[J]oules_> i need log to LOCAL [14:33] ogra_: DUDE [14:33] hmm [14:34] so sip phone soft running on same box? [14:34] right [14:34] then it would likely have own log [14:34] somewhere in configs [14:34] [J]oules_, anything non-standard in /etc/rsyslog.d/ ? [14:34] you dont need to open any ports [14:34] blah [14:34] <[J]oules_> ogra_: no [14:35] any other changes in rsyslog.conf ? [14:36] http://paste.ubuntu.com/25082303/ is the default config as the package ships it [14:36] <[J]oules_> telnet localhost 514 [14:36] <[J]oules_> Trying ::1... [14:36] <[J]oules_> Trying 127.0.0.1... [14:36] <[J]oules_> telnet: Unable to connect to remote host: Connection refused [14:36] ahasenack: that's odd. samba is in our whitelist. Shall we wait for nacc to come online and check the importer? [14:36] remote host? [14:36] dude u said its local [14:36] which one is it? [14:36] <[J]oules_> hehehe: local [14:37] <[J]oules_> i ran the command from the ubuntu server i am on [14:37] rbasak: so you did confirm it's behind? [14:37] No. [14:37] Joules so to make it clear you got sip phone one the box and u want it to send its log to syslog on same box? [14:37] right? [14:37] *on the box [14:38] <[J]oules_> sip phone is not a box, its a physical telephone [14:38] Ist that just a generic can't connect message hehehe? [14:38] <[J]oules_> it is on same LAN as ubuntu server [14:38] oki [14:38] ahasenack: yeah confirmed [14:38] so land hardware sip phone using asterix? [14:39] <[J]oules_> plain and simple, this ubuntu server is not listening on port 514 [14:39] rbasak: thanks [14:39] <[J]oules_> pbx servers are all remote [14:39] Joules plain and simple unless some server uses 514 [14:39] rbasak: I'll bring it up in standup, it's just half an hour away [14:39] some server soft [14:39] Looks like it was published on the 5th. [14:39] 514 wont be listening [14:39] So perhaps the importer wasn't running then? [14:39] <[J]oules_> hehehe: yes agreed, RSYSLOG [14:39] braziercustoms: which one [14:40] Joules this hardware sip phone got a software config file [14:40] rbasak: and server team: NGINX 1.12.0-1ubuntu1 (merge from the 1.12.0-1 packaging that was in Debian then replaced with 1.13.x) merge completed, and uploaded. once that builds and lands, i'll push the latest patch for a security issue (Security team is aware, cc: sbeattie) [14:40] to where does this config file direct logs? [14:40] [J]oules_, i'd really start from scratch .. drop all ufw stuff (uninstall it), flush iptables ... and first of all try to get the standard working that works for everyone else [14:40] maybe it sends them to a separate log file instea of syslog [14:40] :) [14:41] and folks anyone here good with git? :D [14:41] hehehe: i know a bunch, so does rbasak, what's up? [14:41] [J]oules_, once you have that, re-enable the firewall bits and configure it (if you really feel you need to dis-trust devices in your LAN that is) [14:41] * teward also runs a GitLab instance for himself [14:42] [J]oules_, on any Ubuntu machine i worked with in the last 13 years just uncommenting the 4 lines and restarting rsyslog was enough, be assured this usually works :) [14:42] when I do git checkout -b origin and later want to build and make - local box will look for files on the githib repository where branch files are? [14:43] so say initially I git clone master branch and then I run checkout -b origin [14:43] to select a specific branch [14:43] <[J]oules_> ogra_: i cant agree with you more, uncomment those lines and presto [14:43] <[J]oules_> ogra_: but this box flatly says 'not in my lifetime' [14:44] <[J]oules_> brb have to help someone [14:44] well, there must have been some tinkering that broke it i guess [14:44] Joules post you /etc/rsyslog.d/50-default.conf :) [14:44] just to check [14:44] *your [14:44] hehehe, what would you expect to find there ? [14:44] I dont know some mistake :) [14:44] maybe typo [14:45] then rsyslog would complain in the logs on startup [14:45] oki [14:45] so using occam razor what can it be? [14:46] hehehe: I don't understand your question. What are you trying to achieve? [14:47] rbasak: oki - I want to compile modsecurity from a specific branch [14:48] as per howto here https://help.dreamhost.com/hc/en-us/articles/223608748-How-to-Install-libmodsecurity-Nginx-on-Ubuntu-14-04 [14:48] Those instructions look a bit broken to me. [14:48] yes [14:48] I wouldn't create a local branch called "origin/v3/master". That's confusing. [14:49] rbasak: so whats the best way then? [14:49] git will do it, but thereafter lies confusion. [14:49] git clone v3/master https://github.com/SpiderLabs/ModSecurity [14:49] then git submodule init, etc. [14:49] Sorry [14:49] git clone -b v3/master https://github.com/SpiderLabs/ModSecurity [14:49] then git submodule init, etc. [14:50] jamespage: looks like python-sphinx 1.6.3 upload to experimental is just blocked by sphinxcontrib-websupport in NEW [14:50] coreycb: ack [14:50] rbasak: yes thats the command I was missing :) [14:50] how to git clone a branch :) [14:50] thanks! [14:50] You're welcome :) [14:51] well at least last night I had time to read php intro since I was stuck on this front :) [14:52] Joules I think if we carefully look at all setup - there is a logical way to find mistake - its just I am new to linux but I can think logically sometimes :) [15:03] rbasak: usually if make encounter any mistakes it will log then to syslog or not? [15:03] I wonder how people double check that make run correctly [15:07] rbasak: i made the same importer change for your bugfix locally as soon as i woke up, will ack/merge it now [15:07] hehehe: if it's done well, it should stop with an error if there's a problem. [15:07] nacc: thanks! [15:08] cool [15:12] is there a simple way to pull all logs (as per user choice) from a box to remote server, as per event (so simply adding new entries to a logs incrementally in real time) [15:12] or it will consume a lot of client server resources? [15:13] rbasak: done (but you prob. got notified already) [15:13] hehehe: A periodic rsync is probably the easiest trade-off close to that. [15:13] nacc: thanks! [15:19] it is unfortunate that MAAS is free, but Landscape is not [15:30] gimmic: landscape is free for up to 10 physical hosts and 50 containers [15:33] Yeah.. Who wants to use an OS management platform for >10 systems? [15:34] "This car functions, but only drives 10 mph, please pay if you want to go faster than 10 mph" [15:34] that's a trial. [15:36] gimmic, well, something has to pay the salaries ;) [15:38] gimmic, i bet a lot of people would take such a car if you get it for $0 at the vendor and only have to pay if you go above 10mph ;) [15:38] seems antithetical to the open source community. [15:38] open source != free [15:39] geez ... [15:39] You could make the same argument about any of the projects. MAAS could be licensed the same way [15:40] sure [15:40] gimmic: what argument? [15:40] gimmic: If you don't like the way landscape is licenced and/or priced, then don't use it? [15:40] gimmic: i think you are the only making a principled arguemnt here :) [15:40] :) Just venting an opinion [15:41] antiethical....seriousely ? [15:41] not antiethical.. antithetical. [15:42] Although I guess it's really not any different than the rhel environment [15:42] I have no problem payinf for software that I use if it gets the job done [15:43] gimmic: it's not different than anyone trying to make money, if you want to use *only* free software, that's a different discussion than relevant here [15:43] Of course. All I said was that it was unfortunate [15:43] I dont see how it is unfortunate [15:44] unless you mean its unfortunate you cant leech [15:44] that's a bit of a strawman, unless you consider anything you don't exchange money for is leeching [15:44] back to the opensource ethos.. [15:45] opensource ethos......please [15:46] I use the best tool for the job. open/closed, it does not matter [15:46] gimmic: again, you're conflating open and free [15:46] gimmic: IMO [15:47] Yeah. [16:00] rbasak: ahasenack: `git ubuntu lint --for-merge` of the samba merge (so far): http://paste.ubuntu.com/25082678/ [16:00] messaging needs some massage [16:03] Hi everyone. i want to install ubuntu server on a HP ProLiant ML10 Gen9. I really need the RAID functionality. I read on forums that i should set controller to AHCI. IS there a workaround? thank you [16:07] use ahci and Linux raid [16:08] https://en.wikipedia.org/wiki/Mdadm [16:08] nacc: nice! [16:09] Ussat, Is there a guide for mdadm? [16:10] lots of them! [16:10] the linux raid one is what I remember starting with. [16:10] * dpb1 googles [16:12] here: https://raid.wiki.kernel.org/index.php/RAID_setup [16:14] dpb1, got it. thank you. But now i got the error: variable 'prefix' isnt set :( when installing ubuntu from a usb [16:25] rbasak: do we want emit 'pass' or something for checks that pass? [16:27] aatish: would need more details. I'm not familiar with that particular failure mode [16:27] nacc: I feel that would be more noisy [16:27] s/more/too/ [16:27] rbasak: ack, just checking :) [16:27] nacc: except maybe with a -v or something? [16:27] rbasak: we can leave it for not [16:28] *now [16:28] Agreed [16:28] rbasak: about to add the versioning check [16:28] rbasak: reading your code, what function should i call to check the version? i guess for a merge, i should pass the debian version? [16:28] rbasak: next_development_version(debian_version) ? [16:29] Yes, I think so. [16:29] rbasak: ack, doing it now [16:31] <[J]oules_> created a new ubuntu 16.04 lts server. uncommented the 4 lines in rsyslog.conf, restarted rsyslog, phone IS logging to the new ubuntu server [16:31] <[J]oules_> something on this ubuntu server is not working right and is blocking incoming syslog [16:37] rbasak: did you ever figure out what you meant by unapproved in http://paste.ubuntu.com/25039931/ ? [16:41] nacc: I think I must have meant the version in the unapproved queue, but then changed tack and now intend it to mean the version currently highest in the given series. [16:41] nacc: maybe s/unapproved/current/ unless you can think of something better than "current"? [16:42] rbasak: but w/in the context of the importer, that function can obtain the value of uannproved given a repository and a series name (aiui)? [16:42] rbasak: or do you want to query lp for it? [16:42] before = [max(series.pocket_versions) for before_series in serieses if before_series < series] [16:42] rbasak: and/or what does after mean? [16:42] sorry: before = [max(before_series.pocket_versions) for before_series in serieses if before_series < series] [16:43] sorry: before = [max(after_series.pocket_versions) for after_series in serieses if after_series > series] [16:43] Argh [16:43] Take 3: [16:43] heh [16:43] before = [max(before_series.pocket_versions) for before_series in serieses if before_series < series] [16:43] after = [max(after_series.pocket_versions) for after_series in serieses if after_series > series] [16:44] so we're trying to use that to sandwich our versioning, in case the prior series has bumped, etc/ [16:44] nacc: does that make sense? [16:44] Right [16:44] e.g., to detect if we need to do 16.04.1 rather than .1 [16:44] rbasak: ok, that makes sense [16:44] And current (formerly unapproved) = max(series.pocket_versions) [16:45] right, i guess in my mind, this (next_sru_version) is a lower level API and the actual api is (next_sru_version(series)() [16:45] Yes. That's reasonable. [16:45] as the above values for a repo are all derivable given the series :) [16:45] Your actual API would look up in Launchpad. [16:45] yep [16:45] And my lower level API is the pure testable version comparison bit. [16:45] understood [16:47] nacc: a reminder: I believe next_sru_version is incomplete. But we can use it and add test/fix when we hit those cases for now I guess. [16:47] rbasak: ack [16:47] Yeah it doesn't actually examine before or after at all. [16:49] right, but the spec means it can (and should eventually) :)( [16:49] s/(// [16:50] rbasak: fyi, i have a commit in this series which turns GitUbuntuRepository into a wrapper for pygit2.Repository. It's really handy (and let's us drop a bunch of accessor properties). But now if we need some pygit2.Repository function/attribute, it's just there immediately [16:52] I do think that the wrappers are not worth it any more. [16:52] But why not just expose the underlying pygit2.Repository object as a well known property to GitUbuntuRepository? [16:53] rbasak: that's basically the same thing in this case [16:53] So just switch from _local_repo to raw_repo or something. [16:53] rbasak: we do that already [16:53] but no caller actualy needs that object [16:53] they need some method or attr of that object [16:53] Yes but it's explicit then. [16:53] A caller will do repo.raw_repo.foo() [16:54] rbasak: tbh, i think what i have is a lot cleaner than expecting callers to know if something is a method of repo or of repo.raw_repo [16:54] I'm not keen on inheritance or __getattr__ magic if that's the way you're thinking. [16:54] rbasak: ok, is there a specific reason? [16:54] I disagree. It means that someone less familiar with the code and APIs won't know where to look to find a particular implementation of something. [16:55] The name raw_repo could be better. [16:55] Also it means that if we need to change something, it's easier to find what callers are doing by just searching for raw_repo. [16:55] i give you the latter point [16:56] i suppose it's not a big deal either way -- i found the wrapper object pattern handy to not have to type so much and to not have to add any new methods. It's implicit, though, as you suggest, and I can make it explicit instead [16:58] rbasak: i'll retool the change, thanks for the feedback [17:01] hey dpb1 - would you be able to seed numactl for the 16.04.3 server iso now that the MIR is approved? [17:02] dannf: we discussed it this AM in our standup [17:02] rbasak: --^ [17:02] dannf: would be good to subscribe the server team to that bug to get our attention [17:02] nacc: ok [17:03] dannf: thsx [17:09] dpb1: so the question for you here is: are you willing for your team to take on the maintenance for this? [17:10] (from a general process perspective) [17:10] and shouldn't that have been resolved in the MIR rather than in the seeding discussion? [17:10] Really that should happen before the MIR approval... [17:10] Yeah [17:10] i guess the theory was src:numactl is main'd, so we are on the hook for it already [17:10] but i don't think server is subscribed to src:numactl [17:10] not sure if anyone is? [17:10] It missed it in this case because our process (the team bug subscription being the gate) doesn't account for binary only movements. [17:11] oh we are, nm [17:11] Another example of this is php fpm, which has a bigger maintenance issue. [17:12] Perhaps the MIR process should have a requirement for a documented team commitment in addition to the subscription. [17:15] cyphermox: FYI ^ [17:19] well, in a way we do, that's why I'm asking if you guys are aware of that request for numactl (which is already in main) [17:20] numactl was MIRed some time ago already, the other MIR was to make sure the binary numactl package was also promoted, and then seeding (which triggers me checking that it's really what you want) [17:21] nacc: ok for me to push the tags on that samba merge branch? Or should I leave it as is? [17:21] ahasenack: you can push it [17:22] nacc: old/debian new/debian old/ubuntu reconstruct/ \ [17:22] deconstruct/ logical/ ? [17:22] these, right? [17:22] rbasak: in my view, MIR doesn't need to gate on something being seeded, as if it's not, things will just get migrated back to universe anyway next time someone goes to look at component-mismatches [17:22] ahasenack: yeah [17:22] cyphermox: it's not gating on something being seeded I'm requesting. But I do think that MIRs should be gated on a team committing to support it. [17:23] Usually the team subscription check suffices for that. [17:23] But not for a binary only movement, as in this case. [17:23] rbasak: it is [17:23] if you already subscribed to the source, why would you not maintain also one of the binaries that come from it? [17:23] cyphermox: take php fpm as an example. [17:23] you'll need to look at the bugs anyway [17:23] cyphermox: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1267255 [17:23] Launchpad bug 1267255 in php7.0 (Ubuntu) "[MIR] php7.0 (php7.0-fpm binary)" [Wishlist,Confirmed] [17:24] cyphermox: in that case, we're not prepared to have a mess dropped on us. [17:24] nacc: pushed [17:25] Once the issues are fixed (by us or others), then we can consider what burden ongoing maintenance of that binary might have on our team. [17:25] rbasak: we review the things every time there is a MIR anyway [17:25] so if it looks like a mess, it seems rather obvious that one should double-check [17:25] cyphermox: sure. What I'm asking is an explicit gate on the team who is being given the work. [17:25] I mean, I don't disagree that I would check with you guys again if some random person asks for a new binary in a huge package that looks like a mess [17:26] in the case of numactl however, it's a tiny thing [17:26] I agree it probably doesn't matter for numactl. [17:26] (in the grand scheme of already maintaining libnuma, which is where the magic really happens) [17:26] But from a process perspective, I'm pretty sure that's a hole. [17:26] what do you mean? [17:26] Through which something big will slip sooner or later, as it's not a documented part of any process. [17:27] anything that looks messy in a package in a big red flag anytime you review a MIR [17:27] That decision should be down to the team being landed the work, not the MIR team. [17:28] yes [17:28] if the team isn't asking for the MIR themselves, we check [17:28] It shouldn't rely on the MIR team deciding if something has a red flag or not. [17:28] The decision should go to the subscribing team in all cases. [17:28] in all cases, the MIR team is supposed to do a check that something is generally maintainable without too much pain [17:29] That's not what I'm asking for. [17:29] In all cases, I'd like the MIR team to check that the subscribing team is OK with the MIR. [17:29] presumably, if you're writing the MIR for your team, you're already OK with it? [17:29] In this case, the MIR wasn't written by us. [17:29] cyphermox: in this case, we didn't write the MIRs [17:29] in either of these two cases, actually [17:30] which one are we looking at? [17:30]