[03:51] <lotuspsychje> good morning
[07:04] <ducasse> good morning
[18:21] <lotuspsychje> tomreyn: looks like a cheap flaky machine to me, https://incoherency.co.uk/blog/stories/ubuntu-18.04-ideacentre-310s.html
[18:23] <tomreyn> it's definitely a low price platform
[18:24] <lotuspsychje> havent seen his dmesg neither yet
[18:24] <tomreyn> lotuspsychje: the system does work fine as sold, though, just not with this seperately acquired nvidia card, on linux (does work on windows).
[18:25] <lotuspsychje> tomreyn: i also find it weird, 440 doesnt showup his ubuntu drivers list
[18:25] <tomreyn> he's posted several journalctl -b    by now.
[18:25] <lotuspsychje> and -server drivers showup
[18:26] <tomreyn> here's what he gets when he boots with the 450 drivers installed:  http://termbin.com/601ye
[18:26] <tomreyn> same thing but with recovery kernel chosen on grub menu (which also sets "nomodeset"): http://termbin.com/e115
[18:28] <lotuspsychje> tnx
[18:34] <daftykins> pentium silver :( just wow what people try and polish
[18:35] <lotuspsychje> daftykins: whatever the user trys, his nvidia drivers seem to fail
[18:36] <tomreyn> this is the exact model: https://psref.lenovo.com/Detail/IdeaCentre/ideacentre_310S08IGM?M=90HX000PUK
[18:36] <daftykins> yep got that page open
[18:36] <daftykins> there'll be insufficient power i bet, to run a discrete card
[18:37] <tomreyn> 65W is really not much, not sure
[18:37] <tomreyn> i dodn't notice this
[18:37] <tomreyn> *didn't
[18:37] <daftykins> see how it says 65W adapter? so it's unlikely to push the full power spec through the PCIe slot
[18:37] <daftykins> what model is it he's putting in, something like an nvidia 1050 Ti?
[18:37] <lotuspsychje> https://certification.ubuntu.com/hardware/201912-27573 a bit similar lenovo show 18.04 with oem kernel here
[18:38] <lotuspsychje> also with the intel 605
[18:38] <tomreyn> 10de:1d01 is the nvidia
[18:38] <lotuspsychje> PCI-E Nvidia GT 1030
[18:38] <tomreyn> yes
[18:38] <tomreyn> but he said it works on windows
[18:39] <daftykins> i see a 'nvidia-uvm' claiming to load, what's that about o0
[18:39] <daftykins> hrmm 30W card - nvidia's specs say you should have a 300W PSU
[18:40] <daftykins> for me personally, i'm not too persuaded of the claim Windows is fine - it's a bad combo, would refuse
[18:41] <daftykins> 10W CPU, so say it were loaded, that's already 40W of the PSU taken, with the remaining 25W to run disks, motherboard silicon, anything else in there... lol :D
[18:42] <lotuspsychje> 278 euro lenovo :p
[18:46] <tomreyn> looks like he calculates power consumption differently
[18:46] <daftykins> with a hope and a prayer?
[18:47] <tomreyn> :)
[18:49] <daftykins> it might be borderline, seems like the CPU is an SoC there, so the 10W could be full package power, with no further on the board
[18:50] <daftykins> makes so much more sense buying the right tool for the job though
[22:38] <tomreyn> out of interest, i just looked for alternatives to dreamscapes' https://psref.lenovo.com/Product/IdeaCentre/ideacentre_310S08IGM?ch=90HX000PUK (which sells for €265 on ebay) the computer  https://geizhals.eu/?cat=sysdiv&xf=11069_integrierte+Grafik+(IGP)~11121_2~13393_4~445_8192~447_allgsosd~6764_AMD~9718_Dali~9718_Renoir~9724_15&v=k&hloc=at&hloc=de&hloc=pl&hloc=uk&hloc=eu&sort=p&bl1_id=30&togglecountry=set
[22:42] <daftykins> seems like you're keen on AMD ;)
[22:43] <tomreyn> he wanted low power, and better graphics than intel igp
[22:43] <tomreyn> to me, this means amd apu
[22:44] <daftykins> no reason for it to be integrated
[22:44] <tomreyn> also, yes, i prefer anything over nvidia
[22:44] <tomreyn> power savings are a reasn for it to be integrated
[22:44] <daftykins> i find it funny how you think nvidia = trouble :)
[22:46] <tomreyn> i find it sad how i came to think this.
[22:51] <tomreyn> anyways, the first system on the list has twice the ram, a proper ssd (his had 220 MB/s write speed max.), an extra hdd, certainly faster cpu threads (but two cores less), 802.11 ac,(4) USB 3.2 Gen 1 Type-A, HDMI v1.4b/HDCP 1.4, RS-232
[22:52] <tomreyn> and is cheaper :)
[22:53] <daftykins> 'pentium' was all you need know about the current one
[22:55] <tomreyn> :) well, it's like the amd "athlon" nowadays, isn't it
[22:56] <tomreyn> a marketing name, usually referring to the slower / power efficient and, most of all, cheap ones
[22:59] <daftykins> think it's a greater difference than that
[23:06] <tomreyn> yes, probably, they're also not the most current ones. leftover stock which needs clearing. ;-)
[23:07] <daftykins> didn't look too closely, it's foreign! plenty of options going a few generations back on ebay and the like
[23:08] <daftykins> what was the result anyway, were they given up on?
[23:14] <tomreyn> he gave up, saying he'll use his old one instead
[23:17] <daftykins> PC or graphics card?
[23:20] <tomreyn> pc
[23:20] <tomreyn> which was an older low energy pentium
[23:20] <daftykins> TJ-: \o greetings, all well?
[23:21] <TJ-> Hiya :) just arrived in the office for an overnighter!
[23:21] <daftykins> ooh another one
[23:22] <tomreyn> i'm about to arrive in my bedroom for an overnighter
[23:22] <tomreyn> see you!
[23:22] <TJ-> yeah - closed down for everything except tech deployment for 5 days from yesterday, we got a bit behind schedule today so trying to catch up
[23:22] <TJ-> tomreyn: :D
[23:22] <daftykins> TJ-: i had an amusing situation with the encrypted VM, thought you might enjoy hearing... i had the UUID wrong in crypttab, so when the machine booted it would only take to the -25 kernel that was preinstalled post-debootstrap, the real /boot never got mounted to /boot, so instead a /boot as a subdirectory of / was where newer kernels were getting put xD easily fixed up
[23:22] <TJ-> delay mostly caused by Windows Server defrag STILL running 12 hours later!
[23:23] <TJ-> daftykins: ouch - been caught out by that myself once or twice
[23:23] <daftykins> hah, what are you doing messing with that nasty thing, a completely degraded small business server 2011 machine i fixed up was much quicker even with 50% fragmentation
[23:24] <daftykins> TJ-: more seriously though i might have to give up, as i want the module xenfs loaded so the guest utilities can talk to dom0, but on reboot modules keep disappearing from the disk - and i don't understand why at all O_O
[23:25] <daftykins> it's not a custom addition, just one that comes in from linux-modules-<version>
[23:26] <TJ-> we're wiping Windows out completely; currently we have a HyperV Linux on the HP server with PCI pass-through of 2 NVMEs + 4x Ethernet. Now we're going to make it dual boot so need to shrink the OS partition, and the aim is repeat the Windows shares using NFS off the NTFS, and later totally wipe out Windows
[23:26] <TJ-> modules disappearing?
[23:27] <daftykins> yep, it's a magic trick - i can get it loaded once; sudo depmod, modprobe xenfs, but on reboot the actual files are gone from the disk and i have to apt install --reinstall the linux-modules-version package to get them back
[23:28] <TJ-> I can think of one cause; if the module is in a package linux-modules-$VERSION but you do not have the generic non-versioned package that depends on that installed, when a kernel update is added the related linux-modules won't be installed
[23:29] <TJ-> otherwise, you've got a storage failure of some kind. what is the underlying file-system ? LVM + ext4?
[23:29] <daftykins> mmm, nah the modules-generic is present and correct... yeah matched your guide identically but then it's a VM atop XCP-ng
[23:30] <TJ-> give me a specific version you've had problems with so I can check
[23:30] <daftykins> mmm 5.4.0-28 is current on that VM i think
[23:31] <daftykins> the /xen/ files don't disappear on a kernel upgrade though, solely a reboot
[23:32] <TJ-> so linux-modules-5.8.0-25-generic has an rpdends to linux-image-5.8.0-25-generic
[23:32] <TJ-> well, that suggests you've got a file-system problem of some kind. Sure you've not got a stray tmpfs ?
[23:34] <daftykins> hrmm during package installs i think i saw some weird messages about 'leaks' due to LVS invocation, something along those lines
[23:34] <daftykins> some comments online claimed they are harmless
[23:34] <TJ-> that would be grub-install
[23:35] <TJ-> the package installs to /lib/modules/$VERSION/ so if that entire director sub-tree disappears, or files within it do, then there's a storage system fault
[23:35] <TJ-> is there hardware RAID behind it?
[23:36] <daftykins> i'd moved it off of one and onto a single 2TB M.2 PCIe drive during these antics
[23:36] <daftykins> i could move it back and see if anything changes
[23:36] <TJ-> is it possible you've got some problem in fstab entries causing the wrong file-system being mounted?
[23:37] <mgedmin> does debsums -c linux-modules-$(uname -r) find other missing modules, or just the xen one?
[23:37] <daftykins> it's a pretty basic two-liner, LUKS_BOOT and the main / ext4 - can't really see i'd get as far as i do if it were too wrong
[23:38] <TJ-> you can use "dpkg --verify linux-modules-$(uname -r)" instead of debsums :)
[23:38] <daftykins> mgedmin: mm saw you post that the other day, but i wasn't in a position to work on the system then
[23:38] <TJ-> daftykins: OK --- trying to rule out the obvious
[23:38] <daftykins> i will go and fire it up, it'll be a good 15 mins before it's up
[23:38] <TJ-> daftykins: as it is a VM makes me wonder if the hypervisor is doing something bad like not flushing to the real storage
[23:41] <daftykins> not had a problem on my other VMs during setup and configuration
[23:42] <TJ-> I'd check /var/log/apt/history.log in case something in the background is unning a package remove operation!
[23:42] <TJ-> it depends if the entire package content is going missing, or just part of it, and which part
[23:43] <daftykins> it's a select number of files under there, but i can't give the path until it's fired up, lost from memory :D
[23:43] <TJ-> if apt/dpkg still shows the package as installed but files from it are missing then something weird is going on. I'm wondering if the file-system journal isn't being flushed to the file-system (e.g. the ext4 journal being lost so next time the file-system is mounted (at boot) the file-system has effectively been rolled back
[23:47] <daftykins> the issue with that theory, is that when i added xe-guest-utilities - that change persisted
[23:49] <TJ-> yep - losing journal would show up in the kernel log at boot
[23:50] <TJ-> what module are you losing again?
[23:50] <daftykins> xenfs
[23:52] <TJ-> the only thing I can think is you've got some DKMS module that is replacing/removing the original, but again that's doubtful in your scenario
[23:52] <TJ-> but DKMS does move package modules
[23:53] <daftykins> weird, i am missing linux-generic linux-headers-generic linux-image-generic today
[23:54] <TJ-> how 'missing' - reported as not installed?
[23:55] <daftykins> ah i had remembered incorrectly, i'm on 5.4.0-52-generic
[23:55] <daftykins> yep, i'm going to hold off of adding them back just for a moment though
[23:55] <TJ-> you sure it's not using -lowlatency rather than -generic ?
[23:55] <TJ-> "apt list --installed 'linux*' "
[23:55] <mgedmin> hey TJ-, do you know how to interpret dpkg --verify's output?  https://paste.ubuntu.com/p/XWkpJYrFpd/
[23:55] <mgedmin> "??5??????" is not exactly self-explanatory
[23:56] <daftykins> positive because i installed via linux-generic post-debootstrap
[23:56] <TJ-> mgedmin: 5 mean md5sum
[23:57] <daftykins> ok so in my VM, /lib/modules/5.4.0-52-generic/kernel/drivers/xen contains only "xen-front-pgdir-shbuf.ko" whilst there should be plenty more there
[23:57] <TJ-> mgedmin: it's rpm format output, with 9 checks. ? means it wasn't performed
[23:57] <TJ-> mgedmin: so '5' means md5sum didn't match
[23:58] <daftykins> in that case i just got 5's across everything
[23:59] <daftykins> /lib/modules/5.4.0-52-generic/kernel/drivers/xen/xenfs/xenfs.ko - is the specific one i'm after
[23:59] <mgedmin> TJ-: thanks!


[00:36] <tsimonq2> pleia2: there is gonna be a UWN this week, correct?
[06:46] <pleia2> tsimonq2: yes, just got back in from conference things, sending email to summary writers momentarily
[17:26] <tsimonq2> pleia2: Oh ok


[01:46] <akk> Anybody use libreoffice in 12.04? It claims to have templates, but all the template categories seem to be empty.
[01:47] <akk> Is there some extra package I need to install to get them? (I looked for a package with template in the name, but there aren't any.)
[01:49] <akk> I don't want anything fancy, just a standard business letter -- openoffice used to have that.


[00:35] <ali1234> use a text editor for text entry
[00:36] <ali1234> then format it in word or whatever
[00:36] <Azelphur> heh, or just use a editor that doesn't suck :P
[00:36] <Azelphur> failure to save on crash, failure to autosave, and crashing on save, 3 counts of fail :(
[00:36]  * Azelphur punishes it to apt-get remove :P
[00:38] <daftykins> hate to be Captain Hindsight, but i must admit if it's going to be something a fair amount of effort is going into, i tend to save pretty early :(
[00:38] <Azelphur> yea, it was supposed to be on auto save
[00:39] <Azelphur> and I didn't exactly expect it to fall over and die from a simple action such as "save" :P
[00:39] <daftykins> does that really do anything prior to saving once though? i was imagining you meant you were sort of still in 'Untitled' mode
[00:39] <Azelphur> daftykins: no, I was editing an existing document, and it's supposed to auto-save every 5 minutes
[00:40] <daftykins> oh right
[00:40] <Azelphur> it stopped auto saving for a good hour, at least, without saying anything
[00:40] <daftykins> that's worse still then :(
[00:40] <Azelphur> and then crashed on save
[00:40] <Azelphur> yea
[00:40] <daftykins> what you need is a good reliable system like the one i just had a fiddle with
[00:40] <daftykins> http://i.imgur.com/u5QDZ9h.jpg
[00:40] <daftykins> :D
[00:40] <Azelphur> heh, well libreoffice has crash recovery, as do most sane office suites
[00:40] <daftykins> wee laptop underneath ;)
[00:40] <Azelphur> daftykins: lol
[00:41] <daftykins> also i know, i know, i don't have as many screens as you :(
[00:41] <Azelphur> is that the logitech speaker with a screen on it?
[00:41] <daftykins> but they are nice ones
[00:41] <daftykins> in the middle? nah that's just the centre channel on its' little feet
[00:43] <ali1234> no, the thing witht he bright blue stripe on it to the right of the right monitor
[00:43] <ali1234> and the big dial
[00:43] <daftykins> oooh
[00:43] <daftykins> that's the control unit
[00:44] <daftykins> weirdly inputs go into there then go over what is basically a 9 pin serial cable to the amp in the subwoofer box on the floor
[00:44] <daftykins> using digital coaxial of late
[01:19] <neuro> well, that's my star trek deep space nine marathon finished
[01:19] <neuro> forgot how bloody good it is
[01:40] <ali1234> the other day on a whim i decided to download and rewatch wild palms
[01:41] <ali1234> for a 20 year old show it's pretty good... if anything it was ahead of it's time
[01:42] <ali1234> well, i've only watched the first episode so far...
[01:48] <neuro> wow, that's going back a bit
[01:48] <neuro> don't think i ever watched it
[01:48] <neuro> holy crap, the cast looks awesome
[01:48] <neuro> ah, brad dourif, everyone's favourite movie nutjob
[01:49] <ali1234> yeah and he is a good guy in it
[01:49] <neuro> It is by the juice of sapho that thoughts acquire speed, the lips acquire stains, the stains become a warning. It is by will alone I set my mind in motion.
[01:50] <neuro> ah, god bless youtube: http://www.youtube.com/watch?v=EMBb_tPPA8E
[01:51] <ali1234> some of the things they got right: teleconference holograms, patent lawyers causing trouble
[01:51] <neuro> what, wild palms?
[01:51] <ali1234> things they got wrong: everyone is old and wears a suit. lol
[01:51] <ali1234> yeah
[01:52] <neuro> it's funny how many 80s and 90s scifi occasionally predicted something pretty close to what we've got now
[01:52] <neuro> only occasionally, mind
[01:52] <ali1234> indeed. often the little things too, more than the obvious stuff too
[01:52] <neuro> yeah
[01:53] <neuro> and then there's scifi influencing tech; star trek has a lot to answer for!
[01:53] <neuro> crazy boffin types trying to invent anti-matter and warp speed
[01:53] <ali1234> i don't think wild palms influenced anyone... it was critically panned and forgotten
[01:53] <neuro> i'm pretty sure these are the guys who will get the planet sucked into a black hole, never mind the LHC
[01:54] <neuro> bear in mind it's the kids who grew up as geeks watching scifi who turned into the engineers who have ended up building a lot of this stuff, be it hardware, software or the convergence between the two
[01:54] <neuro> so maybe some proto-engineer watched wild palms and thought "... hey!"
[01:55] <ali1234> also they have a dig at scientology before it was cool to do that
[01:55] <neuro> ha
[01:55] <neuro> remember scientology has been around since the late 50s :)
[01:56] <ali1234> of course, but it wasn't really on the radar back in 1993
[01:56] <neuro> you'd be surprised
[01:56] <ali1234> most people back then probably wouldn't even have got the reference
[01:56] <neuro> just that there wasn't the same penetration of internet access to propogate it
[01:56] <neuro> well in the states, maybe
[01:56] <neuro> i've been reading a lot about it lately
[01:57] <neuro> some of the shenanigans that go on, if they can be proved, are pretty heinous
[02:03] <neuro> sorry, got sucked into this: http://www.youtube.com/watch?v=pVkVWnvmjl0
[02:03] <neuro> i love these guys
[02:06] <ali1234> the lighting in that game is amazing
[02:07] <neuro> looking straight into the sun kinda sucks at times
[02:07] <neuro> they've fixed that in battlefield 4 apparently
[02:07] <neuro> i'm pretty good with the Beretta, just not quite as good as that guy :)
[02:08] <ali1234> why is there a wilhelm scream at 2:11? is that actually in the game??
[02:08] <neuro> no :)
[02:08] <neuro> he added the KLONK followed by the wilhelm
[02:08] <neuro> the rest of the audio is as-is
[02:08] <neuro> sounds amazing in surround
[02:12] <ali1234> yea i don't even understand how anyone knows what is going on in this game... it's just like a massive pileup of carnage
[02:12] <neuro> you catch on quickly :)
[02:13] <neuro> there are a lot of audio and visual cues to help you out
[02:13] <ali1234> "shoot guys with orange writing on them"
[02:13] <neuro> well most of the game modes are objective based, so if that's all you did, you'd suck
[02:14] <ali1234> it's really hard to tell from these videos
[02:14] <neuro> capture/defend this area, destroy/defend that crate, CTF, etc etc
[02:14] <neuro> ravic is playing Conquest in all of those clips
[02:15] <neuro> if you look at the map at bottom left, there are red and blue boxes, some of which are flashing
[02:15] <neuro> basically these are flag points on the map you need to capture
[02:15] <neuro> A, B, C, etc
[02:15] <neuro> numbers vary from map to map depending on size etc
[02:16] <neuro> if you stay within the flag area, you can capture it
[02:16] <neuro> if there are more of their guys in the area than yours, you can't capture it
[02:16] <neuro> both teams have 'tickets', default usually about 100-200
[02:16] <neuro> every time a player dies and respawns, that eats a ticket
[02:17] <neuro> if a team holds >50% of the flags, then the opposing team's tickets start decreasing at about 1 every 2 seconds
[02:17] <neuro> first team to lose all their tickets, loses
[02:17] <neuro> sounds complicated, but you pick it up very very quickly
[02:18] <neuro> if one of those boxes down at bottom left is flashing, someone is capturing it, reversing it from red (opfor) to blue (your team) or vice versa
[02:18] <neuro> oh and if you hold a flag, you can spawn at it, rather than at your deployment at the edge of the map
[02:19] <neuro> and optionally, if you are in a squad (of up to 4), and at least one of them is alive and on the ground or in a vehicle with a spare seat, you can spawn on them too
[02:20] <neuro> i've been playing this since release in oct 2011 (and battlefield bad company 2 and battlefield 1943 before it), so i'm used to it now :)
[02:23] <neuro> oh, this *does* work if you're not signed in ... http://battlelog.battlefield.com/bf3/soldier/evilneuro/stats/115000054/xbox/
[02:23] <neuro> 'tis I
[07:18] <ubcqtml> /join #yrs
[07:18] <ubcqtml> sorry
[09:05] <brobostigon> good morning everyone,
[09:07] <MartijnVdS> \o brobostigon
[09:07] <brobostigon> morning MartijnVdS
[12:11] <popey> A'noon
[12:23] <bigcalm> Good morning peeps :)
[12:24] <popey> yo
[12:25] <bigcalm> Howdy popey
[12:25] <bigcalm> popey: which country are you in today?
[12:41] <popey> bigcalm: home
[12:58] <neuro> i wonder if ...
[12:58]  * neuro is listening to "Canyon Battle" by M83, Anthony Gonzalez, Joseph Trapanese, from the album Oblivion. 256kbps AAC
[12:58] <neuro> huh
[13:08] <neuro> ouch, edge now nearly 11m off the pace :(
[13:10] <neuro> they basically need to repeat some of the biggest crowdfunding campaigns
[13:10] <neuro> every day
[15:29] <penguin42> Gah, Scottish power don't seem to know how to do live updates; all their systems for doing meter entry seem to be down - both web and phone
[15:52] <penguin42> anyone used coccinelle?
[16:02] <MartijnVdS> penguin42: what is it?
[16:07] <penguin42> MartijnVdS: It's a 'semantic patch' program - you give it a description of some C and it generates a patch to change it; e.g. if you added an extra parameter to every use of foo() you could get it to go through your code and add it, or search for a particular common type of mistake
[16:15] <penguin42> except I can't get it to take the really neat use one of the developers has just posted; it finds errors of the form           a = b,   c=d;    where the , should be a ;
[18:09] <markie-> Wow everything is exactly how i left it
[20:09] <popey> Evening all
[20:11] <AlanBell> hi popey
[20:18] <penguin42> hey Popey
[20:18] <daftykins> hey all \o
[20:27]  * penguin42 had better take this music player off loop - it's been doing The Eagles for a few hours
[20:41] <AlanBell> you can check out any time you like but you can never leave
[20:42] <penguin42> indeed
[21:21] <Azelphur> Is anyone aware of a decent, p2p encrypted chat network?
[21:22] <ali1234> bitmessage
[21:22] <Azelphur> interesting
[21:30] <Azelphur> ali1234: bitmessage seems more like an email deal
[21:40] <Azelphur> ali1234: torchat looks pretty cool :)
[21:45] <moreati> Azelphur: re you looking for IRC style chat rooms or IM one to one style?
[21:46] <Azelphur> moreati: IM, IRC would be cool too though
[21:46] <moreati> for the later there's OTR
[21:46] <Azelphur> moreati: OTR is a bit naf, as it still lets the service owner know who you are talking to, when, and for how long
[21:46] <moreati> supported by Pidgin I believe
[21:46] <moreati> ah, yes
[21:47] <moreati> would jabber over SSL have the same weakness? Would that differ if both parties were on the same/different servers?
[21:47] <Azelphur> moreati: yea, it would have the same weakness
[21:47] <moreati> Eve could tell when you were connected certainly
[21:48] <Azelphur> I've found a few things I plan on using regularly after seeing them
[21:48] <Azelphur> Bitmessage seems to be a very good secure email alternative, TorChat2 looks like it'll be a pidgin plugin really soon which will be sweet
[21:48] <Azelphur> so that gets you email & IM
[21:48] <moreati> ah, statistical analysis of packet times would show who was chatting with who
[21:49] <shauno> jabber over ssl still requires that you trust the service provider
[21:49] <Azelphur> ^
[21:50] <MattJ> Jabber \o/
[21:50] <Seeker`> Jabber \o/
[21:50] <Azelphur> MattJ: jabber is getting downvoted in this conversation :P
[21:50] <Azelphur> (sorry!) :P
[21:51] <MattJ> Jabber/XMPP can be used via Tor, it can be completely anonymous...
[21:51] <Azelphur> MattJ: even if you use it via tor, that doesn't stop the service provider from knowing who is talking to who
[21:52] <shauno> well, that A is talking to B.  the upshot of that method is the service provider may have no idea or A or B are
[21:53] <MattJ> Indeed
[21:53] <MattJ> Though you can get quite far sometimes
[21:53] <MattJ> But at that point you run your own servers...
[21:53] <Azelphur> yea
[21:53] <MattJ> which can also communicate over tor :)
[21:54] <MattJ> ( https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-over-tor-hidden-services/ - by an Adium dev actually)
[21:56] <Azelphur> nice
[21:56] <Azelphur> that's pretty sweet
[21:56] <Azelphur> are there any public servers that implement that?
[21:56] <MattJ> None that I know of, yet
[21:56] <MattJ> I know several that are already accessible as hidden services
[21:58] <Azelphur> cool
[21:58] <Azelphur> looks interesting :)
[22:00] <shauno> I still find freenet interesting, but it won't (and can't) do realtime
[22:02] <shauno> on the topic of tinfoil, I can't seem to find any vps in Iceland that aren't either unrealistically expensive, or owned by non-icelandic parent companies
[22:10] <ali1234> what's the difference between email and instant messaging?
[22:12] <shauno> mostly the client these days.  but email doesn't present any status
[22:12] <shauno> I don't know if you're online, busy, etc.  I can't be certain an email has actually been delivered yet, let alone seen
[22:14] <ali1234> well, such things are quite hard to do in an anonymous, encrypted way
[22:15] <shauno> why?
[22:16] <shauno> I mean, if you take the linked example - jabber as a hidden service over tor.  each user maintains a connection to the jabber server.  all status ordinarily available over jabber still applies
[22:16] <penguin42> well you could encrypt the responses based on public key and only give people you know an online status
[22:22] <ali1234> because encryption isn't really enough
[22:22] <penguin42> why?
[22:26] <daftykins> got a dead disk in a simple RAID array to sort this week
[22:26] <daftykins> got the report at midnight Friday night that one's popped its' clogs ^_^
[22:26] <penguin42> daftykins: Now the question is will the spare last until you get the new one in?
[22:27] <daftykins> to be honest the storage isn't even used actively now, so it wouldn't even matter if it totally failed
[22:27] <daftykins> warranty's gone too though
[22:27] <penguin42> oh that's ok, in that case it won't fail - only critical things fail viciously
[22:27] <daftykins> and it's a 1.5TB disk which it seems aren't even available anymore :>
[22:27] <daftykins> hahaha
[22:28] <daftykins> yep
[22:28] <daftykins> too true
[22:30] <ali1234> penguin42: because as mentioned, encryption doesn't hide who is talking to who
[22:31] <daftykins> i wonder if, since the forum fiasco, they'll actually honour my request to have my account deleted this time
[22:31] <daftykins> i was told they refuse to delete accounts even if you ask ¬_¬
[22:32] <shauno> hence the addition of tor; you have no idea who 'who' is
[22:32] <penguin42> ali1234: Oh I see, the problem though is that the only way of stopping spam is to be able to know who you're talking to
[22:32] <ali1234> bitmessage uses proof of work to prevent spam
[22:33]  * penguin42 looks
[22:35] <penguin42> ali1234: Hmm that's quite neat
[22:36] <ali1234> tor doesn't provide as much security as most people think. if your connection is monitored, and the chat server connection is monitored, it doesn't really matter what path the packets take in between
[22:36] <ali1234> bitmessage + tor is probably quite effective though
[22:37] <ali1234> since there's no server and everything is broadcast
[22:41] <Azelphur> ali1234: what's your opinion on torchat?
[22:42] <ali1234> never looked at it
[22:42] <Azelphur> I'm thinking that might be good
[22:42] <Azelphur> torchat2 looks particularly cool
[22:42] <Azelphur> I'm on bitmessage now anyway, someone say hello so I can see how it works :) BM-2D94ExvKBzVRiCj81BmXrjC4rhep81jY9g
[22:46] <ali1234> not sure if my client still works
[22:48] <Azelphur> ali1234: http://pastebin.com/PpF5PkTB I did this :)
[22:48] <ali1234> i'm using bashrc's ppa
[22:48] <ali1234> it has indicators
[22:48] <ali1234> oh there we go, it connected
[22:48] <Azelphur> cool
[22:49] <ali1234> tbh i would prefer a command line client like bitcoind
[22:50] <popey> there's an indicator with the python one from github
[22:50] <ali1234> the new version is supposed to support "chans" whatever that means
[22:50] <ali1234> oh cool, maybe he got the patch upstream?
[22:50] <popey> guess so
[22:50] <popey> Azelphur: sent you a test message
[22:50] <Azelphur> cool :)
[22:50] <Azelphur> how long do they typically take to arrive?
[22:51]  * popey shrugs
[22:51] <popey> mine looks like its processing other messages
[22:51] <Azelphur> yea, I'll probably leave mine open 24/7 to help out with processing.
[22:51] <ali1234> a couple of minutes usually
[22:51] <ali1234> the first one can take longer due to ... stuff
[22:51] <Azelphur> stuff \o/
[22:52] <popey> so does it make sense for you to have one identity for establishing contact, publicly known?
[22:52] <popey> and then move to other addresses per person / task?
[22:52] <Azelphur> popey: I think so, since nobody can tell who mail is addressed to.
[22:53] <popey> is it safe to use the first message to "switch channel" to another address mentioned in the reply?
[22:53] <Azelphur> I don't see why not
[22:53] <ali1234> it can be any less safe than just carrying on with the original channel
[22:53] <ali1234> can't*
[22:53] <Azelphur> nobody can do anything without the private keys, I think
[22:55] <Azelphur> bitmessage needs a message received sound, that'd be handy :)
[23:00] <popey> Azelphur: get it yet?
[23:00] <Azelphur> nope :<
[23:00] <daftykins> most secure messaging EVAR
[23:00] <daftykins> nobody knows you did it! not even you
[23:00] <daftykins> ;)
[23:00] <Azelphur> haha
[23:00] <popey> ☻
[23:01] <Azelphur> I have got 10 connections and I'm processing messages like mad
[23:01] <ali1234> it's like bitcoin - you have to catch up
[23:01] <Azelphur> ah
[23:01] <ali1234> also i suspect it got a bit more popular in the past few days
[23:02] <popey> will leave it running overnight i think
[23:02] <ali1234> so first "real" test of the network if you like
[23:02] <Azelphur> ali1234: there's no way to tell when you're caught up it seems though, hehe
[23:02] <popey> yellow blob turns green?
[23:02] <Azelphur> popey: yellow blob is it whining about wanting a port forwarded
[23:02] <popey> ah
[23:04] <ali1234> looks like mine has crashed
[23:08] <popey> mine has stopped processing
[23:08] <ali1234> oh, it finally got azelphur's pubkey
[23:08] <popey> 4713 person to person messages, 505 broadcast messages
[23:08] <Azelphur> ali1234: oh? how'd you know?
[23:09] <ali1234> because it says on the debug log
[23:09] <Azelphur> ah :)
[23:10] <popey> "Message sent: waiting on acknowledgement"
[23:12] <Azelphur> I still got nothin ;)
[23:16] <popey> great tool ☻
[23:17] <penguin42> popey: It's waiting for the NSA to read it first
[23:17] <Azelphur> indeed :P
[23:53] <ali1234> yeah it seems to be crashing while trying to solve the proof of work when sending the message
[23:53] <ali1234> HEAD is probably broken
[23:54] <Azelphur> ali1234: haha, joining #bitmessage too I see :)
[23:54] <Azelphur> I just joined myself to ask about this


[11:00] <daker> mhall119, sorry, i was sick
[11:01] <nigelb> daker: feeling any better?
[11:04] <daker> good ツ
[14:42] <mhall119> daker: glad you're feeling better
[14:42] <daker> thanks
[15:05] <mhall119> daker: would you be able to ready another release of LTP?
[16:12] <daker> mhall119, tonight yes


[11:35] <javahorn> how to test an application in device agnostic manner , i mean to test it on firmware so that it can be established that it will run on all the family of mobile phones of one type ,of one vendor ?
[15:31] <eitreach> Howdy. I'm looking to use Ubuntu Mobile with my asus eee - where can I download the current version?
[15:59] <Random> how does one specify applets to be loaded at desktop startup?
[16:43] <eitreach> Random, how did you install and what did you install on?
[16:44] <Random> i did apt-get install ubuntu-mobile, on a more-or-less normal computer
[16:44] <Random> which, i realize its not quite supported
[16:44] <Random> however, im using this stuff for my carputer, which has a touchscreen
[16:45] <Random> so, the interface is ideal for usage with that
[16:45] <Random> just all the other hardware is pretty much a normal PC
[16:45] <eitreach> random I have very limited space on the eee.. Do you recall how big the install was?
[16:46] <Random> *shrugs* didn't pay attention... i have an 80gb hard drive, so i really haven't paid attention to the space constraints
[16:47] <eitreach> alright. Thanks anyhow. :)
[16:48] <Random> i *think* its one of the options you can select in one of the installers
[16:48] <Random> i've seen that their goal is <= 500MB
[16:48] <eitreach> I haven't been able to find an iso yet.. Just img-files, which I wouldn't know how to use, sadly.
[16:49] <Random> yeah, thats the maddening part... they're specifically targetting handheld phone devices, and not making it easy to use as just another ubuntu install
[16:49] <eitreach> with the umpc-market booming, I hope that'll change soon.
[16:50] <Random> theres a way discussed on the wiki i believe to install into a chroot environment
[16:50] <eitreach> hmm.. I could see that out.
[16:51] <Random> conceivably you could then tar that up and copy to your eee
[16:52] <eitreach> I'm just a regular desktop-user, heh.. It sounds amazingly complicated, sadly.
[16:52] <Random> yeah, its all still very alpha IMHO
[16:53] <eitreach> oh well.. s'pose I'll just use 7.10 on it. It works well anyhow.. just curious to see how it would work. It seems nice.
[16:54] <Random> screenshot: http://www.virtualroadside.com/blog/index.php/2008/04/05/ubuntu-mobile-screenshot-on-my-carputer/
[16:54] <eitreach> sigh.. it looks so nice. Would work well on the small screen, I think.
[16:54] <Random> yes, sadly its not entirely functional :-p
[16:55] <eitreach> that's why I changed from the Xandros-distro shipped with the eee. :p
[16:55] <eitreach> wrecked my system too many times apt-getting ordinary things.
[16:56] <Random> yeah.. of the icons shown on my desktop there... the only ones that actually do anything is the Web Browser, Terminal, Control Panel, and Galculator
[16:56] <Random> lol
[16:56] <Random> the other ones silently die
[16:56] <Random> and i still cant figure out where the hell it decides which icons are displayed on the desktop
[16:56] <eitreach> bah.. wish there were more funds to fund the funding.
[16:57] <eitreach> wonder if Android will be available for installs on umpcs as well.. it could start a pleasant new trend.
[16:57] <Random> indeed
[16:58] <eitreach> not that I don't like regular Ubuntu.. I use it on my main desktop as well - I just like seeing new things.
[16:58] <Random> yeah... heres the chroot thing... it probably works in hardy too: https://wiki.ubuntu.com/MobileAndEmbedded/HildonDesktopManualProcedure
[16:59] <eitreach> I'll try that out should I randomly hop into a manic state of mind. Thanks. :)
[21:01] <ricky_> hi everybody
[21:02] <ricky_> a little question, anyone knows if this porting is possible on a Motorola a1000 ?
[21:46] <solo> i have a 7'' touchscreen and am interested in running ubuntu mobile
[21:46] <solo> where do i stat
[21:46] <solo> start


[00:08] <blahdeblah> And pretty much nobody uses mod_proxy, amirite? :-D
[00:09] <blahdeblah> Actually, looks like it's only forward proxy; that's a bit better.  It's the reverse proxy configurations which would trigger general panic.


[00:37]  * xnox likes Voyager 12.10 - we should totally start calling ubuntu release after the battleships from star trek
[00:50] <mlankhorst> Defiant 13.04!
[00:51] <slangasek> jelmer: hmmmm, do you have plymouth running?
[00:52] <jelmer> slangasek: I had it installed, but I don't think it was running yet
[00:53] <slangasek> jelmer: hmmmm, better questions; do you expect any cryptsetup prompts for non-root filesystems, and if so did you see them?
[00:55] <jelmer> slangasek: yep, I do expect a cryptsetup prompt and I did get one; that was all in 80x25 text mode though. Nothing fancy-looking like I had in Ubuntu.
[00:55] <jelmer> Shouldn't that be the case with plymouth?
[00:56] <slangasek> you got a cryptsetup prompt for a filesystem *other* than the root filesystem?
[00:56] <xnox> jelmer: plymouth in debian default to the "text" plugin, instead of fancy graphics, solar patters and promt boxes.
[00:56] <slangasek> (two different prompting methods, initramfs vs. not)
[00:56] <jelmer> slangasek: Sorry, I have a cryptsetup prompt for lvm
[00:56] <slangasek> jelmer: is your root fs on the vg in question?
[00:56] <jelmer> That LVM contains all my partitions, including the one with /
[00:56] <slangasek> righto
[00:56] <jelmer> Sorry for being unclear.
[00:57] <slangasek> jelmer: workaround: mv /etc/init/cryptdisks-early.conf{,.bak}
[00:57] <jelmer> slangasek: thanks, I'll give that a try and followup
[00:57] <slangasek> I think I reported this bug to dupondje once before
[00:57] <slangasek> possibly only on IRC
[00:58] <slangasek> the problem is that /etc/init.d/cryptdisks-early and /etc/init/cryptdisks-early.conf have the same name but are not the same thing
[01:11] <smoser> hallyn, i have not used hugeadm
[01:56] <achiang> jtaylor: hi, are you on valgrind-devel?
[02:19] <hallyn> smoser: ok, thanks.  i may blog to get opinions on the best way to do waht we want...
[02:56] <infinity> Sweetshark: You around?
[02:57] <infinity> Sweetshark: Can I get you to incorporate the patch from the other libreoffice SRU in the precise queue and reupload (well, once you test that it applies...)
[03:13] <infinity> tjaalton: Your xorg-server SRU to quantal leaves something to be desired. :P
[03:14] <infinity> tjaalton: Could I get you to just re-do -0ubuntu6.1 without the offending patch, instead of the 6.2 that reverts it?
[03:14] <infinity> tjaalton: I'm going to reject all three(!) uploads for now, you can find them in the rejected queue, if you need the source.
[04:42] <pitti> Good morning
[05:31] <tjaalton> infinity: ah, i thought it had to be called 6.2
[05:32] <pitti> cjwatson, ev: thanks for ubiquity's excellent tests/run! I like that it installs all missing build deps, downloads all the embedded source packages etc. by itself
[05:32] <pitti> (it failed its autopkgtests with new pygobject, I'll propose a branch)
[06:07] <pitti> cjwatson, xnox: ubiquity fix sent to https://code.launchpad.net/~pitti/ubiquity/pygobject-fixes/+merge/136327
[06:07] <pitti> I get two test failures (independent from pygobject and the branch), I mentioned those in the MP
[06:10] <infinity> tjaalton: That would be true if the previous one had ever been accepted.
[06:12] <pitti> infinity: darn, eglibc autopkgtest failed again, with a test failure
[06:14] <tjaalton> infinity: right.. I've uploaded 6.1 now, with a fixed changelog
[06:15] <pitti> apparently tst-eintr1 and tst-mqueue5 failed and are not exfail
[06:15] <pitti> migth be VM related?
[06:16] <infinity> pitti: May well be, since they work on the buildds.
[06:16] <infinity> pitti: A lot of those tests are pretty touchy about kernel/hardware/etc.
[06:17] <pitti> at least that's how I interpret https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-eglibc/4/ARCH=amd64,label=albali/console
[06:17] <pitti> (NB that's only the tail of the log; the full log is 57 MB)
[06:18] <infinity> pitti: No, the progressions don't cause a failure.
[06:18] <infinity> The regressions, however, are:
[06:18] <infinity> tst-cancel4.out, Error 1
[06:18] <infinity> tst-cancel5.out, Error 1
[06:18] <infinity> tst-cancelx4.out, Error 1
[06:18] <infinity> tst-cancelx5.out, Error 1
[06:19] <infinity> tst-cpuclock2.out, Error 1
[06:19] <infinity> tst-cputimer1.out, Error 1
[06:19] <infinity> tst-key1.out, Error 1
[06:19] <infinity> tst-key4.out, Error 1
[06:19] <infinity> And almost certainly due to the VM. :/
[06:19] <infinity> Or maybe the raring kernel sucks.
[06:19] <infinity> I just rebooted into it today, I'll have to test.
[06:20] <pitti> *** timer thr2 invoked too soon: 2.903523202 instead of expected 2.903549566
[06:20] <pitti> that's darn close, though
[06:21] <infinity> cpuclock and cputimer are ones I could xfail without feeling too bad about it.  The others, though, I'd like to test on bare metal here and see what's up.
[06:22] <infinity> If I can't reproduce on a raring kernel, I'm at a bit of a loss, mind you.
[06:22] <pitti> infinity: yeah, these might be due to testing in a VM then?
[06:23] <pitti> some jitter in timing tests is rather unavoidable there
[06:23] <infinity> Might be.  We'll have to see.
[06:23] <pitti> I thought that PPA builds would work pretty much the same way?
[06:23] <infinity> Note that even a Panda can grind those tests out fine, though. :P
[06:23] <pitti> do we have eglibc PPA builds?
[06:23] <infinity> The only PPA builds I do are devirt.
[06:24] <pitti> ah, ok
[06:31] <infinity> pitti: Well, let me try that local build now/overnight and see how it ends.
[07:50] <infinity> pitti: Hrm.  So, on a raring kernel on bare metal, I see the cputimer1 regression, but none of the other ones.
[07:50] <infinity> pitti: And adjusting expected failures to suit a VM builder seems wrong.
[07:52] <pitti> infinity: I guess we cannot conditionally exfail them?
[07:52] <pitti> infinity: how much less useful would the rebuild test be if we skip the tests?
[07:52] <pitti> i. e. is it mostly the "it builds" part that you are interested in, or also the tests?
[07:52] <infinity> It would still be useful to know that it builds.
[07:53] <infinity> Knowing if a new toolchain causes a mess of regressions in the testsuite would be nice, but that's also fairly rare and indicative of a pretty large screw up that we'll notice all over.
[07:53] <pitti> it seems it's pretty much the only time when we test the tool chain tests on the actual kernel that it'll be run on
[07:54] <infinity> We could conditionally fail them by shipping a different set of expected results with the test, and having the test copy them in before rebuilding, I guess.
[07:54] <infinity> But maintaining the two sets would be annoying.
[07:54] <pitti> yeah
[07:54] <pitti> I rather thought about exfailing those 5 if DEB_BUILD_PROFILE==autopkgtest or so
[07:55] <pitti> but if it's a text file as opposed to something programmatic, that wouldn't work
[07:59] <infinity> pitti: I can not fail the build on testsuite regressions on that BUILD_PROFILE, at least, so we can complete the build and then look at logs.
[08:00] <infinity> pitti: And perhaps have the test itself re-parse the testsuite output at the end and still exit non-0 on regressions?  It would pretty much always fail, but we'd at least get to complete the package build.
[08:00] <infinity> pitti: Always failed, though, sounds like the sort of red that would just be ignored after a while. :/
[08:01] <pitti> yeah, that wouldn't be very useful
[08:01] <infinity> pitti: Can you waste some cycles and retrigger the test a few times to at least see if the regressions are consistent?
[08:02] <pitti> sure
[08:02] <infinity> pitti: If they are, we can do something like the above, and mangle the testsuite checker to ignore those particular failures or something.
[08:02] <pitti> infinity: we have two runs now (one for -proposed, one for release)
[08:02]  * pitti restarts the -proposed one
[08:03] <pitti> and two arches each
[08:03] <pitti> comparing
[08:03] <dupondje> xnox: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1073649
[08:03] <dupondje> having this every 2 boots :(
[08:03] <dupondje> really *** :P
[08:03] <dholbach> good morning
[08:03] <infinity> Does autopkgtest have any facility for parsing a standard ouput format for pass/fail sets, or does it just assume each test is a single unit?
[08:05] <infinity> pitti: ^
[08:05] <pitti> infinity: http://paste.ubuntu.com/1391100/
[08:06] <pitti> infinity: autopkgtest doesn't do parsing of individual tests results, no
[08:06] <infinity> Okay, that's a reasonably consistent set of regressions.
[08:06] <pitti> just "exit code 0 and stderr == ''", and otherwise attaches the logs
[08:06] <infinity> Basically just the cancel* and key* tests, and sometimes cpuclock/timer.
[08:07] <infinity> Might need to do some digging to see why/how those first two sets are failing.
[08:07] <infinity> The clock/timer stuff, I'm not really concerned about.
[08:07] <pitti> backtrace5 might be i386 only
[08:08] <pitti> the clock/timer ones sound like jitter/race condition
[08:08] <infinity> backtrace5 is already XFAIl anyway.
[08:08] <pitti> infinity: oh, it doesn't say (ignored)?
[08:08] <infinity> If you look at the logs, right under the list you copy/pasted is the list of regressions.
[08:08] <pitti> infinity: anyway, the server that runs autopkgtest sometimes runs 8 VMs in parallel; that will often cause some jitter
[08:08] <infinity> (ignored) is the upstream testsuite ignoring, the next bit is us comparing against our own XFAIL list.
[08:09] <pitti> ah, and then the logs for each failed test
[08:09]  * infinity nods.
[08:12] <infinity> And, actually, I already have cpuclock2 ignored in a few profiles anyway, just not amd64.
[08:12] <infinity> So, I'd be comfy just adding that to every profile.
[08:13] <infinity> But, yeah.  The cancel and key ones are disconcerting.
[08:13] <pitti> infinity: would it be practical to grep -v these tests out of the log in that BUILD_PROFILE before you throw it to the log parser?
[08:13] <infinity> And not reproducible on bare metal.
[08:13] <infinity> pitti: Yeah, something like that could work.  Knowing why those tests fail first would be a requirement, though.
[08:13] <pitti> infinity: so if I were to throw current eglibc into a PPA, we should see the same errors/
[08:13] <pitti> ?
[08:14] <infinity> pitti: Maybe?  Except that the PPAs are hardy dom0 and domU, what's the autopkgtest rig?
[08:14] <pitti> uh
[08:14] <infinity> Obviously a raring domU, at any rate.
[08:15] <pitti> infinity: pretty standard kvm with standard client kernel, i. e. raring for the raring tests
[08:15] <pitti> no xen
[08:15] <infinity> Oh, it's KVM?
[08:15] <infinity> Ew.
[08:15] <infinity> Then no, I bet you won't see this in a PPA. :P
[08:15] <infinity> I can test on my Xen host, but I'm guessing it won't fail the same way at all.
[08:17] <pitti> infinity: so if these are KVM related, and as we primarily want to do a rebuild test, filtering those out seems appropriate to me at least for now
[08:17] <pitti> of course, if they represent an actual problem, our cloud instances would be affected by that
[08:17] <infinity> They're probably KVM-related, yeah.  I'll need to dig a little bit to see for sure.
[08:17] <pitti> but so far these don't seem to be an actual problem
[08:17] <pitti> we are using raring VMs all over the place
[08:17] <infinity> To be fair, most glibc test regressions don't show up as actual real-world problems for any but the most demanding users who like to DoS themselves.
[08:17] <pitti> s/actual problem/obvious problem/
[08:18] <infinity> (Except when something is hideously broken, but the tests that fail when something's hideously broken tend to always pass otherwise)
[08:18] <infinity> But, yeah, to be sure, I want to hunt down WTF those tests are testing.
[08:18] <infinity> They may well be exposing a KVM bug we want to fix.
[09:28] <xnox> @pilot in
[09:28]  * dholbach hugs xnox :)
[09:29] <xnox> dholbach: I am suspecting you have a script running..... ;-) did the topic change?!
[09:29] <dholbach> no
[09:29] <dholbach> and no
[09:29] <xnox> dholbach: ack and ?!
[09:30] <xnox> bug 1
[09:30] <dholbach> tm_T: do you have an idea why the bot did not pick up "@pilot in"?
[09:31] <Tm_T> dholbach: ubottu is gone atm
[09:32] <Tm_T> dholbach: the situation is under investigation
[09:32] <dholbach> thanks a bunch tm_T
[09:32] <Tm_T> np
[09:32] <dholbach> xnox, ^ ubottu is taking some well-deserved holidays :)
[09:33] <xnox> dholbach: we should invest in a marvin model.
[09:34] <dholbach> xnox, reading "here I am, brain the size of a planet..." in my mornings might depress me too much :)
[09:35] <hrw> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676533 - can we merge that in ubuntu while waiting for debian to do that as well?
[09:38] <xnox> hrw: sure, if it applies cleanly.
[09:39] <xnox> tyhicks: see ^ hrw
[09:42] <hrw> it does
[09:44] <xnox> hrw: I am patch piloting right now, and will upload this sometime today. Will that do?
[09:46] <Tm_T> grah, sorry
[09:47] <Tm_T> there ya go
[09:47] <nigelb> Heh, careful there ;-)
[09:49] <Tm_T> nigelb: I'm old and slow, now I need to be careful too?! (;
[09:50] <hrw> xnox: would be lovely
[09:52] <xnox> hrw: run import-bug-from-debian against it, assigned to myself and subscribed you for notifications =)
[09:52] <nigelb> Tm_T: ;)
[09:58] <hrw> xnox: thanks
[10:02] <OdyX> tkamppeter_, pitti: I've pushed two commits to address CVE-2012-5519 in cups to the git repository master branch. It'd be great if you could take a look and eventually upload to raring. I'm very much afraid that this wouldn't qualify to anything near testing/stable/quantal as it implies a configuration files change, etc.
[10:03] <pitti> OdyX: no, indeed; migrating an user-customized conffile over to that new one is going to be hard enough (does that work even?); doing it as a security update is going to be next to impossible
[10:04] <pitti> OdyX: I think for a security update we just want a small patch that temporarily drops privileges to lp or lpadmin when reading files
[10:04] <OdyX> pitti: yes. But that will end up in upstream's 1.6.2 and trunk eventually, so a configuration prompt (over files previously modified through a web interface) doesn't look near to anything easy.
[10:05] <OdyX> pitti: I'm beginning to think some of these could not be turned to be not configurable at all…
[10:05] <pitti> TBH I don't quite see the point of this chane
[10:05] <pitti> change
[10:06] <OdyX> pitti: as I understand upstream: some stuff stays web-configurable, the rest is only config-file configurable.
[10:06] <pitti> yes, but upstream pretty much established the situation that every user will have a modified config file
[10:07] <pitti> so you can't just split it and call that a security fix, because it will not help at all with actually applying that update :(
[10:07] <Sweetsha1k> infinity: you mean I should merge in the patch for bug 585910?
[10:07] <pitti> I guess cupsd will fail if it sees settings which should now be in cups-files.conf, or ignore those
[10:07] <pitti> either breaks existing systems
[10:07] <OdyX> well, it's an upstream massive change that, by magic, happens to fix that.
[10:08] <pitti> for new installs, yes
[10:09] <OdyX> pitti: what do you propose ?
[10:09] <pitti> the apparmor profile should actually take care of the worst stuff
[10:09] <pitti> OdyX: as I said; I think cupsd should temporarily drop privileges when accessing log files
[10:10] <OdyX> pitti: I'm afraid I don't have the skills to implement that.
[10:11] <OdyX> pitti: I'll comment on the Debian bug with pointers to the patch and its implication, if you can chime in that'd be great.
[10:11] <pitti> ok
[10:11] <xnox> slangasek: do we have a user tag for upstart jobs support in debian?
[10:11]  * xnox just came across http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687016
[10:12] <Sweetshark> infinity: for precise that makes sense, but not for quantal. The fix is claimed to be in 3.6.4 and that one will be tagged as a micro release this week: http://wiki.documentfoundation.org/ReleasePlan/3.6#3.6.4_release -- given the time things hangs in the queue, the last thing I want to do is make upload a pre-3.6.4 version for quantal now in addition, just for one fix ...
[11:27]  * xnox did dput instead of sbuild *sigh*
[11:28]  * xnox needs to wrap dput such that it aborts if there is no matching binary .build file.
[11:28] <Laney> use UNRELEASED?
[11:29] <xnox> Laney: I don't like that. I should be building the package that will be uploaded.
[11:29] <ogra_> ++
[11:29] <xnox> & testing.
[11:30] <xnox> also I once saw a package that was parsing the release line in the changelog instead of using dpkg-vendor....
[11:30] <xnox> meh, the package builds fine and works fine, so no damage done.
[11:31] <Laney> by not using it you risk uploading a package you haven't built or tested at all ...
[11:31] <xnox> true.
[11:32] <xnox> pitti: I guess you want ubiquity to be uploaded such that pygobject can be unblocked?
[11:32] <pitti> xnox: it's not super-urgent, but would be nice in the next days
[11:32] <pitti> xnox: but I guess these two test failures need addressing first, or do they not happen for you?
[11:33] <xnox> pitti: already fixed =) together with pep8/pyflakes warnings from your changes
[11:33] <xnox> pitti: how do I setup jenkins to run tests on every commit for lp:ubiquity?
[11:34] <pitti> ubiquity/frontend/gtk_ui.py:471: redefinition of unused 'GLib' from line 52
[11:34] <pitti> ah, sorry about that
[11:34] <pitti> xnox: thanks for pointing out, will run these next time
[11:34] <xnox> pitti: and are there other packages left to fix with new pygobject?
[11:34] <pitti> xnox: I fixed dbusmock, the rest succeeded
[11:34] <xnox> pitti: also pep8 in raring complains about "over-identation"
[11:34] <xnox> pitti: I'll upload then.
[11:35] <pitti> xnox: indeed, the s/GObject/GLib/ of course didn't adjust the continuation lines
[11:36] <pitti> xnox: as for jenkins, I'm not sure; I think you should talk to didrocks or jibel, who set up the equivalent of that for unity
[11:36] <xnox> pitti: thanks a lot for your fixes. As you can see we don't follow gtk developments that close ;-) we are just started to transition things here and there for width-for-height widgets.
[11:36] <xnox> pitti: ack.
[11:37] <pitti> xnox: no worries; I broke it, I fix it :)
[11:37] <pitti> xnox: oh, aptdaemon was another victim, but I fixed that yesterday
[11:37] <pitti> it's great to be able to hold this back in -proposed and run all the autopkgtest stuff against that without breaking the distro
[11:42] <xnox> pitti: rock star ;-)
[11:43] <OdyX> pitti: there, sent more info to the bug.
[12:33] <hrw> someone know how to tell modem-manager to not touch serial ports at all?
[12:44] <seb128> slangasek, bdmurray, infinity, ScottK, SpamapS: is there any way somebody could SRU review http://launchpadlibrarian.net/123208124/gnome-settings-daemon_3.4.2-0ubuntu0.6_source.changes this week? it's a annoying issue in the LTS and it would be good to get the fix in and some other g-s-d fixes are lining up for after this one so it would be good to get that one in to create room for the next one
[12:54] <mlankhorst> mvo: poke, I posted a question on #debian-apt a few days ago, enver got an answer :P
[12:54] <mlankhorst> s/env/nev/
[12:57] <xnox> pitti: in raring, in sbuild/schroot "from gi.repository import Gtk" fails
[12:58] <pitti> xnox: any error message?
[12:58] <xnox> http://paste.ubuntu.com/1391594/
[12:58] <pitti> xnox: needs xvfb-run?
[12:59] <pitti> this is nothing new, Gtk and the old pygtk have always needed a $DISPLAY
[13:00] <xnox> pitti: well something changed in ubiquity dependencies then. Previously I just ran sbuild on ubiquity and the test-suite would run and succeed, now it didn't for me.
[13:00] <xnox> or something change in the minimal install / chroot.
[13:01] <pitti> ./tests/run:    os.execvp('xvfb-run', argv)
[13:01] <pitti> it seems to try at least
[13:01] <xnox> hmm...
[13:02] <xnox> ok, running python3 under xvfb-run does import Gtk just fine.
[13:02]  * xnox goes looking into ubiquity test-suite
[13:02] <pitti> xvfb-run python3 -c 'from gi.repository import Gtk'
[13:02] <pitti> does that work?
[13:02] <xnox> yeap.
[13:02] <pitti> (in schroot)
[13:02] <xnox> yes.
[13:31] <mdeslaur> pitti: FYI, I plan on simply disabling being able to modify cupsd.conf via the web interface...there a _way_ too many options in there that are dangerous
[13:31] <pitti> mdeslaur: but doesn't use it the same auth mechanism as "lpadmin"?
[13:31] <pitti> mdeslaur: you can hardly disallow lpadmin and the command line tools
[13:32] <pitti> mdeslaur: I had actually assumed that the AA profile would prevent the worst of it, like reading /etc/shadow
[13:32] <pitti> hm, but I guess cupsd needs that
[13:32] <mdeslaur> pitti: well, /etc/shadow is allowed by the apparmor profile, unfortunately :)
[13:32] <mdeslaur> pitti: what do you mean disallow lpadmin?
[13:32] <pitti> mdeslaur: I thought the point was that lpadmin group users could change the conffile, and by that read files as root
[13:33] <pitti> mdeslaur: i. e. everyone who can read the auth cookie in /var/run/cups/certs/
[13:33] <mdeslaur> pitti: yes, but only via the web interface, as by default cupsd.conf is owned by root
[13:33] <mdeslaur> pitti: they can change a whole bunch of configuration options in that file, including the default directories, etc.
[13:33] <pitti> ah, you can't set arbitrary options through lpadmin
[13:34] <pitti> ok, seems fine
[13:35] <mdeslaur> no, it's only a web interface issue...and I can't think of a really good reason why editing cupsd.conf is absolutely necessary there
[13:35] <mdeslaur> the upstream change is _way_ too intrusive as a security update, as you said earlier
[13:35] <didrocks> cjwatson: hey, not sure if that's a problem in more regular time where we don't have multiple uploads of libreoffice/webkit/gcc at the same time and more powerpc builders, but the ppa https://launchpad.net/~ubuntu-unity/+archive/daily-build has the "release" priority score (so 1500) and all the rest landing in distro has the "-proposed" one (3000). The net result is that
[13:35] <doko> infinity, https://launchpadlibrarian.net/124204285/buildlog_ubuntu-raring-armhf.gcc-4.7_4.7.2-12ubuntu1_FAILEDTOBUILD.txt.gz
[13:35] <didrocks> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4014568 is waiting for 11h and counting (a lot more as gcc will be built next…)
[13:35] <pitti> mdeslaur: yeah; we don't even have a way of migrating the config files
[13:36] <mdeslaur> pitti: yeah, that's going to be a pain for new versions :(
[13:36] <cjwatson> didrocks: It probably isn't a problem normally; I've scored it up for now
[13:37] <didrocks> cjwatson: thanks
[13:37] <OdyX> mdeslaur: disabling web-edit is probably the safest course of action for security upgrades indeed.
[13:37] <OdyX> jonas had a patch for that on the debian bug.
[13:38] <mdeslaur> OdyX: yeah, that's what I plan on doing...ie: http://paste.ubuntu.com/1391676/
[13:38] <OdyX> btw, if the next cups ubuntu upload could be based on the git repository, it'd be great to get changes in there tested.
[13:38] <mdeslaur> OdyX: ah, I am going to hide the option completely
[13:39] <OdyX> mdeslaur: looks intrusive but I don't have a better option. Could you comment with that patch on the bug, cc'ing debian security team ?
[13:39] <mdeslaur> OdyX: sure, let me test it properly first though
[13:40] <OdyX> mdeslaur: cool, thanks.
[13:48] <SpamapS> hrm, did something change in Debian experimental where there's a new way to build non-native packages without a .orig tarball? PHP5 has just a .tar.gz with the whole source in it.
[13:49] <SpamapS> which really confuses the package importer
[13:49] <OdyX> SpamapS: php5/experimental looks like it's a broken upload
[13:50] <OdyX> SpamapS: it's native where it shouldn't (at all)
[13:50] <Laney> Format: 1.0
[13:50] <OdyX> even then: see the .changes file: php5_5.4.8-1.tar.gz
[13:51]  * OdyX reports a bug.
[13:52] <SpamapS> OdyX: thanks
[13:52] <SpamapS> thought for a second I was losing my mind
[13:53] <SpamapS> Its worth noting that 5.4.9 is out, so perhaps the right thing is just to build 5.4.9's upload properly
[13:55] <OdyX> SpamapS: making the maintainer aware can help that :)
[14:00] <seb128> doko, infinity: hey, could one of you look at the patch on https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1079768 (from the sponsoring queue)?
[14:01] <seb128> no bot?
[14:01] <seb128> bug title is " FTBFS with glibc-2.16 (due to outdated gnulib) "
[14:04] <seb128> pitti, can you mark https://code.launchpad.net/~kampka/ubuntu/quantal/fwknop/upstart-support/+merge/124683 merged (it got uploaded to raring but was targetting the wrong serie)
[14:04] <pitti> seb128: done
[14:04] <seb128> pitti, danke, same for https://code.launchpad.net/~wb-munzinger/ubuntu/precise/havp/fix-init-script/+merge/125949 ?
[14:05] <pitti> done
[14:05] <seb128> pitti, danke ;-)
[14:05] <pitti> de rien
[14:05] <seb128> pitti, reject https://code.launchpad.net/~bkerensa/ubuntu/quantal/kubuntu-docs/fix-for-1049278/+merge/125965 ?
[14:05] <seb128> pitti, sorry to bother you with those, hate launchpad acls...
[14:05]  * seb128 is cleaning a bit the sponsoring queue
[14:05] <pitti> seb128: pas de problem, just ask
[14:05] <pitti> seb128: it's great to clean the queue
[14:05] <arges> cjwatson, hello. looking at bug 1075181 regarding uefi secureboot for 12.04.2. Are there images available already to test and verify some of these packages?
[14:06] <seb128> pitti, ;-)
[14:09] <seb128> pitti, https://code.launchpad.net/~nicolozilio/ubuntu/precise/software-center/fix-for-842706/+merge/127102 ... work in progress or rejected (cf mvo comment which says it's targetting the wrong vcs and has some "to fix")
[14:10] <pitti> seb128: you can do WIP yourself
[14:10] <seb128> pitti, not on a stable serie no
[14:10] <seb128> pitti, I don't even have edit mode for the status on that one
[14:11] <seb128> like the small yellow pen icon
[14:11] <seb128> it's not displayed next to the status...
[14:11] <pitti> seb128: lequel, WIP où rej?
[14:11] <seb128> pitti, reject I guess
[14:11] <seb128> since that's the wrong vcs
[14:11] <pitti> done
[14:11] <seb128> danke
[14:29] <tkamppeter> pitti, OdyX, I have looked into the GIT repo of CUPS and I see that on Oct 30 OdyX has removed my pstops-based-workflow-only-for-printing-ps-on-a-ps-printer.patch as it breaks tests. Is there no way to modify the tests?
[14:30] <OdyX> tkamppeter: I didn't find. If you enable that patch, the tests fail and I couldn't understand why.
[14:31] <OdyX> tkamppeter: see also https://www.cups.org/str.php?L4220 and https://launchpad.net/~odyx/+archive/printing/+packages results
[14:32] <OdyX> tkamppeter: also, I'm testing the introduction of ucf to handle /etc/cups/cupsd.conf with the extensive upstream patch
[14:43] <seb128> mdeslaur, do we need to keep security-sponsors subscribed to https://bugs.launchpad.net/ubuntu/+source/request-tracker3.8/+bug/1004834 ?
[14:43] <mdeslaur> seb128: no, thanks I removed it
[14:43] <seb128> mdeslaur, it's on the sponsoring queue but it doesn't seem there is a lot to be acted on
[14:43] <seb128> mdeslaur, thanks
[14:44] <mdeslaur> seb128: no...in fact, I'll release them now
[14:44] <seb128> cool
[14:45] <mdeslaur> seb128: thanks
[14:53] <diwic> pitti, is the SRU queue still weeks long? I uploaded an SRU for PulseAudio (on 12.04) a while ago but nothing has happened since.
[14:53] <pitti> yes, https://launchpad.net/ubuntu/quantal/+queue?queue_state=1 is quite long
[14:53] <pitti> https://launchpad.net/ubuntu/precise/+queue?queue_state=1 too
[14:55] <diwic> ok
[14:56] <diwic> pulseaudio is not in that list though, so maybe something else went wrong?
[14:57] <diwic> pitti, and it can't have gone through to proposed without me noticing, because then it would have shown up in https://launchpad.net/ubuntu/+source/pulseaudio I believe
[14:58] <pitti> diwic: usually the SRU reviewers should leave a comment in the bug if they reject a package
[14:58] <pitti> diwic: which release did you upload it to?
[14:58] <diwic> 12.04
[14:58] <pitti> diwic: on the +queue page you can look at the rejected queue and check if it's there
[14:59] <diwic> nope, not there either
[15:03] <pitti> hm, then it seems it wasn't actually uploaded?
[15:04] <ogra-cb> or accidentially uploaded to a PPA
[15:05] <diwic> pitti, maybe I did something else wrong...I'll check in a while
[15:07] <barry> didrocks, mvo do either of you have time for a quick review of https://code.launchpad.net/~barry/piston-mini-client/lp1077083/+merge/135449 ?
[15:07] <barry> didrocks, mvo or should i jfdi? :)
[15:08] <didrocks> barry: TBH, you are the most knowledgeable on that than I can ever do, wait on mvo's answer or maybe Anthony's? :)
[15:08] <seb128> pitti, https://code.launchpad.net/~felix-lawrence/ubuntu/quantal/ubuntu-mono/fix-for-748861/+merge/129859 <- can you set to "merged"?
[15:08] <pitti> done
[15:09] <seb128> danke
[15:09] <dholbach> Is anyone interested in the ubuntu development hangout (on air) at 16 UTC and talk about the projects you're working on?
[15:09] <dholbach> (in 50m)
[15:10] <ogra-cb> mvo, could it be that your app-install-data-ubuntu upload from today reverts cjwatson's bugfix from yesterday ? i see strange image build failures re-occuring that were caused by it
[15:10] <seb128> ogra-cb, mvo: let me have a look
[15:10] <barry> didrocks: cool.  if the diff doesn't look insane and achuni or mvo don't respond i may just go for it :)  (i still want to upload tox first so i can enable the tests)
[15:11] <barry> didrocks: then i'll enable the py3 version of the library
[15:11] <mvo> ogra-cb: it was spout, it should be ok
[15:11] <didrocks> sweet \o/
[15:11] <ogra-cb> mvo, hmm
[15:11] <seb128> mvo, ?
[15:12] <mvo> barry: I tear my hairs out over a crash in python with glib and threading right now, once I finished that I can check the diff out
[15:12] <mvo> ogra-cb: do you have a log of the error?
[15:12] <seb128> ogra-cb, mvo: the fix is not reverted according to the debdiff: http://launchpadlibrarian.net/124162411/app-install-data-ubuntu_<IP_ADDRESS>_13.04.diff.gz
[15:12] <barry> mvo: :(  ping me if i can help
[15:13] <mvo> seb128: sorry, the context is that "spout:spout.desktop" was incorrect but it should be good, just verified in my branch
[15:13] <ogra-cb> mvo, http://paste.ubuntu.com/1391846/
[15:14] <seb128> ogra-cb, mvo: the issue is /usr/share/app-install/desktop/gmpc:gmpc.desktop
[15:14] <seb128> "Name=Gnome Music Player Client
[15:14] <seb128> de música del GNOME
[15:15] <seb128> "
[15:15] <ogra-cb> mvo, this is teh same error all image builds had yesterday .... i did two image builds today, the first one worked fine, the log is from the second one (after app-install-data-ubuntu was promioted i guess)
[15:15] <seb128> ogra-cb, mvo: that's invalid
[15:15] <ogra-cb> aha
[15:15] <ogra-cb> new issue, same symptoms then
[15:15] <ogra-cb> fun
[15:15] <seb128> we really need an autopkgtest on app-install-data-ubuntu
[15:15] <seb128> which checks the included .desktops validity through the pyxdg parser on build
[15:16] <ogra-cb> ++
[15:16] <mvo> barry: maybe, I think I simply need to not use threading there at all, it breaks in different way with glib and python :/ I can either have it crash with "Fatal Python error: PyThreadState_Get: no current thread
[15:16] <mvo> " when deallocing some random pkg or it appears to be simply super slow. anyway, that is not helpful I keep digging until I either have a testcase or something useful
[15:16] <mvo> seb128: aha, fun :/
[15:16] <seb128> mvo, I can fix that .desktop and reupload if you want (there is also a trivial merge request for it on the sponsoring queue to add misc:Depends)
[15:17] <mvo> seb128: I can create a verification step during the extraction that deletes the ones that are broken
[15:17] <mvo> seb128: the depends thing is merged, thanks :)
[15:17] <seb128> mvo, oh, great, danke
[15:17] <seb128> mvo, verification step sounds like manual work, we should just have an autopkgtest for it ;-)
[15:18] <seb128> mvo, want to do the upload if you have a checkout ready?
[15:18] <mvo> seb128: as part of the automatic update :) not manal, no
[15:18] <mvo> seb128: sure, I can do that
[15:18] <seb128> mvo, thanks
[15:18] <mvo> seb128: a good excuse to stop looking at this thread bug that makes me really unhappy
[15:18] <seb128> mvo, gmpc.desktop Name's being on 2 lines is the only issue
[15:19] <seb128> mvo, ogra-cb: I checked, once that fixed xapian is happy again
[15:19]  * ogra-cb hugs seb128
[15:19] <ogra-cb> thanks !!
[15:19]  * seb128 hugs ogra-cb back
[15:22] <sconklin> @pilot-in
[15:23] <sconklin> @pilot in
[15:24] <didrocks> sconklin: issue to enter the cockpit? :)
[15:24] <seb128> sconklin, I think the bot is on holidays on something
[15:24] <seb128> dholbach, ^
[15:25] <sconklin> whetever. I don't need a bot in order to get my work done anyway
[15:25] <dholbach> sconklin, didrocks, seb128: yes, tm_T said that ubottu is gone and it's under investigation
[15:25] <bdrung> sabdfl: https://overbenny.wordpress.com/2012/11/27/code-name-for-ubuntu-18-04-lts/
[15:25] <vibhav> does "debuild -S -sa" also need the build-depends to be installed?
[15:25] <jpds> vibhav: Yes.
[15:26] <vibhav> jpds: any way to skip that?
[15:26] <jpds> vibhav: Well, you might need things like cdbs installed.
[15:26] <Laney> I don't think it does, but it does run the clean target
[15:26] <seb128> yeah, you don't need build-depends to build the source
[15:26] <Laney> so whatever you need to execute that, unless you skip it (with -nc)
[15:26] <ogra-cb> heh
[15:27] <Laney> which risks having a dirty source package, so check the diff
[15:27] <ogra-cb> for like 70% of the packages
[15:27] <vibhav> Laney: yes, that was the argument I was talking about
[15:27] <ogra-cb> the other 30 do evil stuff in the clean target
[15:27] <Laney> yep
[15:28] <Laney> for example control.in → control mangling might happen then
[15:28] <Laney> so, beware
[15:28] <xnox> vibhav: currently there is no way to encode which build-depends are needed for clean target only vs a full build. So if you decide to skip any of them, you may get failures to create source package or force missgenerated source package.
[15:29] <vibhav> Well, lets hope that none of that happens
[15:30] <ogra-cb> i would consider it a bug if the build doesnt fail then though
[15:30] <xnox> pitti: it may have been transient, as now they all pass. Weird.
[15:30] <xnox> (ubiquity test-suite failing in sbuild)
[15:31] <mvo> seb128: test as part of the extraction added
[15:31] <seb128> mvo, you rock ;-)
[15:32] <ogra-cb> wow
[15:32]  * ogra-cb bows in front of mvo
[15:34] <seb128> ogra-cb, mvo: note that http://anonscm.debian.org/gitweb/?p=collab-maint/apt-xapian-index.git;a=commitdiff;h=cefa7e5eed2ed0336aaf1fc183cc10faf119b5eb as well
[15:34] <seb128> ogra-cb, mvo: that's a fix in the debian git for apt-xapian-index to continue rather than bailing out on parsing errors
[15:34] <mvo> meat
[15:34] <mvo> eh
[15:34] <mvo> neat
[15:35] <Laney> mmm meat
[15:35] <mvo> (what a lousy vegetarian I am!)
[15:35] <seb128> mvo, note also that we are one version behind debian for apt-xapian-index... if you feel like merging at some point ;-)
[15:35] <ogra-cb> yummy
[15:35] <seb128> lol
[15:36] <OdyX> tkamppeter, pitti : I have now pushed a move to ucf including making the upgrade smoother. The preinst probably has to be amended for the Ubuntu versions but I think the rough idea is there, wdyt ?
[15:41] <vibhav> hmm, its seems to build now
[15:42] <vibhav> Laney: How does -nc result in unclean source packages?
[15:43] <Laney> think about what could happen if you don't clean your tree
[15:45] <GunnarHj> cjwatson: Are you there?
[15:51] <cjwatson> arges: http://cdimage.ubuntu.com/precise/daily-live/ - but I don't think it has a signed kernel in place yet
[15:52] <arges> cjwatson, ok I'll ask apw when those will land
[15:53] <cjwatson> arges: The signed kernel is in precise-proposed but it needs a couple of packaging fixes which apw knows about
[15:53] <cjwatson> GunnarHj: slightly
[15:53] <mvo> pitti: is there a knonw segfaul threading fix in python-gi from 3.4.0 to 3.4.2? I get a segfault here for the reviews helper in quanal but it works fine in raring. If you don't know right away, no worries, I can start digging
[15:53] <mvo> pitti: I would like to backport that fix (if there is one :)
[15:53] <arges> thanks
[15:54] <GunnarHj> cjwatson: Wanted to mentioned that I failed to install from the desktop ISO (i386) this morning. It hanged at the point when it asks you to select a picture, and didn't complete the installation. Tried twice.
[15:55] <GunnarHj> cjwatson: daily build
[15:56] <apw> cjwatson, i believe you needed the meta packages made (should be out in -proposed) and Provides: linux-image which i want to slip in once this -propsoed kernel makes it out
[15:56] <apw> cjwatson, was there anything else i've forgotten
[15:57] <cjwatson> xnox,stgraber: ^- could you look at GunnarHj's problem?  I'm about to be on a call
[15:57] <cjwatson> apw: Right, those two
[15:57] <cjwatson> apw: The metapackage should've been sufficient to make this work - when did that lalnd?
[15:58] <cjwatson> hmm, Friday
[15:58] <apw> cjwatson, i thought they hit -proposed like friday
[15:58] <cjwatson> something else wrong then
[15:58]  * apw checks
[15:58] <stgraber> GunnarHj: can you try removing /usr/lib/ubiquity/plugins/ubi-webcam.py, see if that helps?
[15:59] <xnox> GunnarHj: stgraber: there is also a command line option to disable webcam. I believe Laney was working on porting ubiquity to the new gst api?!
[15:59] <GunnarHj> stgraber: Sure, can do that. But not right now; will try your suggestion later.
[16:00] <xnox> GunnarHj: --no-webcam as commandline flag (launch ubiquity from terminal from live session)
[16:00] <cjwatson> apw: Ah, wrong seeds, my bad
[16:00] <stgraber> xnox: yeah, Laney was doing some work on that, I don't think any of it landed yet, so my guess is that whatever commit I pulled out of gstreamer in precise to fix the hang was re-introduced
[16:00] <Laney> yes but that's not relevant to this problem
[16:00] <apw> cjwatson, yay (sort of :)
[16:00] <xnox> GunnarHj: or UBIQUITY_NO_WEBCAM=1 as bootarg.
[16:00] <apw> cjwatson, the Provides: just makes the CD too big right?
[16:01] <xnox> GunnarHj: did you select the picture & managed to click next and then it hang? or before?
[16:01]  * xnox wonders if it's the webcam hagging or something after that step.
[16:01] <cjwatson> apw: Yeah
[16:01] <GunnarHj> xnox, stgraber: Do you (xnox) with the latter mean an env. var? It hanged before.
[16:01] <cjwatson> apw: Or at least was the most immediate cause of that - I tend to find out about such problems in series
[16:02] <cjwatson> arges: OK, think I've fixed that, tomorrow's build *should* have the signed kernel
[16:02] <arges> cjwatson, great!
[16:02] <apw> cjwatson, ok hopefully i can get that change in fairly soon, we are nearly ready to release whats there
[16:07] <mvo> barry: just reviewed the branch if you don't mind I will merge and upload?
[16:07] <barry> mvo: that would be fantastic.  once that lands i will work on enabling the py3 version of the package
[16:09] <slangasek> xnox: user tag> no
[16:11] <xnox> GunnarHj: environment variable, command line flag or moving ubi-webcam.py out of the way should skip the webcam page. Then we will at least know if the installer is borked in the webcam page or somewhere else.
[16:11] <GunnarHj> xnox: Ok, I'll try it later and let you know.
[16:11] <pitti> mvo: we have a lot of fixes in 3.4.x, but not a specifically threading one (http://git.gnome.org/browse/pygobject/log/?h=pygobject-3-4)
[16:12] <pitti> mvo: can you reproduce this easily? then bisecting might be easiest
[16:12] <pitti> mvo: sure that it's in pygi, and not in glib?
[16:12] <xnox> slangasek: do we need one, or shall we it more gradually?
[16:12] <xnox> slangasek: maybe we can use dholbach's army of contributors here =) to find and forward upstart jobs to debian.
[16:13] <mvo> pitti: could be glib too, but its crashin in "#0  subtype_dealloc.25740 (self=
[16:13] <mvo> " ... #13 pygi_callable_info_invoke (info=0x16e3850, py_args=<optimized out>, kwargs=
[16:14] <pitti> mvo: need to leave for today; if you can reproduce it, please open a LP bug and subscribe me, then I'll have a look tomorrow morning
[16:14] <mvo> pitti: thanks
[16:14] <mvo> pitti: will do
[16:16] <slangasek> xnox: at this point, it should be part of standard Debian merge & upstreaming responsibilitie
[16:16] <slangasek> s
[16:16] <xnox> ack.
[16:17] <xnox> slangasek: but the boot process is the same as in ubuntu or different? e.g. does mountall & udev handle it, or do we have a divergence there for now.
[16:17] <slangasek> xnox: it's mountall+udev+ifupdown the same as in Ubuntu
[16:17] <xnox> cool.
[16:17] <slangasek> Debian *also* has startpar, which is an interesting wrinkle
[16:18] <slangasek> it has consequences for how you name your upstart jobs vs. init scripts, to make sure startpar doesn't try to do double duty
[16:19] <xnox> *shrug* ok.
[16:19] <slangasek> and to make sure you don't deadlock your boot because startpar is waiting for an upstart event that won't happen
[16:20] <slangasek> for instance, we're close to being able to sync cryptsetup in Debian+Ubuntu now; but I probably need to get startpar working in raring first before we can be completely synced
[16:22] <xnox> slangasek: intersting. but currently cryptsetup in ubuntu uses both upstart and initscripts (boot and shutdown respectively)
[16:23] <xnox> and I don't quite see how that can be currently resolved. Unless it already has been in Debian.
[16:24] <xnox> @pilot out
[16:25] <seb128> xnox, sorry you don't get to bail out of piloting today, not bot to allow that ;-)
[16:25]  * xnox please somebody remove me from the topic, as the bot is currently away from keyboard.
[16:25] <mvo> barry: lp:~software-store-developers/piston-mini-client/packaging has my updated version with py2 and py3 if you could do a quick double check that would be cool. I think its good but I am a bit worried about the amount of boilerplate I had to add to debian/rules :/
[16:25] <seb128> xnox, that's dholbach's secret plan to deal with the sponsoring queue backlog
[16:25] <xnox> seb128: well it's not like it's the first time somebody was left "piloting" for days =)))))
[16:25] <Laney> xnox:  you can do it yourself
[16:26] <xnox> ogra-cb: thanks.
[16:26] <xnox> Laney: as far as I know, I am a mere mortal w.r.t. channel access rights. Note the bot is absent.
[16:26] <barry> mvo: cool, i'll take a look after lunch
[16:26] <mvo> barry: great, thanks
[16:26] <Laney> the topic isn't locked
[16:27] <xnox> Laney: cool. Thanks for letting me troll^W know
[16:27] <xnox> ;-)
[16:27] <Laney> (see how the channel mode doesn't have +t)
[16:28]  * xnox is confused with my irc client
[16:29] <barry> xnox: C-c C-t :)
[16:30] <xnox> barry: i used to use erc, but not anymore. It used to become sluggish for me after a few days of idling & no messaging menu integration, unless that has changed.
[16:33] <mitya57> hey arges, I want to ask you about https://launchpad.net/ubuntu/+source/sphinx/1.1.3+dfsg-4ubuntu2
[16:34] <mitya57> (1) is that still actual or can it be dropped? (2) why doesn't that ftbfs happen in debian?
[16:35] <arges> mitya57, hi
[16:35] <mitya57> o/
[16:38] <arges> mitya57, i'm not sure why it doesn't happen in debian. i just saw the ftbfs in ubuntu and fixed it. it was a really weird issue where the xvfb-run will not work the first time it is run, and works fine the next time it is run
[16:38] <xnox> arges: !!!! thank you.
[16:39]  * xnox had all sorts of weird stuff going on with xvfb-run & ubiquity test suite
[16:42] <tkamppeter> OdyX, according to the log the CUPS tests fail due to job control files not being purged (FAIL: 8 job control files were not purged.). I am wondering why changes in the filter chain prevent CUPS from purging job control files. Seems to be a bug in CUPS.
[16:43] <mitya57> arges, so it's a heisenbug, will keep the change :)
[16:43] <mitya57> thanks
[16:43] <OdyX> tkamppeter: that's another problem, see the upstream bugreport.
[16:43] <arges> mitya57, yea I think that's the best way to describe it. np
[16:44] <OdyX> tkamppeter: for both I suspect a problem with libcupsfilters
[16:55] <mvo> pitti: hm, hm, 3.4.2 does not build on quantal, oh well (needs newer gobject-introspection-1.0)
[17:16] <seb128> stgraber, hey, can you mark https://code.launchpad.net/~sonia/ubuntu/quantal/vim-scripts/fix-for-31204/+merge/126966 as merged?
[17:16] <seb128> xnox uploaded to raring but the merge request is against quantal
[17:17] <mvo> pitti: found the crash, https://bugzilla.gnome.org/show_bug.cgi?id=688067 - will prepare a SRU tomorrow
[17:17] <xnox> seb128: darn, thought I included all the correct links with "actions todo" in the report.
[17:17] <xnox> seb128: thanks for spotting.
[17:17] <seb128> xnox, yw ;-)
[17:22] <arges> hallyn, hello. looking at libvirt bug 1055658, i noticed the fix is in -proposed and it is verified, when will it land in -updates? thanks
[17:24] <seb128> who is the right person to talk to about qemu-linaro and getting qemu-kvm-spice built on i386?
[17:24] <seb128> hallyn, slangasek, ...:  ^ ? ;-)
[17:35] <stgraber> seb128: done
[17:38] <seb128> stgraber, thanks
[17:40] <seb128> stgraber, can you set https://code.launchpad.net/~sometimesfood/ubuntu/precise/libvdpau/libvdpau.fix-967091/+merge/130999 as merged?
[17:41] <stgraber> sure, done
[17:42] <vibhav> Arges:yes, once the fix is verified, your package will land in - updates
[17:43] <seb128> stgraber, thanks
[17:44] <cjwatson> arges: It's waiting for bug 1027987 also to be verified
[17:44] <seb128> doko, did you ever forward http://launchpadlibrarian.net/78456781/gcc-h8300-hms_1%3A3.4.6-6_1%3A3.4.6-6ubuntu1.diff.gz to debian? I don't find it in the BTS
[17:49] <micahg> vibhav: there's a 7 day bake time as well for most packages still
[17:50] <vibhav> michag: bake time for verified packages, right?
[17:50] <micahg> vibhav: no, total
[17:51] <vibhav> Ah
[17:51] <vibhav> arges: ^^^^
[17:52] <arges> vibhav, cjohnston thanks
[17:52] <arges> cjwatson i mean
[17:54] <slangasek> seb128: hallyn :)
[17:54] <seb128> slangasek, thanks ;-)
[18:00] <seb128> ScottK, barry: is https://code.launchpad.net/~mitya57/ubuntu/raring/python-defaults/resync/+merge/131193 still on your review list? it's in the sponsoring queue for a while...
[18:03] <seb128> stgraber, can you set https://code.launchpad.net/~bjaanes/ubuntu/quantal/lybniz/invalid-function-fix/+merge/131254 to "work in progress" (or "rejected"), it needs fixes and it's targetting the wrong seie
[18:04] <stgraber> seb128: done
[18:04] <seb128> stgraber, thanks
[18:57] <jtaylor> are packages with adt tests automatically added to jenkins.qa?
[18:59] <Tm_T> bug #1
[18:59] <Tm_T> temporary solution ^
[19:00] <cjwatson> huh?
[19:01] <hallyn> seb128: AIUI spice server can't build on 32-bit, right?
[19:03] <hallyn> arges: if you can verify that other bug, that'd be awesome.  I couldn't reproduce the origianl bug in a VM, haven't had a chance to try on real hardwrae
[19:03] <hallyn> (the other bug being 1027987)
[19:33] <arges> hallyn, ok i'll give it a shot if i have some time
[19:34] <barry> seb128: sorry, i will look at that again
[19:34] <barry> xnox: erc in emacs24 seems pretty responsive so far
[19:48] <seb128> barry, hey, no worry, thanks
[19:49] <seb128> hallyn, the gnome-boxes maintainer (who works for redhat) told me before quantal that recent spice is supposed to work on i386
[19:49] <seb128> hallyn, other distros (including debian) seem to manage that fine, not sure what is special about our linaro version
[19:56] <seb128> hallyn, http://git.qemu.org/?p=qemu.git;a=commit;h=a13ccc991a852cf12f2c05f537c40ce239ae464f
[19:56] <seb128> "This fixes running "-vga qxl -spice" with 32 bit compiled qemu-system-i386."
[19:56] <seb128> hallyn, that's pointed from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640139 which states "0.10 version of spice-server actually fixed 32bit issues too."
[19:59] <hallyn> seb128: excellent.
[20:00] <seb128> hallyn, confirmed on http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04953.html it seems
[20:01] <seb128> hallyn, so, how do we move forward on enabling spice on 32bits in raring? ;-)
[20:01] <seb128> hallyn, I can help testing if needed (in fact I would like to be able to try gnome-boxes which depends on it which is why I'm asking about it)
[20:08] <hallyn> seb128: not sure, i'll take a look at the packaging after i finish lunch and testing this  libvirt bit.
[20:08] <hallyn> assume its one change in debian/control
[20:10] <seb128> hallyn, thanks, let me know how it goes or if I can help on something
[20:16] <GunnarHj> xnox, stgraber, cjwatson: I made a couple of attempts to enter a live session in order to start ubiquity from there without the webcam, but I never made it into the live session. One time the desktop just froze, and two times I ended up on the greeter (without knowing any username/password combination). So the current ISOs seem not to be very healthy. Gave up. :(
[20:22] <darkxst> Sarvatt, are you able to merge this? https://code.launchpad.net/~darkxst/ppa-purge/multiarch-lp892886
[20:50] <stokachu> xnonx, apw: would either of you have time to sru bug 932860
[20:55] <stokachu> also need to have bug 1077095 sru'd
[21:47] <hallyn> seb128: fwiw i've pushed a test pkg to ppa:serge-hallyn/virt (qemu-linaro), but it may be sitting waiting to build for awhile...  but it *should* build 32-bit.  hopefully the upstream fix really was a fix :)
[21:48] <israeldahl_> Hi, I need some assistance in uploading  a new version of a program that is already in USC.  How can I do this without Debian having a new upstream package (there maintainer is non-existant)
[21:49] <seb128> hallyn, thanks
[21:52] <israeldahl_> Does anyone know if this is even possible?
[21:57] <israeldahl_> Really?  Doesn't someone know?
[21:59] <seb128> israeldahl_, you can do the update, add it to launchpad for review and subscribe ubuntu-sponsors
[22:01] <israeldahl_> Sorry... how do I do it?   I have the source, I made a personal bzr branch.  Is there a specific webpage with this info?
[22:06] <israeldahl_> Ok, a different question then, how do I make the software-center recognize a program in a certain category?  Is it the menu file or the desktop file?
[22:08] <israeldahl_> Is anyone out there?
[22:09] <seb128> israeldahl_, http://developer.ubuntu.com/packaging/html/udd-sponsorship.html
[22:10] <seb128> israeldahl_, the desktop categories are used for classification
[22:10] <israeldahl_> is that for the software center as well seb128?
[22:13] <israeldahl_> Ok, I have branched the program and the desktop file is in the source.... why then does the software-center not see it?  Does it not install correctly?
[22:14] <seb128> israeldahl_, not sure how s-c deal with that
[22:14] <seb128> try asking on #software-center
[22:14] <israeldahl_> nobody seems to know this.  is there a forum somewhere that someone might know something like this?
[22:15] <israeldahl_> I tried the ubuntu-app-devel earlier
[22:23] <israeldahl_> Anyone know how software center  decides how to categorize programs?
[22:27] <israeldahl_> Is there a key word to get attention?  Anybody have any idea how Software Center knows how to place a program into the correct catergory i.e. ardour --> sound & video
[22:28] <hallyn> hm, ppa build fails with "Python not found. Use --python=/path/to/python"
[22:28] <hallyn> that's probably not good
[22:30] <SpamapS> israeldahl_: this is not a support channel. #ubuntu would be better. That said, the packager chooses a "Section" for each package. That particular one is in the 'sound' section.
[22:31] <infinity> bdrung: I'd question the sponsorship of all those libreoffice uploads for #585910
[22:31] <bdrung> infinity: why?
[22:32] <infinity> bdrung: Given the ridiculous size of libreoffice updates, it might have been better to work with Sweetshark to get those incorporated in larger updates.
[22:32] <israeldahl_> Ok, fair enough.  I am working to get the latest version of lmms 0.4.13 into the repos, and need to make sure the bugs are all out.  this seemed to be the place to ask questions
[22:32] <bdrung> infinity: the SRUs are still unapproved.
[22:33] <bdrung> Sweetshark: ^
[22:33] <infinity> bdrung: A bit late now for raring, but I think I'll reject the SRU ones and ask you nicely (this is me asking nicely) to work with him on getting the fix in a larger SRU.
[22:33] <bdrung> infinity: can you state that in the bug report, please?
[22:34] <bdrung> infinity: the big size of libreoffice is not an issue for raring.
[22:34] <arges> hallyn, tried to reproduce bug 1027987 on bare metal. I defined a volume group for libvirt, then restarted libvirt-bin and did no noticed any delay with the older package. am I missing some steps?
[22:34] <infinity> bdrung: No, for raring, it's just buildd time.
[22:34] <hallyn> arges: no, i have a feeling an underlying bug in kernel or udev got fixed in the meantime
[22:35] <hallyn> so then the question is, do we drop that part of the debdiff, or do we simply say it isn't regressing anything and keep it in?
[22:37] <arges> hallyn, in the debian bug they used virt-manager.. not sure if that makes a difference
[22:38] <infinity> bdrung: Bug updated, SRUs rejected.
[22:38] <hallyn> arges: yes!  that rings a bell!
[22:38] <infinity> bdrung: As you were happy enough to sponsor it in the first place, can I count on you to chase up Bjoern to make sure it doesn't get missed?
[22:39] <bdrung> infinity: i'll try
[22:39] <infinity> arges: Thanks for verifying those eglibc fixes, BTW.  You rock.
[22:40] <arges> infinity, np thanks for getting that patch done
[22:41] <xnox> bug 1
[22:47] <bdrung> Sweetshark: what are your SRU plans for precise and quantal? will you make sure that the fix for bug #585910 (in upstream release 3.6.4) will be in the next SRUs?
[22:48] <bdrung> infinity: vlc 2.0.4 is stuck in the SRU queue for precise. can you have a look at it?
[22:50] <stgraber> micahg: regarding the lxc backport, someone told me that it should be fine as long as the package I depend on from backport didn't exist in the release pocket, which is the case here
[22:50] <infinity> bdrung: I can in a bit.  I'm arguing with glibc right now.
[22:51] <ScottK> xnox: It depends on how you define the market. That one may actually be fixed now.
[22:51] <bdrung> infinity: maybe this upload needs to go -security too (see Debian bug 692130)
[22:52] <infinity> mdeslaur: ^
[22:53] <infinity> bdrung: As a general rule, if you want it in security, you should talk to the security team and have it done through their PPA.
[22:53] <infinity> bdrung: Assuming the upload only has the security fix.
[22:54] <bdrung> infinity: it's a new upstream release with bug fixes including a security fix.
[22:54] <infinity> bdrung: Oh, yeah.  That's more problematic.
[22:54] <mdeslaur> does it have a microrelease exception?
[22:54] <xnox> ScottK: our regular bot was away from keyboard on vacation, I was checking if the replacement showed up for work or not ;-)
[22:55] <mdeslaur> bdrung: is there a bug open for that upload?
[22:55] <bdrung> vlc has a preliminary microrelease exception
[22:56] <bdrung> mdeslaur: yes, but no open security bug
[22:56] <bdrung> lp 970447 for example
[22:58] <mdeslaur> bdrung: since it contains a security fix, we need to do it through the security pocket.
[22:58] <mdeslaur> bdrung: is there a tracking bug for the SRU?
[22:59] <bdrung> mdeslaur: lp 970447 (the bug with the highest priority)
[22:59] <infinity> bdrung / mdeslaur: If I reject this from precise-proposed, will you two sort out what needs to be done to get it in security instead?
[22:59] <infinity> (Which will, at least, require amending the changelog to include the security bug) :P
[23:00] <mdeslaur> infinity: yes
[23:01] <infinity> Danke.
[23:01] <mdeslaur> bdrung: could you put it somewhere I can grab? is it in a ppa or somewhere?
[23:02] <bdrung> mdeslaur: i attached the debdiff to the bug. the changelog entry needs an adjustment.
[23:02] <bdrung> mdeslaur: do you prefer a debdiff for the debian/ part or a .debian.tar.gz file or a full source package?
[23:02] <infinity> bdrung: Just so you don't think we're screwing you around with unnecesary faff here, rest assured there's rhyme and reason in this. :)
[23:03] <infinity> bdrung: Notably that we builds in -proposed build against -updates, while -security is meant to be self-contained, so I can't copy the SRU to security without a massive rdep audit.
[23:03] <bdrung> infinity: no problem. when i uploaded vlc to -proposed, i wasn't aware a security issue
[23:03] <infinity> bdrung: Much simpler to just work with the security team, since their PPA has -updates turned off.
[23:03] <mdeslaur> bdrung: I'm not quite sure what that debdiff is against
[23:03] <infinity> mdeslaur: I can just give you his package from the queue.
[23:03] <mdeslaur> bdrung: is it based on the quantal package?
[23:04] <mdeslaur> infinity: please
[23:04] <mdeslaur> gotta run...
[23:04] <infinity> mdeslaur: It'll be in chinstrap:~adconrad/vlc/ shortly.
[23:04] <bdrung> mdeslaur: grab the precise-security package, grab the 2.0.4 source, copy the debian/ directory and apply the patch
[23:05] <mdeslaur> bdrung: I'll create a tracking bug, and I'll upload it tomorrow morning to build in the security PPA
[23:05] <mdeslaur> bdrung: thanks
[23:05] <mdeslaur> infinity: thanks
[23:05] <bdrung> mdeslaur: or easier: grab it from the vlc debian git repo (precise branch)
[23:06] <cjwatson> sigh - well, I guess I predicted ending up as TIL for half the archive when I did that armel rebuild
[23:06] <infinity> bdrung: I've just given him your source package from -proposed, that should suffice.
[23:06]  * cjwatson works his way through a ton of merges
[23:06] <infinity> mdeslaur: It's there now.
[23:11] <bdrung> mdeslaur: the faster way to receive the source: git clone git://git.debian.org/git/pkg-multimedia/vlc.git -b precise