[01:11] <Ashburry> 'whois denis__
[01:15] <daftykins> oops
[02:37] <lotuspsychje> good morning
[02:37] <gry> hi
[04:28] <marcoagpinto> Heya
[04:28]  * sarnold passes the soda
[04:29] <marcoagpinto> >:)
[04:29]  * daftykins steps behind the blast shield
[04:30] <marcoagpinto> silly question: what is most probable, a 512-bit computer or a Quantum computer?
[04:30] <marcoagpinto> (what will come next)
[04:30] <sarnold> quantum computer
[04:30] <sarnold> those exist already
[04:30] <marcoagpinto> ahhhhh
[04:30] <marcoagpinto> :)
[04:30] <sarnold> they're not huge but they exist and do work etc :)
[04:31] <marcoagpinto> for week that I have been thinking about this
[04:31] <marcoagpinto> weeks*
[04:31] <sarnold> and there's probably no point to a 512-bit computer. I wonder how many atoms it would take to build that much memory...
[04:32] <marcoagpinto> thanks
[04:32] <marcoagpinto> :)
[04:33] <daftykins> that would have been an easy search
[04:34] <marcoagpinto> I don't want to search
[04:34] <marcoagpinto> I wanted to ask an OS development opinion
[04:34] <marcoagpinto> :)
[04:34] <marcoagpinto> developer*
[04:41] <daftykins> that was a hardware question
[04:41] <marcoagpinto> ahhhhh
[04:41] <marcoagpinto> sorry
[04:41] <daftykins> xD
[04:41] <marcoagpinto> my intention was thinking about an OS
[04:41] <marcoagpinto> :)
[04:41] <marcoagpinto> I wasn't clear
[04:41] <marcoagpinto> a 512-bit OS
[04:42] <marcoagpinto> the ZFS uses a 512-bit table
[04:42] <marcoagpinto> so, I was thinking about a 1024-bit table with 1024-bit times
[04:42] <marcoagpinto> :)
[04:43] <marcoagpinto> to include from the thousands minor time to the highest year possible
[04:43] <marcoagpinto> :)
[04:43] <marcoagpinto> 512-bit times*
[04:43] <marcoagpinto> sorry
[04:43] <marcoagpinto> I am brain damaged
[04:47] <daftykins> it's all the cola
[07:33] <ducasse> good morning
[07:36] <croraf> Hi guys. To prevent Windows on second partition to access data on the first Ubuntu partition, is the only way to encrypt the Ubuntu partition?
[07:40] <croraf> Can I like make a "harder" partitioning where the partitions wont be able to access each other (or format each other).
[07:41] <Ashburry> I am trying to find the locate of my zsh executable. I have tried locate zsh but have found nothing useful. Anyone know how to find it?
[07:41] <ducasse> windows won't be able to access your linux files without 3rd party software
[07:42] <Ashburry> however linux can access windows
[07:43] <ducasse> true, you'd need encryption to prevent that
[08:28] <croraf> ducasse, but the user or malware can easily install 3rd party software and access Linux then?
[08:30] <ducasse> there's nothing preventing them from reading the disk, no
[08:31] <ducasse> this is really a support question, they belong in #ubuntu btw
[08:31] <croraf> So my only option is encryption of linux partition?
[08:32] <ducasse> if you want the data inaccessible from outside that os, yes
[08:40] <croraf> thx
[11:36] <tomreyn> croraf: keep in mind that any other OS could still always just overwrite your data stored on Ubuntu file systems, whether or not it could make sense of it.
[11:37] <tomreyn> but yes, support is in #ubuntu
[12:08] <croraf> tomreyn, yes, thanks. Is there any other way of separation that you are aware of?
[12:11] <tomreyn> croraf: virtualization, hardware access control, physical separation.
[12:12] <croraf> wdym by physical separation?
[12:12] <tomreyn> disconnect and optionally physically move storage
[12:12] <croraf> Have two HD and somehow prevent access from one to the other?
[12:13] <tomreyn> or use network storage which requires authentication
[12:26] <daftykins> this scenario seems a bit nutty
[14:33] <Metamorphosis> Oxfuxxx I see no reason to run Lubuntu from a USB when there is PuppyLinux out there which is made for that purpose in mind.


[00:33] <slangasek> mdeslaur: bug #507148> is /usr/lib/xorg/modules/extensions/libglx.so missing from your system?
[00:38] <mdeslaur> slangasek: hold on, I'll check
[00:40] <mdeslaur> slangasek: no, it's not missing
[00:40] <slangasek> hmm
[00:40] <slangasek> ok, thanks for checking
[00:40] <mdeslaur> anytime
[00:41] <slangasek> I'm not sure what would cause that to go black /after/ a gdm login screen, then
[00:44] <mdeslaur> slangasek: it doesn't go black, it stays at the "flashlight" transition screen and hangs
[00:44] <slangasek> ah
[00:45] <mdeslaur> the currentdmesg log is revealing
[00:46] <slangasek> oh, curious
[00:49] <mdeslaur> may be a dupe of #478493
[00:50] <mdeslaur> hmm, maybe not
[01:15] <slangasek> smoser: did you link the wrong bug # from the ec2 test reports?  I don't think bug #506559 applies to EC2 :)
[02:31] <Drakeson> screen-cleanup is not run, I have to manually do "sudo invoke-rc.d screen-cleanup start" every time I reboot.
[06:33] <dholbach> good morning
[06:38] <Usama> hello, I want to report bug but I want suggestions
[06:38] <Usama> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/451640
[06:39] <Usama> I've the same bug but I want to make usefull report. what is the package name and how to append my report to this open bug
[06:41] <Usama> I found the bug channel thank you
[07:37] <pitti> Good morning
[07:43]  * slangasek waves to pitti
[07:43] <pitti> hey slangasek
[09:14] <UbuntuN00B> hello
[09:15] <UbuntuN00B> I'm probably not in the right place but I need help installing Uuntu 9.10
[09:15] <Mamarok> UbuntuN00B: support is in #ubuntu
[09:15] <UbuntuN00B> I know but they havn't really helped :/
[09:16] <Mamarok> UbuntuN00B: you need to be patient, ask your question and give enough details, if somebody knows the answer, they will reply
[09:17] <UbuntuN00B> I gave every detail possible and I think after 1hr waiting for an answer its time to try elseware
[09:18] <Mamarok> well, again, just be patient, it definitely doesn't belong here
[09:25] <pitti> darn, resuming from hibernation is broken completely now
[09:26] <hyperair> pitti: what broke?
[09:27] <pitti> hyperair: apparently the initramfs now doesn't check at all for a swap signature any more?
[09:27] <hyperair> oh hell, that sucks.
[09:27] <pitti> it just boots, and mountall/fsck notice that swap has a hibernate siguature and re-mkswaps it
[09:27] <pitti> and of course it keeps fscking /, since it wasn't unmounted cleanly
[09:28] <hyperair> ha.
[09:28] <hyperair> lol
[09:28]  * pitti files a bug
[09:28] <hyperair> pitti: check if the resume script's around in /usr/share/initramfs-tools/scripts/local-premount/resume
[09:34] <pitti> hm, it's there
[09:34] <smoser> slangasek, i did use the wrong bug. fixed now.
[09:34] <slangasek> smoser: cheers
[09:34] <pitti> /usr/share/initramfs-tools/scripts/local-premount/.resume.swp, too..
[09:35] <DktrKranz> sbalneav: hi! do you have a ETA for sabayon-2.29.5 final on GNOME FTP?
[09:35] <pitti> hyperair: perhaps it broke with Scott's initramfs scripts reorg
[09:35] <hyperair> hmm perhaps.
[09:35] <pitti> hyperair: a lot of those scripts did assumptions which weren't documented/guaranteed
[09:35] <smoser> slangasek, i was going to go ahead and publish as alpha3 to ec2 unless you object
[09:35] <smoser> just so i have the ids when i wake up tomorrow
[09:35] <slangasek> smoser: yes, please go ahead
[09:35] <hyperair> ouch
[09:38] <smoser> ok. just started: vbcron publish-build --verbose --add-launch=none lucid server alpha2 /srv/ec2-images/lucid/20100113
[09:42] <pitti> hyperair: bug  507390 FYI
[09:42] <hyperair> pitti: ah thanks.
[09:45] <smb> slangasek, Which logs exactly did you like to have from cking and myself?
[09:45] <slangasek> didrocks: is there an open bug for the UNE/gdm issue that we can link from the errata?
[09:45] <slangasek> smb: /var/log/dpkg.log
[09:45] <smb> slangasek, ok a sec
[09:47] <slangasek> didrocks: (other than bug #507121, that is)
[09:48] <cking> slangasek, logs sent
[09:50] <slangasek> cking: thanks - sent where?
[09:50] <cking> to you
[09:50] <cking> via email
[09:50] <slangasek> ok
[09:51] <smb> slangasek, sendemail too. on its way out
[10:05] <didrocks> slangasek: not yet, opening it in a minute
[10:05] <slangasek> didrocks: well, perhaps you can claim bug #507121 then :)
[10:05] <didrocks> slangasek: yes, it should be ok :)
[11:12] <didrocks> cjwatson: if you have a minute, about persitency on an USB key: can you confirm that when I reboot, I retrieved persistent data mounted on /root/<something> in casper phases? (seems I don't get previous file, just an empty one)
[11:27] <pitti> didrocks, cjwatson: we'll debug this after didrocks is back from lunch, with break=casper-bottom
[11:32] <cjwatson> didrocks: persistent mounts should be set up while casper is putting the unionfs together, so yes
[11:37] <LucidFox> A Debian developer doesn't want to move upstream source changes out of the diff.gz into a patchset, because "it's tracked in git anyway".
[11:41] <cjwatson> LucidFox: I sympathise
[11:41] <cjwatson> LucidFox: actually I'd like to have patches be some kind of automatically exported format, and I believe somebody was working on doing that in git though I haven't seen it done in bzr yet
[11:42] <cjwatson> but I think saying "I'd like to use the features of my revision control system to deal with merging" is a perfectly reasonable and unsurprising position
[11:42] <LucidFox> It will make merging into ubuntu a pain, though. :/
[11:43] <cjwatson> that depends on how merging is handled.  ultimately we should be making use of their revision control in some way.
[12:05] <pitti> cjwatson: do an ubuntu git branch?
[12:05] <pitti> sorry
[12:05] <pitti> LucidFox: do an ubuntu git branch?
[12:06] <pitti> LucidFox: also, there's nothing wrong with keeping the ubuntu changes in debian/patches onl
[12:06] <pitti> y
[12:06] <LucidFox> Hmm. Keeping Ubuntu changes in debian/patches and leaving Debian changes in the diff.gz?
[12:07] <pitti> sure
[12:08] <cjwatson> or just applying the Ubuntu changes in the same way as the Debian ones
[12:08] <pitti> that would be the "ubuntu git branch" style, yes
[12:09] <slangasek> pitti: is it the lack of explicit verification of the other two bugs that holds up the cryptsetup SRU currently?
[12:10] <persia> Um, keeping Ubuntu patches in debian/patches and Debian patches unmanaged tends to lead to significant complexity in debian/README,source or stark confusion on the part of those not familiar with the specific package history.
[12:10] <cjwatson> agreed.
[12:11] <cjwatson> any particular reason we have so many Ubuntu patches in this case that it's an issue?
[12:11] <pitti> slangasek: I think it's fine, three weeks and tested by several people
[12:12] <slangasek> pitti: ok, great :)
[12:12] <pitti> speaking about SRU; smb, did you get testing for the armel kernels?
[12:13] <pitti> slangasek: ah, it was the last comment in bug 454898; that's not a regression, though, right?
[12:14] <pitti> slangasek: so it seems we can move to -updates, but keep this bug open?
[12:14] <slangasek> pitti: right, not a regression
[12:15] <slangasek> pitti: actually, that last comment from me may have been a description of what the SRU /fixes/, rather than an outstanding problem
[12:15] <slangasek> viz: "the old upstart job"
[12:15] <pitti> ok; released, thus the bugs are closed now
[12:15] <slangasek> \o/
[12:15] <slangasek> thanks :)
[12:16] <pitti> thanks to you, you did all the work :)
[13:17] <didrocks> cjwatson: thanks, very weird, when we debug this, seems something is ruining it before 15autologin (right file when we break at casper-bottom and wrong when 15autologin is starting). Still investigating on it. Thanks for the answer :)
[13:39] <jdstrand> lool: hey, thanks for the ufw fixes :)
[13:40] <lool> jdstrand: I'm ashamed to say it's the first time I play with it, but let me tell you: it's awesome
[13:40] <jdstrand> hehe
[13:40] <jdstrand> lool: glad you like it :)
[13:40] <lool> I was the guy writing the 7th version of his iptables shell script
[13:41]  * jdstrand nods
[13:41] <jdstrand> been there
[13:41] <lool> Ultimately generating dumps for iptables-load, and now I can just type that in some ufw config if I feel like it but can also use the standard config most of the time
[13:41] <lool> jdstrand: One thing I wonder about is whether you have any integration with vms -- e.g. libvirt networking awareness
[13:42] <jdstrand> lool: they are unaware of each other, but also should not get in each other's way because of how I did the chains
[13:43] <jdstrand> lool: I've been kicking around ideas for that integration, but ultimately ufw needs more FORWARD support
[13:43] <jdstrand> lool: that is planned, but not this cycle
[13:43] <lool> jdstrand: Ack
[13:43] <lool> jdstrand: Anyway, great job!
[13:43] <jdstrand> lool: thanks! :)
[13:54] <pitti> cjwatson: so you just pushed lp:~ubuntu-installer/ubiquity/trunk into lp:ubuntu/ubiquity? Did that cause any confusion for the auto-importer? (I'd like to do that for apport and jockey, since people keep doing wrong merge proposals based on the useless auto-imported branch)
[13:55] <cjwatson> pitti: I did?  I didn't intend to?
[13:55] <cjwatson> pitti: ubiquity is not yet in a form where it's suitable for lp:ubuntu/... IMO
[13:56] <pitti> ah, must have mixed that up
[13:56] <cjwatson> in particular if you check it out from bzr you need to fiddle with it a bit before you can upload a source package
[13:56] <pitti> ah, it was casper, not ubiuqity, sorry
[13:56] <cjwatson> Scott did that push
[13:56] <pitti> ok, thanks
[13:56] <cjwatson> I don't believe the auto-importer minds as long as there are suitable tags
[13:56] <pitti> last time I discussed that with james_w he said that it could cause some extra work for him
[13:56] <cjwatson> I could be wrong, I'm going from design not implementation
[13:57] <slangasek> AIUI it does require him to manually fix up things on his side after a push has been done, but that this is acceptable
[13:57] <slangasek> (per james_w himself)
[13:57] <pitti> james_w: so, I'd like to push the jockey/apport branches into lp:ubuntu/{jockey,apport}; would that be ok for you?
[13:58] <pitti> (they have proper tags for the uploaded releases, etc.)
[13:58] <pitti> cjwatson, slangasek: thanks
[14:04] <tseliot> slangasek: as regards alternatives, do you think the use of --force be better? This would ensure that the slaves are set even if this means overwriting real files
[14:04] <tseliot> s/be/would be/
[14:05] <lool> asac: Am with seb128 here and he wondered whether I could look at the libiphone related MIRs -- did you start review of any of libiphone / libplist / usbmuxd?
[14:05] <slangasek> tseliot: mm, that sounds unpleasant to me :)
[14:07] <tseliot> slangasek: usually (i.e. if we deal with alternatives correctly) we shouldn't need that. I was asking as in Mandriva  they use a fork of update-alternatives which sets --force by default
[14:07] <slangasek> ick :)
[14:07] <tseliot> note: I wasn't suggesting that we use it ;)
[14:08] <asac> lool: i reviewed libplist
[14:08] <asac> odd ... where did it go ;)
[14:08] <lool> asac: Cool; I think the testsuite should be enabled, but we're in sync with Debian so would be nice to ping the Debian/Ubuntu maintainer (Julien Lavergne) when adding that
[14:09] <lool> asac: I will stop reviewing it now, would be happy to get your comments on that one in the bug
[14:09] <smoser> what is the posting policy to ubuntu-devel mailing list ?  I always get "awaiting approval" but I'm subscribed to the list.
[14:10] <elmo> smoser: https://wiki.ubuntu.com/UbuntuDevelModeration
[14:11] <asac> lool: done
[14:11] <elmo> smoser: oh, never mind, that page no longer says what i thought it said
[14:11] <asac> lool: the testsuite doesnt work. i noted it as a nice to have
[14:11] <asac> lool: the type punning things i also noted and the fread not dealt return values
[14:12] <asac> i asked for bugs for those, but didnt block MIR
[14:12] <lool> asac: thanks
[14:13] <asac> lool: i have my mir slot (set up since this week) in 20 minutes. so if you want me to look at something else let me know
[14:14] <lool> asac: Actually if you could tend to usbmuxd and libiphone that'd be great
[14:15] <lool> asac: I'll still do some quick review on them since I started, it should give a better coverage
[14:15] <asac> ok post your findings
[14:15] <asac> though i expect your quick review should be good enough ;)
[14:26] <asac> libiphone done
[14:35] <sladen> asac: the 1.0 release of libiphone should be out Real Soon Now(tm)
[14:36] <asac> kk
[14:47] <sbalneav> DktrKranz: I'm going to cook a new release today
[14:52] <DktrKranz> sbalneav: excellent! I'll prepare update for Debian, we're close to have it in unstable again :)
[14:53] <sbalneav> DktrKranz: Excellent!  I've put in a lot of work to get Sabayon working again for Debian/Ubuntu, I'm glad!
[14:53] <asac> sladen: is usbmuxd running as root?
[14:54] <sbalneav> I'm basically an upstream now for sabayon.
[14:54] <sbalneav> DktrKranz: if you or any other debian devs have problems with sabayon, just ping me here, or in #sabayon at irc.gnome.org
[14:59] <DktrKranz> sbalneav: sure! you already fixed one of my blockers :)
[15:09] <sladen> asac: it immediately drops to user 'usbmuxd'
[15:11] <sladen> asac: it presents a FIFO in /var/run/usbmuxd (same place and talking the same protocol as on Mac OSX).
[15:11] <asac> sladen: where in code is the parsing of input done?
[15:11] <asac> i mean the input we get from device ;)
[15:12] <sladen> asac: multiple applications can then request proxy sessions to particular TCP ports on the device(s);  these are wrapped up and encapsulated in Apple's usbmux [sic] wire protocol and bunged over the USB
[15:12] <rendero> where does drkonqui stores the crashes ?
[15:15] <sladen> asac: daemon/device.c
[15:20] <tkamppeter> someone knows what it means if "mkdir -p" exits with status 2?
[15:24] <sladen> asac: device_data_input() -> device_tcp_input() -> connection_device_input()
[15:33] <asac> sladen: yeah. commented on bug
[15:36] <sladen> asac: oh which bug?
[15:37] <sladen> tkamppeter: not off the top of my head.  Probably lack of permission, or lack of disk space
[15:37] <cjwatson> tkamppeter: the info documentation simply says "a nonzero value indicates failure".  I would expect to see a more detailed error message to accompany the exit status
[15:37] <asac> sladen: the MIR for usbmuxd
[15:37] <asac> not your bug, but you seem to take care for that package :)
[15:40] <cjwatson> tkamppeter: from a quick glance through the source, I actually don't see any way it could exit 2, but I'm probably just missing something.  I don't expect trying to decode the exit status will be very useful in practice
[15:43] <tkamppeter> cjwatson, sladen: Thanks, I did not find anything on Googling, and thought that there are perhaps some standard exit codes or missing documentation. With what I found I am wondering how mkdir can exit 2.
[15:44] <cjwatson> tkamppeter: it's not really important
[15:44] <cjwatson> documented: zero => success, nonzero => failure.
[15:45] <tkamppeter> I can even manually do this mkdir (it fails when executed by a web app) on the same server and as the user as which web apps get executed.
[15:45] <aburch> Could somebody request removal of the `anyevent' package?  See #470560 for the rationale (/me does not use Ubuntu, so I cannot look for reverse dependencies).
[15:52] <sladen> asac: 'sent' upstream
[15:53] <sladen> asac: could you sanity check the privilege dropping too?  (grep drop_privileges daemon/main.c
[15:57] <asac> sladen: that looks good afaict
[15:58] <asac> sladen: hmm. maybe drop_privileges should default to 1?
[15:58] <asac> who is running that?
[15:58] <asac> e.g. who is supposed to use -U?
[15:59] <sladen> asac: what about the locking and notifying of previously copies over the drop---there's more of it than I'd like
[15:59] <sladen> asac: A user /can/ it as themselves, if change the FIFO location away from the standard Apple location
[15:59] <sladen> asac: so -U is basically used from the udev rules
[16:01] <asac> sladen: the locking?
[16:01] <asac> or loggin?
[16:02] <sladen> asac: grep for kill()
[16:05] <sladen> asac: main() { parse_opts(), set_signal_handlers(), lock file handling,  drop_privs,  usb_init() } ---so there shouldn't be any externally derived data until after the drop
[16:07] <asac> the killing wont work if not run as root if the previous instance didnt rop privileges
[16:07] <asac> otherwise i agree
[16:13] <cjwatson> tkamppeter: use strace or something to figure it out
[16:17] <tkamppeter> cjwatson: Thanks, I have already found the cause of the problem, was not mkdir by itself.
[16:56] <mterry> How do I download a package from debian NEW?  (specifically http://ftp-master.debian.org/new/google-gadgets_0.11.1-1.1.html)
[16:56] <seb128> mterry, you can't
[16:58] <mterry> seb128, oh.  How do they get accepted then, if one can't see the changes?
[16:58] <seb128> mterry, who is one?
[16:58] <seb128> mterry, the archive admin can
[16:58] <seb128> the archive admins
[16:58] <mterry> seb128, ah, ok
[16:59] <mathiaz> ttx: the -server iso have been respun?
[17:00] <ttx> mathiaz: see -server
[17:00] <ttx> mathiaz: yes, another day, more ISo testing :)
[17:04] <sbalneav> DktrKranz: FYI, sabayon-2.29.5.tar.gz just got released.  It'll be working it's way through the usual GNOME mirrors
[17:08] <DktrKranz> sbalneav: yeah, just got the mail, thanks! :)
[17:15] <slangasek> luisbg: it appears UbuntuStudio install is broken right now because it wants usplash, which is conflicted by plymouth, which is now standard; do you guys want to try to fix this for alpha-2?
[17:27] <mathiaz> apw: hi
[17:27] <mathiaz> apw: is the i386 -virtual kernel flavour supposed to be -generic-pae?
[17:28] <mathiaz> apw: in the past releases it used to be -server
[17:43] <mathiaz> kenvandine: hi - are you sponsoring the ubuntuone-client packages usually?
[17:44] <mathiaz> kenvandine: there is bug 495676 about a karmic SRU
[17:49] <matti> Folks, can somebody update MD5/SHA1 hash for this little fella?
[17:49] <matti>  W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/pool/restricted/f/fglrx-installer/fglrx-amdcccle_8.660-0ubuntu4_i386.deb Hash Sum mismatch
[17:50] <cjwatson> matti: I'm pretty certain it's fine in the archive (it's extraordinarily rare for this to be actually an archive-side problem); it's almost certainly a problem on some web proxy between you and the archive, unfortunately
[17:51] <matti> Hm.
[17:51] <matti> It is not me actually.
[17:51] <matti> I am talking on behalf of AlanBell ;]
[17:52] <matti> cjwatson: And you were very right, indeed ;]
[17:52] <matti> [18:51:40] < AlanBell> actually it worked now
[17:52] <matti> [18:51:53] < AlanBell> mobile broadband ftl
[17:52] <matti> cjwatson++
[18:15] <mathiaz> jcastro: hi!
[18:15] <mathiaz> jcastro: is there a standard bug reply for "Forward this patch to Debian please?"
[18:15] <mathiaz> jcastro: this is for example in bug 229760
[18:17] <Daviey> mathiaz: you could just use submittodebian yourself :)
[18:17] <mathiaz> Daviey: the patch is not the ubuntu package yet
[18:17] <Daviey> mathiaz: ah
[18:52] <jcastro> mathiaz: not as far as I know, you could just add one here: https://wiki.ubuntu.com/Bugs/Responses
[18:52] <jcastro> mathiaz: an adaptation of this one perhaps: https://wiki.ubuntu.com/Bugs/Responses#A bug that should be handled upstream
[18:53] <mathiaz> jcastro: ah nice. Thanks!
[18:57] <mathiaz> jcastro: is https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Bugs%20fixing%20small%20details still valid?
[18:57] <mathiaz> jcastro: are there any other tags/process that should be used bugs that needs to be forwarded to upstream?
[18:58] <jcastro> mathiaz: having the open task is all you need
[18:59] <jcastro> mathiaz: however, if would be wise to have someone checking bugs with open upstream tasks and fixed in ubuntu on a regular basis
[18:59] <mathiaz> jcastro: I've opened an empty Debian task - so it's all good :) thanks
[19:29] <slacker_nl> hi, what was the irc channel again for canonical sysops?
[19:30] <Pici> slacker_nl: #canonical-sysadmin
[19:30] <slacker_nl> Pici: thnx
[20:55] <mathiaz> kees: Hi! - is export DEB_BUILD_HARDENING=1
[20:55] <mathiaz> kees: hm- - is ^^ enough to enable-pie?
[20:55] <mathiaz> kees: in apache2, there is configure option for enabling pie
[20:56] <mathiaz> jdstrand: ^^ actually you did the last merge
[20:56] <mathiaz> jdstrand: in apache2 debian/rules enable-pie is no longer there
[20:56] <jdstrand> mathiaz: I didn't do the merge, I applied a security update
[20:57] <jdstrand> oh, wait, maybe I did
[20:57] <jdstrand> mathiaz: https://launchpad.net/ubuntu/+source/apache2 show zul as the last merger
[20:58] <kees> mathiaz: you need two things: export DEB_BUILD_HARDENING=1 in rules, and hardening-wrapper in debian/control
[20:58] <mathiaz> jdstrand: right - the package branch is not up-to-date
[20:58] <kees> mathiaz: upstream removed native pie?
[20:58] <kees> mathiaz: actually, I didn't think apache2 had that, I thought it was only samba.
[20:59] <mathiaz> kees: hm well - debian/rules has --enable-pie
[20:59] <kees> mathiaz: anyway, if you want, try building with  hardening-includes  instead of hardening-wrapper.  I can find an example of that.
[20:59] <zul> that branch may not be up to date
[20:59] <kees> mathiaz: ah, okay.
[21:00] <zul> kees: hardening is there i dont think the branch is up to date
[21:03] <mathiaz> kees: so apache2 build-depends on hardening-wrapper, export DEB_BUILD_HARDENING=
[21:03] <mathiaz> kees: and --enable-pie in configure
[21:04] <mathiaz> kees: should some of this be dropped?
[21:04] <mathiaz> kees: it export DEB_BUILD_HARDENING=
[21:04] <mathiaz> kees: it export DEB_BUILD_HARDENING=1
[21:04] <kees> mathiaz: that's probably correct as upstream probably only does the PIE part, but the wrapper also enables -Wl,-z,now which we do for our PIE builds
[21:04] <mathiaz> kees: ok - so it should be kept as it is now
[21:05] <kees> mathiaz: in the off chance that --enable-pie does something additional to support PIE in apache, yeah, I would leave it all as-is.
[22:20] <kwwii> does anyone here understand what the --priority option for dh_gconf actually does?
[22:20] <kwwii> I have read the man page but it leaves me clueless
[22:22] <RAOF> It looks like it'll set the priority of the gconf defaults you install; so packages can override other defaults.
[22:22] <ScottK> slangasek: I got tired of libicu20, so I've now uploaded all the rebuilds needed to see it go except boost1.38 and I'm closing in on just removing that.
[22:24] <kwwii> RAOF: yeah, but does a higher number mean more important or less?
[22:24] <RAOF> More.
[22:24] <kwwii> I know, I can figure it out by testing but I'd rather not waste the time if anyone knows offhand ;)
[22:26] <micahg> tedg: are you available?
[22:27] <tedg> micahg: Sure.
[22:27] <tedg> micahg: What's up?
[22:27] <micahg> tedg: I think I sent an email a while back about updating a mozilla bug with some info about libindicate
[22:28] <micahg> tedg: would you be able to update mozilla 478463
[22:28] <micahg> please :)
[22:29] <tedg> micahg: I don't have a login there :-/
[22:29] <micahg> tedg: it's free to create an account :)
[22:30] <micahg> tedg: or if you give me the info requested I can post it
[22:31] <tedg> micahg: About the desktop file?  It seems that Thunderbird would have to have one it installs, right?
[22:31] <micahg> tedg: yes, but not from mozilla
[22:32] <asac> micahg: you can link the bug
[22:32] <micahg> tedg: they were looking for API docs
[22:32] <asac> then the launchpad users can communicate via launchpage
[22:32] <micahg> asac: already did
[22:32] <tedg> micahg: Seriously?  They're bitching about us modifying how their apps are seen and they don't even provide the most basic interface for the app.  Wow.
[22:32] <asac> pad
[22:32] <asac> tedg: you can use the launchpad bug to talk to them ;)
[22:32] <asac> use reply to upstream bug
[22:32] <micahg> ok, right :)
[22:32] <micahg> forgot
[22:33] <micahg> bug 334344
[22:36] <micahg> tedg: the FF bug is worse ;)
[22:39] <kwwii> duh, sometimes one should go to bed when one is tired instead of making an idiot of oneself
[22:42] <tedg> micahg: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/334344/comments/43
[23:13] <tweakt_> I've created a custom installer cd, but base-installer doesn't seem to be installing any kernels, even though they are available in the packages I've included on the CD. Any hints as to where to start looking?
[23:14] <tweakt_> In /tmp I see available_kernels.txt and available_kernels.txt.unfiltered, both empty
[23:21] <tweakt_> looks like apt was never configured, so no apt-cache, no lines in /etc/apt/sources.list nothing in sources.list.d
[23:22] <tweakt_> nevermind... I haven't preseeded my keyring used to sign the cd
[23:23] <cjwatson> tweakt_: ... you beat me to it, I was about to start making suggestions but you're ahead of me
[23:23] <cjwatson> tweakt_: you could just turn off authentication for now
[23:23] <cjwatson> tweakt_: debian-installer/allow_unauthenticated=true
[23:24] <tweakt_> whats the best method of getting our key into the system prior to apt-setup? customize ubuntu-keyring?
[23:25] <cjwatson> that's reasonable, although I've come to believe that signing CDs is a bit of a waste of effort
[23:25] <cjwatson> the user's booting from the thing - they trust it implicitly
[23:25] <cjwatson> signing the checksum for downloaders, that's a different matteer
[23:25] <cjwatson> -e
[23:25] <tweakt_> ahh true
[23:25] <cjwatson> so personally, I'd recommend just not signing the Release file on the CD at all
[23:26] <cjwatson> d-i should be OK with that
[23:26] <tweakt_> I see, cause if I wanted to inject something I would just replace the key and resign the whole thing
[23:26] <cjwatson> indeed
[23:26] <cjwatson> or just remove the key
[23:26] <cjwatson> or replace the entire CD with something else :)
[23:27] <tweakt_> We're still going to want a key on the system for custom packages
[23:27] <cjwatson> you want a key for authenticating network archives
[23:27] <tweakt_> yes
[23:27] <cjwatson> apt-setup has some special preseeding for that
[23:28] <cjwatson> look for things like apt-setup/local0/key in the installation guide
[23:28] <tweakt_> oh, right. cool.
[23:28] <tweakt_> btw, ended up using a combo of germinate + reprepro to build things
[23:29] <tweakt_> germinate output gets pulled into a selections list, used to filter what reprepro mirrors
[23:29] <tweakt_> works nicely


[08:56] <mantas-baltix> Hi all
[08:58] <mantas-baltix> How I can help to speed-up inclusion of simple 3 lines patch from Debian to Ubuntu 18.04 LTS? See bug #1781746
[08:58] <mantas-baltix> bug is already fixed in Debian initramfs-tools ver 0.132, just 3 lines patch from Debian, see https://salsa.debian.org/kernel-team/initramfs-tools/commit/312393b0cf1231125eeff3d1a2b6b778a935c21d
[09:08] <seb128> mantas-baltix, hey, subscribing ubuntu-sponsors would be better, but you might want to try to nag someone from foundations team on IRC to review it, e.g xnox or cyphermox or vorlon
[09:09] <seb128> mantas-baltix, you can also tag it rls-bb-incoming for nominating for review on the b serie
[19:09] <johnnyfive> Hello, i'm trying to understand why iucode-tools is in both main and restricted (sources are only in restricted, package is published in main AND restricted). Is this a bug?
[19:15] <mdeslaur> johnnyfive: it used to be in restricted but then we decided that the kernel needed to depends on microcode updates, so it got copied to main
[19:16] <jbicha> the binaries are only in main https://people.canonical.com/~ubuntu-archive/madison.cgi?package=iucode-tool
[19:18] <johnnyfive> mdeslaur, however the sources are still in restricted? is this going to be changed or kept as-is?
[19:21] <mdeslaur> johnnyfive: I don't know...is that a problem?
[19:22] <mdeslaur> an AA would have to chime in to say why the sources weren't copied
[19:26] <jbicha> johnnyfive: you can file a bug against the package and subscribe ubuntu-archive
[19:27] <johnnyfive> mdeslaur, it's not a problem, just need to account for it if this is intended. AFAIK this breaks the contract of how the repositories are set up. If, however, this is intended and I misunderstand the deb ecosystem, that's fine, I just have to prepare for it.
[19:45] <jbicha> johnnyfive: there are several packages where the source is in main but some binaries are in universe
[20:33] <bdmurray> Does anybody have a better idea to check for fglrx or nvidia than this? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/xorg_fix_proprietary.py#L106
[20:43] <cjwatson> jbicha: That way round is permitted, but source in universe + binary in main wouldn't be.  I think the situation that johnnyfive has pointed out is a clear bug.
[20:45] <cjwatson> vorlon: ^- looks like you missed a bit in https://bugs.launchpad.net/ubuntu/+source/iucode-tool/+bug/1738272
[20:45] <cjwatson> (comment #3 shows you moving the binaries but not the source)
[20:49] <bdmurray> cjwatson: he's travelling today
[21:06] <johnnyfive> cjwatson, thanks for the investigation/information
[21:28] <cjwatson> bdmurray: yeah, no rush, it's been like this since bionic :)