=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[04:09] <pitti> Good morning
=== freeflying is now known as freeflying_away
[04:35] <xnox> pitti: i didn't go to sleep yet =/ i guess i should =)
[04:37] <pitti> xnox: eek; yes indeed :)
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
[07:39] <infinity> doko: Removing libmudflap0 made libmudflap0-4.4-dev, libmudflap0-4.6-dev, libmudflap0-4.7-dev uninstallible.
=== iahmad is now known as iahmad|afk
=== freeflying_away is now known as freeflying
=== iahmad|afk is now known as iahmad
=== freeflying is now known as freeflying_away
=== tkamppeter_ is now known as tkamppeter
[11:20] <cjwatson> barry: Any objection to me syncing python-wsgi-intercept from Debian over the top of our entirely Ubuntu-local wsgi-intercept source package?  debdiff is http://paste.ubuntu.com/6381487/
=== brainwash_ is now known as brainwash
=== MacSlow is now known as MacSlow|lunch
=== andreas__ is now known as ahasenack
[12:42] <seb128> jpds, hey, I saw you did some redshift uploads today, could you check https://bugs.launchpad.net/ubuntu/+source/redshift/+bug/868904 (it's in the sponsoring queue)?
[12:42] <ubottu> Ubuntu bug 868904 in Redshift "Redshift fails to start with session due to geoclue failure" [High,Confirmed]
=== christoffer_ is now known as Christoffer
=== Christoffer is now known as Guest2975
=== Guest2975 is now known as christoffer__
=== christoffer__ is now known as christoffer_
[12:43] <jpds> seb128: Oh, that'd be marrusl's patch.
[12:44] <jpds> seb128: Yeah, I'll add that in.
[12:44] <seb128> jamespage, hey, could you look at https://bugs.launchpad.net/horizon/+bug/981269? you wrote on it a while ago saying you would handle it and unsubscribed sponsors, it's back in the sponsoring queue ... is that still on your list?
[12:44] <ubottu> Ubuntu bug 981269 in horizon (Ubuntu Precise) "instance_type is still set as a property value of "none" even when flavors cannot be retrieved" [Medium,In progress]
[12:44] <seb128> jpds, thanks
=== iahmad is now known as iahmad|afk
[12:53] <seb128> slangasek, xnox, infinity, cjwatson: hey, is there any chance you guys could look at the sponsoring queue a bit? The red items are mostly stuff desktop doesn't feel competent enough to review (sysvinit, debian-installed, efitbootmgr, acpi-support, partman-base, ...)
[12:54] <seb128> smoser, jamespage: same for server stuff, you guys have horizon/cloud-init/mysql stuff in there
[12:54] <cjwatson> The partman-base one is probably mine, I'll try to look today
[12:54] <seb128> cjwatson, thanks
[12:54] <cjwatson> Part of a gigantic bug of doom
[12:56] <seb128> cjwatson, xnox, https://code.launchpad.net/~srwarren/debian-installer/tegra/+merge/175967 ... do you have any recommendation on who would be right for review?
[12:56] <mdeslaur> cjwatson: FYI, I'm going to release an openssh security update for saucy today for http://www.openssh.com/txt/gcmrekey.adv
[12:56] <xnox> seb128: i'd say infinity
[12:56] <seb128> infinity, ^? ;-)
[12:56] <seb128> xnox, thanks
[12:57] <mdeslaur> cjwatson: do you want me to do the trusty upload also, or shall I wait?
[12:59] <brainwash> pitti: just curious, wouldn't it be possible to push your systemd-shim package into proposed? it fixes the issue for most users already
[13:00] <barry> cjwatson: go for it!
[13:02] <cjwatson> seb128: yeah, that's an infinity one
[13:02] <cjwatson> mdeslaur: go ahead; I was just in the process of chasing up http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722970 so I can do the update to 6.3 ...
[13:02] <ubottu> Debian bug 722970 in fail2ban "fail2ban: adapt to OpenSSH 6.3" [Important,Open]
[13:02] <rbasak> seb128: jamespage is at ODS this week.
[13:02] <cjwatson> barry: done, thanks
[13:02] <mdeslaur> cjwatson: thanks...oh, you might want to update to 6.4 :)
[13:02] <seb128> cjwatson, thanks
[13:02] <seb128> rbasak, ok, thanks
[13:03] <cjwatson> mdeslaur: well, either one :)
[13:03] <cjwatson> need to avoid the regression in fail2ban either way
[13:23] <seb128> slangasek, bdrung: how do we move forward on https://code.launchpad.net/~vorlon/ubuntu-packaging-guide/dont-recommend-packaging-dev/+merge/192244 (that's in the sponsoring queue ... should it be there, or should we mark it Work in progress to get it out of the queue? (seems it's a discussion between concerned parties rather a sponsoring request)
[13:36] <bdrung> seb128: i think we should raise it to the wider audience or we should adjust the text to reflect that _some_ developers prefer to use packaging-dev and others selective installations of tools
[13:37] <seb128> bdrung, seems like moving the discussion to ubuntu-devel@ could be a good idea there?
[13:37] <bdrung> seb128: yes
=== MacSlow|lunch is now known as MacSlow
[14:13] <seb128> xnox, do you need sponsoring for https://code.launchpad.net/~xnox/ubuntu-dev-tools/fix-series-alias-lookups/+merge/191700 ? can't you just upload?
[14:14] <xnox> seb128: i need code review, sensibility check, et al. I'm not "ubuntu-dev-tools" upstream.
[14:14] <seb128> xnox, who is upstream for those?
[14:14] <xnox> seb128: and i think it got rejected on irc, setting the status appropriately.
[14:15] <seb128> xnox, thanks
[14:15] <xnox> seb128: well: who-uploads ubuntu-dev-tools
[14:15] <xnox> seb128: mostly bdrung
[14:15] <xnox> seb128: in general if a core-dev requests code-review, there are $reasons =)
[14:16] <seb128> xnox, yeah, but stuff sit in the sponsoring queue for months, it would be nice if people were a bit more active seeking for reviews when that happens
[14:32] <psusi> according to the man page for dpkg-source, you have to specify --abort-on-upstream-changes to have it do so, but it seems to be on by default... why is this and how do you turn it off?
[14:37] <psusi> ( and it isn't in debian/source/local-options... in fact there is no debian/source )
[14:38] <xnox> psusi: typically i add files to ignore which are modified/regenerated at build time. Or add them to debian/clean, such that they are always removed.
[14:38] <xnox> psusi: are you sure it's the only warning? maybe there are errors, such as unrepresentable changes in diff.
[14:38] <xnox> psusi: please paste full error.
[14:38] <psusi> that's the one
[14:39] <psusi> I'm trying to rebuild the source package from the debian git repo for util-linux... let me get it up again
[14:40] <xnox> psusi: git repository is not a valid source package format =)
[14:40] <xnox> psusi: thus i'm not sure why you think "dpkg-source manpage" is at fault here ;-)
[14:41] <psusi> xnox: because this is how lamont maintains the package... debianised in the git repo
[14:42] <psusi> so you must be able to build the source package from there but it seems to complain that there have been upstream changes
[14:42] <xnox> psusi: locally I have source/format "1.0" defined in util-linux package. So i'd guess you have unrepresentable changes in your tree somehow.
[14:42] <psusi> well yea, that's intentional
[14:44] <psusi> ohh I see, that's just a warning... the real error is the unrepresentable changes... hrm...
[14:44] <lamont> psusi: git clone, and then debian/rules autofiles; debuild "$@"
[14:45] <psusi> pfft.. it's trying to include the .git direcotry
[14:46] <lamont> debuild -I.git
[14:46] <xnox> lamont: i think the changelog is dated. As 2.19 tags are merged, yet changelog is still at 2.17.
[14:46] <lamont> xnox: ON WHAT BRANCH
[14:46]  * xnox tried fetching a tarball matching the changelog, how naive
[14:47] <lamont> xnox: master is so totally irrelevant to anything
[14:47] <xnox> lamont: ok. It's just what $ debcheckout util-linux
[14:47] <xnox> gave me.
[14:47] <psusi> lamont: would be nice to delete it then and set the HEAD to something sane ;)
[14:48] <lamont> debcheckout... I can sort of tell what that command is going to try based on the name...
[14:49] <xnox> lamont: as per debian policy Vcs-git should point to packaging repository, there is no syntax agreed on specifying packaging brach, thus it is expected for HEAD to point to something packaging-like. =)
[14:49] <lamont> xnox: that makes sense, sort of
[14:49] <xnox> lamont: anyway, i'll go away and do my thing. But you certainly placed enough hoops =)))) to make sure that one knows what they are doing, when touching it ;-)
[14:49] <xnox> which is good =)
[14:49] <lamont> git branch -l -a <-- pretty much tells the tale
[14:51] <psusi> debuild -I.git is not working, it's still trying to include .git
[14:51] <xnox> lamont: is the remote repository up to date? git tag --list | grep v2.20, gives me nothing.
[14:52] <xnox> lamont: yet you did upload 2.20.1-5
[14:52] <psusi> the git url in the control file is also wrong ;)
[14:52] <psusi> seems debian migrated the git repo and the web browser link auto forwards you
[14:52] <psusi> the correct url is now git://anonscm.debian.org/users/lamont/util-linux.git
[14:55] <xnox> psusi: right, I see. yeah, now i get v2.21 and v2.20 et al.
[14:58] <lamont> clearly, benevolent neglect is failing here.
=== _salem` is now known as _salem
=== _salem is now known as salem_
[16:04] <cjwatson> Ooh, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725767
[16:04] <ubottu> Debian bug 725767 in ftp.debian.org "RM: dbs -- ROM; deprecated, superseded by the `3.0 (quilt)' source format" [Normal,Open]
[16:04] <cjwatson> And it's safely removable from Ubuntu too
[16:48] <xnox> it's the end of an era.
[17:14] <cjwatson> slangasek: If you managed to find time to merge isdnutils, we could remove automake1.7 and the kitten quotient would increase
=== smb` is now known as smb
[17:24] <mdeslaur> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
[17:29] <fishor> hello devs. are there any way to connect hardware database with bug reports in launchpad? I working on atheros ath9k-htc firmware and it is hard to find related bugs. Mostly they are reported per factory name, not per driver or related chip
[17:30] <sladen> fishor: try ogra_, who used to look after it a (long, long) time agin
[17:30] <sladen> ago
[17:31] <sladen> fishor: ogra_ might be able to tell you who took over the baton
[17:31] <fishor> ogra_, ping
[17:31] <fishor> sladen, "took over the baton"?
[17:32] <fishor> sladen, do you means this functionality or this hardware?
[17:34] <ogra_> sladen, fishor i have had nothing to do with the hardware database in 4 years or so ...
[17:34] <ogra_> i only wrote the initial stuff for it about 8 years ago
[17:35] <ogra_> afaik it is called checkbox today ... and there should be a LP team ...
[17:35] <bdmurray> slangasek: regarding bug 1193509 apport-checkreports does kind of print the crash file name
[17:35] <ubottu> bug 1193509 in apport (Ubuntu) "invalid problem report" [Undecided,New] https://launchpad.net/bugs/1193509
[17:35] <fishor> ogra_, how about custom search with email notification?
[17:36] <cjwatson> IIRC the old hwdb is scheduled for removal from LP
[17:36] <ogra_> yeah
[17:36] <ogra_> its dead since ages
[17:36] <slangasek> bdmurray: ah, so we could check that $MATCH is in the list?
[17:37] <ogra_> fishor, i dont know anything about checkbox or whatever the new hwdb is (if there is even any)
[17:37] <bdmurray> slangasek: well its a truncation of the filename - print(r.split('.')[0].split('_')[-1])
[17:38] <bdmurray> but that could probably be fixed
[17:40] <fishor> ogra_, are there any good way to help finding bugs related to some chip or project?  For example "TP-Link TL-WN821N" and "TP-Link TL-WN822N" and so on ... may have differiert  HW insight
[17:40] <slangasek> bdmurray: or we could do the same truncation on $MATCH for matching purposes, maybe?  but yeah, that seems like a good approach
[17:40] <fishor> mostly they are never reported upstream
[17:41] <fishor> since i work on this HW i would like to find some one who can report enough information.
[17:42] <bdmurray> fishor: if this is something collected by apport when bugs are reported you might find it in bug descriptions or probably in attachments of bugs reported by apport.  You could then log for bug reports with this information.
[17:42] <bdmurray> s/log/look/
[17:42] <fishor> for now i just take a list from wikidevi and search for device names,
[17:42] <bdmurray> slangasek: okay thanks
[17:43] <fishor> bdmurray, first i need to find related bugs - it is already problematic
[17:43] <fishor> then, apport usually do not provide information i need
[17:45] <fishor> we know there is some crasher in our fimware, it seems to be related to some spesial conditions or access points, but till now, no one provided information we need
[17:47] <slangasek> cjwatson: blah, how did I ever become TIL for isdnutils
[17:48] <fishor> is it possible to extend apport or ubuntu-bug, to help gether wireless related information?
[17:48] <cjwatson> slangasek: ... or get somebody in Germany (who therefore cares) to do it :-)
[17:48] <slangasek> oh, I see how, I multiarcheded it
[17:50] <bdmurray> fishor: apport when used to report a bug about the linux package collects lsusb information - this is a usb device right?
[17:50] <fishor> yes
[17:51] <bdmurray> so you could find people with this hardware if that's what you want to do
[17:55] <fishor> uff, i just found the reason why it was not enough results with ath9k_htc. For some reason they are reported as ath9k_usb
[18:00] <fishor> bdmurray,  here is one example, Bug #1049383  it is still imposible to get needed information :(
[18:00] <ubottu> bug 1049383 in Linux "ath9k_usb: TL-WN821N v3 (AR7010+9287) Connection drops" [High,Confirmed] https://launchpad.net/bugs/1049383
[18:01] <fishor> but is is probably not new for you :)
[18:01] <slangasek> cjwatson: isdnutils hasn't been merged with Debian since feisty; this is going to take a while
[18:03] <bdmurray> fishor: you might look at bugs reported about network-manager by apport as that would contain some of the wireless information you asked for in comment #7
[18:11] <fishor> bdmurray,  suddenly there is no results for network-manager + ar9271 or ar7010, nor ath9k_htc or usb
[18:12] <fishor> may be there is any
[18:14] <bdmurray> Did you also check expired bugs?
=== salem_ is now known as _salem
[18:25] <fishor> bdmurray, no results. but thank you for the tip
[18:35] <hyperair> so upower -d shows can-suspend: no, but pm-is-supported --suspend shows that it is supported (exit code 0) and pm-suspend does work.
[18:35] <hyperair> what gives?
[18:35] <dave_>  
[18:36] <hyperair> ?
[18:45] <seb128> bdmurray, hey, are you (or somebody else in foundations) looking at debugging https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1024590? it's ranked 1 in e.u.c daily issues now that the hud and some other ones got resolved
[18:45] <ubottu> Ubuntu bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed]
[18:45] <seb128> in fact update-manager has the 1 and 3 (and 2 is fixed so going to drop in the list)
[18:46] <seb128> dobey, hey, are you looking at the s-c issues on e.u.c? It's having the 7-8-12-17 entries there
[18:47] <seb128> ev, ^ 7-8 are failed retracing, anything we could do to have a that fixed? (e.g who has access to the e.u.c retracers to debug retracing issues?)
[18:50] <bdmurray> seb128: I got as far as I could with bug 1024590 - could use some help from glatzor or mvo...
[18:50] <ubottu> bug 1024590 in update-manager (Ubuntu Saucy) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Confirmed] https://launchpad.net/bugs/1024590
[18:52] <dobey> seb128: the failed retrace ones are the webkit2 issue
[18:52] <seb128> bdmurray, I tried to ping mvo this morning without success
[18:52] <seb128> dobey, I doubt it, there is no webkit in the filenames
[18:53] <dobey> seb128: the partial trace that is there includes cairo, which is where the webkit crash is happening
[18:53] <seb128> shrug
[18:53] <seb128> dobey, I opened an upstream bug on webkit but nobody replied ... did you get any luck trying to debug it?
[18:54] <dobey> and i can't view the list of crashes on errors.ubuntu.com, unless i select a specific package so the 7-8-12-17 numbers mean nothing to me
[18:55] <dobey> seb128: no i don't have time to try and debug webkit
[18:56] <seb128> dobey, e.u.c doesn't work for you? (you say you can't see the list)
[18:56] <seb128> https://errors.ubuntu.com/problem/eb9f7ebe2cb2dbf7d79986d38e2d000bb4bfaf04
[18:56] <seb128> https://errors.ubuntu.com/problem/ddf3377b6988d948653e94fa421be8d713a624fc
[18:57] <dobey> seb128: if i tell it to display all binary packages it just says "No data to display"
[18:57] <seb128> https://errors.ubuntu.com/problem/94f7beb32c9a9172de3f9281691510762d655d47
[18:57] <seb128> https://errors.ubuntu.com/problem/8a013246d3c6a42c90701932a3a8d4dfde51af89
[18:57] <dobey> seb128: if i select only software-center, it displays only software-center
[18:57] <seb128> dobey, what if you load https://errors.ubuntu.com/?release=Ubuntu%2013.10&period=day ?
[18:57] <dobey> that seems to have loaded
[18:57] <seb128> but the table is empty?
[18:58] <dobey> not on that link, no
[18:58] <dobey> although the numbers don't exactly line up with the ones you mentioned
[19:00] <seb128> weird, dunno about that
[19:00] <dobey> https://errors.ubuntu.com/problem/8a013246d3c6a42c90701932a3a8d4dfde51af89 looks like a bug in libmenu?
[19:00] <seb128> but yeah, changing the combo doesn't always work
[19:00] <seb128> could be
[19:01] <dobey> or gnome-menus or whatever it's called
[19:20] <bdrung> xnox, seb128: everyone can commit changes to ubuntu-dev-tools, but only a few developers do the upload to debian.
[19:23] <bdrung> xnox, seb128: re the sponsoring request: i am not that familiar with this code segment. so the requested change could be what we want. a test case would be nice.
[20:10] <slangasek> cjwatson: wow, the isdnutils merge is mind-bogglingly bad, somewhere along the way someone added a dpatch build-dep to the package in Ubuntu :p
[20:11] <stgraber> slangasek: do we actually have any remotely useful delta on that one?
[20:12] <slangasek> stgraber: how can I know the answer to that before merging it? ;)
[20:12] <stgraber> slangasek: by reading the very well maintained and readable changelog? :)
[20:12] <tumbleweed> does hardware supported by that package still exist?
[20:12] <slangasek> heh
[20:13] <stgraber> tumbleweed: I'm pretty sure I still have an ISDN PCI card somewhere, not that I've used it in the last decade ;)
[20:14] <slangasek> stgraber: there's some stuff, it may be mostly merged into Debian but it's different enough I can't be sure yet
[20:15] <infinity> slangasek: I assume you're tearing out the dpatch bits as you merge?
[20:15] <slangasek> "tearing out" would be too gentle
[20:24] <infinity> I'm really not okay with this Midway system being so much faster than my old PPC machine.
[20:24] <infinity> On the one hand, it's ten years newer.  On the other hand, it's ARM.  It's not allowed to be fast.
[20:25] <slangasek> on the gripping hand, oh no it's an ARM with three hands
[20:25] <infinity> SO MANY HANDS.
[20:32] <stgraber> infinity: oh, we actually have a midway system somewhere now?
[20:32] <infinity> stgraber: OEM has a chassis with some cards.  I used it for the d-i enablement a few months ago, and I'm using it right now for glibc test building.
[20:32] <stgraber> nice, any of you tried running VMs on that stuff?
[20:33] <infinity> That's still a WIP, I believe.
[20:34] <infinity> Though the goal is to ship 14.04 with a sane A15 KVM and libvirt solution, I think.
[20:35] <stgraber> would be kind of nice if we could get working openstack on A15 (and maybe A57?) hardware, having a few of those in canonistack and buildstack would solve our current porter and buildd situation
[20:36] <infinity> stgraber: Our buildd situation is great (except for PPAs).
[20:36] <infinity> stgraber: But yeah, my plan for builders is to skip from our A9s to A57s, and do some PPA virt fanciness there when we have 'em.
[20:36] <stgraber> infinity: btw, how do those calxeda box boot? Should I add some code to my d-i branch to spit out something they can actually boot from?
[20:36] <infinity> stgraber: I'm not sure I can justify the budget to upgrade the A9s to A15s.
[20:36] <hallyn_> tjaalton: sadly, Xspice is giving me segv :(  will have to try under debian ...
[20:37] <infinity> stgraber: They boot raw vmlinuz/initrd.gz, the one pooped out in the base generic/ directory works fine.
[20:38] <stgraber> infinity: yeah, doesn't seem worth it, the ton of A9 we have currently clearly is enough to deal with any distro workload. The qemu based buildds kind of suck but they shouldn't be getting any worse and aren't on the critical path since we can turn on devirt for distro use, so waiting for A57 based server seems perfectly reasonable.
[20:38] <stgraber> infinity: ah good, so they have their bootloader and config built into some kind of onboard chip?
[20:40] <infinity> stgraber: Yeah, u-boot's in firmware, and so is the DTB.
[20:40] <infinity> stgraber: Would be a weird chicken-and-egg issue to say "sure, you can pxeboot this, but only after you insert 24 SD cards with u-boot on them".
[20:41] <infinity> (viable for a Panda, laughable for a server blade chassis)
[20:42] <stgraber> sounds like a reasonable implementation. I guess they're using the stock u-boot pxe implementation which basically just parses a subset of pxelinux.cfg, grabs kernel and initrd, and then they pass the dtb to the kernel on top of that
[20:44] <stgraber> infinity: finally managed to get a succesful build: https://www.stgraber.org/download/d-i/current/images/generic/
[20:44] <stgraber> infinity: would be nice if you could test those .img.gz on your beagle and panda
[20:46] <infinity> stgraber: Is that beagle image really xM-only?
[20:46] <stgraber> infinity: the only dtb we have in our package says beagleboard-xm
[20:46] <infinity> stgraber: Our current omap3 images boot on a few beagle models (and the one I have is an old c3)
[20:47] <infinity> Of course, this could be a lie, and maybe our current omap3 images don't boot at all. ;)
[20:47] <infinity> I'll try to test later today.
[20:47] <stgraber> it very well could be that the xm dtb works fine on older models too, I try to keep the name in the d-i build in sync with the dtb though
[20:48] <stgraber> hmm, looking at the result in my browser now, I think I'll move vmlinuz and initrd.gz to a "standalone" directory (better names are welcome) should be slightly less confusing to someone who doesn't know how things work on arm
[20:49] <infinity> stgraber: Except that a ton of people rely on that structure. ;)
[20:49] <infinity> (I don't mind breaking Panda, I do mind breaking production highbank setups)
[20:50] <stgraber> infinity: well, I kinda broke the structure already when I dropped netboot/ from the path ;)
[20:51] <stgraber> infinity: hmm, I guess I could keep vmlinuz and initrd.gz in netboot/ and dump the rest into a new board/ directory maybe?
[20:51] <stgraber> that way URLs for highbank should still work
[20:51] <infinity> Oh, you dropped netboot?  I didn't notice the path mangling...
[20:51] <infinity> No netboot, cdrom, etc...
[20:52] <stgraber> yeah, I dropped that level, but I'll re-introduce it now so that the path to vmlinuz and initrd.gz stays the same
[20:52] <infinity> stgraber: Well, and you can't just drop the cdrom images... We use those.
[20:52] <infinity> And they're different from the netboot ones.
[20:52] <infinity> (Well, the initrd is)
[20:54] <stgraber> infinity: what's using the cdrom ones? (not that I mind re-introducing them, I just couldn't think of anywhere we were actually using those)
[20:55] <infinity> stgraber: We still produce server CDs for omap* (though, maybe we should stop).
[20:55] <infinity> stgraber: But they're also convenient for someone else who wants to do the same.
[20:55] <mdeslaur> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[21:01] <stgraber> infinity: building d-i again with cdrom builds back on, and the fs structure tweaked to be more conventional with the board images under netboot-boards (which should be clear enough that those are netboot images for particular boards)
[21:04] <dobey> anyone know a good way to flash an ubuntu iso to a usb flash drive, in 13.10 that has udisks which apparently casuses usb-creator-gtk to segfault?
[21:04] <mdeslaur> dobey: you can just use dd
[21:04] <infinity> dobey: dd
[21:05] <dobey> dd if=foo.iso of=/dev/sdg ?
[21:05] <mdeslaur> dobey: yep
[21:05] <infinity> dobey: Yeah.  And add a bs=4M or so, if you don't want it to take a year.
[21:17] <dobey> thanks, that did work
[21:36] <stgraber> infinity: new proposed structure: https://www.stgraber.org/download/d-i/current/images/generic/
=== _salem is now known as salem_
[21:50] <Noskcaj> pitti, Is there any chance i could get a testimonial for MOTU from you? https://wiki.ubuntu.com/Noskcaj/MOTU
[21:50] <Noskcaj> (I'm not actually applying till next month, but i'll try and get the testimonials now
[21:54] <ari-tczew> can you log-in on wiki.ubuntu.com ?
[21:59] <Noskcaj> ari-tczew, The page isn't loading, but i think that's just my internet crashing
[21:59] <Noskcaj> works fine, internet fixed
[22:00]  * ari-tczew sees Please contact the server administrator, webmaster@ubuntu.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
=== vibhav is now known as Guest51956
[22:28] <melodie> hello
[22:29] <melodie> I have been told that the build method for the isos would have been changed for the Saucy version. If this is right, is there any available doc about it somewhere?
[22:30] <slangasek> melodie: it hasn't; there was a rewrite to the tools, but that was a couple of cycles ago already, and available at lp:ubuntu-cdimage
[22:31] <melodie> thanks slangasek
=== freeflying_away is now known as freeflying
=== freeflying is now known as freeflying_away
=== salem_ is now known as _salem