[00:08] zyga: barry: what's the status on pyotherside? =) I'd like to port usb-creator and ubiquity to qt5, and i think pyotherside is the way of the future =) [00:08] zyga: barry: also that should pull in qt stuff into main ;-) [00:08] (well pyotherside) === _salem is now known as salem_ [01:27] bdmurray: done [01:31] xnox: you can play with it on a ppa [01:31] xnox: it's still in NEW in debian [01:31] xnox: I was playing with it on nexus 7 today, a bit slow so far [01:31] xnox: works okay on the desktop though [01:31] xnox: get the package and have a look at the examples [01:32] xnox: if you need armhf packages they are built in ppa:checkbox-dev/ppa [01:33] xnox: as for pulling into main, qt is in main already [01:33] xnox: so is python, only pyotherside isnt [01:36] xnox: depending on what you need to call from ubiquity and usb-creator you should have fairly easy access to anything visible from python (gi, dbus) [01:36] xnox: keep in mind though, that you can only return simple objects (think json) across the qml/python bridge [01:37] xnox: so you can list all partitions and keep a model in python (if needed) but you must dumb it down to a list of dicts of strings/ints/lists etc if you want to push it to qml [01:37] xnox: I think it generally works but needs consideration on how the app will work [01:39] Since ubiquity and usb-creator already use PyQt, seems like a lot of work. [01:40] ScottK: I think it depends on QML, if you want Qt5 -- fine, if you need to work in QML current bindings are a bit heavyweight and you need to rewrite the UI anyway [01:43] usb-creator-kde uses PyKDE4, so that'd be a tough one to support. [01:44] ScottK: pyotherside is remarkably tiny, that is a good thing to support [01:45] How do you do KDE bindings with it? [01:45] ScottK: well, it doesn't do anything related to KDE [01:46] ScottK: I meant in comparison to python + something-qt [01:46] So it's not helpful for at least one of the usb-creator front ends. [01:47] Also, does it provide a dbus mainloop? [01:47] You kind of need that for these apps too. [01:47] ScottK: from what I think so far you just use qt5 + python dbus loop (the one already packaged) [01:48] OK. [01:48] ScottK: the thing with pyotherside is that you don't block the UI no matter what happens in python [01:49] ScottK: python can be busy computing stuff/waiting for stuff and QML is not affected because all the requests are asynchronous [01:49] ScottK: it's kind of paiful at first but seems to work better than our C++ + QML approach earlier [01:49] ScottK: it's async gui which can receive callbacks from python, or send requests async to python. [01:50] Seems more interesting for new projects than porting existing stuff to Qt5. [01:50] ScottK: yeah, I think you are right [01:50] ScottK: if you need to jump from qt4 or gtk to QML+SDK then it makes sense IMHO [01:50] ScottK: currently we have a lot of glue code in the backend which does "display this" "query that", which tries to be "toolkit" agnostic, but really isn't. [01:50] xnox: :-) [01:51] xnox: do you want it to work on the phone/tablet or just on the desktop? [01:51] ScottK: i'd rather have "oh i'm shiny ui", "oh backend told me to display 10 usb disks in a list", "oh user made all of it's selections lets shove it into backend", "oh backend didn't like it" [01:52] or "oh backend says we are 20% done" [01:52] zyga: i want to have as little gui code in my backends as possible & I must send / communicate with UI in async manner. [01:52] I wonder when we have bindings for KF5 if this'll be easy using bits of it. [01:53] xnox: so I think this will just work for you [01:53] xnox: we're in the same situation with checkbox [01:53] ScottK: KF5? [01:53] ScottK: so far pyotherside looks like the best model-view-controller separation that i can find. [01:54] KDE Frameworks 5, the Qt5 based replacement for KDE libs. [01:54] ah [01:54] ScottK: where models are in python, yet view/controller is in qml/qt/gui [01:54] Instead of one big library, it's (IIRC) 61 so it doesn't have to be heavy. [01:55] xnox: Do you know where we are on Qt 5.3? [01:55] Looks like the new plasma will need 5.3. [01:55] ScottK: does that double the number of kde* packages in the archive? or even tripple it? [01:55] Not even. [01:55] ScottK: i'm not that much involved in qt packaging. Send email to ubuntu-devel? [01:56] ScottK: well i guess you're keeping qt4 ones for now as well. [01:56] On my list. I just thought you might know. [01:56] Yes. For 14.10 we'll release a Qt4/KDE4 based desktop. [01:56] ScottK: busy working on upstart/python2-removals mostly. [01:56] We want all of KF5 in the archive though so it's available for developers. [01:57] Not sure if plasma 2 will make it in the archive or not, but we'll definitely make it available somewhere so we want 5.3 if we can get it. [02:00] bdmurray, is there a way to generate the errors.ubuntu.com graph as far back as we have data? [02:02] robert_ancell: if i remember correctly all data is not in one place. at one point cassandra fell over it's head and data was archived elsewhere, and then a new cassandra got brought up to deal with fresh data. [02:02] xnox, oh so the graph (which seems to show ~1 year of data?) is all the "new data" only? [02:02] robert_ancell: it's highly inaccurate though. It counts total amount of users using heuristics of unique count of machines submitted any reports over a period of past X days. [02:03] xnox, I was wondering why it all converges like crazy on the left - I wonder if that is a side effect of the heuristic [02:03] robert_ancell: and then counts a rate of errors within that pool. which clearly is bogus during a surge of machines, aka release date. [02:04] ... or like inception of the data base =) [02:04] ha! [02:05] i think it was also up for a couple of days, then down for a few and up again. making the beginning of the graph look crazy =) [02:06] robert_ancell: login on the top right and look at https://errors.ubuntu.com/ops/instances/ [02:07] xnox, whats the y-axis there? [02:07] robert_ancell: it tells the tale that everyone uses LTS and upgrades to next LTS. [02:08] robert_ancell: and !lts migrate to next release swiftly see 13.10 release date. [02:08] robert_ancell: in my high scool that graph would get zero marks, because units are not specified. [02:08] I think any school would do that [02:09] robert_ancell: so i guess this is calculating Ingress Mind Units per ubuntu release over time =) [02:09] I wonder if this is absolute number of reports? [02:11] robert_ancell: or maybe unique machines making a report? [02:11] It does seem like a more useful graph than the first one [02:11] robert_ancell: not sure which of the two is worse: only 100k of crash reports, or only 100k of users reporting. [02:12] robert_ancell: this one is raw data, the other one applies a lot of math to answer the question "Is this release more stable than the other one" === salem_ is now known as _salem [02:13] robert_ancell: the most useful bit however is, that we track SRU regressions via errors histograms per package/version combos. And we phase the SRU updates, thus broken SRUs get detected quickly and pulled (set phasing to zero -> update manager doesn't upgrade it) [02:13] the latter graph suggests 75% of 13.10 users have migrated in a month which is pretty impressive [02:14] robert_ancell: well they get notification to upgrade. Average time for SRU update is ~2 weeks. (you can see drop-off in crash reports on a given bucket/bug) [02:15] robert_ancell: so a month for a "i will need to download this for a long time" sounds awesome =) [02:15] I seem to recall that -updates gets suggested weekly, while -security is suggested daily; is that correct? [02:15] yeah, I'd have expected people to be a lot more conservative. I guess the 13.10ers are all developers and willing to do the upgrade [02:15] sarnold: sounds about right. [02:16] sarnold: oh, in that case 1w to update is near-instant =) as in when offered. [02:16] sarnold: i wonder if we should change that to daily though. [02:16] developers or technically minded users [02:16] xnox: yeah, and 2w is "oh it bugged me once already I should do that" :) [02:16] sarnold: because only ~10% will get the update offered on day one anyway. [02:17] xnox: I'm mindful of the complaints I've heard about firefox/thunderbird "gee another update already??" -- but we do security updates nearly every MTWT, we're probably already giving that feeling.. [02:32] Hi all [02:33] I compiled wu-ftpd but is not accepting connection [02:37] mun24: I'm headed out but three thoughts: (a) ftp is a horrible protocol, please don't use it unless you have to (b) check firewalling, iptables -L or ufw.. (c) check netstat -anp to make sure it's listening on the ports and IPs you expect [02:39] (d) if you're going to run an ftp server, why would you not run one that's been updated in the past decade with at least some attempt at security [02:39] that is for minternal purpose [02:39] internal [02:39] I want to do high speed upload. I already wrote a windows client for it [02:40] but experiencing some problem so want to troubleshoot [02:40] well, this isn't really the channel for that [02:41] I just want to understand how to install wu-ftpd server after compiling it [02:43] there are plenty of ftp servers in the archive that you could install and run; if you choose not to use them and compile a different one for yourself, you're not going to find support for it on this channel [03:39] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === thegatta_ is now known as thegattaca === micahg_ is now known as micahg [04:41] Good morning [06:47] good morning [06:57] good morning dholbach [07:00] hi Riddell [07:28] cjwatson, infinity: ah, FYI, jibel is on holiday today, so the britney fix will have to wait until Monday [07:29] pitti: all those frenchies… [08:28] dpm: it seems I finally managed to put out all the fires in http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/, so I'll get to your langpack mail ASAP [08:28] awesome, thanks pitti! [08:29] and I officially hate 9p now :) === oSoMoN_ is now known as oSoMoN [08:47] hi happyaron, so regarding your e-mail, would you recommend to test "Droid sans fallback" in the touch images for Simplified Chinese? Do you happen to know how to set the default font? [08:48] dpm: I don't know about touch, but for desktop version it's set by language-selector [08:49] yeah, I don't know if we can use the same, we'd probably have to put the image in RW mode [08:49] pitti, if we'd want to test different fonts for Simplified Chinese on the phone images, would you happen to know how to switch fonts? Or do you know who to best ask? [08:54] dpm: I only have a very vague idea about how fonts are selected; I think font packages ship some fontconfig snippets whcih define a font selection priority for glyph ranges [08:54] pitti: hm, ok, thanks [08:55] dpm: so that e. g. a font optimized for Korean could mark the Korean-specific glyphs as preferred, but leave latin or math chars to other fonts [08:56] dpm: so for switching fonts you'd have to edit those [08:56] dpm: but I'm afraid the above already exhausts my fontconfig knowledge [08:57] pitti, that's definitely much more than I knew, so thanks :) [08:57] dpm: GunnarHj might have an idea [08:57] dpm: I don't think he's an "expert" either, but at least he recently fixed a couple of bugs in that area [08:57] ok, cool [09:03] mardy: not sure if you saw it or not, but I replied on https://bugs.launchpad.net/ubuntu/+source/signon-plugin-oauth2/+bug/1316021 that your signon-plugin-oauth2 fix solved the problem for me [09:03] Launchpad bug 1316021 in signon-plugin-oauth2 (Ubuntu) "OAuth2 Tokens from providers that don't provide an expiry date are incorrectly expired on first use" [Undecided,Confirmed] [09:06] cjwatson: do you know why we have ubuntu-touch.utopic seeds, but the packages (e. g. unity8 or indicator-bluetooth) don't have a corresponding Task: ? [09:20] pitti: We only generate tasks for a subset of seeds; the ubuntu-touch seeds are only used to generate metapackages [09:21] pitti: A seed only gets a corresponding task if it has some Task-* headers [09:22] Oh, ubuntu-touch does have Task-* headers, now that I look [09:23] pitti: In that case it's because ubuntu-touch isn't listed in FLAVOURS in cronscripts/publishing/cron.germinate in Launchpad [09:23] pitti: I'd probably only fix this if the touch people actually want tasks for some reason [09:24] cjwatson: I was looking at that as dpm asked me about options for generating touch langpacsk [09:24] cjwatson: so I'm looking for way to tell "is package X on touch" [09:25] and I first looked at Tasks: and then at http://people.canonical.com/~ubuntu-archive/germinate-output/ [09:25] cjwatson: ubuntu-touch depends: helps quite a bit indeed, but doesn't get us dependencies; but I suppose langpack-o-matic could just run germinate by itself for that? [09:26] i. e. check out lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.$RELEASE, run germinate, use the result as a package list to match against? [09:26] cjwatson, are the task headers not needed for proper germinate output ? [09:26] I thought the Tasks: headers come *from* the germinate output? [09:26] pitti is correct [09:26] ah, k [09:27] pitti: So, I mean, I could if it would be useful to you, certainly [09:27] I just didn't want to bother if it was only for consistency or something [09:27] pitti, important thing: touch uses no-install-recommends ... [09:27] cjwatson: if it's possible that langpack-o-matic runs germinate by itself, that's fine by me (certainly much cheaper to only do that once a month or so and without adding to the size of Packages.gz) [09:28] pitti: You can certainly do that if you like [09:28] (but the germinate output reflects that since a few weeks) [09:28] ogra_: ah, good [09:29] ogra_: A bit more than that, I thought - didn't I fix that in r136, 2013-11-21? [09:29] * pitti RTFMs germinate to find out the invocation [09:29] cjwatson, only half of it ... xnox recently found that you need some "* ..." entry inside the seed file too, you added it to STRUCTURE back then [09:30] Oh, it actually looks like no-follow-recommends isn't honoured in STRUCTURE at all [09:30] cjwatson: i did add Feature: no-follow-recommends in e.g. r171 [09:30] xnox probably should have got me to fix germinate instead [09:31] PES uses the germinate file as input for their own git server (they branch all the trees of all touch packages) and that had a weird set of packages ... which made us look [09:31] jamesh: oh, I didn't see it! I'll try to get that merged soon, then [09:31] cjwatson: hm. I've inspected lubuntu seed (which did work as expected) and mimicked it. [09:31] So the seed change is an OK fix, but I'll fix germinate to honour the way I thought it worked when I made my change [09:31] mardy: thanks for doing the fix. [09:32] Hm, or maybe that would have bad effects on inner seeds inherited from platform [09:32] ogra_: hm, not their own git server. they branch bzr branches, and index them for search similar to e.g. opengrok but using some other indexer. aka similar to ubuntu-codesearch.surgut.co.uk but limited in scope with history. [09:32] Might need to think about that [09:32] xnox, oh, i thought it was a git server with a gerrit instance [09:33] ogra_: git + gerrit is used for e.g. android code hosting like https://code-review.phablet.ubuntu.com/#/q/status:open,n,z [09:33] yeah i know [09:33] ogra_: and the code search indexer will be public once it's hosted on prodstack. [09:34] not talking about our android trees ... i though that PES server was git too [09:34] thanks for clearifying :) [09:46] cjwatson: does that look like a reasonable invocation? germinate -v --bzr --no-installer -s ubuntu-touch.utopic -d utopic -a armhf -c main,universe -m http://ports.ubuntu.com/ [09:47] cjwatson: I'm just a bit unsure how to use the result; for example, the generated "touch" file does not contain most of the indicators which are in the seeds (like indicator-bluetooth); that one is in "all", but that also has firefox and lots of stuff which we don't need [09:47] cjwatson: so "touch" plus "sdk-libs" looks reasonable, does that sound right? [09:48] $ seeded-in-ubuntu indicator-bluetooth -> ubuntu-touch: daily-preinstalled [09:48] pitti: so somehow at least generators on ubuntuwire figure it out. [09:49] pitti: firefox is in, because i think its translations debs get pulled in via langpacks chain of dependencies. [09:50] pitti: Generally speaking you need to follow through the inheritance tree given in the "structure" output file [09:50] pitti: I'd recommend using --no-rdepends, since that makes a noticeable performance difference; --bzr is probably mostly unnecessary these days; and -v is likely to be very boring :-) [09:52] cjwatson: oh wow, it's really fast with --no-rdepends, thanks :) [09:52] xnox: seeded-in-ubuntu isn't a very useful comparison for this, I think, because AIUI it looks at image manifests [09:52] (Its name is a lie) [09:53] touch: minimal sdk-libs [09:53] pitti: ^- so that bit in structure tells you that the touch seed assumes that those other two seeds are already in place (and iterate) [09:54] cjwatson: ack; so if I expand this by hand, that would be touch plus sdk-libs plus minimal; and I ignore supported and -dev [09:54] Yeah, in general just ignore output files that aren't explicitly on your chain [09:54] Since there'll be a ton of random stuff [09:55] They're pretty much all used for *something somewhere*, but most consumers only need small bits [09:55] cjwatson: yeah, wrt. langpacks I think we can safely ignore -dev [09:55] I suspect so, yes [09:55] I'm mostly interested in the visible part of the images that we ship [09:56] I assume apps/clicks will continue to ship their own translations; I don't think it makes any sense to langpackify them [09:56] Right [09:56] and I'm not entirely sure yet whether and when we'll move to touch langpacks; this is mostly research for dpm and for discussion at this point [10:02] pitti, hopefully before release :) [10:29] thanks pitti [10:53] xnox: A few packages are dep-wait on the latest debhelper, and you're TIL; could you merge it? === MacSlow is now known as MacSlow|lunch [11:00] cjwatson ack. [11:00] also delta can become smaller, since we released lts. === aerocarbine is now known as aero === aero is now known as aerocarbine [11:22] ev_, bdmurray: Is there a reference anywhere for how a developer can report a RecoverableError? [11:28] tedg: ^ ? [11:28] tedg wrote a few... [11:37] slangasek: why do we _not_ call update-rc.d by default if both init.d & upstart jobs are present? [11:37] pitti: does systemd, for sysv init units, need update-rc.d call? (and thus symlinks in rc*.d dirs?) [11:39] xnox: yes, unless of course there's a real unit with the same name to replace it [11:39] pitti: thanks. [11:39] it keeps the sysvinit semantics (just starting everything would be wrong and too much) [11:40] pitti: =) so i guess debhelper in ubuntu, should start calling udpate-rc.d then =)))))) we have that conditional if [ ! -e /etc/init/$foo.conf ].... [11:41] xnox: ah, you mean for providing sysv fallbacks with systemd? yes, that sounds sensible [11:41] xnox: not sure why it didn't create symlinks, perhaps just for avoiding unnecessary work? [11:41] xnox: how does upstart run the sysv scripts, directly parsing LSB headers? [11:41] xnox: ah no, ignore that question, that was stupid [11:42] xnox: so yes, either extend the test to /etc/init/$foo.conf && /lib/systemd/system/$foo.service or, just call update-rc.d [11:42] we need update-rc.d for enabling systemd units too [11:46] pitti: i'm trying to recall, if things would break. On debian side, startpar et.al. are upstart aware and thus do not run symlinks from rx*.d directories if there is equivalent upstart job. [11:46] pitti: i'm not sure if that was done or not. [11:46] pitti: or depeneds on the merge of doom that didn't happen. [11:47] pitti: i think it's safer if i go with extending the check to "...and no unit file" [11:48] xnox: hm, I can't tell off the back of my head, but I think eventually we need to fix that anyway as names of units, jobs, and init.d scripts don't always match up [11:48] xnox: that would be the "service" script, right? [11:49] xnox: so our service script is already upstart aware, but not yet systemd (or openrc) aware, that's the current delta to -53 [11:49] (looking at my local merge) [11:50] and there is no delta to startpar? [11:51] xnox: there's quite a large one; startpar was split out into a separate package [11:51] which is stuck in -proposed until we merge [11:51] xnox: in our version it's a huge patch against sysvinit [11:51] I haven't checked the "net diff" between those [11:51] "net interdiff" i guess =)))) oh, my. [11:51] as I thought it's fairly uninteresting to us? [11:52] xnox: well, it's a native source package now [11:53] it's just e.g. if a job is stuck in waiting state (waiting for some event) i don't want runlevel 2 kick in and do service foo start, disrespecting (potentially extra) "start on..." conditions and thus starting a job pre-maturely. [11:54] i'll do this change separately rebuild at least rcS/rc0/rc6 jobs and make sure my desktop at least boots/shuts-down without problems. === _salem is now known as salem_ [12:06] diff -r -U4 sysvinit-2.88dsf/startpar/ startpar-0.59/ | diffstat is only 11 files changed, 116 insertions(+), 41 deletions(-) [12:06] pitti: so i wonder, if we can inspect that delta, and land split out startpar, on top of our sysvinit. [12:07] pitti: would that make future sysvinit merge smaller? === MacSlow|lunch is now known as MacSlow [12:10] pitti: the two are exact equivalents, sans refactoring and new one accepting options if it needs to be executed against /etc/init.d or /etc/rcX.d etc. [12:11] pitti: can i see your sysvinit merge somewhere? [12:11] xnox: startpar is already in utopic-proposed, and I uploaded our Ubuntu delta there [12:12] pitti: ah, cool. [12:12] xnox: http://people.canonical.com/~pitti/tmp/sysvinit_2.88dsf-53ubuntu1.dsc [12:12] xnox: NB that this currently moves to insserv, i. e. dynamic reordering of the [SK]NN levels [12:12] xnox: I didn't have time to continue working on this since I asked slangasek and you (and devel@) about insserv [12:13] xnox: so perhaps run it in a VM (although I've run it on my desktop for a week without any problems) [12:14] xnox: oh, and that one has "Drop startpar dependencies, we don't need that in Ubuntu where we only support upstart." → I'm not currently sure whether that's actually true, that point was on my TODO list [12:15] pitti: i guess in debian we do need upstart & upstart-core. [12:16] pitti: well, first we need to land "Remove various initscripts (and an ifupdown hook) that have been replaced by upstart jobs shipped in other packages." [12:16] as in, reinstate those init.d scripts, iff there is no systemd unit for them. [12:17] or they are needed for insserv to work. [12:17] xnox: mostly for the latter, yes [12:18] xnox: quickly running through them and seeing which we are missing [12:19] - /etc/init.d/motd [12:19] xnox: ^ yes, that's the only one [12:19] xnox: oh, and the ubuntu specific /etc/init.d/ondemand [12:20] xnox: seems we don't have an upstart job for that [12:21] funny, ha =) [12:26] pitti: in your test machines do you have /etc/init.d/.legacy-bootordering ? [12:26] (and new sysvinit) [12:27] xnox: I do, but I think with that merge this is ignored as that isn't supported any more [12:28] i. e. -53 only supports insserv now [12:28] xnox: and I think we still have some delta for this in the merge; but I kept it for now as I wasn't sure whether we go that route [12:28] it seems we agreed on "if we add back the important init.d scripts so that insserv gets things right, we use it", right? [12:29] cause conversion is suppose to run. [12:29] i'll revert that portion and thus trigger conversion to insserv with current sysvinit and check how far it would get me. [12:29] xnox: I'm not currently sure how to tell apart "good" from "bad" [12:30] i. e. what constitutes a broken ordering [12:31] pitti: (a) will sysv-rc succeed to configure and migrate to insserv (b) ability to boot, reboot, shutdown, halt, use single user mode. [12:31] the rest are bugs we would be able to sort out. [12:32] ah, that's simple enough [12:33] xnox: ah, warning, I don't think that merge adjusts the update-rc.d path to insserv for our changed location [12:34] xnox: it's pretty much an "in the middle of testing and see what's wrong" state, when I had to stop and put out fires :/ [12:34] xnox: I hope I can get back to it next week though [12:34] as with our current update-rc.d, many packages fail to upgrade/configure badly [12:34] (when running systemd) [12:38] i wonder what would happen if i execute all of: grep -A1 '! -e "/etc/init/' *.postinst | grep update-rc.d === oSoMoN__ is now known as oSoMoN === oSoMoN_ is now known as oSoMoN === wedgwood is now known as Guest40395 === wedgwood1 is now known as wedgwood [14:08] xnox: a while back you patched the reboot command in upstart to try and pass the REBOOTCOMMAND to the reboot syscall... it seems this patch introduced a bug #1174272, but I really wonder.. why did you do this? it looks like the kernel itnores the argument anyhow and sysvinit never bothered trying to pass it [14:08] bug 1174272 in upstart (Ubuntu) "'reboot now' reverting to maintenance mode" [Undecided,In progress] https://launchpad.net/bugs/1174272 [14:11] psusi, the phones (which are using an android bootloader and kernel source) need an arg handed over ... i.e. to boot into recovery mode [14:11] sudo reboot -f recovery ... sudo reboot -f bootloader ... etc [14:12] ahh [14:13] the bootloader picks it up and pre-fills bootreason= on the kernel cmdline ... the kernel then picks it up and boots to whatever is defined for a bootreason [14:13] ok... proposing branch merge now of a one line fix to correct the regression that caused [14:14] would have been nice to mention that in the changelog ;) [14:20] https://code.launchpad.net/~psusi/ubuntu/utopic/upstart/fix-reboot/+merge/218997 [14:20] psusi: this is wrong. [14:21] psusi: time option may not be passed to reboot command. [14:21] psusi: why do you expect that? [14:21] psusi: all of "reboot, halt, poweroff" do not take a time parameter. [14:22] psusi: "shutdown -r now" is to perform reboot with a time parapeter, aka emmidiately now. [14:22] xnox: I know that, but REBOOTCOMMAND is only supposed to be honored in conjunction with --force [14:22] otherwise it should be ignored [14:23] your patch to pass REBOOTCOMMAND with --force added a new mode enum, REBOOTFORCE, that caused the non --force path to forget to add the -r switch to the regular reboot command [14:23] psusi: looking. [14:23] psusi: but i have to. [14:23] fixing it is as simple as adding the new enum to the case statement and letting it fall into the old one ;) [14:25] psusi: -f bypasses invoking shutdown first, before doing reboot syscall. [14:25] psusi: the rebootcommand is always passed to the syscall. [14:26] right.. and without -f, we invoke shutdown... which should be with the -r switch, but your new REBOOTCOMMAND enum caused the -r to be dropped [14:26] the syscall is only invoked with --force, man page even explicitly says that without --force, shutdown is run *without* REBOOTCOMMAND [14:26] mpt: there is an issue with recoverable problems that needs to be addressed - bug 1316763 [14:26] bug 1316763 in Daisy "bucketing of recoverable problems is done poorly" [Undecided,New] https://launchpad.net/bugs/1316763 [14:27] which is true, it is run without rebootcommand, but also without -r, which is wrong [14:31] psusi: syscall is invoked, if one is in runlevel 0, 6, or --force was given. [14:31] xnox: right.. and otherwise shutdown is run... [14:31] psusi: remember that shutdown(8) -r eventually calls reboot. [14:31] the error is that shutdown is being run without the -r switch because of the new enum you added... so instead of rebooting, it goes ot single user mod [14:32] psusi: "reboot now" is not suppose to invoke "shutdown -r" [14:32] yes, it is [14:32] reboot is supposed to invoke shutdown -r... any argument following it is ignored [14:33] ( again, when not using --force or in runlevel 0 or 6 ) [14:34] in other words, reboot now, or reboot foo, or reboot whatever used to all work since the argument was completely ignored... as it is supposed to be according to the man page... after your patch, it has the side effect of dropping the -r switch to shutdown so instead of a reboot, you get single user mode [14:35] psusi: i still didn't get your argumentation. [14:35] psusi: i understand marga's comments though. [14:36] psusi: where she says it wouldn't be a bug if syscall with "now" arg would be executed =)))) [14:36] did you look at the actual patch yet? it's pretty clear when you look at the code ;) [14:36] * psusi waits to hear the sound of a facepalm [14:36] psusi: the patch is also wrong, not future proof, against wrong branch =) [14:36] psusi: http://paste.ubuntu.com/7421706/ ? [14:36] against the wrong branch? [14:37] ahh, that works too [14:38] psusi: yes, upstart is developed in lp:upstart. [14:38] psusi: the bug is that, we went down runlevel2 codepath. Valid modes in runlevel2 codepath are only those that it handles. [14:38] psusi: and as per manpage, REBOOTCOMMAND mode should only be valid when force is active. [14:39] right, that's what I've been saying... otherwise it's ignored ;) [14:39] psusi: and slitgthly above "force" is defined as --force or runlevel 0 or runlevel 6. [15:24] cjwatson: the grub ls command is built into the normal module and so should never need to load a module when run right? Or did this change in the latest grub? [15:25] this bug #1316068 is just weird... [15:25] bug 1316068 in grub2 (Ubuntu) "error: disk 'hd0,msdos5' not found" [Undecided,New] https://launchpad.net/bugs/1316068 [15:29] psusi: ls is a separate module [15:30] who is "owning" ubottu? can we get it in #ubuntu-desktop as well? ;-) [15:30] (we had an ubot but it went away recently) [15:31] psusi: but if grub has been improperly installed then it might need to load modules to read a given filesystem; anyway you seem to be on the right track with the info you're asking for there [15:31] psusi: could be a partition table parsing bug or something, hard to say as yet === darkbasic_ is now known as darkbasic === buxy_bak is now known as buxy === jasoncwarner___ is now known as jasoncwarner [16:41] https://bugs.launchpad.net/reminders-app/+bug/1317977 [16:41] Launchpad bug 1317977 in Ubuntu Reminders app "GPLv3 license terms violation" [High,Confirmed] === mbiebl_ is now known as mbiebl [16:48] xnox, should have posted that in #ubuntu-app-dev ... thats where the devs are [16:48] err [16:48] #ubuntu-app-devel [16:49] mhall119, ^^^ [16:50] ogra_: i'm actually not sure if that app is shipped. [16:50] ogra_: it's in ppa only? can't find it pre-installed, nor in the ubuntu archive. [16:50] ogra_: is it in the store? [16:50] xnox, it is pending, we are waiting for it to be switched to the actual server from the test server [16:50] was discussed over the last days in #ubuntu-touch [16:50] it is supposed to be preinstalled afaik [16:51] once it points to the right server so you dont need to use fake accounts [16:51] good catch btw === roadmr is now known as roadmr_afk [17:08] xnox: its in a ppa and in the click store [17:08] thanks xnox [17:08] xnox, if you tell us what we need to do to fix it, we can do it straight away [17:09] dpm: Adding an exception to your license is the quickest fix, and he copy-pastaed some boilerplate in the bug. [17:10] infinity, xnox, argh, sorry, I misread the bullet points [17:10] ok, will do that [17:16] cjwatson: ok, I thoguht it was part of the normal module... but here's what is so weird... if the normal module loaded, then it obviously managed to find /boot/grub... so now when it tries to load the ls module, how can it claim that it can't find the /boot partition? [17:17] Could be various reasons. Maybe it's not actually trying to find /boot, but /. [17:17] Or maybe the signed EFI image is in use in which case normal is built into the core image [17:18] Don't know really without that debugging output you asked for [17:23] since he's using an msdos partition table, that should preclude EFI as a possibility... [17:26] Probably, but you never know :) [17:26] Anyway, not enough information to say, but there are various possibilities [17:31] infinity, xnox, so essentially doing this for all source files should be enough? -> https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037 [17:42] hi tedg, so following up on the e-mail, can you help me setting up the translations exports for indicator-network? If you're happy with it, I'd like to wrap it up for the weekend and start testing the translations next week [17:42] tedg, It's just about going to https://translations.launchpad.net/indicator-network/14.04/+link-translations-branch and setting: [17:42] ~indicator-applet-developers/indicator-network/trunk.14.04 [17:42] dpm, That's probably not a good idea. [17:42] dpm, Indicator-network will be changing all it's translations shortly. [17:42] dpm, We should wait for the rewrite to land. [17:43] dpm, It's got a silo, but I don't think it's landed yet. There were some ppc64 issues. [17:44] tedg, can we set up LP at least, so that's already done? I can hide the translations if necessary, so that translators do not do any unnecessary work [17:47] dpm, Hmm, the new one doesn't have any translation files setup :-/ [17:48] ok, I think I'll call it a week then, we can follow up on Monday. For now, I'll disable translations in Launchpad [17:50] dpm, Yeah, I'll ping folks on that. Sorry :-/ [17:51] np, we'll follow up next week === roadmr_afk is now known as roadmr [18:04] hello there. Not sure if this is the right place to ask.. but I am an arch user (I left when unity came about.. guess you know those kind of stories ,p) but.. I see serge and graber? have dome great progress on the LXC part. Now, our kernel doesn't have user name spaces enabled but I have re-compiled that. We also have the nsexec bazaar version we can pull. But regarding newuidmap and the patched shadow, package.. I was wondering if someone here cou [18:04] ld point out what I might need ot do to have the right patches for this? we use systemd and you have upstart or sysv still, right? Any tips or perhaps a repo I can find the patches I would need to work with ? [18:56] Few days ago with some difficulty was able to download nautilus via bzr, and make a silly change to the code (duplicated the forward button for test) and got it running in my machine via dpkg -i [18:56] To do so I had to make a patch via quilt for the change I made. [18:56] The build tools seemed to mandate the patch. [18:57] Is there a very simple way to make changes to the source code, build them to a .deb and install and avoid the need for the patch. (This is only for my own use after all) [20:01] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray === salem_ is now known as _salem [20:55] slangasek: I've seen two sponsorship requests for SRUs for package description typos. Is there some reason to SRU those? [20:55] bdmurray: I ... would not think so [20:56] I wasn't sure if I missed some memo [20:56] bdmurray: if the packages were being SRUed for some other reason, that seems ok to include, but certainly doesn't justify an update per se [20:56] that was my thought too [21:28] can i get someone to approve the ubuntuone-client and ubuntuone-storage-protocol packages in the proposed queues for saucy and precise please? [21:42] slangasek: ^^ pretty please? :) [23:18] dobey: you mean the ubuntuone-storage-protocol upload for bug #1307549, which has an unanswered question from me asking for a proper test case? [23:18] bug 1307549 in ubuntuone-storage-protocol (Ubuntu Saucy) "Should load all available CA Certificates and not just the u1 bundled/shipped ones" [Critical,In progress] https://launchpad.net/bugs/1307549 [23:28] infinity: Do you have any objection in principle (I haven't tested it yet, won't for a day or two) to http://paste.ubuntu.com/7425787/ in livecd-rootfs and http://paste.ubuntu.com/7425798/ in launchpad-buildd? It'd be awfully convenient to be able to pass arbitrary extra arguments to "lb config", particularly --apt-http-proxy. [23:29] (For local testing, in the case of that example) [23:30] cjwatson: Nope, no arguments conceptually, though it could mean we need some strict input validation if we intend to pass that all the way back to the API. [23:30] Do we, since the LP master basically owns buildds? [23:31] cjwatson: I guess it depends on who has the rights to make the API calls. [23:31] cjwatson: If that's a strict and trusted subset anyway, then I guess we can throw whatever garbage we want at it and get to keep both pieces. [23:31] ~launchpad-livefs-builders gets to create new LiveFS rows; the owner of a given LiveFS gets to edit it. [23:32] And vaguely similarly for builds of a given LiveFS. [23:32] I think, though, that code is actually reasonably safe to the extent that it doesn't let you append random shell metacharacters and such [23:32] cjwatson: I could forsee this being problematic in a future where PPA owners could set up custom builds, maybe. Though, I guess they can also upload a livecd-rootfs that does Stupid Things too, so maybe I'm overthinking it, and the potential for explosion is already there. [23:33] Right, anyone who can do this can already own a build chroot in a myriad other ways. [23:33] And so long as we don't let the Stupid escape the chroots and clean up sanely afterward, then meh. [23:34]