[00:01] <zequence> lousygarua: Have you used that device on Linux before?
[00:03] <lousygarua> zequence, no, I only recently got it it back at my apartment and back then it wasn't fully supported. I saw that it's now supported so I said let's give it a try, and what do you know, it works!
[00:03] <lousygarua> I wonder if my MIDI keyboard will work as well
[00:03] <zequence> most midi keyboards do
[00:04] <zequence> as long as they use generic drivers
[00:04] <zequence> Well, many, anyway
[00:04] <lousygarua> zequence, good to know, i will check tomorrow, it's 3 am here
[00:04] <zequence> I'm assuming it's a usb midi keyboard
[00:18] <lousygarua> zequence, yeah it's a regular USB keyboard
[15:42] <Guest95268> jack freezing can anybody help thanks
[16:01] <marious> bbbb
[17:54] <devtekbeta> im looking to create a live usb of ubuntuStudio to test my hardware, the live image i want to download is the same image you use to install the os on a system right?
[17:55] <holstein> devtekbeta: the live installer
[17:55] <holstein> we dont have an official alternate anymore AFAIK
[17:55] <devtekbeta> so after i test it and if it works via usb with my hardware, i can restart and use that same usb stick/image ot install it on my disk?
[17:56] <holstein> devtekbeta: no restart needed.. there will be "install" options from that live environment.. but, yes, bascially
[17:56] <devtekbeta> i see. thanks
[19:33] <antonio__> Hallo! This is my first time in this chat and in ubuntu, and i dont know at all what Im doing.
[19:34] <antonio__> Bien. Y luego?
[19:34] <Arkhanos> Ok Antonio, what do you want to know?
[19:40] <Arkhana> Keenan, how did you invite me?
[19:41] <keenan> mean u in twitter, or?
[19:41] <Arkhana> No in IRC
[19:42] <keenan> i dont know!
[19:42] <Arkhana> Ok, I gonna check it out on google
[19:44] <devtekbeta> ok
[19:44] <devtekbeta> i booted the live usb. and it worked, but it took a while to load the os from usb
[19:44] <devtekbeta> is it usually faster to load/boot once installed on the internal drive
[19:44] <zequence> usb is a bit slower than a hard disk
[19:45] <Arkhana> Cd slower than USB
[19:45] <Arkhana> DVD slower than CD
[19:45] <Arkhana> Floppy slower than CD
[19:45] <zequence> I would say CD is slower than DVD
[19:45] <zequence> Anyway, it has to do with read speed of the medium.
[19:46] <devtekbeta> it should work well then
[19:46] <devtekbeta> even the internet works right away
[20:10] <devtekbeta> just shame the laptop is pink
[20:10] <devtekbeta> lol
[20:15] <Temukano> help needed here
[20:15] <Temukano> some 1?
[20:16] <SunStar> yeah
[20:17] <Temukano> ok..
[20:17] <Temukano> I have just installed this thing in my laptop
[20:18] <Temukano> but there is no wifi device detected
[20:18] <Temukano> I have this HP pavilion crap.. cannot find drivers for wifi
[20:19] <SunStar> check launcher menu -> settings - software updater -> additional drivers to see if it sees missing drivers it needs (will need ethernet connection)
[20:20] <Temukano> but the shit is.. there is no such problem like this in any other laptop i have
[20:20] <SunStar> if that doesnt work install ndis wrapper and wicd from software center. ndis wrapper can use the windows driver
[20:20] <Temukano> haaa ok
[20:20] <Temukano> mmm wisedom...
[20:21] <Temukano> i am going to write it down
[20:22] <Temukano> tnks!
[20:25] <Temukano> now... another dubt
[20:26] <Temukano> there is a fine app to fix the hd partitions?
[20:26] <Unit193> What's wrong with 'em?
[20:26] <SunStar> testdisk and photorec
[20:27] <Unit193> (Testdisk is pretty awesome, but if you're going for a resize, wrong tool.)
[20:27] <SunStar> gparted
[20:27] <Unit193> Was an example, but you may need a live cd for that.
[20:30] <Temukano> tnks
[20:31] <Temukano> i just want to re organize the partitions
[20:31] <Temukano> there is more than nesesesary - escuse my english, but it is not my native language---
[20:32] <SunStar> gparted
[20:32] <Temukano> ok
[23:56] <wheeler_> oh hehe... da bin ich... geschafft moin moin... ist jeman da?!
[23:56] <Unit193> !de


[12:50] <quappa> hello. is there a way to know if I upstart is ok after upgrade to Edgy? I don't see any change in startup time. People on forums say it's dramatic.
[12:50] <quappa> s/if I/if/
[12:51] <_ion> In edgy, upstart just launches the same old sysvrc scripts. It doesn't affect startup time until the whole bootup process is migrated to upstart jobs (that's going to happen in feisty). Edgy has other changes that may decrease startup time, though.
[12:52] <quappa> oh. thanks.
[12:53] <quappa> probably those other changes didn't affect my setup.
[11:28] <Keybuk> Md: you'll probably like the plan to take over the world that the Ubuntu Kernel Team and I are cooking up :p
[11:39] <Md> Keybuk: --verbose
[11:40] <Keybuk> Md: moving the decision about which devices get bound to which drivers to userspace
[11:41] <Keybuk> so udev is responsible for it
[11:42] <Md> how?
[11:44] <Keybuk> first, with .20 and a couple of patches, ensure that drivers are first class sysfs objects with uevents, etc.
[11:44] <Keybuk> then modify the module information so that a module announces which drivers it contains, and maps modaliases to driver names instead of module names
[11:44] <Keybuk> alias pci:blahblah pci:drivername
[11:44] <Keybuk> alias pci:drivername modulename
[11:45] <Md> but is this needed for every driver?
[11:45] <Keybuk> finally merge modprobe into udev (using kay's patch) so we can lookup this in udev
[11:45] <Keybuk> I think that the first two are very useful for every driver
[11:45] <Keybuk> the third bit is also useful, because you can use udev to force a bind or unbind
[11:46] <Keybuk> as to which drivers we make the decision for, I don't think it makes much difference; we could leave the easy decisions up to the kernel, and just do the hard ones in userspace
[11:46] <Keybuk> but I don't think there's any drawback to doing it all in userspace
[11:46] <Md> performance?
[11:46] <Keybuk> I don't think that the bind between a device and driver is ms critical?
[11:47] <Md> no, but when you load 30 drivers at boot time maybe it starts to be noticeable
[11:47] <Keybuk> udev is going to get called out anyway for those 30 devices


 "youngbin: re UbuCon Asia on..." <- Hi, thanks for the new category setup! Would be nice if i can have full access under ubucon category. I plan to use indico for at least call for proposals and schedule management.
[05:41] <Fallen> youngbin: you have event creation permissions there which will allow you to create an event which you have full access to.
[05:43] <Fallen> I'm also going to check with legal if there are any requirements we might need to take into account when people are submitting information there, eg accepting the privacy policy, and acknowledging that community contributors will have access to the data.
[05:48] <youngbin_> Sounds good :) But Indico says I have no permission to create one. Could you check this later?
[05:48]  * youngbin_ uploaded an image: (57KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/IVYoexqlzOobyrCrhudGuexT/image.png >
[05:52] <Fallen> Yes will do, need some breakfast first! :)
[05:52] <youngbin_> Thanks :)
[09:55] <Fallen> youngbin: ah of course, again I forgot to hit save due to how the UI works :)
[09:55] <Fallen> Should be good now
[11:12] <youngbin_> Thank you! just created one on indico :) https://events.canonical.com/e/UbuconAsia2023


 so it plasma 5.12.8 landed in bionic backports..... (I was looling all over for it)..... no issues with backport upgrade... :)
 s/so it/so it appears/
 5.17 fixes a pet peave of mine when KDE 5.0 was introduced (as per this article: https://notmart.org/blog/2019/07/a-week-in-valencia/ and this bug https://bugs.kde.org/show_bug.cgi?id=360478) \o/
 @DarinMiller, Thank, but is is the packages in the archive proposed pocket I really need to have verified
 https://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1819075
[08:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #3065: SUCCESS in 58 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/3065/
[08:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #3065: SUCCESS in 1 min 56 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/3065/
[08:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #3065: SUCCESS in 4 min 31 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/3065/
[14:45] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #3066: SUCCESS in 52 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/3066/
[14:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #3066: SUCCESS in 1 min 28 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/3066/
[14:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #3066: SUCCESS in 4 min 18 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/3066/
 Is ppa:kubuntu-ppa/ppa  the correct ppa to test?  When I added that ppa, no updates were found....
 @DarinMiller The updates to test are in the proposed pocket of the main archive
 example: https://launchpad.net/ubuntu/+source/plasma-desktop/4:5.12.8-0ubuntu0.1
 enable via the software-sources menu?
 yep
 @DarinMiller, Probably as you have the backports ppa enabled? The versions in there are deliberately higher that the updates PPA or archive
 What really needs tesing here is a stock 18.04.2 install, updated without any PPAs, the the plasma in -proposed adding
 Having the backports PPA on an install screws that up. This is a test of packages to go on 18.04.3 iso
 When enabled, 29 packages available for update but I was expecting more "plasma" specific packages: https://paste.ubuntu.com/p/PCC5N5WFdn/
 @DarinMiller, Do you have the backports PPA on that install?
 You must have
 As i said above, the 5.12.8 version in the backports PPA are delibertely versioned higher than anything else. Having that enabled borks this test.
 back later
 OK, so ppa purging and trying again....
 ppa purge croaked... re-installing....
 thanks for testing, I'm considering to do an upgrade round of all my VMs and test the proposed packages
 Are you running 18.04 in your vm's?
 I have everything supported with and without backports
 (Photo, 1280x719) https://irc-attachments.kde.org/zm0WPn9k/file_16391.jpg
 upgrading now, whenever I have some time I will try to test
 wow, that's an impressive VM list!
 haha
 btw I'm benchmarking area51 right now. I replaced the processor yesterday. I had to fix some bent pins 😱
 How much disk space is reserved for each VM?
 20G
 I have all of that in the laptop, which has a 250G SSD and a 1TB classic magnetic hard disk for this kind of stuff
 I replaced some time ago the CD/DVD drive with a caddy, so I have now these 2 devices
 What was the old processor and what is the new one?
 the old processor from area51 was a phenom II x4, the "new" one is a second hand amd fx 4100
 I changed it to have one with proper security support
 Rik, the 180.4 staging upgrade to 12.8 worked flawlessly here.  No issues running basic tests...
 According to this website, the 4100 is a slower CPU.... https://cpu.userbenchmark.com/Compare/AMD-Phenom-II-X4-965-vs-AMD-FX-4100/606vs2878
 I guess, but I got it just to get microcode updates
 I could get a six core or eight core fx which would be faster than this fx 4100, but that might alter the memory peaks when building in parallel so I got this one to be conservative wrt that
 also it was just 20€
 cheap as hell XD
 oh wow, that is cheap!
 @DarinMiller, Once again, it is the paackages in the main archive that need testing, not PPAs
 that phenom was 100€ back in the days
 @RikMills, how are we suposed to test this, just adding -proposed to sources or what?
 RIk, no PPAs added after re-install. I only used the proposed option.
 @Santa, Yes, and then selectively upgrading the new plasma packages.
 how you do the selection?
 (I suspect I have a better way to do the "selection"...)
 everything is working... but I can retest with fresh install if needed.
 @Santa, I just install synaptic, search for all packages with version 5.12, and then in the result list right click to upgrade ones where there is a new 5.12.8 version to upgrade to
 allright, I have a better way in mind, I will try to come up with a better idea later
 @Santa, Yeah, I am sure some scripting can do a better job
 Yeah, I was thinking in composing with some scriptery an apt pinning file using what we have in ka-metadata
 If I'm speaking chinese just wait to see the thing XD
 Nah. I Know what you mean. I'm just lazy. If it had been a 200+ source apps release I might have tried to script it!
 ok
 another option would be creating a reprepro repository with a literal copy of the involved packages
 While we know that would be ok, release team would I think be not impressed.
 so better the apt pinning I guess
 I can vouch that the enitre proposed stack is working fine here...
 @Santa, I think so
 ok, so from there, I could write a script to generate the file automatically and attach it to the SRU bug report
 That would be cool
 @DarinMiller http://tritemio-area51.ddns.net/benchmark/test-compilacion/composite.xml
 the results of that benchmark
 not a catastrophic difference given with microcode security patched is suposed to perform worse
 Agreed, fairly close.  Is compilacion-malvo also yours?
 yes
 malvo is the laptop, compilacion-groomlake-xxx are tests in the other server, tested 3 different bios settings


[03:43] <sarthor> HI, I have ubuntu installed on PC, and have two NIC, one NIC is configured automatically when I was installing OS, and name as "ens18", I have other LAN card also plugged in the same box, How to find the name of that lan card, because the name are not like eth0/ eth1 and eth2 .... HELP
[03:44] <sarnold> try 'ip link'
[03:53] <sarthor> ifconfig -a shown that.. thanks
[04:59] <cpaelzer> good morning
[06:02] <lordievader> Good morning
[07:20] <tobasco> jamespage: coreycb https://www.cvedetails.com/cve/CVE-2017-2592 is not in main python-oslo.middleware for xenial (mitaka)
[07:20] <tobasco> https://review.openstack.org/#/c/425734/
[07:20] <tobasco> python-oslo.middleware is already the newest version (3.8.0-2).
[07:21] <tobasco> 500 http://se.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
[07:35] <tobasco> can see it triaged but the fix is not released
[10:27] <joelio> yep
[10:36] <rbasak> nacc: I think it's distro-info-*data* that needs updating, which is a separate source package.
[10:37] <rbasak> The distro-info snap part has a stage-packages of ridsro-info, which is confusing
[10:38] <rbasak> I suspect that if we need distro-info from source, we don't need it staged explicitly, but we do need distro-info-data staged as that comes from the archive perhaps?
[10:38] <rbasak> So a rebuild might work.
[10:41] <rbasak> nacc: do you remember why distro-info is built from the tarball?
[13:22] <ahasenack> rbasak: hey, I got a distro-info-data update today in bionic, and it has a cosmic line in the ubuntu csv
[13:31] <frickler> thedac: coreycb: updated https://bugs.launchpad.net/neutron/+bug/1750121 . I'll be mostly off for a long weekend now, will check back next week
[13:32] <coreycb> tobasco: ok that is on our security team's radar, though I think I'll just give them a hand and do the SRU myself
[13:33] <coreycb> frickler: thanks! i'll check in with david when he gets in.
[13:33] <coreycb> frickler: he is thedac btw
[13:34] <frickler> coreycb: yes, I found that out and highlighted him, too ;)
[13:35] <coreycb> frickler: ah missed that, cool :)
[14:04] <Neo4> Hi, I've done first shell scrip, it installs apache2, mysql, php, phpmyadmin and node.js nvm
[14:04] <Neo4> https://gist.github.com/kselax/0b07445fba101e6b74732f64814070c0
[14:20] <joelio> Neo4: I'd imagine most people in here use a configuration management too like ansible or puppet
[14:20] <joelio> s/too/tool
[14:20] <joelio> but fair play if it's yout first :)
[14:20] <Neo4> joelio: that is not modern, better to use your own
[14:20] <Neo4> joelio: your own script give you more flaxibility, you can put editing files there, as I did in mine
[14:21] <joelio> no, it doesn't but anyway
[14:21] <joelio> ansible and puppet allow you to create hierarchies of looups of configuration data
[14:21] <Neo4> joelio: before editing file I output a tip and run vim with file, then user are able to press CTR+z an go to shell and read tip and then return back to file type fg
[14:22] <Neo4> joelio: ok, I saved this names, ansible and puppet, and will look on youtube what they are
[14:22] <joelio> ok, if it works for you fair enoiugh, just don't expect to get much traction in this channel... like I said, people use more specific tools
[14:22] <joelio> they were bourne out of ssh in a loop with shell scripts ;)
[14:23] <joelio> Neo4: I'd look at ansible first, it's probably easier to get into
[14:24] <Neo4> joelio: I'm going to write a few my scripts that will create automaticaly virtual host, for example put this file ~/bin/newvh newvh - means new virtual host, and user do this newvh site.com
[14:24] <Neo4> and he got /var/www/site.com and apache should be configured automatically and reload
[14:25] <Neo4> joelio: and one script that will install wp
[14:25] <Neo4> ~/bin/cpwp (copy wordpress) , cpwp site.com
[14:25] <Neo4> and script should go to github and download from there wp to /var/www/site.com
[14:25] <Neo4> joelio: is it cool? :)
[14:26] <joelio> I'd just use nginx and ansible modules, but whatever you wish :)
[14:26] <Neo4> joelio: it looks so cool, I used to do this all manually
[14:26] <joelio> if you can work it and it looks good, then fair enough, that's the most important part - if you as an admin are comfortable with the tools
[14:27] <Neo4> joelio: it will streamline your work
[14:27] <Neo4> joelio: you will do more work for short time
[14:27] <joelio> what will?
[14:27] <Neo4> joelio: shell, how much time it will take to create virtual host? and put there wordpress tite?
[14:28] <joelio> hah, well considering I never deploy wordpress (yuk) then no, it really woruild
[14:28] <joelio> *wouldn't P:)
[14:28] <Neo4> it takes much time if do it manually, sometimes you forgot commands, somtimes other errors
[14:28] <Neo4> with shell it's one minute, type two row
[14:28] <joelio> dude, I getcha, look at what configuration management tools do then come and speak to me again :)
[14:28] <Neo4> joelio: it can be other CMS, doesn't matter,
[14:29] <joelio> I don't depoloy CMS's mate, I write automation for cloud services
[14:29] <Neo4> joelio: I don't thing they better than own tools?
[14:30] <joelio> trust me, they are better than shell, for my usecases
[14:30] <joelio> if you read up on them, then you will see why :)
[14:30] <Neo4> joelio: in programming people to use frameworks only when they work in team for other people will able to understand what is going on, it might in linux people use general tools as well for other people understand it
[14:31] <Neo4> joelio: no, I doubt
[14:31] <Neo4> joelio: they should be worse, because they are made for common use
[14:31] <joelio> dude, I do this everyday for a living, sure
[14:32] <joelio> shell scripts have their place, but not for large scale system automation working with heteregenous environments
[14:32] <Neo4> joelio: ok, I look there, but I really very impressed, how easy deploy apps using shell :)
[14:32] <joelio> hell, then you ain't seen nothing yet :D
[14:32] <Neo4> joelio: can't calm down...
[14:33] <Neo4> joelio: yes, I'm a newbie
[14:34] <joelio> heh, it's cool dude!
[14:34] <joelio> being keen on tech is something to be encouraged :D
[14:34] <joelio> also, http://timstaley.co.uk/posts/why-ansible/
[14:36] <Neo4> joelio: I think  a mail server with shell also will be easy deploy and fast
[14:37] <Neo4> joelio: if you want to send spam, you can buy servers and fast deploy a few mailservers
[14:37] <Neo4> or VPN or others apps
[14:37] <Neo4> it's very big possibilities
[14:39] <Neo4> joelio: do you know about backup? I am thinking now. about theory
[14:40] <Neo4> joelio: I read in book there we can write shell script that will remotely using ssh connect to our server and get from there data and store in our local computer, This is possible to do using scp command or srsynk
[14:41] <Neo4> is this called backup?
[14:42] <Neo4> I think write script that will connect to server, and take make database damp, make archaive from /var/www/site with this damp and put to my local computer, and this task should run in cron
[14:50] <joelio> Neo4: sure, sounds fine. There are other tools available for backups btw.  Depending on your site and how busy it is, you may need to lock the tables before dumping the database too, so consistency is fine. I think mysqldump does that if you're using that
[14:51] <joelio> can create a tar of the site and db backup etc and use ssh to pull that (look up ssh keys too, you'll need those)
[14:51] <Neo4> joelio: yes, using, I have never done backup, I see on my shared hosting it had been set up, but I didn't know how it was working
[14:51] <joelio> there are off the shelf solutions too like duplicity/backupmypc etc
[14:52] <joelio> if your host does it, leverage that
[14:52] <joelio> just be aware on checking the update timestamp of the backups etc.. to make sure you've got a valid, recent backuo
[14:52] <Neo4> joelio: I read about remote backup in 'Linux bible', this was the main solution, make remote connection
[14:52] <joelio> and *the* most important part of backups - TEST YOUR RESTORES! :D
[14:53] <joelio> yea, that's fine, via ssh
[14:53] <Neo4> joelio: no, now host nothing do, if you have VPS you have to do all yourself
[14:53] <joelio> use an ssh key and then it's non-interactive
[14:53] <joelio> there are loads of tutorials etc
[14:53] <Neo4> joelio: yes, need to break down this theme on days
[15:08] <nacc> rbasak: pong
[15:09] <nacc> rbasak: you're right, we just need an updated d-i-d
[15:09] <nacc> rbasak: which you'd get on a rebuild (which appears needed for USNs anyways)
[15:13] <rbasak> nacc: thanks. Can distro-info just be used from the package now, rather than built from tarball?
[15:20] <nacc> rbasak: I *think* so -- there were times where it wasn't up to date in enough time, possibly? I'm not 100%, but I think that should be safe. You'll need to add it as a stage-package in git-ubuntu, I think
[15:21] <nacc> tbh, i would do it as two separate commits, cleanbuild each and diff the squashfs images
[15:25] <nacc> rbasak: sorry I didn't comment that better
[15:25] <nacc> rbasak: oh, we might have needed a newer python3-distro-info
[15:25] <nacc> rbasak: that's what it was
[16:02] <station> was I clumsy, hdd rack slipped directly into motherboard, the leg of an capacitor was injured and had   to replace the hall cap. but since its an eBay motherboard and I'm dealing with first timer Server Motherboard and apparently Im still very slippery. I'm still not out of the clouds. the MB supermicro A1SRi-2758F is cycling trough al kinds of code errors at System Initialising … 71 is the most stubborn one and seems to be
[16:02] <station> ved by http://www.supermicro.com/support/faqs/data_lib/FAQ_18625.pdf
[16:02] <station> with USB in … for AMI.BIOS flash it stops at F2 code with seems to be Recovery process started
[16:02] <station> mentioned in this PDF if I'm right F3 means it found it AMI.BIOS file https://www.supermicro.com/manuals/other/AMI_BIOS_POST_Codes_for_Grantley_Motherboards.pdf
[16:02] <station> so on OSX I flashed as Microsoft FAT 16 , the keyboard is on at F2 so its functioning for CTRL+HOME
[16:31] <teward> mail servers are FUN!  >.>
[16:32] <teward> unrelated, server team: you've got a glowing report to the CC from me detailing how you all helping me was instrumental in helping to get NGINX ready to go for BIonic.  (I was talking to the CC on something else, and gave a "By the way" admiration of how helpful you all have been)
[16:36] <nacc> dpb1: fyi, i'll work on getting as much of php* sync'd over the next few weeks
[16:36] <nacc> I need to send a bunch of stuff to Debian first, I think
[16:46] <dpb1> cpaelzer: ^
[16:46] <dpb1> nacc: awesome!
[16:46] <dpb1> :)
[17:05] <sdeziel> nacc: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1770222 (HTH)
[17:07] <nacc> sdeziel: I can probably help the team do it, but I'm no longer at Canonical (fyi)
[17:08] <sdeziel> nacc: oh, I wasn't aware
[17:25] <cpaelzer> big +1 nacc, thanks
[17:26] <nacc> sdeziel: np
[17:26] <nacc> cpaelzer: i can send MPs for PHP MREs, or just do them myself, which would you prefer?
[17:31] <cpaelzer> nacc: I'd say decide case by case - if it is trivial/no-discussion - then I'd not want us to block you
[17:32] <cpaelzer> nacc: if there is a reasonable change that needs to be considered make an MP
[17:32] <nacc>  cpaelzer: yeah, typically the MREs are pretty straight forward; I may need to coordinate with mdeslaur though if there are CVEs
[17:32] <nacc> cpaelzer: +1, thanks
[18:24] <eshas>  I want to use the ubuntu cloud image for 18.04 on KVM ppc64le. I have done following:wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-ppc64el.img
 qemu-img convert -O raw bionic-server-cloudimg-ppc64el.img bionic-server-cloudimg-ppc64el.raw
 how do I now create passwd, ssh to imag and use it then to boot?
[18:31] <sarnold> eshas: probably best is to use cloud-init to perform the first-boot initialization tasks
[18:32] <eshas> so cloud init should alread be there in the .img
[18:32] <eshas> should I just boot it?
[18:32] <eshas> what about user/login?
[18:33] <nacc> eshas: cloud-init is a program that runs at init-time, it's what initialized (customizes) a cloud image, if you want it to
[18:33] <eshas> yes,
[18:33] <eshas> but cloud-init v18.2 should be there in image itself
[18:34] <eshas> or do I need to apt-get install it?
[18:34] <sarnold> http://cloudinit.readthedocs.io/en/latest/topics/modules.html#users-and-groups
[18:34] <nacc> eshas: it will be there in the cloud images
[18:34] <eshas> I was under impression after converting to raw I have to mount the image, chroot, passwd etc
[18:35] <eshas> and then boot it so i can use the username/passwd
[18:35] <eshas> but I am not sure how to mount and make changes to it
[18:35] <eshas> let me just first try to use the .img as is
[18:36] <sarnold> once upon a time that was probably the way things worked -- but the idea with cloud images these days is to have a single image that all the hosts can boot and a simple declaritive way to add users, ssh keys, install packages, etc., so when you start a cloud image, it comes up with the day's security updates already applied, your users and ssh keys as needed, etc, and is ready to use without manual
[18:36] <sarnold> mucking
[18:38] <eshas> how do I add my users?
[18:38] <nacc> eshas: with cloud-init.
[18:38] <nacc> eshas: as we've said a few times now :)
[18:39] <eshas> hmm..cloud-init will run when I boot and do initialization to pick network info etc
[18:39] <eshas> I dont know how to specify user/passwrd there
[18:39] <eshas> you mean config drive data?
[18:39] <sarnold> the trouble with cloud-init is how to supply the data to the thing at boot time. that's severely underdocumented.
[18:40] <eshas> yes, thats what I am stuck at.. how to ssh or have a valid username/passwd on first boot
[18:40] <nacc> there is also #cloud-init
[18:40] <nacc> and lots of docs
[18:40] <eshas> do I mount .raw / and chroot
[18:40] <eshas> hmm
[18:40] <eshas> this is more of cloud image usage
[18:41] <sarnold> just set aside an hour to read all the docs and *then* try to solve problems ;)
[18:41] <eshas> is there a channel for cloud image?
[18:41] <nacc> eshas: no, i think it's just a matter of learning cloud-init
[18:42] <nacc> eshas: i don't think it has much to do with 'cloud image usage', tbh
[18:42] <eshas> ok, I do know about cloud-init and use it but mainly for network config etc
[18:43] <nacc> eshas: you can do just about everything in cloud-init
[18:43] <eshas> there is no default user/password for ubuntu cloud-image
[18:43] <eshas> ?
[18:46] <nacc> eshas: i would doubt it
[19:04] <ahasenack> I don't understand lp's diff in https://code.launchpad.net/~ahasenack/ubuntu/+source/apache2/+git/apache2/+merge/345312
[19:04] <ahasenack> it's too big, it has changes outside of debian/
[19:05] <ahasenack> https://pastebin.ubuntu.com/p/jfvkf4vydR/ locally it's sane and as expected
[19:05] <nacc> ahasenack: looking
[19:06] <sarnold> guessing, it's showing everything different since 2.4.29-1ubuntu4.1
[19:06] <ahasenack> my guess too, which would imply debian/sid is out-of-date in lp
[19:07] <nacc> ahasenack: the branch is at 2.4.33-3
[19:07] <ahasenack> debian/sid?
[19:08] <nacc> yeah
[19:08] <nacc> (per the web UI)
[19:08] <ahasenack> that's correct then
[19:08] <nacc> ahasenack: yeah, give me a sec
[19:09] <ahasenack> oh, wait
[19:09] <ahasenack> there was a warning about empty directories
[19:09] <ahasenack> WARNING: empty directories exist but are not tracked by git:
[19:09] <ahasenack> docs/manual/style/lang
[19:09] <ahasenack> docs/manual/style/xsl/util
[19:09] <ahasenack> could that be related?
[19:09] <nacc> yeah
[19:09] <nacc> all the changes are related to fully added files
[19:10] <ahasenack> from docs/
[19:10] <nacc> and modules/ maybe?
[19:10] <ahasenack> the warning only mentioned the two dirs above
[19:10] <nacc> hrm
[19:10] <nacc> yeah docs/ for sure is all adds
[19:10] <ahasenack> let me do a clean clone elsewhere
[19:11] <nacc> did it go from empty to not?
[19:11] <ahasenack> let me check 2.4.33
[19:12] <nacc> ahasenack: and, afaik, the importer is keeping up right now (I don't have visiblity to the reports, but I periodically check and the git page is moving)
[19:17] <zave> hi all, is this the place to ask a question about systemd unit files? i'm getting an error when trying to start a service. the error is code=exited, status=200/CHDIR ... that's a permission issue?
[19:17] <ahasenack> nacc: those directories are still empty in 2.4.33: https://pastebin.ubuntu.com/p/DP8KT5Gbqb/
[19:17] <ahasenack> they are the only empty dirs in both versions
[19:17] <nacc> ahasenack: i can see in git properly tht the merge is normal
[19:17] <nacc> ahasenack: i would ask in #launchpad what's going on
[19:17] <nacc> ahasenack: there are bugs here, iirc
[19:18] <dpb1> zave: likely directory not existing?
[19:18] <ahasenack> nacc: ok, thanks for checking
[19:18] <dpb1> zave: `journalctl -u <unit>` give any more?
[19:18] <sarnold> zave: check the unit file to see if it instructs systemd to change directories or run only if a directory exists or something similar
[19:18] <nacc> ahasenack: i didn't check the merge proper, but my diff matches your pastebin
[19:19] <ahasenack> good
[19:19] <nacc> ahasenack: tbh, i don't usually pay much attention to the web UI -- but I would still ping in #launchpad, just to see if it's something obvious
[19:20] <ahasenack> nacc: it's just that, at first, I obviously selected "ubuntu/devel" as the target, which is incorrect for a merge. And the size of the diff is what alerted me to that
[19:20] <ahasenack> nacc: so I resubmitted with the correct target, but the diff was still wrong :)
[19:20] <nacc> ah
[19:21] <nacc> did you fully repropose it?
[19:21] <ahasenack> at first yes, then I saw it was still wrong, then I deleted it
[19:21] <ahasenack> but it's still wrong
[19:21] <nacc> hrm
[19:22] <nacc> there were some known issues with libgit2 that cjwatson was aware of (I'm reviewing my IRC logs :)
[19:22] <zave> unicorn_abm-demo-01.service: Main process exited, code=exited, status=200/CHDIR
[19:22] <zave> unicorn_abm-demo-01.service: Control process exited, code=exited status=200
[19:22] <zave> systemd[1]: unicorn_abm-demo-01.service: Unit entered failed state.
[19:22] <zave> systemd[1]: unicorn_abm-demo-01.service: Failed with result 'exit-code'.
[19:23] <zave> unicorn_abm-demo-01.service: Main process exited, code=exited, status=200/CHDIR unicorn_abm-demo-01.service: Control process exited, code=exited status=200 systemd[1]: unicorn_abm-demo-01.service: Unit entered failed state. systemd[1]: unicorn_abm-demo-01.service: Failed with result 'exit-code'.
[19:23] <zave> sorry about that.
[19:23] <nacc> ahasenack: ok, i hit this with apache2 some time ago, as well. pygit2 itself was generating that weird diff, even though it correctly found the merge_base being debian/sid
[19:24] <nacc> i appear to have dropped it after that and not followed up :(
[19:24] <zave> dpb1: that was the journalctl log entry
[19:25] <ahasenack> nacc: ok, and about those two empty dirs, what care should be taken before uploading? The tarball that git ubuntu build-source generates, I noticed during that run that it rejected one method of obtaining the tarball because of a hash mismatch, and I think it then downloaded it from lp
[19:25] <dpb1> zave: as seth said, I'd look at the unit file next
[19:25] <ahasenack> would that be the telltale about this empty-dir problem?
[19:25] <nacc> ahasenack: yes, i expect so, but I'm not 100%
[19:26] <ahasenack> ok, thanks for sticking around :)
[19:26] <nacc> ahasenack: i would obviously trust lp (even for debian tarballs) over our pristine-tar, if there is a mismatch
[19:26] <ahasenack> that one I can upload, so if the mp gets approved, I'll be careful about that
[19:26] <nacc> ahasenack: i'd like to see the log with the mismatch if you have it, though
[19:26] <ahasenack> oh, sure, let me run it again
[19:27] <ahasenack> the orig tarball is not a symlink in that case
[19:27] <nacc> ahasenack: wht do you mean (sorry, only half here)
[19:28] <ahasenack> like
[19:28] <ahasenack> lrwxrwxrwx  1 andreas andreas   96 mar  6 12:25 sssd_1.16.0.orig.tar.gz -> /home/andreas/git/packages/sssd/.git/git-ubuntu-cache/ubuntu/sssd/1.16.0/sssd_1.16.0.orig.tar.gz
[19:28] <ahasenack> that's what g-u usually gives us
[19:28] <nacc> right, it puts it into the cache and symlinks it
[19:28] <nacc> (when it downloads from LP)
[19:29] <ahasenack> I can delete that cache safely, right? rm ./.git/git-ubuntu-cache/*
[19:29] <nacc> yeah
[19:29] <ahasenack> k
[19:31] <ahasenack> nacc: I cleaned the cache, and the orig tarball in ../: https://pastebin.ubuntu.com/p/gPxnTbmC8T/ so far, still running
[19:31] <zave> sarnold: do you have a sec to look at my unit file, please? i don't think there's anything there that fits that description ..https://pastebin.com/3qkzzfc1
[19:32] <sarnold> zave: what's namei -l /home/deploy/apps/abm_staging/amb_demo_01/current   look like?
[19:33] <nacc> ahasenack: it's technically possible for pristine-tar to do something funky to tarballs, but we should have complained about it at import time
[19:33] <nacc> ahasenack: i'd file a bug, so we can figure out what happened
[19:34] <ahasenack> I might also file a bug because it crashed after
[19:34] <nacc> :)
[19:34] <ahasenack> https://pastebin.ubuntu.com/p/9SjvRkJbYz/ whole output
[19:34] <zave> sarnold: user was originally deploy, i just changed it a minute ago to root to see if that would affect this problem ... here's the output of what you asked ...https://pastebin.com/jTj9gpPz
[19:35] <sarnold> zave: *curious*, I wonder if the symlink upsets systemd?
[19:35] <nacc> ahasenack: ah it would appear pristine-tar is not cleaning up the generated tarball when it fails verification
[19:35] <ahasenack> yeah
[19:35] <sarnold> zave: can you try /home/deploy/apps/abm_staging/abm_demo_01/releases/20180501225458 directly and see what happens?
[19:36] <sarnold> zave: .. I've got to run, good luck with this, and please report back :)
[19:36] <zave> kthx
[20:32] <plagerism1> We have a server which has bcm5709 cards in them, but I am unable to initialize the interfaces
[20:33] <tomreyn> is ubuntu readily installed, yet, or is this while running the installer?
[20:34] <plagerism1> tomreyn: it is installed
[20:34] <tomreyn> how did you install it?
[20:34] <tomreyn> you said it's "16.04", is it 16.04.0 or a different point release?
[20:34] <plagerism1> Installed via USB media.  It was 16.04.4
[20:35] <plagerism1> I will attempt to reinstall
[20:35] <tomreyn> can you show lsb_release -ds and cat /proc/version ?
[20:35] <tomreyn> should be just two lines, no need for a pastebin
[20:44] <plagerism1> tomreyn: Ubuntu 16.04.4 LTS kernel is 4.4.0-116-generic
[20:44] <plagerism1> Network wasn't initialized during the install
[20:45] <plagerism1> Would that make a difference?
[20:45] <tomreyn> well that'd explain why it doesn't try to bring them up, and why it didnt include things in initrd
[20:46] <tomreyn> plagerism1: still, "modinfo bnx2" should not return an error
[20:46] <tomreyn> does it?
[20:46] <plagerism1> Tomeryn: for what it's worth, I did not install it
[20:47] <tomreyn> it's a bit unusual that 16.04.4 would install with the GA kernel, also, normally it'd prefer the HWE one, i think (although it should actually prompt)
[20:48] <tomreyn> !info linux-image-generic xenial
[20:49] <plagerism1> Which kernel should I try?
[20:49] <tomreyn> that's not the 16.04.4 GA kernel also
[20:50] <sdeziel> tomreyn: server now defaults to the GA kernel
[20:50] <sdeziel> https://wiki.ubuntu.com/Kernel/LTSEnablementStack#LTS_Enablement_Stacks: "Server installations will default to the GA kernel and provide the enablement kernel as optional."
[20:51] <tomreyn> you should be on this https://packages.ubuntu.com/xenial/linux-image-4.4.0-124-generic (a dpeendency of linux-image-generic) or this https://packages.ubuntu.com/xenial/linux-image-4.13.0-41-generic (a dependency of linux-image-generic-hwe-16.04) kernel.
[20:51] <plagerism1> Okay
[20:51] <tomreyn> sdeziel: thanks, good to know. the one plagerism1 has is neother GA nor HWE, though.
[20:52] <plagerism1> Weird
[20:52] <sdeziel> tomreyn: by GA, I meant the latest 4.4.0-X :)
[20:53] <tomreyn> sdeziel: are you saying https://packages.ubuntu.com/xenial/linux-image-4.4.0-124-generic is not the latest 4.4.0-X ?
[20:53] <sdeziel> tomreyn: no, I'm with you, -124 is the latest and what everyone should be running if on 4.4
[20:54] <tomreyn> thanks for clarifying
[20:54] <tomreyn> plagerism1: i'm assuming that when you said "Ubuntu 16.04.4 LTS kernel is 4.4.0-116-generic" that you were reporting the kernel version your system is running?
[20:54] <tomreyn> (since that's what i asked for, not an internet research)
[20:54] <sdeziel> my point is that 16.04.2 and subsequent point releases will still default to installing a 4.4 kernel
[20:55] <plagerism1> Yes you are correct
[20:55] <tomreyn> sdeziel: alright, i got so much
[20:56] <tomreyn> plagerism1: okay, chances are that 4.4.0-116-generic is just what the 16.04.4 installer comes with and you could not update it since for lack of network access.
[20:57] <plagerism1> Yea
[20:58] <tomreyn> plagerism1: i guess you could either reinstall while bringing the system online during installation, or you could boot from the installer image and chroot into the existing installation and just install the missing patches, this would get you an upgraded kernel, thus a new initrd, and since you'll have internet access at the time it should also include what's needed to bring up your nics this time.
[21:02] <plagerism1> I don't know what I did, but nics are working now
[21:02] <plagerism1> I installed the extras kernel and rebooted
[21:03] <plagerism1> All 7 nics
[21:04] <plagerism1> Gonna dist-upgrade and hope for the best
[21:06] <tomreyn> how did you install it with out network access?
[21:56] <plagerism1> Tomeryn: I mounted the USB drive.  The only thing I did install was linux-image-extra-4.4.0-116 and rebooted.
[21:56] <plagerism1> Interestingly enough after dist upgrade and reboot to 4.4.0-224 nics were gone
[22:01] <plagerism1> I suppose if I install linux-image-extra-virtual, this would keep dependencies with kernel updates?
[22:03] <sdeziel> plagerism1: that's the theory :)
[22:04] <Blueking> I wanna build filserver with ubuntu.. should I go intel xeon or ryzen ?
[22:05] <plagerism1> sdeziel: thanks
[22:06] <sarnold> fileservers don't usually need much cpu power, just enough to run whatever compression, hashing, and raid algorithms your filesystem needs .. ECC memory is a good choice
[22:06] <Blueking> ecc are a requirement yes
[22:06] <Blueking> gonna use it for mediaserver too
[22:07] <sarnold> is that involving on-the-fly transcoding?
[22:07] <sarnold> does that parallelize well?
[22:07] <Blueking> maybe,  havn't dug into to really
[22:07] <Blueking> into it
[22:07] <sdeziel> I once made the mistake to build a smb/cifs server using an embedded type of CPU AMD C-60 ... that turned out to be too a little weak
[22:08] <sarnold> heh
[22:08] <Blueking> amd c-60 ?
[22:08] <sarnold> yeah I've never heard of it either
[22:08] <sarnold> I suspect there's areason for that :)
[22:08]  * lyn||ian has not heard of that
[22:08] <sdeziel> yeah, old one. You should be fine with Xeon/Ryzen
[22:09] <Blueking> xeon or ryzen :P
[22:09] <sdeziel> https://paste.ubuntu.com/p/bgSSP28yqz/
[22:10] <Blueking> old is that cpu ?
[22:10] <sdeziel> I went for it because of the 9W TDP
[22:10] <sarnold> nice
[22:11] <Blueking> ok I have apc with xeon dual core  xeon e3 v3 1230L  12,5 or 25W
[22:11] <sdeziel> 2011
[22:11] <sdeziel> makes a decent lxd server though :)
[22:11] <Blueking> lxd ?
[22:11] <sdeziel> not bad for VMs either
[22:12] <sdeziel> https://help.ubuntu.com/lts/serverguide/lxd.html
[22:12] <sarnold> sdeziel: I was thinking it'd probably make a nice little maas thingy..
[22:12] <Blueking> would xeon E3 1230L be enough for filserver purpose ?
[22:12] <Blueking> + some features
[22:12] <sdeziel> that's the cool thing with AMD, they do not castrate their low-end models so it has all the smart of that generation
[22:13] <sarnold> nice
[22:14] <powersj> Blueking: I use a E3-1225 and it works just fine for file serving and hosts various lxd systems (e.g. grafana, influx, unifi software)
[22:14] <Blueking> powersj -> on-the-fly transcoding?
[22:14] <powersj> that I don't do
[22:15] <sarnold> Blueking: yeah that looks nice. 32 gigs might be a bit tight depending upon what you want to do with it, but it certainly feels like it ought to be able to fill your NIC from your disks :)
[22:15] <Blueking> would cpu do it ?
[22:16] <Blueking> I am looking for a supermicro mobo with 10GBit nic onboard..
[22:16] <Blueking> might go dual cpu mobo
[22:17] <powersj> Blueking: a quick search and there is a thread on the freenas forums about the 1230l
[22:20] <Blueking> powersj  link ?
[22:24] <Blueking> mobo for xeon E3  with 10Gbit nic onboard have not enough pci-e lanes..
[22:25] <sarnold> maybe xeon-d boards would be a good fit? iirc they've got more pcie lanes
[22:43] <tomreyn> just like eypc's and threadrippers do
[22:47] <nacc> ahasenack: rbasak: dug a bit, i think we assumed that if `gbp buildpackage` fails, it would clean up the tarballs that failed to verify, say. It does not.
[22:47] <nacc> so that's the backtrace part
[23:24] <nacc> cpaelzer: dpb1: fyi, i think i need to bootstrap phpunit again, unless slangasek or another AA wants to help untangle the builds from Debian.
[23:24] <nacc> I have started sending stuff to Debian, for universe packages, which we will hopefully be able to sync
[23:46] <kevr> what would be the best way to query if a service is set to start at boot, regardless of sysv or systemd
[23:46] <kevr> ?
[23:47] <sdeziel> systemctl is-enabled $foo
[23:48] <sdeziel> I don't know if that would work for sysv scripts though
[23:48] <kevr> there's a systemd-sysv-install script as well
[23:48] <kevr> that helps with dealing with that
[23:48] <kevr> thanks
[23:49] <sdeziel> I can't find any sysv service to test with
[23:50] <kevr> i tested
[23:50] <kevr> works fine on bionic.
[23:52] <sdeziel> which service was that?
[23:52] <kevr> it's a custom init.d service script which no systemd port
[23:52] <kevr> old school
[23:52] <kevr> well of course systemd does do the porting for me
[23:52] <kevr> ;)


[00:40] -queuebot:#ubuntu-release- Unapproved: flatpak (cosmic-proposed/universe) [1.0.3-1 => 1.0.4-1] (ubuntugnome) (sync)
[00:40] -queuebot:#ubuntu-release- Unapproved: accepted flatpak [sync] (cosmic-proposed) [1.0.4-1]
[01:04] -queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (bionic-proposed) [2.9.2-0ubuntu<IP_ADDRESS>]
[03:58] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (bionic-proposed) [1:<IP_ADDRESS>]
[07:41] <acheronuk> hi release team. I have a LP: #1797643 cropped up, which is pretty sever for Kubuntu
[07:42] <acheronuk> installing Bionic packages works, so I'm going to try a git bisect on upstream sources
[07:42] <acheronuk> s/sever/severe
[08:45] <infinity> acheronuk: Good thing we haven't released yet, then.
[08:47] <acheronuk> infinity: yeah. looks like some changes to an apparmor profile shipped by akonadi might be needed
[08:48] -queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu554 => 20101020ubuntu555] (core)
[08:49] -queuebot:#ubuntu-release- New: accepted spirv-tools [source] (cosmic-proposed) [2018.2-0ubuntu1]
[08:49] -queuebot:#ubuntu-release- New: accepted vulkan-tools [source] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[08:49] -queuebot:#ubuntu-release- New: accepted vulkan-loader [source] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[08:49] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [source] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[08:49] -queuebot:#ubuntu-release- New: accepted fontcustom [sync] (cosmic-proposed) [2.0.0+ds4-5]
[08:49] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (cosmic-proposed) [20101020ubuntu555]
[08:54] -queuebot:#ubuntu-release- New binary: fontcustom [amd64] (cosmic-proposed/universe) [2.0.0+ds4-5] (no packageset)
[08:54] -queuebot:#ubuntu-release- New binary: spirv-tools [s390x] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[08:55] -queuebot:#ubuntu-release- New binary: spirv-tools [ppc64el] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[08:56] -queuebot:#ubuntu-release- New binary: spirv-tools [amd64] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[09:02] -queuebot:#ubuntu-release- New binary: spirv-tools [i386] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[09:03] <acheronuk> infinity: when are you planning RC spins?
[09:07] -queuebot:#ubuntu-release- New binary: spirv-tools [arm64] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[09:09] -queuebot:#ubuntu-release- New binary: spirv-tools [armhf] (cosmic-proposed/universe) [2018.2-0ubuntu1] (no packageset)
[09:09] <infinity> acheronuk: First ones in the morning, but they'll be intentionally not the last.
[09:12] <acheronuk> infinity: ok. test building a fix short. timewise, my main concern was that akonadi triggers a lot of tests of rdeps, but maybe should not be too bad with empty queues and fairly likely respins anyway
[09:12] <acheronuk> thanks
[09:12] <acheronuk> *shortly
[10:17] -queuebot:#ubuntu-release- Unapproved: akonadi (cosmic-proposed/universe) [4:18.04.3-0ubuntu1 => 4:18.04.3-0ubuntu2] (kubuntu)
[10:41] -queuebot:#ubuntu-release- New binary: vulkan-tools [ppc64el] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[10:41] -queuebot:#ubuntu-release- New binary: vulkan-tools [s390x] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[10:43] -queuebot:#ubuntu-release- New binary: vulkan-tools [arm64] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[10:43] -queuebot:#ubuntu-release- New binary: vulkan-tools [i386] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[10:43] -queuebot:#ubuntu-release- New binary: vulkan-tools [armhf] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[10:44] -queuebot:#ubuntu-release- New binary: vulkan-tools [amd64] (cosmic-proposed/universe) [<IP_ADDRESS>+dfsg1-0ubuntu1] (no packageset)
[14:24] -queuebot:#ubuntu-release- Unapproved: equinox-framework (cosmic-proposed/universe) [4.7.3-4 => 4.7.3-5] (no packageset) (sync)
[14:24] -queuebot:#ubuntu-release- Unapproved: accepted equinox-framework [sync] (cosmic-proposed) [4.7.3-5]
[14:47] -queuebot:#ubuntu-release- Unapproved: gscan2pdf (cosmic-proposed/universe) [2.1.6-1 => 2.1.7-1] (no packageset) (sync)
[14:47] -queuebot:#ubuntu-release- Unapproved: accepted gscan2pdf [sync] (cosmic-proposed) [2.1.7-1]
[15:46] <jbicha> please remove the gdm3/s390x binaries (needed as part of the gjs/s390x removal)
[16:30] -queuebot:#ubuntu-release- Unapproved: accepted akonadi [source] (cosmic-proposed) [4:18.04.3-0ubuntu2]
[16:30] -queuebot:#ubuntu-release- New: accepted fontcustom [amd64] (cosmic-proposed) [2.0.0+ds4-5]
[16:30] -queuebot:#ubuntu-release- New: accepted spirv-tools [arm64] (cosmic-proposed) [2018.2-0ubuntu1]
[16:30] -queuebot:#ubuntu-release- New: accepted spirv-tools [i386] (cosmic-proposed) [2018.2-0ubuntu1]
[16:30] -queuebot:#ubuntu-release- New: accepted spirv-tools [s390x] (cosmic-proposed) [2018.2-0ubuntu1]
[16:30] -queuebot:#ubuntu-release- New: accepted vulkan-tools [arm64] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:30] -queuebot:#ubuntu-release- New: accepted vulkan-tools [i386] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted vulkan-tools [s390x] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted spirv-tools [amd64] (cosmic-proposed) [2018.2-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted spirv-tools [ppc64el] (cosmic-proposed) [2018.2-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted vulkan-tools [armhf] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted spirv-tools [armhf] (cosmic-proposed) [2018.2-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted vulkan-tools [ppc64el] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:31] -queuebot:#ubuntu-release- New: accepted vulkan-tools [amd64] (cosmic-proposed) [<IP_ADDRESS>+dfsg1-0ubuntu1]
[16:50] -queuebot:#ubuntu-release- New binary: fonts-fork-awesome [amd64] (cosmic-proposed/universe) [1.1.2+ds3-3] (no packageset)
[16:50] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [s390x] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[16:54] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [amd64] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[16:56] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [ppc64el] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[16:56] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [armhf] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[16:58] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [arm64] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: vulkan-validationlayers [i386] (cosmic-proposed/universe) [<IP_ADDRESS>-0ubuntu1] (no packageset)
[17:48] -queuebot:#ubuntu-release- Unapproved: oregano (cosmic-proposed/universe) [0.70-3ubuntu2 => 0.84.40+dfsg.1-1] (no packageset) (sync)
[17:49] -queuebot:#ubuntu-release- Unapproved: accepted oregano [sync] (cosmic-proposed) [0.84.40+dfsg.1-1]
[17:50] <tsimonq2> infinity: Lubuntu will also need one last Calamares settings package and we should be set.
[17:51] <tsimonq2> Otherwise we are going to look at 0-day SRUing qtwebkit-opensource-src and libreoffice.
[17:57] <tsimonq2> Oh, and the Cala change also needs a casper upload.
[17:58] <tsimonq2> I plan on preparing that within the hour, assuming I can find some desk space. :P
[18:32] -queuebot:#ubuntu-release- New sync: anbox (cosmic-proposed/primary) [0.0~git20180821-1]
[18:44] <jbicha> ^ anbox should work now with Ubuntu's lxc
[19:08] <tsimonq2> infinity: Assuming nobody finds anything else, those two packages I just uploaded should be it for stuff to get on the Lubuntu ISO before release.
[19:08] <tsimonq2> So, huzzah.
[19:09] -queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [25 => 26] (lubuntu)
[19:09] <tsimonq2> It's just renaming the Calamares .desktop file to something sane and then using casper magic to make it a trusted executable, instead of doing horrible, hacky things with /etc/skel.
[19:10] -queuebot:#ubuntu-release- Unapproved: casper (cosmic-proposed/main) [1.397 => 1.398] (desktop-core, ubuntu-server)
[20:09] <infinity> tsimonq2: Explain the efi change to me.
[20:09] <infinity> tsimonq2: Or, rather, explain why you fixed it wrong. :)
[20:09] <infinity> tsimonq2: You want "if grep -q foo; then"
[20:10] <infinity> tsimonq2: The part where it's wrapped in a subshell and then in a test is why it's going all weird for you, and the "fix" is relying on the string return evaluating true, which is vaguely undefined.
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (cosmic-proposed) [1.398]
[20:14] -queuebot:#ubuntu-release- New: accepted anbox [sync] (cosmic-proposed) [0.0~git20180821-1]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [amd64] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [armhf] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [ppc64el] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:14] -queuebot:#ubuntu-release- New: accepted fonts-fork-awesome [amd64] (cosmic-proposed) [1.1.2+ds3-3]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [i386] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [arm64] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:14] -queuebot:#ubuntu-release- New: accepted vulkan-validationlayers [s390x] (cosmic-proposed) [<IP_ADDRESS>-0ubuntu1]
[20:16] <tsimonq2> infinity: You're correct there, and I relied on "wxl
[20:16] <tsimonq2> *"wxl's bash knowledge is much better than mine".
[20:17] <tsimonq2> infinity: I'll patch that up and run it through a VM, thanks.
[20:23] -queuebot:#ubuntu-release- New binary: anbox [amd64] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
[20:24] <infinity> tsimonq2: Easily mockable (to remind yourself of correct syntax) with something like:
[20:24] <infinity> if grep -q bogomips /proc/cpuinfo; then echo "I love bogomips."; fi
[20:24] <tsimonq2> Heh.
[20:26] -queuebot:#ubuntu-release- New binary: anbox [arm64] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
[20:26] -queuebot:#ubuntu-release- New binary: anbox [armhf] (cosmic-proposed/multiverse) [0.0~git20180821-1] (no packageset)
[20:27] -queuebot:#ubuntu-release- New: accepted anbox [amd64] (cosmic-proposed) [0.0~git20180821-1]
[20:27] -queuebot:#ubuntu-release- New: accepted anbox [armhf] (cosmic-proposed) [0.0~git20180821-1]
[20:27] -queuebot:#ubuntu-release- New: accepted anbox [arm64] (cosmic-proposed) [0.0~git20180821-1]
[20:32] <tsimonq2> infinity: So, like this? "        -    command: apt install -y --no-upgrade -o Acquire::gpgv::Options::=--ignore-time-conflict grub-efi-$(if grep 64 /sys/firmware/efi/fw_platform_size; then echo amd64-signed; else echo ia32; fi)"
[20:32] <infinity> tsimonq2: grep -q
[20:32] <infinity> tsimonq2: 'if' is checking the return code, not the output.  You want to toss the output.
[20:33] <tsimonq2> infinity: "        -    command: apt install -y --no-upgrade -o Acquire::gpgv::Options::=--ignore-time-conflict grub-efi-$(if grep -q 64 /sys/firmware/efi/fw_platform_size; then echo amd64-signed; else echo ia32; fi)"
[20:33] <tsimonq2> That?
[20:33] <infinity> tsimonq2: Yup.
[20:33] <tsimonq2> Cool.
[20:35] <infinity> tsimonq2: The reason it didn't work before was because it was wrapped in a test (and, for some odd reason, a subshell), so the test was testing the output of "grep -q ..." to see if it was true.  The output was null, which is false.
[20:35] <infinity> tsimonq2: It got "fixed" when you dropped the -q, but that was now testing if "garbage string with 64 in it" was "true", which is undefined, and a big maybe.
[20:35] <tsimonq2> infinity: Right.
[20:36] <tsimonq2> infinity: So, unless my clipboard is whack, that follow-up upload should be good?
[20:36] <tsimonq2> (Er, the one currently dput'ting.)
[20:36] <infinity> Seems likely.
[20:36] <infinity> I'll know when I see it. :P
[20:37] -queuebot:#ubuntu-release- Unapproved: calamares-settings-ubuntu (cosmic-proposed/universe) [25 => 26] (lubuntu)
[20:38] <tsimonq2> Theeere it is.
[20:38] -queuebot:#ubuntu-release- Unapproved: rejected calamares-settings-ubuntu [source] (cosmic-proposed) [26]
[20:39] <infinity> LGTM.
[20:40] <tsimonq2> Awesome.
[20:40] -queuebot:#ubuntu-release- Unapproved: accepted calamares-settings-ubuntu [source] (cosmic-proposed) [26]
[20:40] <infinity> tsimonq2: If you're ever mildly confused about [] in shell, remember it's just prettier shorthand for "test", and "help test" will tell you all about it.
[20:41] <tsimonq2> Cool, thanks.
[20:42] <infinity> ie: 'if [ "$foo" = "cat" ]; ...' is the same as 'if test "$foo" = "cat"; ...'
[20:42] <infinity> But the former is about 1000 times more readable.
[20:42] <tsimonq2> Heh, true.
[21:09] <jbicha> the only one of the apps in LP: #1771025 that even *runs* for me in cosmic is bareftp 😭
[21:33]  * jbicha looks suspiciously at ncurses
[22:40] -queuebot:#ubuntu-release- Unapproved: anbox (cosmic-proposed/multiverse) [0.0~git20180821-1 => 0.0~git20180915-1] (no packageset) (sync)
[22:40] -queuebot:#ubuntu-release- Unapproved: accepted anbox [sync] (cosmic-proposed) [0.0~git20180915-1]
[23:21] <xnox> infinity, not sure if we care to upload nss with tls1.3 as well or not. the biggest win would have been chromium-browser, but that one clamps down tlsv1.3 to the draft versions only and thus does not gain final v1.3. and openjdk-8|lts execute no adt tests at all it seems. and libreoffice `regression` is observed in cosmic-release at the moment anyway.
[23:21] <xnox> https://bileto.ubuntu.com/excuses/3479/cosmic.html
[23:21] <xnox> will land into unapproved, but i have no strong feelings if we should or should not take it.
[23:21] <infinity> xnox: I'd say no.
[23:22] <infinity> xnox: cosmic isn't an LTS, there's plenty of time to fix this in DD.
[23:23] <xnox> ack
[23:23] <xnox> and testing is unconvincing.
[23:23] <xnox> plus e.g. firefox/google-chrome embed their own nss anyway, and that will get v1.3 via usual code-drops anyway.
[23:24] <infinity> Right.
[23:24] -queuebot:#ubuntu-release- Builds: Netboot amd64 [Cosmic Final] (20101020ubuntu555) has been added
[23:24] -queuebot:#ubuntu-release- Builds: Netboot arm64 [Cosmic Final] (20101020ubuntu555) has been added
[23:24] -queuebot:#ubuntu-release- Builds: Netboot armhf [Cosmic Final] (20101020ubuntu555) has been added
[23:24] -queuebot:#ubuntu-release- Builds: Netboot i386 [Cosmic Final] (20101020ubuntu555) has been added
[23:24] -queuebot:#ubuntu-release- Builds: Netboot ppc64el [Cosmic Final] (20101020ubuntu555) has been added
[23:24] -queuebot:#ubuntu-release- Builds: Netboot s390x [Cosmic Final] (20101020ubuntu555) has been added
[23:25] <infinity> tsimonq2: Still doing lubuntu i386 for final?
[23:25] <tsimonq2> infinity: Yup.
[23:26] <tsimonq2> infinity: I believe Xubuntu is also still doing i386, too. :P
[23:26] <infinity> tsimonq2: Figured.
[23:26] <tsimonq2> ¯\_(ツ)_/¯
[23:27] <tsimonq2> We have testers, so I'm not complaining, really.
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Cosmic Final] (20181013.1) has been added
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Cosmic Final] (20181013.1) has been added
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Cosmic Final] (20181013.1) has been added
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Cosmic Final] (20181013.1) has been added
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Cosmic Final] (20181013.1) has been added
[23:30] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Cosmic Final] (20181013.1) has been added
[23:34] <infinity> tsimonq2: I'd like to see the last two i386 ISOs die so people stop installing with i386 so they don't expect an upgrade path if/when we drop it.
[23:35] <infinity> tsimonq2: I mean, it's going to suck regardless, but the earlier we tear off the band-aid, the better.
[23:35] <infinity> tsimonq2: (But don't read that as me pressuring you to drop the ISO, I don't care deeply enough to bother doing that)
[23:36] <infinity> tsimonq2: I've pressed The Button to rebuild $world (and sent a mail about it).  If you don't see some images by late tonight, please do annoy people (ie: vorlon) about missing stuff.
[23:37] <tsimonq2> infinity: Can you say for certain that archive support (i.e. package builds) will be gone before 20.04 is released?
[23:37] <tsimonq2> infinity: Sure, if you say so. :P
[23:37] <infinity> tsimonq2: I can't.  That's still up in the air, and the decision isn't being taken until next year (not my call, I'd have dropped it the day after 18.04 released if we'd had my way :P)
[23:38] <tsimonq2> infinity: (If I had it my way it would have been gone at the same time, but other team members and the community have grabbed pitchforks, so I've taken a "you test and support it, you can have it" approach. :P)
[23:39] <infinity> Guess I'm boarding in a few minutes.  Time to pack up the laptop.
[23:39] <tsimonq2> Have fun.
[23:39] <infinity> See you on the flipside.
[23:39] <tsimonq2> (If airplanes can be fun?)
[23:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Cosmic Final] (20181013.1) has been added
[23:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Cosmic Final] (20181013.1) has been added
[23:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Cosmic Final] (20181013.1) has been added
[23:40] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Cosmic Final] (20181013.1) has been added
[23:57] <jbicha> the mono app issue isn't as bad as it first looked; only problem now is mono doesn't build LP: #1797727