[00:08] <kirkland> TheMuso: no worries, I think I figured it out ;-)
[00:09] <TheMuso> kirkland: ok.
[00:22] <tormod> TheMuso: the pc speaker issue, can it not be fixed by lowering the priority of the device some way, like the index=-2 for modems and usb devices?
[00:23] <TheMuso> tormod: That has been done for alsa, its pulseaudio thats the issue, as well as the volume for the pcsp alsa device, at least on the hardware I have. If pcsp is muted, then for me at least, there is no sound from the pc speaker when pulse initializes it.
[00:24] <tormod> TheMuso: what criteria does pulseaudio use for selecting the primary sound device?
[00:24] <TheMuso> tormod: Unless the user has set a configuration to use a particular device, pulse uses the first device it finds.
[00:25] <tormod> and it does not go through them in alsa order?
[00:25] <TheMuso> tormod: It goes through them in the order that hal lists them.
[00:25] <tormod> I am sorry I don't know how these things are stacked
[00:26] <TheMuso> tormod: But thats no longer the issue. The pc speaker will never be used by default any more, but the crackling/squeaking sound people get is the issue.
[00:26] <tormod> ok
[00:59] <mardi_soir> hello
[02:58] <RAOF> Oh, curses.  Pulseaudio's getting killed with "Soft CPU limit exhausted" messages again.
[03:09] <crimsun> more context?
[03:10] <jdong> I think RAOF is playing cheapskate CPU socialist government with his shell server ;-)
[03:11] <RAOF> crimsun: Run pulseaudio.  Play some music.  At some point pulseaudio will be killed with SIGXCPU.
[03:11] <LaserJock> crimsun: you know, the thingamagiggie bug in the whatchamacallit
[03:11] <crimsun> RAOF: erm, 8.10? more detail? :)
[03:11] <RAOF> crimsun: 8.10, updated as of this morning, just started happening.
[03:12] <crimsun> interesting, I'll pull a daily-live shortly
[03:12] <RAOF> This _has_ happened before, though.  I forget what happened then, though.
[03:13] <pushax> hi all.  A question. Which html engine as the most interoperability?
[03:16] <LaserJock> pushax: I'm not sure this is the best channel to answer that
[03:16] <RAOF> pushax: In what way do you think that's on-topic for #ubuntu-devel?  Also, there's nowhere near enough information; what do you mean by "interoperability"? :)
[03:16]  * RAOF watches the SIGXCPU signals being ruthlessly caught by gdb.
[03:23] <pushax> ROAF as I want to develop and application but want ti to run also on other systems with minimal changes.
[03:24] <RAOF> pushax: Still off-topic, but both firefox & webkit should be nicely portable.
[03:24] <pushax> KHTML/webkit seems to the be well supported.  I'm fairly new to linux.
[03:25] <pushax> what is the default engine on Gnome?
[03:25] <pushax> is gecko a complete web engine?
[03:26] <pushax> brb
[03:26] <lifeless> gecko is the core of firefox
[03:26] <lifeless> webkit is the core of safari
[03:26] <pushax> does gnome has a web layer?
[03:31] <LaserJock> pushax: Gnome's default web browser, epiphany, has used gecko, but I think webkit is also being worked on
[03:31] <RAOF> Epiphany is moving removing the pluggable backends and supporting just webkit, but it's apparently not going to make 2.24
[03:33] <pushax> thanks gyes
[03:34] <pushax> I wanted soem base, before jumping into reading
[05:21] <LaserJock> hmm, KDE and gnome seem to share the same autostart systems
[05:22] <LaserJock> that seems slightly inconvenient
[05:23] <RAOF> I believe KDE respects the X-KDE-StartOnlyInKDE key, fwiw.
[05:24] <LaserJock> but does Gnome respect X-Gnome-StartOnlyInGnome ?
[05:24] <LaserJock> that's what started this all, Gnome-do was starting in my KDE session and screwing up some things
[05:24] <LaserJock> then I disabled it from KDE and it disappeared altogether from Gnome
[05:25] <LaserJock> hmm, KDE needs to respect X-GNOME-Autostart-enabled I think
[06:00] <Hobbsee> i presume so, but has someone pointed out prior to this point that the information printed on the 8.04 cd sleeves is incorrect?
[06:00] <ajmitch> Hobbsee: which info is that?
[06:01] <Hobbsee> ajmitch: the stuff about the default option being deleting all data on your computer.
[06:03] <dholbach> good morning
[06:03] <Hobbsee> hey dholbach
[06:04] <dholbach> hiya
[06:25] <\sh> moins dholbach
[06:25] <lukehasnoname> I know it's supposed to be a recovery console, but doesn't anyone think it's insecure to have the recovery console (root) not be password protected?
[06:25] <lukehasnoname> What good is locking my screen when a friend (enemy) could reboot, go into recovery and have root control?
[06:26] <dholbach> hi \sh
[06:26] <realist> lukehasnoname: if your enemy has physical access, you've already lost the battle
[06:26] <RAOF> lukehasnoname: That's what luks is for.
[06:26] <lukehasnoname> sudo passwd root
[06:27] <lukehasnoname> luks...
[06:27] <RAOF> Encrypted hard drive.
[06:27] <realist> RAOF means; encrypted root partition
[06:27] <lukehasnoname> ah, yes.
[06:27]  * \sh just fixes all the ESX servers in our company...grmpf
[06:28] <RAOF> Failing that, physical access trumps everything (and, of course, not even failing that given sufficient encouragement).
[06:28] <realist> Which still wont protect you from someone attempting the frozen memory reboot technique.
[06:28] <lukehasnoname> I'm also thinking of the general population, who won't have any idea to encrypt / or to change root's pass.
[06:28] <RAOF> lukehasnoname: It's a trade-off between convenience and (a little) security.
[06:29] <lukehasnoname> true.
[06:29] <\sh> most people won't know how to access a machine without a password...it's only a promille of the world population
[06:29] <realist> lukehasnoname: I happen to agree with you, by the way. Setting a root password is still a "good idea"
[06:30] <RAOF> The alternative to "no password required for recovery access" is "the root password that you typed once 2 years ago when instaling the system and you've now forgotten is required"
[06:30] <StevenK> Which Windows can do.
[06:30] <realist> RAOF: in which case you can still boot from a recovery disc, chroot, and passwd
[06:30] <RAOF> realist: Indeed.  So what has your root password on recovery access given you?
[06:31] <\sh> realist: that's what bios boot security is for
[06:31] <realist> RAOF: false sense of security :-)
[06:31] <RAOF> realist: Right :)
[06:31] <StevenK> \sh: Sure, and you reboot a server remotely, and then have someone type the password. No, bad.
[06:32] <realist> StevenK: reboot remotely... from alternate boot media?
[06:32] <\sh> StevenK: hmmm? remote insight boards are quite common in our days
[06:32]  * \sh doesn't need remote hands to do the usual work
[06:32] <realist> \sh: or a remote kvm
[06:32] <StevenK> I tend to not like remote KVMs
[06:32] <\sh> realist: I'm HP fan ;) so I have ILO :)
[06:32] <StevenK> They do horrid things like want Java
[06:33] <realist> I'm a Sun fan, so I have an ok> prompt via serial console ;-)
[06:33] <realist> StevenK: not 'real' kvms
[06:34] <StevenK> The "real" remote KVMs tend to cost large sums of money
[06:34]  * realist truely dislikes those web-based remote consoles (eg. Dell RAC, or IBM RSA)
[06:35] <realist> StevenK: there's a nice market there for an open source (hardware/embedded) alternative
[06:41] <Treenaks> nice or niche :)
[06:41] <spm> fwiw, even encrypted partitions can deliver a false sense of security: eg Attacker holds gun to head of (liked vs disliked :-) ) co-worker: "give me the code or bang". There's always a way around, just depends on how much effort an attacker is willing to invest.
[06:42] <RAOF> spm: Or the person with physical access could add a hardware keylogger, or whatever.
[06:43] <spm> RAOF: sure. or take the unencrypted backup tapes :-D
[06:43] <RAOF> Indeed.  Whatever.  Physical access > *.
[06:44] <spm> Hence: Defence in Depth. Physical. Personnel. Logical. (sorry for lecture mode. used to teach this crap... ;-) )
[06:47] <lukehasnoname> spm, a/s/l
[06:47] <lukehasnoname> haha
[06:48] <lukehasnoname> I believe I am one of the younger people to hang around here on the IRC.
[06:49] <spm> lukehasnoname: us grumpy old farts were young once. just remember that. :-P
[06:50] <lukehasnoname> I'm sure. I've been realizing that more and more recently
[06:50] <pitti> Good morning
[06:50] <StevenK> Morning pitti
[06:51] <pitti> emgent: it's always better to do a normal upload to intrepid only, and an automated backport to hardy
[06:51] <Hobbsee> pitti!
[06:51] <pitti> emgent: manual uploads to *-backports should be avoided, and require a special rationale
[06:52] <pitti> kirkland: I am now
[06:52] <pitti> TheMuso: I already blacklisted it yesterday; testing and input appreciated
[06:52] <pitti> TheMuso: I know that it isn't ideal, but I think it's still better than living with those eternal squeaks and hangs
[06:53] <pitti> TheMuso: and if we don't have another solution, we can still re-enable kernel support for the old module?
[06:53] <pitti> hey StevenK, moin Hobbsee
[06:53] <TheMuso> pitti: Yeah I saw, I found a fix for the original problem I tried to fix in alsa-utils. I simply needed to move the calls to mute the pc speaker card to 0. It should be fine now. I have yet to upload alsa-utils, but I've tested the fix locally and it works.
[06:53] <pitti> TheMuso: but how is that different, in principle?
[06:53] <pitti> TheMuso: pc speaker keyboard beeps won't be audible?
[06:53] <TheMuso> pitti: Its because I forgot that udev calls the alsa init script for individual cards, so the reset for pc speaker mute wasn't being called.
[06:54] <TheMuso> pitti: Pc speaker beeps will still be audible. That is a different control for the mixer of the pcsp card.
[06:54] <pitti> TheMuso: ah, I see
[06:54] <TheMuso> If you were to load the pcsp module now, and check the mixer, you will notice a few controls, one is PC speaker which is the beeps.
[06:55] <TheMuso> The Master volume is separate and the one we are wanting to quash.
[06:55] <pitti> TheMuso: other thing, the reported hangs at session start in vmware et al, that won't change with changing the volume, will it?
[06:55] <TheMuso> pitti: I don't know. I don't have VMWare to test with.
[06:56] <pitti> TheMuso: happened to me in kvm, too; not very reliable, seems to be a race condition
[06:56] <pitti> I had it hang in vmware and kvm three times, then tried half a day later, and had it working in kvm
[06:56] <TheMuso> pitti: Is it anything to do with sound?
[06:57] <pitti> TheMuso: that's just what bug 246969 claimed
[06:57]  * TheMuso looks
[06:58] <pitti> no bugbot?
[06:58] <StevenK> Nope, ubotu is MIA
[06:59] <pitti> TheMuso: when I experienced the bug, playing the startup sound through pcsp took half a minute or longer, which could be well perceived as 'hanging'
[07:00] <TheMuso> pitti: Right, but the startup sound will not play through PC speaker any more, the only thing that can still be heard is crackling, which I have now found a better fix for.
[07:00] <pitti> TheMuso: how did you fix the former?
[07:00] <pitti> i. e. ignoring the card if it's there?
[07:00] <TheMuso> pitti: Patched pulseaudio to make sure that the last device it loads support for is pcsp.
[07:01] <TheMuso> pitti: Pulse doesn't ignore it, it just loads pcsp support last.
[07:01] <TheMuso> With my patch.
[07:01] <pitti> TheMuso: how does that help? if you don't have any other card, pcsp is the one that gets used
[07:01] <TheMuso> Prior to that, hal was giving pulse a list of devices, with pcsp at the top of the list.
[07:01] <pitti> and in VMs you very often don't have any other card
[07:02] <TheMuso> pitti: THis is true. I can blacklist the pc speaker from being used with pulseaudio entirely, however I have had some users say that pcsp is sometimes useful with pulse, believe it or not.
[07:04] <TheMuso> back in a bit
[07:05] <\sh> oh what a day...esx update works out of the box
[07:07] <Treenaks> \sh: it'd better, after yesterday
[07:08] <\sh> Treenaks: well, updates via update manager are still not working...but suspending all vm-machines, and applying the issued update package manually from the commandline works as expected..and all machines are coming back without any errors
[07:10] <TheMuso> back
[07:11] <TheMuso> pitti: Ok, after the alpha, I'll blacklist the PC speaker from pulse altogether, and we can unblacklist it.
[07:15] <superm1> pitti, I remember you had some chatter going on about usplash and uvesafb a week or so ago.  "should" things be stable on it right now?
[07:17] <pitti> superm1: stable in the sense of "it didn't change", but it's still broken
[07:17] <superm1> pitti, okay wasn't sure if i was having isolated incidents that i should file bugs on
[07:18] <superm1> but that clears that up :)
[07:20] <tjaalton> pitti: ok if I upload xorg which drops input devices from xorg.conf (irrelevant now anyway, and possibly only confusing)?
[07:20] <pitti> tjaalton: the a4 candidate CDs are in the middle of building
[07:20] <tjaalton> pitti: doesn't touch existing conf's
[07:20] <tjaalton> pitti: hum, ok
[07:21] <pitti> tjaalton: do you think that is critical for a4? if so, it's doable, just asking
[07:22] <tjaalton> pitti: not critical, just that people might be confused by seeing entries in the conf that have no meaning
[07:22] <tjaalton> forgot to upload earlier.
[07:23] <pitti> would you be fine with uploading it on Friday?
[07:23] <tjaalton> pitti: sure, no problem
[07:23] <pitti> if you are concerned that people get confused about it, feel free to add a caveat to the release notes (https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview)
[07:23] <pitti> tjaalton: ok, thanks
[07:23] <tjaalton> pitti: ok, that would work
[07:35] <tjaalton> pitti: done
[08:41] <pitti> TheMuso: oh, I just noticed that livefses are reeeally old, so they just didn't contain your latest fixes
[08:41] <pitti> ok, not that old, 20080808 built
[08:42] <pitti> now they fail with "couldn't find xresprobe"
[08:43] <StevenK>  xresprobe | 0.4.24ubuntu8 |         hardy | source, amd64, i386
[08:43] <StevenK>  xresprobe | 0.4.24ubuntu8 | intrepid/universe | source, amd64, i386
[08:43]  * pitti fixes livecd-rootfs
[08:43] <StevenK> pitti: ^
[08:43] <pitti> right, I was told xresprobe isn't necessary any more
[08:59] <TheMuso> pitti: right.
[09:36] <pitti> siretart: here by chance?
[09:40]  * pitti points tkamppeter at the soft freeze and the topic; please try not to break anything in intrepid ATM :)
[09:42] <ion_> tkamppeter: How would one go about testing the new PDF pipeline used by CUPS without wasting paper? I could of course print blank sheets, but is there a way to simulate and print the filter chain without printing?
[09:43] <Hobbsee> ah yes, that reminds me.  really should track down that printer bug.
[09:43] <ion_> Uh, s/simulate and print/simulate and dump/
[09:43] <pitti> ion_: you could set up a file:// queue?
[09:43] <ion_> pitti: Thanks
[09:43] <pitti> if you found out, that would make some nice test scripts
[09:43] <slytherin> Can anyone please sponsor the fix for bug 256949? I expected doko to do that by now, but he seems to have forgotten or missed it.
[09:44] <pitti> ion_: cups upstream has a test suite and runs it during build, but unfortunately the new filters aren't covered by that yet
[09:44] <pitti> slytherin: doko is on a conference
[09:44] <ion_> Ok
[09:44] <slytherin> pitti: so does that mean he will be available soon?
[09:45] <pitti> slytherin: no, not before next week
[09:46] <pitti> slytherin: I can upload that for you
[09:46] <tkamppeter> ion_, you can creat a printer which prints into a file. At first do
[09:46] <tkamppeter> cupsctl FileDevice=yes
[09:46] <tkamppeter> Then create a queue with URL file:/tmp/printout
[09:47] <tkamppeter> /tmp/printout will be of the format what the printer expects.
[09:47] <pitti> slytherin: uploaded, thanks
[09:47] <ion_> Alright
[09:47] <slytherin> pitti: Thanks. :-)
[09:48] <pitti> slytherin: once it's built and in the archive (ideally in about 1:10 hours), feel free to toss a list of packages to me which should be reattempted to build on powerpc
[09:48] <slytherin> pitti: sure.
[09:49] <tkamppeter> ion_ to get a PDF printing workflow you need a driver which already accepts PDF. This is currently gutenprint and other CUPS-raster-based drivers (others to follow).
[09:50] <tkamppeter> Second, use PDF as input format, by either using KDE or Qt apps for printing or by sending PDFs directly (lpr -P <printer> <file>.pdf).
[09:51] <pitti> tkamppeter: let's hope that once Mike integrates those filters upstream, they'll get tested in the test suite eventually
[09:52] <tkamppeter> pitti, I hope so, too, but he did not answer to CUPS bug 2897 yet ...
[09:54] <ion_> tkamppeter: I noticed cupsfilter and tried cupsfilter -p /etc/cups/ppd/HP_LaserJet_2300.ppd /usr/share/doc/gdb/refcard.ps.gz. It began processing it correctly by running /usr/lib/cups/filter/pstopdf, but that script failed because PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin (note the last item).
[09:55] <ion_> tkamppeter: I mean, cupsfilter itself printed: DEBUG: envp[6]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin/usr/bin"
[09:57] <ion_> tkamppeter: % strings =cupsfilter | grep usr/bin
[09:57] <ion_> %s/filter:/usr/bin:/usr/sbin:/bin/usr/bin
[09:59] <pitti> slytherin: the build made it quickly enough, so the after the next publisher (in 1 hour) it will be avilable
[10:00] <slytherin> pitti: Cool. I will keep list of packages ready. Should I split them by main/universe?
[10:00] <pitti> slytherin: for retrying the builds? not necessary
[10:01] <pitti> slytherin: I'd just appreciate if you could do the list with just spaces, no commas, and no "or", "and", etc. in between, so that it is cut&pasteable
[10:02] <slytherin> pitti: sure
[10:02] <tkamppeter> ion_ so the CUPS code contains a bad path? Looks like a bug in CUPS. But as all needed directories are there, this should not be the source of the problem.
[10:05] <tkamppeter> ion_, but cupsfilter has one problem: It does not report what the actually used filter chain is.
[10:06] <ion_> tkamppeter: I’m about to send a diff for cupsfilter. Oh, and it seems to print which filter commands it runs.
[10:10] <StevenK> pitti: Remind what needed libxsettings in main?
[10:10] <tkamppeter> ion_ for me
[10:11] <tkamppeter> cupsfilter -p /etc/cups/ppd/x.ppd ~/walking-map-portland-1.pdf > x
[10:11] <pitti> StevenK: matchbox-window-manager and libmatchbox
[10:12] <tkamppeter> says that gziptoany and no other filter was invoked, strange, as nothing is gzipped here.
[10:13] <tkamppeter> pitti, all printing-related uploads which I am doing currently cannot break the installation or the CD size. They do not introduce new dependencies.
[10:14] <pitti> "famous last words" :) , well, just be careful
[10:14] <pitti> breaking printing would be bad enough :)
[10:14] <tkamppeter> pitti, they are mainly changing PPD files and such so that PDF printing will work. Alpha 4 users should test the PDF workflow.
[10:15] <pitti> tkamppeter: right, but many alpha-4 CDs are already done
[10:15] <pitti> kubuntu is missing still, rest should already work
[10:15] <tkamppeter> If certain jobs do not print we have still two months to fix these cases.
[10:17] <Ng> ./win 69
[10:17] <Ng> gar
[10:17] <lifeless> nice number there
[10:18] <Ng> I really need to alias /win to /fail given how often I manage to type something else first ;)
[10:18] <tkamppeter> ion_ for better testing you should create a queue printing into a file and set debug mode. Then yiou can see the actual filter chains in error_log
[10:19] <ion_> tkamppeter: Alright
[10:22] <mcadetg> hi, I've a problem with lib/firmware when trying to compile/install vanilla kernel on ubuntu via the git/debian way...
[10:23] <mcadetg> I think the main problem is that dpkg -i linux-image tries to install firmware in /lib/firmware instead of /lib/firmare/$(uname -r)
[10:23] <mcadetg> can I configure this somewhere under the debian control directory?
[10:24] <ion_> tkamppeter: http://heh.fi/tmp/cups_1.3.8-4.debdiff
[10:24] <StevenK> pitti: Thanks, MIR coming soon.
[10:26] <tkamppeter> ion_, thanks. Please do also report a bug to CUPS upstream: http://www.cups.org/str.php
[10:27] <ion_> tkamppeter: Will do.
[10:30] <tkamppeter> ion_ I have found also another cupsfilter bug: I can print a JPG in a regular queue but not via cupsfilter. Seems that cupsfilter does not see all conversion rules.
[10:32] <StevenK> pitti: MIR for libxsettings is bug 257541
[10:42] <StevenK> pitti: I thought you NBS'd out gnustep-back0.12?
[10:43] <pitti> not yet, still wrestling with CDs
[10:44] <StevenK> pitti: If not, gnustep-back0.12 gnustep-back0.12-art libgnustep-base1.14 libgnustep-gui0.12 can all go.
[10:44]  * pitti -> back in ~ 1 hour
[10:53] <ion_> tkamppeter: I tried cupsfilter -m application/vnd.cups-postscript /usr/share/doc/gdb/refcard.ps.gz with the patched cupsfilter, it did gziptoany | pstops, i.e. didn’t do gziptoany | pstopdf | pdftopdf | pdftops. Should it have done that?
[10:54] <echo6> I'm looking for a method of enforcing mount read-only,  especially on a livecd,  there appears to be no way to enforce this using hal policies / gnome-mount. Is it possible that this can be remedied in future releases. Where should I post/email to bring this to the developers attention??
[10:54] <ion_> tkamppeter: I’ll try with a file printer next.
[11:14] <kirkland> pitti: hi, i was working on grub and I saw that both you and benc had also made some changes...  however, I was working off of a bzr branch, but I couldn't find your bzr branches
[11:51] <pitti> kirkland: I didn't do a bzr branch, just a regular upload; it doesn't have Vcs-Bzr:
[11:52] <pitti> kirkland: if it is in bzr, can you please add the Vcs header?
[11:52] <pitti> kirkland: my debdiff is attached to the bug
[11:53] <kirkland> pitti: hmm, when I do an apt-get source of grub, i see ....
[11:53] <kirkland> NOTICE: 'grub' packaging is maintained in the 'Bzr' version control system at:
[11:53] <kirkland> https://code.launchpad.net/~ubuntu-core-dev/grub/ubuntu
[11:53] <slytherin> pitti: This is the list of packages with FTBFS on powerpc - ant bsh jakarta-log4j libjaxp1.3-java libmx4j-java libservlet2.4-java libxerces2-java sacjava libjdic-java
[11:54] <pitti> kirkland: oh, whoops *brown paperbag*
[11:54] <pitti> kirkland: sorry, I'll commit my change then
[11:54] <dholbach> this is the most hilarious piece of feedback on the Global Bug Jam: http://daniel.holba.ch/blog/?p=167#comment-92989
[11:54] <kirkland> pitti: cool, thanks.  i was thoroughly confused :-)
[11:55] <kirkland> dholbach: :-D
[11:56] <kirkland> dholbach: good point...  lady bugs are too cute to be a representative of truly nasty bugs :-)
[11:56] <dholbach> kirkland: tell kwwii - he did the logo :)
[11:57] <pitti> slytherin: all given back
[11:59] <kirkland> dholbach: ;-)  if you want an ugly bug, you have to go with a flea or a tick :-)
[11:59] <pitti> kirkland: oh, right, the bzr branch is horribly out of date
[11:59] <thorwil> uglier bug availabale for reuse: http://thorwil.files.wordpress.com/2008/01/banner_bugs_01_i.png ;)
[12:00] <pitti> kirkland: seems that we first need to commit the last 5ish uploads first
[12:00] <kirkland> pitti: i think benc may have done the same thing, possibly
[12:00] <kirkland> pitti: i have a bug fix for #33649 in https://code.launchpad.net/~kirkland/grub/33649b
[12:00] <ion_> Missing a ’s
[12:03] <pitti> kirkland: maybe you can grab the debdiffs from https://edge.launchpad.net/ubuntu/+source/grub and commit them one by one into the ubuntu branch? (sorry, I am pretty busy with RMing for alpha-4)
[12:04] <kirkland> pitti: let me see what I can do....
[12:04] <pitti> kirkland: oh, hang on, owned by -core-dev
[12:04] <kirkland> pitti: i'll do the work in my own
[12:04] <kirkland> pitti: and you can merge from there
[12:05] <pitti> kirkland: I'll commit them here, don't worry
[12:06] <pitti> kirkland: the raid fixes in the UNRELEASED commits are not yet in intrepid, right? (you are the current changelog owner)
[12:06] <kirkland> pitti: that is correct
[12:07] <pitti> ah, they were recently merged by slangasek
[12:07] <kirkland> pitti: kees gave verbal approval of those changes before the bzr/dsc diversion was discovered
[12:08] <kirkland> pitti: slangasek merged a downlevel version of that patch...  he asked me to fix a couple of things before releasing
[12:08] <kirkland> pitti: revision 841 in lp:~kirkland/grub/33649b is what i need sponsored and committed
[12:14] <pitti> kirkland: ok, all uploads committed to bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu, and pushed
[12:14] <kirkland> pitti: awesome, thanks
[12:15] <kirkland> pitti: hang on...
[12:15] <pitti> merging your branch now
[12:16] <kirkland> pitti: that is a downlevel version of grub-install_better_raid.diff
[12:16] <pitti> 'that'?
[12:16] <pitti> pending merges:
[12:16] <pitti>   Dustin Kirkland 2008-08-11 This commit adds some smarts (back) into the handling of the multiple
[12:16] <kirkland> pitti: oh, wait...  looks like http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes is still showing new commits
[12:16] <pitti>     Dustin Kirkland 2008-08-11 slightly different approache to this problem, per IRC with slangasek...
[12:17] <pitti> kirkland: ^ that's what bzr merge lp:~kirkland/grub/33649b gives me now
[12:17] <kirkland> pitti: yes, that one is right
[12:17] <pitti> conflicts:
[12:17] <pitti>   Text conflict in debian/patches/grub-install_better_raid.diff
[12:17] <kirkland> pitti: a few seconds ago, Rev 839 was the top entry on http://bazaar.launchpad.net/~ubuntu-core-dev/grub/ubuntu/changes ;-)
[12:17] <pitti> kirkland: hm, maybe you can merge your branch against /ubuntu again, now that I pushed everything, and resolve the conflict?
[12:18] <pitti> I think you are in a better position to do that
[12:18] <kirkland> pitti: okay, let me do that
[12:22] <pitti> dendrobates, kirkland, zul: will the server team do the alpah-4 server CD testing again? (VMs are ok)
[12:23] <kirkland> pitti: yeah, i can help with some of that
[12:23] <kirkland> pitti:  i need to test a bunch of this raid stuff
[12:23] <pitti> kirkland: yes, don't worry, please finish that first
[12:23] <StevenK> pitti: Did you commit your livecd-rootfs changes to it's bzr branch?
[12:23] <pitti> StevenK: yes, I did
[12:23] <StevenK> pitti: Too distracted to do NBS stuff?
[12:23] <kirkland> pitti: will these grub changes make it onto that iso?
[12:24] <pitti> kirkland: I was just going to say, by default I wouldn't upload it, since most of the CDs are done already
[12:24] <pitti> and it sounds like intrusive changes
[12:24] <pitti> I'm always open for pings why this or that upload must make it to the CDs, of course
[12:25] <kirkland> pitti: hmm, well, mainly because this stuff really needs testing.  i can probably live without it
[12:25] <StevenK> pitti: If you're open for NBS stuff, please sync sear from Debian, no Ubuntu changes, builds fine, etc, etc, hand-wavy
[12:25] <kirkland> pitti: try: https://code.launchpad.net/~kirkland/grub/33649b
[12:26] <StevenK> pitti: If you commited, did you push? I can't see your changes by pulling from it.
[12:27] <pitti> StevenK: *cough* try again
[12:27]  * StevenK grins
[12:27] <StevenK> That looks better.
[12:28] <StevenK> Ah, and the sync too. Way cool.
[12:28] <pitti> StevenK: gnustep NBS goo removed, thanks
[12:29] <StevenK> pitti: From the directory too, or that needs a regen after a few go-rounds?
[12:29] <pitti> StevenK: just from the archive
[12:29] <slytherin> pitti: all packages build except one which has FTBFS for some different reason.
[12:29] <pitti> still needs publisher, et all
[12:30] <pitti> kirkland: merged, pushed; feel free to pull from lp:~ubuntu-core-dev/grub/ubuntu into your branch
[12:30] <StevenK> pitti: It's actually 'et al' :-)
[12:30] <pitti> I know, tpyo
[12:30] <kirkland> pitti: cool
[12:30] <StevenK> Teehhe
[12:31] <pitti> yohooooo
[12:31] <pitti> ubuntu livefs builds
[12:31] <StevenK> \o/
[12:31] <pitti> first since Sunday
[12:31] <kirkland> well, if you want to get really technical, it's "et alii" or "et alia"  :-)
[12:31] <StevenK> Or "et alibi" when refering to text
[12:31] <StevenK> Or "et alia" as well
[12:32]  * StevenK points kirkland at 'dict "et al"'
[12:33] <kirkland> StevenK: agreed ;-)
[12:47] <pitti> kirkland: btw, was it ever discussed to provide some helper script/app to move all secret data like gpg and ssh keys, the gnome and firefox keyrings, to ~/Private/?
[12:47] <pitti> kirkland: I'm pondering using ecryptfs instead of complete LUKS-lvm for performance reaons on my next desktop install
[12:47] <pitti> but I always have to manually move them across, etc.
[12:47] <kirkland> pitti: \o/
[12:48] <kirkland> pitti: it was discussed....  but the reception was cold/lukewarm
[12:48] <kirkland> pitti: i like the idea though
[12:48] <broonie> Perhaps .Private or similar since those are usually in hidden directories?
[12:49] <kirkland> pitti:
[12:49] <kirkland> rkland@t61p:~$ ls -al Private/
[12:49] <kirkland> total 24
[12:49] <kirkland> drwx------  6 kirkland kirkland 4096 2008-08-08 03:13 .
[12:49] <kirkland> drwx------ 93 kirkland kirkland 4096 2008-08-13 06:40 ..
[12:49] <kirkland> drwx------  2 kirkland kirkland 4096 2008-08-13 06:12 .gnupg
[12:49] <kirkland> drwx------  4 kirkland kirkland 4096 2008-08-13 06:21 .liferea_1.4
[12:49] <kirkland> drwx------  4 kirkland kirkland 4096 2008-02-14 06:59 .mozilla
[12:49] <kirkland> drwx------  2 kirkland kirkland 4096 2008-07-26 21:49 .ssh
[12:49] <kirkland> drwxr-xr-x  9 kirkland kirkland 4096 2008-08-12 14:17 .evolution
[12:49] <kirkland> pitti: that's what I'm running in my Private on a daily basis
[12:49] <kirkland> pitti: kees suggested liferea as a pseudo-stress test, as he's had trouble with that dir on NFS mounts before
[12:50] <pitti> kirkland: ah, you are putting the entire .mozilla there? including cache?
[12:50] <kirkland> pitti: yup
[12:50] <sistpoty|work> must be for some reason :P
[12:50] <kirkland> pitti: i'm symlinking everything back to their natural homes
[12:50] <pitti> kirkland: ah, I was just going to ask
[12:51] <pitti> usually I keep ~/.gnupg where it is and set secret-keyring /media/PittiCrypt/gpg/secring.gpg
[12:51] <pitti> (from the time I used a LUKS-encrypted usb stick to carry my secret stuff)
[12:51] <kirkland> pitti: that's a good idea
[12:51] <kirkland> pitti: one thing to consider....
[12:51] <pitti> because the pubring is huge and not sensitive
[12:51] <kirkland> pitti: you're going to want encrypted swap as well
[12:51] <pitti> and just my secret ssh key, not the entire dir
[12:51] <kirkland> pitti: in that passphrases could get swapped to disk
[12:52] <pitti> kirkland: well, I'm trying to achieve some more speed
[12:52] <kirkland> pitti: right, totally
[12:52] <pitti> kirkland: usually most programs should use mlock() properly, but that doesn't help for hibernate, of course
[12:52] <kirkland> pitti: encrypting all of /usr, /lib, and so forth is a waste
[12:57] <kirkland> pitti: i'd love to get your feedback on encrypted Private, if you do it
[12:58] <zul> pitti: I can do some of it
[12:58] <pitti> zul: great, thanks
[12:59] <pitti> zul, kirkland, dendrobates: we don't need exhaustive coverage, but at least some smoke test and the particular server features you are interested in; e. g. no need to exercise all partitioning options, since they are the same on the normal alternates
[13:02] <tseliot> pitti: I've been hacking on Jockey today and now it is possible to distinguish between a recommended version of a driver and the other versions
[13:02] <tseliot> pitti: the only thing I'm not sure about is how you would like to highlight the recommended version: bold, underline, etc.
[13:04] <tseliot> pitti: I've got the following screeshots of the gtk GUI (the last screenshot is of the QT4 gui):
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-bold.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-underline.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-recommended.png
[13:04] <tseliot> http://albertomilone.com/ubuntu/jockey/jockey-kde-bold.png
[13:04] <tseliot> pitti: let me know what you think
[13:05] <pitti> tseliot: how does jockey find out which driver is recommended?
[13:07] <tseliot> pitti: I had to add an is_recommended() method  to XorgDriverHandler. It can only return False. The NVIDIA handler overrides this method with one
[13:07] <pitti> tseliot: ah, shouldn't that be on Handler, not just on XorgDriverHandler?
[13:07] <tseliot> which uses nvidia-common and returns either True or False if self.package == recommended
[13:08] <tseliot> pitti: I can move it there if you wish
[13:08] <pitti> mpt might have an opinion, too, but personally I like the [recommended] best, since it's most obvious
[13:09] <tseliot> pitti: then I added this to backend.info:  'is_recommended': str(h.is_recommended())
[13:09] <pitti> tseliot: that sounds good; please adapt the test cases accordingly
[13:10] <tseliot> pitti: and both GUIs will see if self._(info['is_recommended']) is True or False and set the markup accordingly, that's all
[13:10] <tseliot> pitti: ok
[13:10] <pitti> tseliot: please don't call _() on boolean values
[13:11] <pitti> tseliot: those are not strings which need to be l10n'ed
[13:11] <tseliot> pitti: where?
[13:11] <pitti> tseliot: tseliot| pitti: and both GUIs will see if self._(info['is_recommended'])
[13:13] <tseliot> pitti: ah, right, I'll use info['is_recommended'] instead
[13:13] <pitti> right ... == 'True'
[13:13] <pitti> (I know, it's weird, but doesn't work otherwise over D-BUS)
[13:14] <tseliot> pitti: yes, I know that it's a string and not a bool. Otherwise it wouldn't have worked here ;)
[13:14] <tseliot> pitti: which screenshot do you prefer?
[13:14] <pitti> tseliot: as I said, the [recommended] one; mpt, WDYT?
[13:14] <pitti> oh, not online
[13:14] <tseliot> pitti: sorry, I didn't see it
[13:15] <pitti> tseliot: which one do you prefer?
[13:15] <tseliot> pitti: maybe the one in bold
[13:16] <tseliot> pitti: I will also clean up the x-kit part of Jockey
[13:16] <pitti> tseliot: btw, the place where you should use _() is the actual string, like '<b>[%s]</b>' % self._('recommended')
[13:17]  * ion_ shivers at explicit ‘self’.
[13:17] <tseliot> pitti: and isn't it info['is_recommended'] ?
[13:18] <pitti> tseliot: no, info['is_recommended'] is the boolean, whereas 'recommended' is the string you show (or not) in the UI
[13:18] <pitti> ion_: jockey's AbstractUI._() is magic, it translates keyboard shortcuts in GNOME and KDE, etc.
[13:19] <pitti> so that we avoid duplicating strings just because of & vs. _
[13:19] <tseliot> pitti: sorry, I meant info['name']
[13:19] <pitti> tseliot: I'm confused, what's with name? what's the question?
[13:19] <tseliot> pitti: ok, I see your point now.
[13:20] <tseliot> pitti: info['name'] is the one which we put in the row of treeview
[13:20] <tseliot> and therefore the one which we put in bold or whatever
[13:21] <tseliot> if we add the "[Recommended]" string to the name
[13:21] <tseliot> then we'll have to translate Recommended too
[13:21] <tseliot> pitti: it's ok, don't worry
[13:22] <pitti> right
[13:23] <tseliot> pitti: therefore if we choose to use the word "Recommended", I will add it to ui.py
[13:24] <tseliot> pitti: oh, and you don't mind if I use nvidia-common to detect the recommended version, do you?
[13:25] <pitti> tseliot: as long as that logic is in the NvidiaHandler, that's fine
[13:25] <tseliot> pitti: yes, it's only there. Ok, then
[13:27] <tseliot> pitti: also, is there anything I can do for the progress bar or are you waiting for packagekit?
[13:27] <pitti> ouch, apparently grub created a menu.list with /dev/hda1 in that amd64 desktop install, but it's boot=/dev/sda1
[13:28] <pitti> tseliot: I don't think full PK will make it, that dbus-glib bug is a real blocker, and I don't know a workaround
[13:28] <pitti> tseliot: so I guess we have to resort to using python-apt, and its progress callbacks
[13:29] <tseliot> pitti: ok, I'll have a look at it then
[13:29] <pitti> tseliot: great! (sorry, no time this week, I am the RM in charge for alpha-4)
[13:29] <pitti> and problems pop up all over the place, as usual
[13:30] <tseliot> pitti: no problem, I'll see what I can do.
[13:31]  * pitti hugs tseliot
[13:32] <tseliot> ;)
[13:33] <pitti> kirkland: do you happen to know, do we still put things like root=/dev/hda1 into grub's menu.list?
[13:34] <pitti> I mean, do we *mean* to
[13:34] <pitti> (on my desktop installation I just have root=/dev/mapper/foo, which is fine)
[13:35] <kirkland> pitti: i'm not sure i understand your question
[13:36] <kirkland> pitti: my laptop is root=/dev/mapper/vg0-lv0, like you say
[13:36] <pitti> kirkland: I mean, shuold I get UUIDs or device nodes in menu.list?
[13:36] <kirkland> pitti: UUIDs, i think
[13:36] <kirkland> pitti: my RAID-testing vm has root=UUID=29175762-644b-439d-a763-ab15298ef799
[13:37] <kirkland> pitti: which is /dev/md0
[13:38] <pitti> kirkland: right, in an alternate install I get UUIDs, in a desktop install I get device nodes
[13:38] <pitti> which causes a boot failure for me
[13:39] <kirkland> pitti: i should think that UUIDs would be preferred
[13:39] <pitti> since the desktop install added /dev/hdXX, but the device node is /dev/sdaXX
[13:39] <pitti> kirkland: absolutely
[13:39] <kirkland> pitti: for that reason ^  :-)
[13:39] <pitti> argh
[13:39] <kirkland> pitti: does ubiquity use something different?
[13:39] <pitti> and ENOCOLIN to tell us how it's all plumbed together
[13:40] <pitti> kirkland: apparently
[13:40] <kirkland> pitti: see the grub-installer package
[13:41] <kirkland> pitti: that's what's run in the alternate installer at least
[13:41] <kirkland> pitti: i have no idea about the desktop
[13:45] <pitti> "Cannot determine root device. Assuming /dev/hda1"
[13:45] <pitti> bummer
[13:58] <pitti> kirkland: ah, no /etc/fstab, so it's probably not grub-installer
[13:58] <kirkland> pitti: ah
[14:09] <pitti> does anyone happen to know some bits about ubiquity? in particular, which part writes (or currently fails to write) /etc/fstab?
[14:38] <cr3> pitti: would you happen to know which wiki page describes the process for renaming a package in intrepid?
[14:39] <pitti> cr3: I don't think we have one
[14:39] <cr3> pitti: hm, what would you recommend I do?
[14:39] <pitti> best option: avoid it
[14:39] <pitti> second best: upload the new package with a Conflicts/Replaces/Provides: old-name
[14:39] <pitti> and have a transitional package under the old name which depends on the new name
[14:40] <pitti> and keep that transitional one until the next LTS
[14:48] <cr3> pitti: regarding the transitional package, I'm not sure how I understand how it can depend on the new name when the new package conflicts with the old name
[14:50] <cr3> pitti: also, is the transitional package just an empty shell in order to address dependency concerns?
[14:50] <sistpoty|work> cr3: the magic is the combination of conflicts and replaces of the new package, which will force the transitional package to uninstall (at least iirc)
[14:51] <cr3> sistpoty|work: cool, I'll give it a whirl
[15:15] <seb128> pitti, mvo: would it be possible to add an apport hook in compiz to report what nvidia binary driver is being used? there is lot of crashes in libGL coming from nvidia users and I'm not sure where to reassigning those nowadays
[15:15] <jorgenpt> Hiya. Is this the right channel to ask about packaging?
[15:15] <jorgenpt> (i.e. creating packages)
[15:16] <seb128> jorgenpt: not really, try #ubuntu-motu rather
[15:16] <jorgenpt> Ok, thanks. :)
[15:18] <pitti> seb128: right, so far you just know that a reporter is using any nvidia-driver-*, not the version
[15:19] <pitti> anyone with nvidia on intrepid? does "modinfo nvidia" show the version anywhere?
[15:28] <seb128> MacSlow: do you use nvidia on intrepid?
[15:29] <MacSlow> seb128, I'm not on intrepid on my nvidia box yet
[15:29] <seb128> ok
[15:29] <MacSlow> seb128, what issues are there?
[15:29] <MacSlow> general Xorg or compiz?
[15:29] <seb128> MacSlow: just to reply to pitt's question before
[15:30] <MacSlow> ah
[15:30] <seb128> MacSlow: no, just trying to include informations on the nvidia driver version in compiz bugs because they are often due to the nvidia driver
[15:30] <tjaalton> pitti: I've got one back home, but it's not on currently
[15:30] <pwnguin> i hear rumors that the new nvidia triage system is to mark them "wontfix" and ask users to run "nvidia-report-bug.sh" instead
[15:31] <tjaalton> right
[15:31] <MacSlow> seb128, pitti: for some reason I always use -> glxinfo | grep "OpenGL version"
[15:31] <tjaalton> there are hundreds of nvidia/fglrx bugs that we can do nothing about
[15:31] <MacSlow> seb128, pitti: never modinfo
[15:31] <MacSlow> seb128, pitti: at least regarding graphics-drivers
[15:31] <seb128> tjaalton: I don't aim to do something about those, they should just not be assigned to compiz
[15:32] <seb128> tjaalton: and knowing what libGL is used would help to reassigning to mesa or nvidia drivers too
[15:32] <tjaalton> seb128: for the time being you can assign them against nvidia-graphics-drivers-*
[15:32] <pwnguin> -*?
[15:32] <tjaalton> versino
[15:32] <tjaalton> -on
[15:32] <seb128> tjaalton: I did reassigning the new one to -177 but I'm not sure that's right
[15:32] <seb128> tjaalton: that's why I was asking
[15:33] <seb128> tjaalton: looks like some recent nvidia update makes compiz crash a lot in intrepid
[15:33] <tjaalton> seb128: maybe -177 for all of them, since the others are a dead end
[15:33] <seb128> ok will do that, thanks
[15:33] <tjaalton> mine works, GF8600GT
[15:33] <seb128> and again one, grrr
[15:33] <tjaalton> heh :)
[15:35] <pitti> seb128: a specific compiz.py package hook can just do some dpkg -l nvidia* of course
[15:35] <pitti> seb128: but if it can be seen from modinfo, we can extend the generic "NonfreeModules:" field
[15:36] <seb128> pitti: that would be nicer
[15:36] <seb128> bug #256340 is this new nvidia crash
[15:37] <seb128> can we add "crash on any package in _nv000071gl()" as a hook?
[15:37] <pitti> if there are so many, then a bug pattern might be adequate?
[15:37] <seb128> pattern I mean
[15:37] <pitti> seb128: s/hook/pattern/?
[15:37] <pitti> yes
[15:37] <seb128> not "so many" yet, but I reassigned 3 of those today already
[15:38] <seb128> and who knows how long it'll take to get a fixed nvidia update
[15:38] <pitti> seb128: "_nv000071gl () from /usr/lib/libGLcore.so.1" in StackTraceTop should do
[15:38] <pitti> StacktraceTop, even
[15:39] <pitti> seb128: but we don't have packageless patterns, so for now it should be against compiz
[15:40] <seb128> pitti: right that was my question, the "any package" part
[15:40] <seb128> I guess compiz will get most of those crashes
[15:40] <seb128> so that should be good enough
[15:41] <seb128> pitti: hum, there is a retracer or apport bug somewhere
[15:41] <seb128> pitti: see bug #257124
[15:42] <seb128> pitti: it has eaten all the attachments
[15:43] <pitti> seb128: whoops, WTH? did you see that more often?
[15:44] <seb128> pitti: a few times since yesterday yes
[15:44] <pitti> https://bugs.edge.launchpad.net/ubuntu/+source/evolution/+bug/257124/+activity shows additions, but no removals
[15:45] <seb128> pitti: I bounced you the launchpad mail about the attachments removal
[15:45] <pitti> seb128: thanks
[15:47] <seb128> pitti: and since when does the retrace change the private status? I though somebody had to check the stracktrace before doing that?
[15:47] <pitti> seb128: it's only supposed to do that for duplicates
[15:47] <pitti> seb128: it removes attachments, makes it public, marks it as a dup
[15:48] <pitti> maybe it crashed on the latter
[15:48] <seb128> I'll keep an eye and let you know about buggy cases
[15:48] <pitti> anything in the retracer log for that bug?
[15:48]  * pitti chases another alpha-4 failure ATM
[15:48] <seb128> pitti: 08/13/08 11:15:45: retracing #257124 exit status: 0
[15:49] <pitti> seb128: did it say that it is a dupe?
[15:49] <seb128> pitti: the bug has been retraced twice
[15:49] <pitti> aaaah
[15:49] <seb128> maybe that's a buggy case
[15:49] <pitti> I bet apport got confused and tried to mark it as a dup of itself
[15:49] <seb128> pitti: I did retag it since the first retracing failed to produce a good stacktrace
[15:49] <pitti> but that would be weird
[15:49] <pitti> we often retag
[15:50] <seb128> well the log is weird, it's only line for this bug
[15:50] <seb128> usually there is a
[15:50] <seb128> "E: You must put some 'source' URIs in your sources.list
[15:50] <seb128> Report has no crash signature, so retrace is flawed
[15:50] <seb128> Duplicate check negative"
[15:50] <joaopinto> has anyone else experienced bug 254060 ?
[15:50] <seb128> anyway I'll keep an eye on it
[15:51] <joaopinto> It turns the system unusable with a regular boot
[15:55] <james_w> joaopinto: I think there may be another bug on that
[15:56] <joaopinto> I get into gdm with the warning that my home dir is not available, checked with ps, checkfs was still running
[15:57] <james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255563
[15:57] <james_w> https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/255562
[15:57] <james_w> they're the ones I was thinking of
[15:59] <joaopinto> My symptom is different. My system seems to boot normally and gdm runs fine. Shouldn't I get the "Do you want to skip?" notice ?
[15:59] <joaopinto> oh, its equal to the second bug
[16:00] <joaopinto> time to set mine as duplicate
[16:03] <joaopinto> I would also appreciate if someone could check bug 254177 , since it is not a clean install, I may have changed some configuration related to the problem
[16:11] <pwnguin> there's a lot on the ML about CD space -- does the install CD use lzma-squash?
[16:12] <pwnguin> err, squashfs-lzma
[16:12] <tjaalton> pitti: modinfo nvidia does not say anything about the version
[16:12] <pitti> tjaalton: thanks
[16:13] <broonie> tjaalton: the nvidia module prints its version when it loads, if there's not been much kernel output it should be in dmesg
[16:13] <tjaalton> broonie: true
[16:18] <devfil_> pitti: can yo do the giveback at php5 source? it builds fine
[16:18] <pitti> devfil_: nothing to give back, it already built fine
[16:19] <devfil_> pitti: I'm looking http://qa.ubuntuwire.com/ftbfs/, maybe it needs to be updated, however great
[16:30]  * pitti hopes that the sync flood won't break the alphas
[16:37] <pitti> Keybuk: you don't happen to have an ubiquity expert up your sleeve?
[16:38] <pitti> Keybuk: I'm afraid we have to release alpha-4 without desktop CDs, I don't think that there's a way for me to learn ubiquity code and do the rest of the release until tomorrow :(
[16:38] <Keybuk> heh, *I* haven't got evan ;)
[16:38] <Keybuk> I think he's chasing Mark's stewardess round San Francisco or something <g>
[16:39] <pitti> lol
[16:39] <Keybuk> (desperately trying to prove to the world that he's not gay - despite being in SF, and wearing the cowboy hat he got in TX :p)
[16:41] <pitti> ok, can't help it then
[16:41] <superm1> pitti, what sort of trouble is it?
[16:41] <pitti> superm1: bug 257580
[16:42] <pitti> and the isntaller syslog doesn't talk about fstab at all, until grub-installer fails on its absence
[16:44] <superm1> i thought partman is actually responsible for spitting out the fstab?
[16:45] <pitti> superm1: right, but I didn't find anything helpful in the partman log either
[16:45] <superm1> pitti, could you perhaps run ubiquity in debug mode and attach the same types of information?
[16:45] <pitti> superm1: sure
[16:48] <pitti> superm1: how did that work again, sudo UBIQUITY_DEBUG=1 ubiquity ?
[16:48] <superm1> pitti, i thought ubiquity -d should do the trick
[16:49] <pitti> superm1: that seems to work, yes
[16:50] <superm1> pitti, there should then be an extra log that is in /var/log/installer after you get your failure too
[17:10] <pitti> superm1: reading partman-target scripts now, but it doesn't even seem to get to finish.d
[17:11] <pitti> nor does it give any helpful log info in the partman log...
[17:11] <pitti> grep target /var/log/partman is completely empty
[17:20] <mpt> ArneGoetje, did you see S'orlok Reaves' message about Burmese input on ubuntu-devel-discuss@?
[17:22] <pitti> superm1: done
[17:22] <superm1> pitti, okay i'll take a glance this afternoon and see if anything stands out to me
[17:22] <pitti> superm1: thank you
[17:23] <pitti> superm1: I wonder why it works in d-i, but not in ubiquity; it uses the same code, shouldn't it?
[17:23] <superm1> should be
[17:30] <ArneGoetje> mpt: yes
[17:31] <ArneGoetje> mpt: didn't have time to answer yet
[17:31] <mpt> ok
[17:33] <LaserJock> seb128: is your last comment in bug #248163 still the plan?
[17:34] <seb128> LaserJock: yes, nm0.7 is in intrepid and it allows to do static configurations, what exactly can't you do using it?
[17:35] <LaserJock> static eth0
[17:35] <seb128> it allows to do that
[17:35] <LaserJock> spent 20min this morning trying to get it to work
[17:35] <seb128> asac: ^
[17:35] <LaserJock> whenever I try the "OK" button is greyed out
[17:35] <LaserJock> it won't save any configuration
[17:36] <LaserJock> unless it's DHCP
[17:36] <seb128> LaserJock: here it's right click on the nm icon, edit connection, select the connection, change, IPv4 settings, enter the infos
[17:36] <LaserJock> right
[17:36] <LaserJock> when I do that the "OK" button is greyed out
[17:36] <seb128> LaserJock: did you enter the prefix informations, it's a different column and not intuitive
[17:36] <LaserJock> so all I have is "Cancel" which is less than helpful
[17:37] <LaserJock> yes, I filled it out completely as far as I know
[17:37] <seb128> ie, you need to set the network mask there
[17:37] <LaserJock> yep
[17:37] <LaserJock> every column and entry line is filled in
[17:37] <LaserJock> search path, etc.
[17:37] <seb128> LaserJock: what "prefix" did you use?
[17:37] <LaserJock> <IP_ADDRESS>
[17:37] <seb128> I just tried setting an IP and a mask and the ok is unblocked
[17:38] <seb128> can you make a dialog screenshot?
[17:38] <LaserJock> yeah, just got to do some rebooting since I have to do networking in Hardy ;-)
[17:38] <seb128> ah
[17:38] <LaserJock> brb
[17:38] <pitti> asac: do you have some time for the "NM 0.7" section in https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview ? or, alternatively, tell me what to point out?
[17:38] <seb128> LaserJock: wait
[17:38] <LaserJock> seb128: yeah?
[17:39] <seb128> LaserJock: I get the issue when selecting "manual"
[17:39] <LaserJock> yeah
[17:39] <LaserJock> is that not what I want?
[17:40] <seb128> LaserJock: anyway "network-manager has a bug" is not a good reason to install network-admin
[17:40]  * LaserJock is used to "DHCP" and "static"
[17:40] <seb128> LaserJock: let's fix the bug rather
[17:40] <LaserJock> seb128: well, it's a lot more convenient that NM, but I understand your point
[17:40] <seb128> LaserJock: it was working when I tried some time ago, must have been broken since
[17:40] <LaserJock> NM is generally a pain in the butt for me
[17:40] <seb128> LaserJock: let's make NM convenient? if the dialog is not easy enough to discover or the UI sucks could you make suggestions?
[17:41] <seb128> LaserJock: well, there is no reason the "edit connection" in network-manager could not be similar to network-admin
[17:41] <LaserJock> it's just that it does everything automatically and I'm rarely in an environment where networking should be automatic
[17:41] <seb128> LaserJock: the way forward is to fix network-manager, not to write a buggy, complicated, written in perl, non actively maintained, application
[17:42] <LaserJock> for instance, it seems to try to fight between wireless and eth0
[17:42] <pitti> LaserJock: really? what's a good use case of not using dhcp in an eth network nowadays? (that's an honest question, I'm curious)
[17:42] <seb128> LaserJock: I've used nm0.7 to configure my wired static eth interface and that works fine
[17:42] <LaserJock> can I tell it to use one or the other without constantly shutting stuff off and on?
[17:42] <LaserJock> pitti: I have no idea, I've just never found a use for DHCP personally
[17:43] <pitti> as in, it would make things too easy and just work? :)
[17:43] <LaserJock> pitti: at uni we're all static IPs, at home I like to assign IPs so I can easily port-forward
[17:43] <LaserJock> most of it (uni) is out of my control
[17:43] <seb128> you can assign IPs using dhcp too ;-)
[17:43] <pitti> LaserJock: static IP assigment doesn't collide with dhcp
[17:43] <pitti> to the contrary, you have a central management for them
[17:44] <pitti> that's what I do for our house (8 flats with 8 families)
[17:44] <LaserJock> well, I'm not going to argue networking with the experts ;-)
[17:44] <pitti> we need to keep IPs for the way our ISP does its accounting
[17:44] <pitti> LaserJock: no, I was just really curious about use cases for manual setting of IPs
[17:44] <ion_> Yeah, DHCP is really useful for assigning static IP addresses.
[17:44] <pitti> because I think it's cumbersome, error prone, and quicky becomes unmanageable
[17:45] <pitti> so I wondered whether there are cases where dhcp isn't adequate
[17:45] <LaserJock> pitti: I've only got one place (uni wifi) that uses DHCP
[17:45] <sistpoty|work> pitti: if you don't have a dchp server... e.g. spontaneous lan party with friends in a garage *g*
[17:45] <pitti> and whether we might mitigate those
[17:45] <sistpoty|work> (good old days)
[17:45] <pitti> sistpoty|work: for that I'd recommend ipv4ll :)
[17:45] <sistpoty|work> heh
[17:45] <pitti> plug a cable between the two, and there they go negotiating an 169.254. address
[17:45] <pitti> (works since feisty)
[17:46] <LaserJock> pitti: so in my case not using DHCP is just a matter of 1) uni doesn't do it for ethernet yet 2) in my house it was easy to assign IPs
[17:46] <pitti> sistpoty|work: that's a good use case, actually, and one where the particular IPs don't matter at all, just that they are all different and in the same subnet
[17:46] <pitti> LaserJock: 1) is a very good reason, of course (your ISP doesn't give you one)
[17:47] <LaserJock> yes, that's the troublesome case, because right now Intrepid gives me *no* network connectivity at the uni
[17:47] <LaserJock> it used to be eth0 was a given and wireless was hard to set up
[17:47] <LaserJock> we're quickly going the opposite ;-)
[17:48] <pitti> LaserJock: back to /etc/network/interfaces then? that should work
[17:48] <pitti> nm should ignore the interface in this case
[17:48] <LaserJock> yikes, maybe
[17:48] <LaserJock> that's what I used to do
[17:48] <LaserJock> but then NM would barf, and cause problems
[17:48] <pitti> that's where network-admin saves its configuration, too
[17:48] <pitti> LaserJock: that needs to be fixed then
[17:48] <LaserJock> ok, maybe I'll give it a go and see
[17:49] <pitti> (independent of any shiny GUI)
[17:49] <pitti> it's an upgrade issue, and all that
[17:49] <pitti> LaserJock: ok, thank you!
[17:49] <LaserJock> first I'll try to see if there's something in the NM connection editor that'll let me save the config
[17:50] <LaserJock> it seems like it *should* work in the UI, so it's perhaps a bug there
[17:50] <LaserJock> and if I can keep NM around without it causing problems it'd be nice
[17:50] <Keybuk> ooh
[17:50] <Keybuk> I made LWN
[17:50] <Keybuk> http://lwn.net/Articles/293689/
[17:51] <LaserJock> apps seem to be wanting to use NM more and more to determine network connectivity, which is a real pain
[17:51] <ion_> Subscription required
[17:51] <Keybuk> ion_: LWN is well worth the fee
[17:52] <liw> I second that
[17:52]  * sistpoty|work heads home... cya
[17:53] <tseliot> pitti: does progress_cb exist (in oslib)?
[17:55] <tseliot> pitti: you use it in OSLib.install_package()
[18:01] <LaserJock> sooo, got it to work
[18:01] <LaserJock> NM still has "OK" greyed out but /etc/network/interfaces had the information
[18:01] <LaserJock> but resolve.conf was empty
[18:02] <LaserJock> so once I put the nameservers in resolv.conf and ifup eth0 I got a connection
[18:02] <pitti> tseliot: it's a function passed as a parameter to install_package()
[18:02] <pitti> tseliot: install_package() has to call it regularly with current progress numbers
[18:02] <pwnguin> if the ACM can publish Linux proceedings to the wider public
[18:02] <pitti> tseliot: see the dummy implementation in the ubuntu branch
[18:06] <tseliot> pitti: I had a look at backend.Backend.install_package() and at jockey-gtk (from the ubuntu branch). Did I missing anything?
[18:06] <pitti> Keybuk: interesting, I wasn't aware that our udev rules delta was still that big
[18:07] <pitti> tseliot: the thing which calls apt-get with a dummy feedback is jockey/oslib.py, install_package(), in teh ubuntu branch
[18:07] <pitti> that ideally would use python-apt and real progress
[18:08] <pitti> Keybuk: (why does that remind me of Mao so much? "WTF - Your rule?" -- "My rule!"
[18:11] <tseliot> pitti: yes, I saw it and backend.Backend.install_package() calls OSLib.inst.install_package() right?
[18:12] <tseliot> pitti: what I don't get is what the parameters passed to OSLib.inst.install_package() mean
[18:13] <tseliot> pitti: the name of the package and either True or None, right?
[18:18] <tseliot> pitti: but according to install_package in oslib, the 2nd argument should be a function
[18:45] <pitti> tseliot: no, as the docstring says, it's the name of the package, and a function
[18:45] <pitti> def my_progress_cb(phase, cur, total):
[18:45] <pitti>     foo
[18:45] <pitti> OSLib.inst.install_package('pmount', my_progress_cb
[18:50] <tseliot> pitti: maybe I'm looking at the wrong branch. Let me get the code again
[18:51] <tseliot> pitti: ubuntu-core-dev/jockey/ubuntu right?
[18:51] <pitti> tseliot: yes, sounds right
[18:51] <pitti> tseliot: the callback is defined in the GUI, the OSLib implementation calls it
[18:54] <tseliot> pitti: in which directory do I find the file with the example? tests, example, jockey?
[18:54] <pitti> tseliot: example for what?
[18:54] <tseliot> pitti: OSLib.inst.install_package('pmount', my_progress_cb
[18:55] <tseliot> the one you mentioned before
[18:55] <pitti> tseliot: oh, I just invented that from scratch in IRC
[18:55] <pitti> tseliot: the ubuntu branch's oslib.py has an implementation using apt-get
[18:55] <tseliot> pitti: yes, I've noticed that
[18:59] <tseliot> pitti: and does this call in backend mean anything? OSLib.inst.install_package(package, hasattr(self, '_locations') and self.install_progress or None)
[19:01] <tseliot> pitti: I'm just trying to figure out where is the function which you pass to install_package() together with the name of the package.
[19:01] <pitti> tseliot: ah, that's a bit tricky, it should have a comment
[19:01] <pitti> tseliot: you know what "condition and a or b" does in Python?
[19:02] <pitti> tseliot: similar to C's ? :
[19:02] <pitti> tseliot: if condition is true, the value of that expression is a, if condition is false, it's b
[19:02] <tseliot> is it like the conditional operator "?"
[19:02] <sbeattie> LaserJock: what did you do to figure out how to get a static address in Network Manager?
[19:02] <tseliot> yes, it's like that
[19:03] <tseliot> pitti: I knew it only in C and not in python
[19:03] <LaserJock> sbeattie: well, in my case I put in all the information but it won't let me save it
[19:03] <pitti> tseliot: ah, there is a comment
[19:03] <LaserJock> sbeattie: but when I looked at /etc/network/interfaces it was all there
[19:03] <sbeattie> LaserJock: I can't even get it to do let me enter information under xubuntu
[19:03] <LaserJock> sbeattie: hmm
[19:03] <pitti> tseliot: so in practice that means that self.install_progress is the function that oslib install_package() calls
[19:04] <sbeattie> LaserJock: http://www.nxnw.org/~steve/tmp/xubuntu-network-manager.png
[19:04] <pitti> tseliot: hasattr(self, '_locations') is a way to check if your object is a dbus.service.Object instance (at least the best I could fine)
[19:04] <pitti> tseliot: s/fine/find/)
[19:04] <sbeattie> If I unclick "auto eth0" it just automatically requests a new dhcp address.
[19:05] <tseliot> pitti: ok, it makes sense now
[19:05] <LaserJock> sbeattie: if you right click on NM do you get "Edit Connections"
[19:05] <pitti> tseliot: JFYI, it's not exactly like C's ? :
[19:06] <sbeattie> LaserJock: ah, for some reason when I right-clicked before I didn't get anything, but there it is.
[19:06] <pitti> tseliot: "TRUE : 0 : 1" is 0 in C, but "True and 0 or 1" is 1 in Python
[19:06] <pitti> tseliot: (due to the way 'and' and shortcut evaluation work in Python)
[19:07] <pitti> tseliot: but for everything that isn't regarded as False, i. e. 0, None, [], {}, and set(), the and/or construct works
[19:07] <pitti> tseliot: I don't use it often, but sometimes in my tired hours I get lazy :)
[19:08] <pitti> bbl, doing install testing
[19:08] <tseliot> pitti: aah, thanks for the explanation
[19:09] <pitti> tseliot: so the short rule is "and/or works as long as the "true-case" value is not False
[19:11] <tseliot> pitti: ok
[19:14]  * tseliot > dinner. bbl
[19:15] <mdz> something is causing all of my Places to be opened in totem-xine rather than nautilus
[19:16] <mdz> can someone give me a pointer as to where to look for the problem?
[19:18] <Treenaks> mdz: the mime database?
[19:18] <Treenaks> (and the new xine package vs the old one)
[19:18] <ted2> mdz: See what the command "gnome-open" does with the directories.
[19:18] <mdz> ted2: it does the right thing
[19:18] <mdz> MimeType=x-content/video-dvd;x-content/video-vcd;x-content/video-svcd;
[19:18] <mdz> seems correct enough
[19:19] <ted2> mdz: That's really odd.  Places in the panel?
[19:19] <mdz> ted2: yes
[19:20] <mdz> ted2: the Bookmarks menu in nautilus does the right thing
[19:20] <ted2> Makes me want to just blame the panel then, if all those work.
[19:20] <mdz> happens both with the stock bookmarks like Pictures, as well as those I've added
[19:20] <mdz> I don't know why the panel should have a different idea of how to handle file types
[19:20] <mdz> or where its settings would be if it did
[19:20] <ted2> The problem is that you've got a lot working :)
[19:24] <ted2> I don't see any settings for that either.  How odd.
[19:25] <ted2> totem-xine is the new konquerer.  :)
[19:26] <mdz> aha, I found it
[19:26] <mdz> /home/mdz/.local/share/applications/mimeapps.list:inode/directory=totem-xine.desktop;nautilus-folder-handler.desktop;
[19:26] <mdz> I wonder where that came from
[19:26] <mdz> I must have done 'Open with...' to launch totem-xine on a DVD folder
[19:27] <mdz> I wonder why it didn't affect gnome-open or nautilus
[19:29] <ted2> They both must have hard coded directory.
[19:42] <kirkland> mdz: ping, regarding the degraded RAID y/n prompt
[19:45] <seb128> mdz: nautilus doesn't look at this to open directory, it just open those
[19:46] <seb128> mdz: gnome-open is still using gnome-vfs and doesn't look at mimeapps.list which is a new gio thing
[19:49] <superm1> pitti, i identified what's happening re the fstab
[19:49] <superm1> pitti, it looks like it gets created properly, but when the filesystem copy begins, it gets overwritten by the one thats in the squashfs
[20:07] <jpds> pitti: In your buildd.py, are MOTU/core-dev capable of using the "rescore" operation, or is that just for buildd admins?
[20:10] <pitti> re
[20:10] <pitti> jpds: that's just for buildd-admins, I believe
[20:10] <jpds> pitti: OK, thanks.
[20:10] <pitti> superm1: oh, bugger
[20:11] <superm1> pitti, i think i've gvot an idea of a quick hack that might get around it
[20:11] <superm1> pitti, not necessarily the way that evan and colin will want to put in the end, but that should suffice for a4 to get out the door
[20:12] <pitti> superm1: in ubiquity, or in livecd-buildfs? (removing fstab, perhaps)
[20:13] <superm1> pitti, in ubiquity
[20:13] <superm1> pitti, although removing fstab in livecd-buildfs would probably solve it too
[20:13] <pitti> superm1: a hack in ubiquity could be tested right on the live CD, so that's a bit safer
[20:14] <pitti> superm1: what's the plan, like stash it into /etc/fstab.real, and move it over after squashfs copying?
[20:14] <superm1> pitti, okay give me a sec and verify that it works on this end (i'm doing an install here).  i'll post a diff momentarily
[20:14] <pitti> superm1: you rock
[20:17] <pitti> superm1: I just compared the squashfses in hardy and intrepid
[20:17] <pitti> hardy has a default fstab, too
[20:17] <superm1> pitti, some extra magic was added recently in ubiquity that does a file by file unlinking if files exist though
[20:18] <superm1> pitti, which i believe is what's triggering this
[20:18] <superm1> pitti, http://paste.ubuntu.com/37224/ appears to resolve it for me.  if you want to go the ubiquity route, i'll add that to ubiquity bzr and get an upload ready for it
[20:20] <pitti> superm1: ah, I see how http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/2753 has caused that
[20:21] <pitti> superm1: maybe we should just revert that commit for now?
[20:22] <superm1> pitti, well i believe that commit is correct, this is just an odd exception because its the only file written to etc prior to the squashfs copy
[20:22] <pitti> superm1: right, that would have been my next question
[20:22] <pitti> 'do we create any other files in /target before copying'
[20:22] <superm1> pitti, since partman has to run so early, i think this is the only one that it happens with.
[20:24] <pitti> ok, there are a couple of files matching "fstab" in my system, but none prefixed with etc/ (except for /etc/fstab)
[20:25] <pitti> superm1: so I believe your hack should work
[20:25] <pitti> superm1: so, let's use that for a4
[20:25] <pitti> superm1: did you already run a full install test with this applied? or shall I?
[20:26] <tkamppeter> pitti, I need your help.
[20:27] <pitti> superm1: how should we go on, do you have time to prepare the branch and test the fix? and I'll do the uploading/beating throuhgh publisher/CD rebuild/test afterwards? I need 30 minutes for getting some food
[20:27] <pitti> tkamppeter: what's up? I'm about to leave for half an hour
[20:28] <superm1> pitti, i just ran through an install and it did work
[20:28] <pitti> superm1: rocking
[20:28] <tkamppeter> pitti, can you send an e-mail to heno telling him that I sent him several e-mails and did not get any answer from him. Perhaps some spam filter does not let my e-mail come to him.
[20:28] <superm1> pitti, i can add it to the branch right now if you can upload from the branch after i add it
[20:28] <pitti> superm1: sure, will do
[20:28] <pitti> checking out in the meantime
[20:34] <pitti> tkamppeter: he's on holiday
[20:34] <Keybuk> Why are kernel developers so afraid of patches?
[20:34] <pitti> Keybuk: as in "not a git commit but a flat file", or as in "accept changes from other people"?
[20:34] <Keybuk> accept changes
[20:35] <Keybuk> I strongly object to having udev rules like this:
[20:36] <Keybuk>   KERNEL=="hw_random", NAME="hwrng"
[20:36] <Keybuk> especially in the default, hard-coded, non-modifiable udev rules
[20:36] <Keybuk> that says the kernel calls it one thing, but everybody calls it something else
[20:36] <pitti> you mean, then the kernel could just name it hwrng right away? agreed
[20:36] <Keybuk> (including the LANANA Device Names list)
[20:36] <Keybuk> exactly
[20:36] <Keybuk> a *one line* patch to the kernel fixes that
[20:36] <alex-weej> fight the power
[20:36] <Keybuk> I also object to having rules like this:
[20:37] <alex-weej> doesn't ubuntu maintain its own git repo of the kernel anyway?
[20:37] <Keybuk>   KERNEL=="mice", NAME="input/mice"
[20:37] <Keybuk> the kernel could just include DEVNAME=input/mice in the uevent
[20:38] <tkamppeter> pitti, until when? I asked here a lot and no one could tell me this.
[20:38] <pitti> superm1: what do I need to do to turn this into a source package?
[20:39] <superm1> pitti, me to push one more commit, and then debuild -S -sa should do it
[20:39] <superm1> pitti, you might need to run debian/rules update-local too though
[20:39] <superm1> or debian/rules update
[20:39] <superm1> it's been a while since i made a fresh tree to see
[20:39] <pitti> superm1: if you have a ready-made checkout, maybe you can build the source pacakge, too, put it somewhere, and I just sign it?
[20:40] <tkamppeter> pitti, it is about https://blueprints.edge.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format why I want to talk with heno.
[20:40] <pitti> superm1: AFAIK it needs to fetch/include some packages fromd-i?
[20:40] <superm1> pitti, yeah that's what the debian/rules update stuff does
[20:40] <pitti> tkamppeter: according to the holiday calendar he should be back next Monday
[20:41] <pitti> superm1: local checkout still running, remote checkout in developer chroot might screw it up, I dunno
[20:41] <pitti> superm1: ah, debian/rules update looks good
[20:41] <pitti> it fetches them from teh archive
[20:43] <pitti> superm1: ok, nevermind, I think I got it right
[20:44] <pitti> superm1: debdiffing my created source against 1.9.8 is sane
[20:44] <pitti> superm1: so I just wait for your second commit
[20:44] <pitti> superm1: that's just UNRELEASED -> intrepid and tag?
[20:45] <superm1> pitti, doing it right now, i was looking up the last part to do
[20:45] <superm1> modifying configure* and then debian/changelog and then its good to go
[20:46] <superm1> pitti, okay if you pull revno 2767, that should be good to go
[20:46] <pitti> got it
[20:48] <pitti> superm1: uploaded
[20:48] <pitti> superm1: thanks muchly!
[20:48] <superm1> pitti, great.  no problem :)
[20:48] <pitti> now I head out for a bit and let it build and publish
[20:48] <tkamppeter> pitti, you can access a holiday calendar? Can I do so, too?
[20:49] <pitti> tkamppeter: I don't think so, no; sorry


[03:42] <bluesabre> !team | I'll be publishing a post tomorrow announcing the 20.04 wallpaper contest. Submissions are currently open, and we'll allow submissions through March 13th. Then we should vote over the course of the following week and announce the results and upload on the following weekend. Please let me know if any of this is a problem, and if you can, review the submission terms for any needed changes.
[03:42] <bluesabre> https://contest.xubuntu.org/
[03:42] <bluesabre> Thanks knome for getting the site back up to snuff :)
[03:43] <bluesabre> jphilips: yeah, the clarification that the icon will only be displayed on a non-live session makes sense.
[03:44] <bluesabre> !team | (reiterated since the list got cut short, see above)
[08:22] <astraljava> brainwash: It was simply the setting in Window Manager > Focus > New window focus. I didn't know to suspect it, as I had only tinkered with the ones in Window Manager Tweaks. Or so I thought, now I'm not sure. :) Sorry for the noise.
[10:05] <brainwash> astraljava: glad that you figured it out
[12:38] <jphilips> bluesabre: okay will make the documentation change.
[12:43] <jphilips> pleia2: cloned git, created the patch, so now what should i do
[12:43] <jphilips> does xfce and xubuntu share any documentation
[16:00] <flocculant> jphilips: not as far as I remember - though we do get the xfce help pages from xfce applications
[16:00] <flocculant> and of course it could have changed in the last 18 months
[16:01] <jphilips> flocculant: thanks. just looking to do more things upstream so that xubuntu and other xfce distros can all benefit, which reduces duplicated efforts
[16:02] <flocculant> jphilips: the xubuntu docs are just that - xubuntu docs, don't believer there is any duplication, but I've been out of the loop for a while now
[16:03] <flocculant> the xubuntu docs should cover what we have as default and the specific differences we get from using Xubuntu
[16:06] <jphilips> bluesabre, ochosi: what do you guys think of including a startup welcome app like other distros like ubuntu mate, linux mint, manjaro, etc. have?
[16:07] <jphilips> i've contributed to the ubuntu mate welcome
[16:07] <flocculant> that got looked into in the past too :D
[16:07] <flocculant> don't think it got far because no-one that had time iirc
[16:10] <flocculant> I'd hazard a guess that it's be best to look at that post LTS release, when I was in team we'd not add something new this late in the LTS cycle (and as the QA lead I'd have had kittens :p )
[16:17] <jphilips> flocculant: if we'd go with the version in manjaro, it mainly links to external urls, so very little work would be needed.
[16:17] <jphilips> https://imgur.com/HS1fAxh.png
[16:18] <flocculant> jphilips: maybe little work would be needed - but it'd still need testing etc
[16:19] <brainwash> I'd think that everyone just closes the welcome screen anyway
[16:19] <flocculant> anyway could well be speaking out of turn
[16:19] <flocculant> brainwash: I'd certainly just hit the start installer button
[16:19] <brainwash> more like a nag screen :)
[16:19] <flocculant> and I thought the Mate one had options to choose etc?
[16:19] <brainwash> we got a shortcut for that on the desktop
[16:20] <jphilips> i close it as well, as i've seen it before, but for people who never saw it, they'd atleast look over it to once
[16:22] <jphilips> hopefully the community who isnt involved might start getting involved once they see a button about it
[16:26] <brainwash> the xubuntu website has all the links already though
[16:34] <jphilips> yes it would but what would make a user visit the xubuntu website after downloading the iso
[16:35] <jphilips> yes it does*
[22:46] <jphilips> is there a simple means to build xfce components on xubuntu?
[23:59] <jphilips> pleia2: installer documentation pointing to https://docs.xubuntu.org/1804/


[05:36] <cpaelzer> good morning
[10:15] <yossarianuk> hi - I have a question about the default KSM setting (i.e ksm/kvm)
[10:15] <yossarianuk> i.e -> /etc/default/qemu-kvm - has '# Set to 1 to enable KSM, 0 to disable KSM, and AUTO to use default settings.'
[10:16] <yossarianuk> What are the default (AUTO) settings ?
[10:44] <yossarianuk> Hi - we are setting up an office squid proxy / gateway using Ipfire in a KVM vm (using ubuntu 16.04 as the KVM host) - as there is going to be a lot of network traffic through the vm is it a good idea to enable 'vhost_net'?
[10:44] <yossarianuk>  I notice in Ubuntu the default setting in /etc/default/qemu-kvm is 'VHOST_NET_ENABLED=0'
[10:45] <yossarianuk>  so logically should I set that to 'VHOST_NET_ENABLED=1'?
[10:51] <lordievader> Good afternoon
[10:59] <yossarianuk> ust wondering if it is more sensible to enable or disable in my situation (i.e a proxy/gateway vm that all office traffic will be flowing through)
[11:06] <cpaelzer> hi yossarianuk - just realized I answered you in #ubuntu already
[11:06] <cpaelzer> TL;DR yes I'd recommend vhost_net but it is very likely already loaded
[11:06] <cpaelzer> the config you refer only checks if qemu-kvm loads it which is a failsafe mechanism, but some other triggers might load it anyway
[11:07] <cpaelzer> so they do for me at least
[11:07] <yossarianuk> again thanks
[11:08] <cpaelzer> and KSM auto is enable it on bare metal but not in guests
[11:53] <ezethnesthrown> Hello, I have a problem. Please see at http://paste.ubuntu.com/24536348/
[12:00] <cpaelzer> nacc: not sure IIRC - have you reworked the samba sections back then? any idea ^^
[12:00] <cpaelzer> rbasak: I'm trying to hunt down an issue with uvtool that tries to break my virt tests all too often - after a while I'm now down to systems not agreeing on the images available
[12:01] <cpaelzer> rbasak: the systems share /var/lib/uvtool/libvirt (via container shared paths)
[12:01] <cpaelzer> so what is in one is also in the other
[12:01] <cpaelzer> that worked fine so far, but since I recently stared to have one more system that does stop sharing these paths by bindmounting something else over it things break too much
[12:02] <cpaelzer> rbasak: I only now start to dive into uvtool for this trying to understand what other paths they might read in those cases
[12:02] <cpaelzer> rbasak: but if something comes to your mind please let me know
[12:02] <teward> rbasak: cpaelzer: powersj: nacc: any of you going to be at the server team meeting tomorrow?
[12:03] <cpaelzer> teward: I would be there I think
[12:03] <cpaelzer> there is a chair pointer pointing to me
[12:04] <teward> cpaelzer: well i won't be able to be at the meeting tomorrow - i have a more important meeting at my job - make a note on the action item for me re: nginx release notes  to push it to the next meeting for a status checkin
[12:04] <teward> i've got the bulletpoints on a notepad document, i've not gotten much further
[12:04] <teward> please :)
[12:04] <cpaelzer> ok, thanks teward for keeping us updated
[12:04] <teward> yeppers.
[12:05] <teward> Unrelated, anyone know how I can have a one-to-many SSH connection with one ingress and multiple backends based on the requested hostname?
[12:05] <teward> i'm not 100% clear on how to multiplex SSH that way, but...
[12:05] <teward> thought I'd ask :)
[12:07] <cpaelzer> teward: I think cluserssh does what you want?
[12:08] <teward> ooh prettu
[12:08] <teward> pretty*
[12:08] <cpaelzer> I'm not clear on "multiple backends based on the requested hostname" but it gives you one-to-many ssh
[12:08] <teward> cpaelzer: i think it'd be best if I diagram it
[12:08] <cpaelzer> That tool is my poor mans mass deployment helper
[12:08] <cpaelzer> sometimes
[12:08] <teward> I have a server with multiple LXD containers on it, each with SSH.  To get into it i have to first SSH to the host machine, then SSH into the specific container
[12:08] <teward> i'd like to cut out one of the 'hops' in what commands i type, if possible.
[12:09] <teward> s/into it/into one container/
[12:09] <cpaelzer> yeah ok that works as well
[12:09] <cpaelzer> you need a proxy ssh setup on your client
[12:09] <teward> cpaelzer: any idea on how i'd go about that?
[12:09] <teward> i've googled but am head-scratching
[12:09] <cpaelzer> to pass any command to foo-container actually to the host and fromt here to the container
[12:09] <cpaelzer> I can paste a snippet, let me search my notes
[12:09] <teward> thank you kindly :)
[12:10] <teward> i'm trying to take the fifteen or so VPSes and consolidate on one massive system heh
[12:10] <teward> allllll the services >:D
[12:11] <cpaelzer> teward: that matches what I did and has some nice text around https://www.cyberciti.biz/faq/linux-unix-ssh-proxycommand-passing-through-one-host-gateway-server/
[12:11] <cpaelzer> combine that with cluserssh and you can do stuff on all containers at once
[12:12] <teward> nice.
[12:13] <teward> cpaelzer: that'll help because now i can create SSH configs for each 'container' heh.  I'll just have to set up some command evils for the SSH without-password part to the containers... but that shouldn't be too hard.
[12:13] <teward> since the containers aren't directly SSH exposed to the 'net... :P
[12:13] <cpaelzer> exactly
[12:13] <teward> (CBA to buy a /24, wayyyyyyy too expensive)
[12:13] <teward> s/buy/rent/
[12:13] <teward> ah heck, my license for avast expired.
[12:13] <teward> damn, that means my mailserver has no AV protection
[12:14] <teward> ah well after my next big paycheck comes in that won't be an issue heh
[12:17] <teward> (it's $150/yr.  Not bad but outside my current budget)
[12:17] <ezethnesthrown> Hello, I have a problem, the text is quite long. Please see at http://paste.ubuntu.com/24536348/
[12:26] <rbasak> cpaelzer: that's all that uvtool cares about. But it uses libvirt's API to manipulate everything inside images/, and libvirt has its own in-memory cache of what that directory contains IIRC. So that could fall out of sync.
[12:27] <cpaelzer> rbasak: interesting hint, thanks
[12:28] <rbasak> cpaelzer: libvirt does support multiple image pool types. There might be one that is sufficiently networked?
[12:28] <rbasak> Then you'd only need to bind mount metadata/
[12:28] <rbasak> Once uvtool-libvirt is installed I doesn't touch the pool configuration again IIRC.
[12:28] <rbasak> (except perhaps on removal/purge)
[12:28] <cpaelzer> that might be a workaround
[12:28] <rbasak> If it is indeed the problem.
[12:28] <cpaelzer> but surely implementing that is as work intensive as understanding what goes on with the current one
[12:29] <cpaelzer> and understanding the current issue might reveal something that puzzles me some time now
[12:29] <cpaelzer> here it seems reproducible
[12:29] <rbasak> That makes sense
[12:29] <cpaelzer> so I want to know
[12:29] <cpaelzer> I can in that env e.g. show that query reports no images, and the subsequent sync fails because the file is already there
[12:30] <cpaelzer> rbasak: so effectively an affected guest can not make it working again (other than rm'ing files)
[12:33] <rbasak> IIRC, query reflects metadata/ exactly
[12:33] <rbasak> Is it doing that in your failure case?
[12:34] <cpaelzer> rbasak: output is different on two systems sharing the dir
[12:34] <rbasak> The actual image can be there when the metadata is not. This is for images being removed while still being used.
[12:34] <cpaelzer> I verified they are still in sync (md5sums, touched files appear, ...)
[12:37] <rbasak> cpaelzer: that's puzzling. I can jump into a hangout to do some debugging with you if you can reproduce that difference right now?
[12:38] <rbasak> cpaelzer: though can you just double check that /var/lib/uvtool/libvirt/metadata/ really is the same directory on both affected machines?
[12:38] <cpaelzer> rbasak: it is active right now if you have a few minutes I'd be happy
[12:38] <cpaelzer> surely faster with more eyes/brains
[13:07] <ezethnesthrown> Hello, I have a problem, the text is quite long. Please see at http://paste.ubuntu.com/24536348/
[14:06] <ezethnesthrown> Hello, I have a problem, the text is quite long. Please see at http://paste.ubuntu.com/24536348/
[14:12] <cpaelzer> rbasak: fyi new test runs the shared screen is now gone due to cleanup
[14:30] <ezethnesthrown> OK nevermind my bad
[14:38] <rbasak> cpaelzer: np
[15:00] <ahasenack> ezethnesthrown: sorry about your problem with the smbldap guide
[15:00] <ahasenack> ezethnesthrown: I hope to get to that area of ubuntu-server pretty soon
[15:02] <ahasenack> in fact, I want to update this to current ubuntu: https://github.com/panlinux/openldap-dit/tree/master/doc (just imported it from LP)
[15:30] <nacc> ezethnesthrown: aiui, you have to create the file
[15:30] <nacc> ezethnesthrown: an example is shipped with smbldap-tools
[15:33] <nacc> ezethnesthrown: as documented in the README.Debian file
[15:33] <nacc> ezethnesthrown: specifically SMBLDAP-TOOLS bit
[15:34] <nacc> ahasenack: so i think a short term fix is to copy out those bits into server guide (that you need to take the example config and do stuff to it to match your local install)
[15:35] <ahasenack> yeah
[15:35] <ahasenack> I think I'll start on that after this samba fix
[15:35] <nacc> ahasenack: thanks
[15:39] <cpaelzer> ahasenack: nacc: but next serverguide release is way way out
[15:39] <ahasenack> we can update the current one, right?
[15:39] <ahasenack> i.e., fix it
[15:39] <cpaelzer> ahasenack: nacc: I had another case which I wanted to fix in doc, but that will need time
[15:39] <nacc> cpaelzer: agreed, i'm saying as a fix to the current release
[15:39] <nacc> iirc, pmatulis has taken such thing with bugs
[15:39] <cpaelzer> ahasenack: no it only updates the user readable html/pdf on explcit releases
[15:40] <cpaelzer> yes you can "bug" them and ask
[15:40] <nacc> that's how i got the original serverguide fixed
[15:40] <cpaelzer> they will share doc release plans
[15:40] <nacc> hrm, maybe i'm misremembering
[15:40] <cpaelzer> nacc: yeah I pushed a few dpdk things that way as well
[15:40] <cpaelzer> nacc: but
[15:40] <cpaelzer> nacc: recently I wanted to add some libvirt things and got told that it will really take a while
[15:40] <ahasenack> seems silly not to be able to correct docs. It's not a rewrite
[15:40] <nacc> that policy seems less in the best interest of our users
[15:40] <nacc> oh adding things is diifferent, imo
[15:41] <ahasenack> right
[15:41] <nacc> fixing bugs should be allowed, if it's not, i think we should bring it up to the doc team
[15:41] <cpaelzer> I agree, but my case wasn't important enough to set me into the mood to punch this through
[15:41] <ahasenack> it has to have the SRU spirit
[15:41] <nacc> cpaelzer: ack, i think i saw your case
[15:41] <cpaelzer> yeah, "SRU spirit" covers most of it
[15:41] <cpaelzer> not random doc changes
[15:42] <nacc> cpaelzer: right, in this case, a missing step (at least_) that causes the next step to fail
[15:42] <cpaelzer> ahasenack: lets ask on ubuntu-doc ML how/if they would agree to handle those
[15:42] <cpaelzer> and share/discuss the feedback in the IRC meeting
[15:42] <cpaelzer> and drive via actions from there
[15:42] <nacc> +1
[15:42] <cpaelzer> ahasenack: would you do the initial mail to them or should I?
[15:44] <ahasenack> cpaelzer: I think you have more context now
[15:44] <cpaelzer> hehe
[15:44] <cpaelzer> ok
[15:44] <cpaelzer> leave a task open and you'll get it :-)
[15:45] <ahasenack> np :)
[15:51] <cpaelzer> ahasenack: nacc: I set you to cc
[15:51] <ahasenack> thx
[15:51]  * ahasenack -> lunch
[15:51] <cpaelzer> I was in a hurry so enjoy my surely intersting fast writeup :-)
[15:51] <nacc> cpaelzer: ack
[16:08] <cpaelzer> nacc: I see you pushing all the merges to done, if you could take an eye on the three in the review queue for the importer that would be very kind
[16:08] <nacc> cpaelzer: yep, im swtiching tack this week back to the importer and will review
[16:08] <cpaelzer> nacc: in order of complexity dovecot, ntp, strongswan
[16:08] <nacc> cpaelzer: tbh, for these three, on some level, im trusting you
[16:08] <cpaelzer> I trust myself as well :-)
[16:08] <nacc> cpaelzer: in that, you've done the merge, i just need to get them into the importer, right?
[16:08] <nacc> cpaelzer: or do you need a full merge review as well?
[16:09] <cpaelzer> nacc: the poitn I learned is that there are always issues - and we don#t need to stop the line but discussing them is step one
[16:09] <nacc> cpaelzer: ack, ok -- one takes longer than the other :)
[16:09] <cpaelzer> nacc: I don't need a formal review, yet on strongswan a pair of eyes would be nice
[16:09] <nacc> cpaelzer: and, on some level, if you could upload these (and maybe you can?) you aren't technically gated by me normally
[16:09] <nacc> cpaelzer: ack, strongswan was complicated before
[16:10] <nacc> rbasak: what state is your linter in?
[16:10] <cpaelzer> nacc: there is a lot of "known to drop delta" left that I made more clear in the MP and such
[16:10] <cpaelzer> nacc: I'd want to upload them tomorrow, so getting them into the importer and tagged would be nice
[16:11] <cpaelzer> nacc: tests are all good, so the issues left shoudl be easily possible as ubuntu2 or next-cycle as applicable
[16:11] <rbasak> nacc: not really usable yet, sorry. I just have pieces.
[16:11] <rbasak> nacc: it doesn't do merges at all yet.
[16:11] <nacc> rbasak: np, just checking :)
[16:12] <nacc> cpaelzer: ok, i'll bump it up my list
[16:12] <rbasak> nacc: but the script in wip/review can be used for merges.
[16:14] <cpaelzer> fyi I don't have merge bugs on these as they were trivial, but integrated that into my process so I'll in future open one in any case I think
[16:15] <nacc> cpaelzer: i'm also tempted to just give you upload rights to the git repos
[16:15] <nacc> or wait until we figure out where upload tags will live properly
[17:31] <thatstevecena> Hello. I'm having problems with Ubuntu 14.04LTS, Postfix & DKIM failing to verify signatures. My install runs fine for a few hours but ultimately starts failing signatures due to "no padding data". Has anyone seen this?
[17:44] <ezethnesthrown> What does this mean [[ bash: /usr/sbin/smbldap-populate: cannot execute binary file: Exec format error ]]
[17:44] <nacc> ezethnesthrown: what does `file /usr/sbin/smbldap-populate` say?
[17:45] <ezethnesthrown> Tried 'cat' it now the CLI broke
[17:45] <ezethnesthrown> smbldap-populate is a command
[17:45] <nacc> ezethnesthrown: yes, i know
[17:46] <nacc> ezethnesthrown: can you please tell me what the command i asked for says?
[17:46] <nacc> ezethnesthrown: if it's a binary, you don't wnat to `cat` it
[17:46] <ezethnesthrown> It says exactly that. Straight up error
[17:47] <nacc> ezethnesthrown: what?
[17:47] <nacc> ezethnesthrown: it says "Straight up error"?
[17:47] <ezethnesthrown> No
[17:47] <ezethnesthrown> There's no prompt
[17:47] <nacc> ezethnesthrown: `file` doesn't output such a thing
[17:48] <ezethnesthrown> I'm sorry. I'm a bit lost here
[17:48] <nacc> ezethnesthrown: so you ran `cat` on a binary? you probably need to start a new terminal session
[17:48] <ezethnesthrown> Rebooted
[17:48] <nacc> ezethnesthrown: ok, that was probably unnecessary
[17:48] <nacc> ezethnesthrown: run `file /usr/sbin/smbldap-populate`
[17:49] <ezethnesthrown> [[ /usr/sbin/smbldap-populate: gzip compressed data, max compression, from Unix ]]
[17:51] <nacc> well you can't run a data file
[17:51] <nacc> ezethnesthrown: what version of ubuntu?
[17:51] <ezethnesthrown> nacc: 16.04.2 LTS
[17:51] <ahasenack> rbasak: hey, where is the merge report output again?
[17:51] <ahasenack> I had http://people.canonical.com/~rbasak/merges.html from before you had commit access
[17:52] <nacc> ezethnesthrown: http://paste.ubuntu.com/24538078/ is what it should output
[17:52] <nacc> ezethnesthrown: that's from a fresh 16.04 container
[17:52] <nacc> ezethnesthrown: not sure what you're using
[17:52] <nacc> ezethnesthrown: `apt policy smbldap-tools` in a pastebin please
[17:57] <rbasak> ahasenack: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/merges.html but it looks like the cronjob is still failing so it's very out of date. I'll need to sort that out :-/
[17:58] <ezethnesthrown> nacc: http://paste.ubuntu.com/24538099/
[17:59] <nacc> ezethnesthrown: hrm, that's worrisome, same version here
[17:59] <nacc> ezethnesthrown: this is a VPS or anything? did you do any changes after installing?
[18:00] <ezethnesthrown> nacc: I'm installing in Virtual Box
[18:00] <ezethnesthrown> nacc: I followed the Samba and LDAP guide and the guide at the bug post
[18:01] <nacc> ezethnesthrown: can you run `dpkg -V smbldap-tools` ? and/or `dpkg -C smbldap-tools`
[18:02] <ezethnesthrown> dpkg -V smbldap-tools > [[ ??5??????    /usr/sbin/smbldap-populate ]]
[18:02] <ezethnesthrown> dpkg -C smbldap-tools > [[ ]]
[18:02] <nacc> ezethnesthrown: yeah so you've changed it from how it isinstalled
[18:02] <nacc> ezethnesthrown: 5 is 'file contents have changed'
[18:03] <nacc> ezethnesthrown: so ... what did you do? :)
[18:03] <ezethnesthrown> I did 'sudo dpkg-reconfigure slapd' I few times
[18:03] <ezethnesthrown> A few times*
[18:04] <ezethnesthrown> nacc: Thank you for your time. I'll restart then
[18:05] <nacc> ezethnesthrown: np, i don't thnk the dpkg-reconfigure should have changed the contents of an executable
[18:05] <nacc> ezethnesthrown: something else must have happened, but i don't know what
[18:08] <nacc> rbasak: do you have time this week for a importer/git sync?
[18:09] <ezethnesthrown> nacc: Is it inside smbldap files? I don't think I tampered anything inside. But I'll report here if it happens again.
[18:10] <nacc> ezethnesthrown: yes, that file (/usr/sbin/smbldap-populate) is fromm smbldap-tools afaict, and should be a perl script
[18:13] <ezethnesthrown> nacc: I can't recall
[18:13] <nacc> ezethnesthrown: you'd have to have been root to do so, and just imo, you should always konw what you did as root :)
[18:14] <ezethnesthrown> nacc: Thank you. I'll keep that in mind
[18:21] <cpaelzer> nacc: upload rights to the repos would help with trivial thigs at least
[18:23] <cpaelzer> nacc: and I think I can decide when to push and when not to
[18:23] <nacc> cpaelzer: yeah
[18:23] <nacc> cpaelzer: our eventual goal is if you can upload a srcpkg you can upload the corresponding tag
[18:23] <nacc> cpaelzer: but that needs lp stuff, etc.
[18:23] <cpaelzer> nacc: and in the worst case it is easy for you to catch me :-)
[18:24] <cpaelzer> nacc: I know the target
[18:24] <nacc> cpaelzer: yeah :)
[18:24] <cpaelzer> nacc: yet given that we mainly sync server and I have server + a few as upload rights ...
[18:24] <nacc> cpaelzer: yep
[18:24] <cpaelzer> nacc: the remaining subset isn't that big
[18:24] <nacc> cpaelzer: yeah
[19:09] <ezethnesthrown> nacc: Works magically now
[19:10] <nacc> ezethnesthrown: did you reinstall?
[19:27] <rbasak> nacc: yeah, let's arrange something.
[19:30] <nacc> rbasak: thanks
[19:54] <greenmanspirit> Hello all! I am trying to preseed NIS and when I reboot, rpcbind won't start. Is there something like networkmanager-wait-online that centos has? I am guessing the network isn't ready when rpcbind tries to start.
[19:55] <sarnold> which release? 16.04 uses a different service framework than 14.04..
[19:55]  * sarnold -> lunch
[19:56] <greenmanspirit> sarnold, 16.04
[20:05] <nacc> greenmanspirit: well on server, you wont' have networkmanager
[20:06] <nacc> greenmanspirit: if someting depending on network it shoulbe After=network.target in the service file, i think?
[20:10] <nacc> greenmanspirit: but i would thing rpcbind would be generally broken if it won't start becasue it needs networking and network isn't up in your case
[20:14] <nacc> cpaelzer: i did dovecot just now, but let's do it at the same time, as there is a bit of an inherent race
[20:14] <manukapua> im trying to delete a samba user after i deleted their unix account but get errors from smbpasswd - x and pdbedit -x , do i have to recreate the unix accoint before deleting the samba one ?
[20:14] <nacc> cpaelzer: tmrw AM for the others?
[20:17] <greenmanspirit> nacc, rpcbind doesn't have After=Network in the rpcbind.server file
[20:18] <manukapua> answered my own question - apparently yes
[20:18] <manukapua> have a fun mad day all : )
[20:19] <greenmanspirit> sorry, After=network.target
[21:02] <gartral> ok so i migrated my server from that half-ass VPS into a better host annd i'm still having issues with apache
[21:04] <gartral> nacc  sarnold thank you by the way, for other day
[21:10] <sarnold> hey gartral ;)
[21:11] <gartral> sarnold: I figured it out
[21:11] <gartral> it was a port collision between my vpn server and apache
[21:13] <sarnold> gartral: woot
[21:17] <Anonymes> hi
[21:34] <gartral> sarnold: arrrrrrrrrrgh
[21:35] <gartral> this is a game of catch 22 wrapped in a game of catch 22
[21:35] <sarnold> uhoh :) I was hoping that was the 'argh' of "i can't believe that mistake was so simple" :)
[21:40] <gartral> sarnold: I need a valid ssl cert, so I go through and try to use a let's encrypt cert for 'simplicity'... except certbot only uses port 443 and that port is already taken up by openvpn
[21:41] <sarnold> gartral: can't LE do dns too?
[21:41] <sarnold> gartral: and probably openvpn can be made to run on another port, if only temporarily
[21:42] <sarnold> gartral: I know some people run their vpn on ALL PORTS, so a simple nmap from their hotel room or airplane or whatever can often find a way through that's... ahem... cheaper than usual :)
[21:45] <gartral> sarnold: yea but I have ~30 or so devices on this vpn
[21:46] <gartral> most of which are family, and I don't need my mother screaming at me that her internet broke (again, because I had to re-issue cert packets to everyone from the the server move)
[21:46] <sarnold> gartral: ouch that's a lot of devices to reconfigure
[21:47] <gartral> yes it is... everyone tells me I'm a good IT guy... I don't think so but meh
[21:52] <sarnold> gartral: stand up a second server?
[21:52] <gartral> sarnold: moneies
[21:55] <sarnold> gartral: it's only got to live for an hour or something to get certbot to work; if you haven't used it already, aws's free tier may be enough?
[22:50] <eatingthenight> Hey i am pxe booting an image and i see this passed in as the command line argument for /proc/cmdline root=live:/genesis.iso
[22:50] <eatingthenight> what does that do specificly.
[22:50] <eatingthenight> i'm puzzled where it's getting the iso from since it's booting over ipxe using the initrd and vmzlinuz
[22:51] <eatingthenight> I read the kernel docs and it doesn't mention anything about live: and everything I have found is using live:http://....
[22:51] <eatingthenight> which make sense
[22:52] <nacc> eatingthenight: root= is not parsed by the kernel
[22:52] <nacc> eatingthenight: it's parsed by the init process, i think
[22:52] <nacc> eatingthenight: i don't where genesis.iso lives, because that's not ubuntu afaict?
[23:30] <eatingthenight> nacc: correct sorry i just figured people here may know a bit more about the command line boot args
[23:30] <eatingthenight> it's a custom image
[23:31] <eatingthenight> but I belive /genesis.iso in this case would mean it was baked into the image.
[23:32] <nacc> eatingthenight: i *think* that live: is just a prefix to something (init? not sure) that says it's a livecd rootfs. i'm guessing that if you're pxe booting, maybe it knows to alos look on the network for the iso
[23:32] <nacc> it being the boot processe
[23:36] <eatingthenight> aa ok, so might be looking it up on a sftp server on the network
[23:36] <nacc> eatingthenight: yeah, i'm not 100% on that, but i'd believe it
[23:40] <eatingthenight> hmm, darn. That does sound correct to me but the sftp server that it is using only contains the ipxe kpxe file.
[23:40] <eatingthenight> just checked to make sure. very strange.
[23:41] <nacc> eatingthenight: is it in the initramfs by any chance?
[23:45] <eatingthenight> hmm i dont see that file but i see this pre-udev/30dmsquash-liveiso-genrules.sh which looks interesting
[23:52] <eatingthenight> o ok https://www.redhat.com/archives/rhl-list/2009-December/msg01582.html looks to confirm that that is what does it
[23:52] <eatingthenight> looks like some legacy stuff from the liveiso creator
[23:53] <eatingthenight> nacc: thanks for the help! I'm somewhat satisfied knowing that it's custom to liveiso
[23:53] <nacc> eatingthenight: yw


[00:00] <dirty__> i am now same question for latest release please
[00:01] <wilee-nilee> dirty__, Just making sure is all, not considered a stable OS. Not sure of a fix, just concerned you are informed.
[00:02] <dirty__> no problems amigo thanks for the patience ill check forums again and or pop back here in coming days much thanks
[00:02] <wilee-nilee> dirty__, Cool, keep an eye here, there are great helpers. ;)
[03:40] <guest-ZkIzyk> hello all, sort my 14.04 out just right however i shut down slept came back and when i tryto logon to my account i get a blackscreen then back to logon screen again im currently having to use guest account to reach you any guidance
[06:53] <lordievader> Good morning.
[06:56] <elfy> morning :)
[06:56] <lordievader> Hey elfy, how are you doing?
[06:57] <elfy> I'm good thanks - you?
[06:58] <lordievader> Doing good, reinstalling OS'es on my laptop :)
[06:58] <elfy> :)
[07:09] <wilee-nilee> Gentlemen ;) had a partial upgrade come in here today, watch out for it.
[07:09] <elfy> hi wilee-nilee :)
[07:10] <wilee-nilee> hi elfy , good to see you.
[07:10] <elfy> well I'm glad that some think that :D
[07:10] <wilee-nilee> I know the feeling.
[07:12] <wilee-nilee> elfy, Mods have my sympathy, when it looked like I was being recruited at the forums I ran away and never cane back. ;)
[07:13] <wilee-nilee> came*
[07:13] <wilee-nilee> all the grub helpers ended up there some still workin.
[07:18] <lordievader> o/
[10:16] <BluesKaj> 'Morning folks